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:

1. Transactions are grouped into blocks
2. Each block header contains: previous hash, Merkle root of transactions, timestamp, nonce
3. Hash of block header links it to previous block (chain)
4. 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

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