# Blockchain Here's the problem this whole field grew out of: you have ten thousand machines, run by strangers with conflicting interests, and you need them to agree on a single shared history — with no coordinator, no admin, and no one you can call when it breaks. Everything in this vault is a piece of the answer, and the pieces fit together better than you might expect. ## The one sentence If you keep a single idea in your pocket while reading, make it this one: > A blockchain is a replicated state machine where correctness comes from cryptographic verification, economic incentives, and a consensus rule for ordering state transitions. Whenever a concept feels confusing, come back and ask which part of that sentence it serves. It usually snaps into place. [[01 Replicated State Machines]] sharpens the same idea as a through-line: one machine, then cooperative replicas, then open adversaries — all converting concurrent proposed transitions into one canonical replayable log under weaker and weaker trust. ## Who this is for This is a **systems engineer's primer** — written for people who already know databases, logs, replicas, or backend architecture, and who want blockchain treated as adversarial state-machine replication rather than as coins or hype. If MVCC, WALs, and Raft are familiar friends, you are in the right place. If you want a non-technical product survey or an investor brief, this vault will feel dense early; that is intentional positioning, not a flaw in you. **Scope bias, stated plainly.** Modules 01–04 use Bitcoin as the minimal base case (ordered history, proof-of-work, double-spend). From Module 05 onward the center of gravity is **Ethereum-like programmable blockchains**: accounts, EVM, tokens, rollups, wallets, DeFi. Other designs — UTXO-only depth, Solana, Cosmos, Move-based chains, privacy chains, permissioned ledgers — appear as contrasts, not coverage targets. When the text says "blockchain," check whether it means the abstract machine or the Ethereum-shaped one. ## Why anyone pays for this painful machine Postgres, Stripe, and a bank are usually cheaper, faster, and easier. People still use public chains when the alternative is trusting an operator they cannot constrain: self-custody without a custodian's balance sheet, censorship resistance for settlement, global permissionless composition of financial programs, and *credible neutrality* — rules that are hard for any one party to rewrite mid-game. Speculation and capital formation ride along; they are real drivers, not side notes. The same stack that enables those properties is terrible for ordinary CRUD. The judgment rule is later under "When not to use a blockchain." Custody failures (FTX, Celsius, and company) are the contrast case: the protocol may have been fine while users trusted a centralized balance sheet instead of verifying or holding keys. ## The eight questions And when you meet a new protocol — any protocol — it helps to notice that each one is really just a different set of answers to the same eight questions: 1. Who orders transactions? 2. Who verifies execution? 3. Who stores data? 4. Who pays? 5. Who can cheat? 6. Who notices? 7. Who can recover? 8. What does the user have to trust? Cheapest UX usually means a lower row on the [[Trust Assumptions]] spectrum — full node at the top, light client, proofs, watchers, committees, then RPC/CEX at the bottom. Name the row before you ship. ## When not to use a blockchain Use the cheaper tool when its trust model is enough: | **Situation** | **Use** | |---|---| | You have a trusted operator | A normal database | | You only need tamper *evidence* | Signatures and audit logs | | Participants are cooperative | Raft / a replicated database | | You need planetary agreement among adversaries | A public chain — and accept the cost | | Ordinary create/read/update/delete | Do **not** buy global consensus | Public chains are for when removing or constraining the operator is worth latency, fees, reorg risk, and operational pain. If that sentence does not apply, stop here and keep Postgres. ## The minimum mental model A blockchain is usually four protocols glued together: | **Layer** | **Question it answers** | |---|---| | **Networking** | How do nodes gossip transactions and blocks? | | **Consensus** | Which block/history is canonical? | | **Execution** | Given a block, how does the state change? | | **Data availability** | Can validators/users actually obtain the data needed to verify the state? | Bitcoin fuses these into one simple chain. Ethereum separates them more clearly, especially after proof-of-stake and rollups — and the industry keeps pulling them further apart. Watching that separation happen is, in a real sense, the story of the last decade. ## The path If you want the guided route, start at [[Learning path]] — it sequences everything below into five phases with checkpoints. Or wander the modules directly: ```mermaid graph TD M01[01 Replicated State Machines] M02[02 Cryptographic Primitives] M03[03 Blocks, Hashes, and History] M04[04 Consensus] M05[05 Execution and Smart Contracts] M06[06 Transaction Lifecycle and MEV] M07[07 Wallets and Account Abstraction] M08[08 Nodes, RPCs, and Indexers] M09[09 Scaling - Rollups and Data Availability] M10[10 Bridges and Interoperability] M11[11 DeFi, Stablecoins, and Governance] M12[12 Security and Incentive Design] M01 --> M02 --> M03 --> M04 --> M05 --> M06 M06 --> M07 --> M08 M04 --> M09 M08 --> M09 --> M10 M05 --> M11 M10 --> M12 M11 --> M12 ``` ### Modules 1. [[01 Replicated State Machines]] — what problem is this actually solving? 2. [[02 Cryptographic Primitives]] — what tools make trustless verification possible? 3. [[03 Blocks, Hashes, and History]] — how is history made tamper-evident? 4. [[04 Consensus]] — who decides which block comes next? 5. [[05 Execution and Smart Contracts]] — given a block, how does state change? 6. [[06 Transaction Lifecycle and MEV]] — what happens between "send" and "confirmed"? 7. [[07 Wallets and Account Abstraction]] — who holds the keys, and what can they do? 8. [[08 Nodes, RPCs, and Indexers]] — what infrastructure actually runs this? 9. [[09 Scaling - Rollups and Data Availability]] — how does the machine grow? 10. [[10 Bridges and Interoperability]] — how do separate machines talk? 11. [[11 DeFi, Stablecoins, and Governance]] — what runs on top? 12. [[12 Security and Incentive Design]] — how does it all break? ### Concepts Cross-cutting ideas that many modules lean on. Each answers one question. - [[Finality]] — when can I treat this as irreversible? - [[Gas and Blockspace]] — what is the scarce resource, and how is it priced? - [[Reorgs]] — what happens when history changes? - [[Merkle Trees]] — how do you prove inclusion without showing everything? - [[Data Availability]] — was the data actually published? - [[MEV]] — what happens when transaction ordering becomes a market? - [[UTXO vs Account Model]] — what shape does state take? - [[Trust Assumptions]] — what, exactly, am I trusting? - [[Distributed Systems Bridges]] — FLP, Byzantine bounds, fork choice vs finality, and other DS ideas blockchains reuse ### Applied - [[Projects to Build]] — internalize by building. - [[Wallet Infrastructure Roles (Privy)]] — the boundary between protocols and product. ### Reference - [[Learning path]] — the ordered journey, with checkpoints. - [[Resources]] — annotated reading list, mapped to modules.