One organization operates the core system:
Independent participants follow common rules:
Think in stages, not fixed product-release promises
Most rollup-based activity follows this path. Users can also transact directly on Ethereum Layer 1.
The design logic, using analogies only where they help
Independent nodes can receive blocks and messages at different times. How do they still converge on one accepted Ethereum history?
Think of many independent record-keepers receiving updates at slightly different times but using the same rules to converge on one official record.
Consensus is the agreement mechanism. It keeps nodes aligned on the canonical chain and brings blocks to finality.
Once a block is accepted, every node needs to calculate the same resulting balances, contract changes, and state.
Like running the same formula on the same data: every correct implementation should produce the same result.
Execution runs transactions and smart contracts in the EVM and updates Ethereum's state.
Transaction order can change economic outcomes. Specialized actors therefore compete to assemble valuable candidate blocks.
Like assembling a batch of orders when the order itself can affect the result. The sequence has economic value.
Builders specialize in assembling candidate blocks. This can improve block-production efficiency, but it also creates MEV and concentration concerns.
Builders and proposers don't trust each other. Builders don't want to reveal their blocks (someone could steal the strategy). Proposers don't want to blindly accept a block that might be invalid.
Like a sealed-bid intermediary that lets builders submit bids without revealing the full block to the proposer first.
Relays connect external builders and proposers in today's common MEV-Boost flow. They are off-protocol intermediaries; Glamsterdam's ePBS is designed to remove this relay dependency.
Who publishes a block for this slot? Ethereum needs one selected proposer, but that proposer should not be able to declare the block final by itself.
Think of the proposer as the designated publisher for one round. Publishing a candidate block does not make it final by itself.
The selected validator proposes the block for that slot and has staked ETH at risk. Other validators attest, and finality emerges from wider consensus — not from the proposer's signature alone.
Ethereum L1 deliberately limits how much work fits into each block because independent nodes still need to verify the chain within tight timing and hardware constraints.
This is where the court analogy works best: rollups handle large volumes of routine activity, while Ethereum acts as the shared settlement layer where data, proofs or disputes ultimately anchor.
Rollups execute many transactions outside L1, then publish data and state commitments or proofs to Ethereum. This can provide faster and cheaper execution while anchoring important guarantees to L1.
On L2, someone needs to order transactions quickly (sub-second) before they're batched to L1. Waiting for L1's 12-second slots would kill the user experience.
Like a filing clerk that immediately timestamps and orders your submission. That gives a fast acknowledgment, while final settlement happens later.
A sequencer orders L2 transactions and can provide fast "soft confirmations" before the rollup settles to Ethereum. Many major rollups still rely on a single sequencer operator today.
Rollups need transaction or state data to remain available so others can reconstruct and verify what happened, but permanent L1 storage is expensive.
Like a public filing system that guarantees records remain available for a defined period so others can inspect or reconstruct what happened.
Blobs give rollups lower-cost temporary data availability on Ethereum. The protocol guarantees availability for roughly 18 days, after which clients may prune the data and external archives can retain it.
Ethereum should not need to re-execute every L2 transaction. So how can it trust the rollup's claimed result?
Optimistic: A result stands unless someone successfully challenges it during a defined appeal window.
ZK: The result arrives with a cryptographic proof that Ethereum can verify directly.
Optimistic rollups use challenge mechanisms; ZK rollups use validity proofs. Both are ways to let Ethereum enforce an L2 result without replaying every L2 transaction.
Consensus determines which chain the network agrees on. Execution determines what transactions do to state. Builders may assemble candidate blocks. The roles are separated, although protocol upgrades can span multiple layers.
Proposer selection distributes block-production opportunities and makes the next proposer difficult to know far in advance. It reduces some coordination and corruption risks; it does not make manipulation impossible.
Validators put ETH at economic risk and receive rewards or penalties based on their behavior. Some consensus violations can lead to slashing.
Ethereum is designed so core protocol state and execution can be independently verified. Applications and L2s may add additional trust assumptions that should be evaluated separately.
