Blockchain Security Fundamentals
What to Know
Start with the CIA triad applied to distributed ledgers. Confidentiality is unusual on public chains because state is replicated to every node; privacy therefore depends on cryptographic commitments, zero-knowledge proofs, and off-chain storage. Integrity rests on hash-linked blocks and consensus finality. Availability depends on node distribution, but also on smart-contract invariants and key custody.
Understand security boundaries: the protocol layer (consensus, P2P, mempool), the application layer (smart contracts, wallets, oracles), and the operational layer (key management, node hardening, governance). Most exam traps blur these layers. A question describing a reentrancy loss is an application-layer defect, not a consensus failure, even if the chain "confirmed" the transaction.
Know immutability's dual edge. Tamper-evidence is a strength; irreversibility of harmful transactions is a weakness. Recovery usually requires governance action (fork, pause, migration) rather than rollback. Also distinguish pseudonymity from anonymity: addresses are linkable through transaction-graph analysis.
Traps
- Equating "decentralized" with "secure"; decentralization affects censorship resistance and trust assumptions, not code correctness.
- Assuming encryption on-chain provides confidentiality; on-chain ciphertext is public and durable.
- Treating a confirmed transaction as authorized; confirmation proves inclusion, not intent.
Rule of Thumb
Ask which layer owns the failure and who holds the trust assumption. If the answer is "the contract code" or "the key holder," it is not a protocol-level break. Worked example: a bridge drained because a validator threshold was met with compromised keys is a key-management and governance failure, not a cryptography break.
Study Focus
Map each control to a threat: multisig and HSMs to key compromise, formal verification and audits to logic flaws, rate limits and circuit breakers to availability, and monitoring to detection latency.