--- # System prepended metadata title: Ethereum Consensus from Scratch --- # Ethereum Consensus from Scratch ### Everything You Need Before Reading Post-Quantum Research --- There's a specific frustration that hits when you start reading Ethereum research. The writing is clear. The vocabulary is precise. Every sentence parses. And yet at the end of a paragraph, you couldn't tell someone what you just read. Here's a real example, from a recent paper on Lean Consensus: > By reducing slot time from 12 seconds to 4 seconds and targeting single-slot finality, Lean Consensus leaves dramatically less time for signature propagation and proof generation. Thirty thousand XMSS signatures cannot be broadcast naively. Instead, a SNARK proof attests that all signatures verified correctly, without publishing the signatures themselves. That's not a failure of attention. It's that the author, reasonably, assumes you already speak the language. Slots, finality, signature propagation, aggregation, the number 30,000. None of it is defined because it doesn't need to be defined for the audience the author had in mind. The vocabulary is invisible. This article makes it visible. By the end, you'll re-read the paragraph above and parse it without thinking. You won't be a researcher, but you'll have the foundation researchers assume you already have. We'll get there by following a single transaction from the moment it leaves a user's wallet to the moment the block containing it becomes permanent. Every concept shows up in that journey, in the order it actually matters. Two upfront notes. This describes Ethereum's consensus layer as it works today, post-Merge. I'll flag where I'm simplifying so you know what to dig into later. I'll also be using terms like "validator" and "node" before defining them. Trust that they'll click as we go. --- ## The two layers One orientation point before the story starts: Ethereum is two systems, not one. The **execution layer** is what most people picture. It runs transactions, executes smart contracts, holds account balances. When you use MetaMask, you're talking to the execution layer. The **consensus layer** is responsible for keeping thousands of computers around the world in sync about the current state of the chain: which block is the latest one, which fork to follow, and which history becomes permanent. It runs Proof of Stake. It doesn't care what's inside the transactions. It just orders the blocks and decides which ones are official. Since The Merge in September 2022, both layers run side by side. A typical Ethereum node runs two pieces of software, an execution client (Geth, Reth) and a consensus client (Lighthouse, Teku, Prysm, Nimbus), talking to each other through a defined interface. Everything in this article lives on the consensus side. The execution layer barely matters for our story. Keep that distinction in mind. --- ## The clock Ethereum has a coordination problem. Millions of validators around the world need to agree on: * when blocks can be proposed * who is allowed to propose them * when voting starts * when voting ends And they need to do this without a central coordinator. Ethereum solves this with a shared global clock. Time is divided into **slots**, each exactly 12 seconds long. In every slot, the protocol allows at most one new block. Slots are grouped into **epochs** of 32 slots each, making an epoch 6.4 minutes long. Every validator, node, and client agrees on the current slot number and exactly when that slot began. Slot numbers started at genesis in December 2020 and increase forever without resetting. This matters because the protocol can schedule work ahead of time. Instead of validators negotiating in real time, everyone already knows the schedule: * validator X proposes during slot N * committee Y votes during slot M No messages are needed to coordinate this. Everyone simply looks at the clock. That shared timing becomes even more important later when we talk about post-quantum signatures. Slot numbers are globally unique and never reused, which turns out to solve a surprisingly difficult cryptographic problem. --- ## Step 1: A transaction enters the mempool The story starts with a user who wants to send some ETH. In their wallet, they construct a transaction (sender, recipient, amount, gas fee) and sign it with their private key. The wallet broadcasts the signed transaction to an Ethereum **node**: any computer running Ethereum software. There are tens of thousands of these nodes scattered around the world, run by individuals, companies, and infrastructure providers. The node checks the transaction. Is the signature real? Does the sender's account exist and have enough funds? Is the gas fee reasonable? If anything looks wrong, the transaction is dropped on the floor. If it checks out, the node adds it to its **mempool**: a local pool of pending transactions waiting to be included in a block. Then the node gossips the transaction to a handful of other nodes it's directly connected to (its "peers"), who run the same checks, add it to their own mempools, and gossip it further. Within a second or two, the transaction is sitting in mempools across the entire network. This pattern, where every node forwards every message to its peers, who forward to theirs, is called **P2P gossip**, and it's how all consensus traffic moves. There's no central server. No coordinator. Just a viral spread of messages. Two things about the mempool are worth pausing on. First: **the mempool is not part of the chain.** It's a buffer of transactions that *want* to be in the chain. Nothing in it is permanent until it gets included in a block. Second: **every node has its own mempool.** They're similar across the network (gossip ensures that) but not identical. There's no single canonical "the mempool." Each node sees a slightly different snapshot. --- ## Step 2: A proposer is chosen While the transaction waits in mempools across the network, Ethereum is already scheduling the next block. Every slot has exactly one assigned **proposer**: a validator chosen to build the block for that 12-second window. Validators are participants who have staked 32 ETH to help run consensus. Their responsibilities are simple: sometimes they propose blocks, and most of the time they vote on blocks proposed by others. At the start of each epoch, Ethereum shuffles validators and pre-assigns duties for the next 32 slots. The shuffle uses a randomness source called **RANDAO**, which validators themselves contribute to over time. Each block carries a small piece of randomness, and these get mixed together across an epoch to seed the next epoch's shuffle. Everyone can independently compute the same assignments just by looking at the protocol state and the current slot number. So when Slot N begins, the network already knows: * who is allowed to propose the block * which committee will attest to it No coordinator is needed. The schedule is already known ahead of time. One subtle detail worth flagging: a "validator" is a *role*, not a physical machine. A single computer can run thousands of validator identities. Large staking services like Lido and Coinbase do exactly that. When you hear "one million validators," picture that many cryptographic identities, not a million separate computers. --- ## Step 3: The block is built When the proposer's slot arrives, the clock starts. They have 12 seconds, though in practice they aim to publish within the first few so the block has time to spread before voting begins. The proposer constructs the block by setting its parent to the current head of the chain (the most recent block they believe is canonical) and packing in transactions from their mempool, typically prioritizing the ones paying the highest gas fees. They also include attestations from the previous slot (we'll see why in a moment), and finally sign the whole thing, proving they're the legitimate proposer for this slot. Then they broadcast it via P2P gossip. Within a second or two, most validators worldwide have seen it. Our user's transaction, if it was high-fee enough to make the cut, is now inside a freshly-broadcast block. One simplification: in modern Ethereum, proposers don't actually build their own blocks. They buy them from specialized "builders" through a system called **MEV-Boost**. Builders compete to produce the most profitable block possible, and proposers select the highest bid. This matters enormously for Ethereum's economics, but for understanding consensus mechanics you can treat the proposer as the builder. The signing and broadcasting parts are the same. --- ## Step 4: The committee attests Now we get to the heart of the protocol. The same epoch shuffle that picked proposers also assigned every validator to a **committee**, a group responsible for voting on a specific slot. Every validator is in exactly one committee per epoch, which means every validator votes exactly once per epoch. Do the math. About one million validators, 32 slots per epoch. That's roughly **31,000 validators per committee**, all attesting at once. This is the source of the "30,000 signatures per slot" number you see everywhere in the research. Committees are split into subcommittees for technical reasons, but you can ignore that for now. Four seconds into the slot, one-third of the way through, every validator in that slot's committee does three things. They look at the head of the chain *they* see. If the proposer's block arrived and looks valid, they'll vote for it. If something went wrong (the proposer was offline, the block was malformed, the network briefly split), they vote for the previous block instead. They construct an **attestation**: a small signed message containing three votes. Vote one: this is the current head. Vote two: this checkpoint should be justified. Vote three: this checkpoint is my finalization source. Don't worry about checkpoints yet. We'll get there. They sign the attestation with their private key and broadcast it via gossip. So in every single slot, around 31,000 validators around the world simultaneously sign and broadcast attestations. Picture it: a coordinated burst of voting traffic, every 12 seconds, forever. That's the signal that makes the next part, BLS, so important. --- ## Step 5: BLS aggregation If 31,000 attestations were broadcast individually each slot, the bandwidth cost would be brutal. Each attestation carries a signature. Even at 96 bytes per signature, that's nearly 3 MB per slot of just signatures, before you count metadata. Multiplied across the network, the math gets ugly fast. Ethereum solves this with a specific property of **BLS signatures**. BLS, named for Boneh, Lynn, and Shacham, has one remarkable trick: many BLS signatures on the *same message* can be combined into a single signature of the same size. Their public keys combine the same way. The combined signature verifies against the combined public key as if a single signer had produced it. Concretely: when 31,000 validators all attest to the same block in the same slot, you can take all 31,000 of their signatures and aggregate them into **one** 96-byte signature. You can verify this aggregate against an aggregate of their 31,000 public keys, in roughly the same time it takes to verify a single signature. The mechanics: within each committee, certain validators are designated as **aggregators**. They listen for attestations from their committee, group together the ones voting for identical contents, run the BLS aggregation algorithm, and broadcast the combined attestation along with a bitfield (a string of bits indicating which validators contributed). The network sees a few hundred aggregated messages instead of 31,000 raw ones. This is *the* reason Ethereum picked BLS. And it's exactly the property that breaks under quantum attack. BLS is built on elliptic curve pairings. Its security rests on the hardness of the discrete logarithm problem on those curves. **Shor's algorithm**, running on a sufficiently large quantum computer, solves discrete logarithm in polynomial time. That's what people mean when they say "BLS is broken under quantum attack." Not weakened. Broken. We don't have such quantum computers yet. The Ethereum community has decided not to wait around to find out when we will. The research article you started with is the community's attempt to figure out what comes next. --- ## Step 6: Fork choice Most of the time, blocks arrive cleanly, attestations flow, everyone agrees. Sometimes they don't. Maybe two proposers produce blocks in the same slot. (Shouldn't happen, but a malicious or buggy validator can do it.) Maybe the proposer's block was delayed and some validators voted on a different parent. Maybe the network briefly split into two halves. In any of these cases, the chain temporarily forks. When this happens, every node has to pick which fork to follow. The rule they use is called the **fork choice rule**, and Ethereum's current rule is **LMD-GHOST**. The name is intimidating. The idea is simple. *Follow the fork with the most accumulated attestation weight.* Validators are voting with their attestations, and the heaviest branch wins. As more attestations arrive, every node continuously re-evaluates which block is the current head. Forks usually resolve within one or two slots. Once attestations pile up on one side, the other has no chance of catching up, and validators switch to following the heavier branch. This is sometimes called "reorging": a node thought block A was the head, then evidence accumulated for block B, so it reorganizes its view to follow B instead. Fork choice answers "what's the current head?" But it doesn't tell you when a block becomes truly permanent. For that, we need finality. --- ## Step 7: Finality Finality is the property that makes a block irreversible. Once finalized, reversing it would require destroying *billions of dollars* of staked ETH. At that point, "permanent" stops being a hedge word. Ethereum's finality system is called **Casper FFG**. It runs in parallel with LMD-GHOST and operates on a coarser time scale: epochs, not slots. Here's the mechanism. The first block of each epoch is a **checkpoint**. Remember those two extra fields in every attestation, the "source" and "target" checkpoints? Every time a validator attests, they're voting not just on the head, but on a pair of checkpoints they want to see promoted. A checkpoint becomes **justified** when at least two-thirds of all validators (weighted by stake) vote for it as the target of an attestation that has a justified source. Justification is a step toward finality, not finality itself. A justified checkpoint becomes **finalized** when the *next* epoch's checkpoint also gets justified, and the votes link the two together. In other words, finality requires two consecutive epochs of supermajority agreement. In time terms: an epoch is 6.4 minutes, so blocks finalize about two epochs after they're produced. Roughly **12.8 minutes**. Until then, the block is the "head" but not yet permanent. After finalization, reversing requires at least one-third of staked ETH to be slashed. At today's stake levels, that's many billions of dollars destroyed simultaneously. Not impossible. Economically unthinkable. Two systems running in parallel, and it's worth saying this out loud: **LMD-GHOST gives you the current head, second by second. Casper FFG gives you permanence, epoch by epoch.** They're separate systems looking at the same underlying votes, answering different questions. --- ## The whole loop Step back. Look at what we've built. Every 12 seconds: a user's transaction sits in the mempool. A proposer is chosen by the epoch shuffle. They pull transactions from their mempool, build a block, and broadcast it via P2P gossip. Four seconds later, ~31,000 validators in the slot's committee attest to what they see, signing with BLS. Aggregators combine those attestations into a small number of compact messages. Every node runs LMD-GHOST to update its view of the current head. In parallel, Casper FFG counts attestation votes on checkpoints, justifying and finalizing them across epoch boundaries. That's it. That's Ethereum consensus. Visualized: ```mermaid flowchart TD User([USER signs transaction in wallet]):::input Mempool[MEMPOOL
P2P gossip spreads tx
to every node's pending pool]:::buffer Proposer[PROPOSER CHOSEN
by RANDAO shuffle at epoch start
One validator per slot]:::propose Block[BLOCK BUILT AND BROADCAST
Proposer pulls tx from mempool,
signs, broadcasts via P2P
1-2s to reach the network]:::propose Committee[COMMITTEE ATTESTS
~31,000 validators sign simultaneously
head = X, justify = Y, source = Z
SIGNED WITH BLS]:::vote BLS[BLS AGGREGATION
31,000 sigs to 1 sig of 96 bytes
The property quantum computing breaks]:::aggregate LMD[LMD-GHOST
Picks current head
by attestation weight
Updates every slot]:::consensus Casper[CASPER FFG
Justifies and finalizes checkpoints
via 2/3 supermajority
~12.8 min to finality]:::consensus Next([Next slot begins
Loop repeats every 12s]):::output Final([BLOCK PERMANENT
Reverting requires
destroying 1/3 of stake]):::output User --> Mempool Mempool --> Proposer Proposer --> Block Block --> Committee Committee --> BLS BLS --> LMD BLS --> Casper LMD --> Next Casper --> Final classDef input fill:#FFF6E5,stroke:#E8A317,stroke-width:2px,color:#1A1A1A classDef buffer fill:#FFF6E5,stroke:#E8A317,stroke-width:2px,color:#1A1A1A classDef propose fill:#E8F0FF,stroke:#2E5BFF,stroke-width:2px,color:#1A1A1A classDef vote fill:#FFFFFF,stroke:#2C3E50,stroke-width:3px,color:#1A1A1A classDef aggregate fill:#F3E8FF,stroke:#7B2EFF,stroke-width:2px,color:#1A1A1A classDef consensus fill:#E5FFE9,stroke:#2EA84F,stroke-width:2px,color:#1A1A1A classDef output fill:#FFF6E5,stroke:#E8A317,stroke-width:2px,color:#1A1A1A ``` Every concept plays a specific role: The **clock** schedules everything. **P2P gossip** is the substrate messages travel over. The **mempool** buffers transactions before they reach a block. **Validators** hold the stake and do the voting. **Proposers** build blocks. **Attestations** are the votes. **BLS aggregation** makes 31,000 signatures per slot affordable. **LMD-GHOST** picks the head moment to moment. **Casper FFG** promotes blocks from "current head" to "permanent." --- ## Coming back to where we started Read the opening paragraph again: > By reducing slot time from 12 seconds to 4 seconds and targeting single-slot finality, Lean Consensus leaves dramatically less time for signature propagation and proof generation. Thirty thousand XMSS signatures cannot be broadcast naively. Instead, a SNARK proof attests that all signatures verified correctly, without publishing the signatures themselves. Different experience this time, I'd guess. You know what a slot is, and you can feel why shrinking it from 12 seconds to 4 makes everything harder. You know where 30,000 signatures comes from, because we counted them together. You know why XMSS being unable to aggregate is the actual problem, since BLS aggregation was the property the whole system was leaning on. The SNARK trick (broadcast a proof instead of the signatures) makes sense as the obvious move once you see the bandwidth math. The full story of how that works (what XMSS is built from, how SNARKs actually compress, why the hash function choice is the hardest open question) is the next article. You can now confidently read and understand it here: **[Ethereum's Lean Consensus: Breaking Down the Quantum-Safe Signature Problem](https://hackmd.io/@Annie25/r1rHSG9AWx)**