| name | "algo-blockchain-basics" |
| description | "Explain blockchain fundamentals including distributed ledger architecture, consensus mechanisms, and block structure. Use this skill when the user needs to understand blockchain concepts, evaluate whether blockchain fits a use case, or design a blockchain-based solution — even if they say 'how does blockchain work', 'do I need blockchain', or 'distributed ledger'.". |
| allowed-tools | Read, Glob, Grep |
Blockchain Fundamentals
Overview
A blockchain is a distributed, append-only ledger where blocks of transactions are cryptographically linked. Each block contains: transactions, previous block hash, timestamp, and nonce. Consensus mechanisms (PoW, PoS, BFT) ensure agreement without a central authority. Trade-off: decentralization vs performance.
When to Use
Trigger conditions:
- Evaluating whether blockchain is appropriate for a use case
- Designing systems requiring distributed trust, immutability, or transparency
- Understanding blockchain architecture for integration or development
When NOT to use:
- When a trusted central authority exists and works well (use a database)
- When performance (thousands of TPS) is the primary requirement
- When data privacy requires deletion capability (blockchain is append-only)
Algorithm
IRON LAW: Blockchain Is Useful ONLY When You Need TRUSTLESS Consensus
If participants trust each other (or trust a central authority), a
traditional database is faster, cheaper, and simpler. Blockchain's
value proposition is: untrusted parties can agree on state without
an intermediary. If trust already exists, blockchain adds overhead
with no benefit. Ask: "Who doesn't trust whom?" before choosing blockchain.
Phase 1: Input Validation
Assess use case against blockchain decision criteria: multiple untrusting writers? Need for immutability? No trusted central party? Public verifiability required?
Gate: At least 3 of 4 criteria met to justify blockchain.
Phase 2: Core Algorithm
Block structure:
- Transactions are grouped into blocks
- Each block header contains: previous hash, Merkle root of transactions, timestamp, nonce
- Hash of block header links it to previous block (chain)
- Modifying any past block invalidates all subsequent hashes
Consensus mechanisms:
- PoW (Proof of Work): miners compete to solve hash puzzle. Energy-intensive, secure.
- PoS (Proof of Stake): validators stake tokens. Energy-efficient, relies on economic incentives.
- BFT (Byzantine Fault Tolerance): voting-based, fast finality, requires known validator set.
Phase 3: Verification
Check: is the use case genuinely multi-party with trust deficits? Would a simpler solution (shared database, digital signatures) suffice?
Gate: Blockchain justified, appropriate consensus mechanism selected.
Phase 4: Output
Return architecture recommendation with trade-off analysis.
Output Format
{
"recommendation": {"use_blockchain": true, "type": "permissioned", "consensus": "PBFT", "platform": "Hyperledger Fabric"},
"trade_offs": {"decentralization": "medium", "throughput_tps": 3000, "finality_seconds": 2, "energy": "low"},
"metadata": {"use_case": "supply chain provenance", "participants": 5, "trust_level": "low"}
}
Examples
Sample I/O
Input: 5 companies tracking seafood provenance from boat to restaurant
Expected: Permissioned blockchain recommended (known participants, no trust, need immutable audit trail). Platform: Hyperledger Fabric or similar.
Edge Cases
| Input | Expected | Why |
|---|
| Single company internal use | Don't use blockchain | Trust already exists internally |
| Need to delete data (GDPR) | Blockchain problematic | Immutability conflicts with right to erasure |
| Public transparency required | Public/consortium chain | Permissionless or hybrid |
Gotchas
- Blockchain ≠ cryptocurrency: Blockchain is the technology; cryptocurrency is one application. Many blockchain use cases have nothing to do with tokens.
- Immutability is a spectrum: "Permissioned" blockchains can be rewritten by consortium agreement. True immutability only exists in large public chains.
- Oracle problem: Blockchain guarantees integrity of data ON the chain. It cannot guarantee the accuracy of data ENTERING the chain from the real world. Garbage in = immutable garbage.
- Scalability trilemma: Decentralization, security, scalability — pick two. No blockchain optimizes all three simultaneously.
- Regulatory uncertainty: Legal status of blockchain records, smart contracts, and tokens varies by jurisdiction. Consult legal before production deployment.
References
- For consensus mechanism comparison, see
references/consensus-comparison.md
- For blockchain decision framework, see
references/decision-framework.md
