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'.
Scanned 9/6/2026
Install to Claude Code
npx -y skills add charlieviettq/awesome-agent-skill --skill algo-blockchain-basics --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Algo Blockchain Basics?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/charlieviettq-algo-blockchain-basics-awesome-agent-skill)More formats (shields.io, HTML) on the badges page.
---
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
```json
{
"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`
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!