---

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'." metadata: category: "WP-49 區塊鏈演算法" tags: ["blockchain", "distributed-ledger", "consensus", "cryptography"]

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

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