How Ethereum Produces Blocks
Ethereum is a network of thousands of computers (called nodes) that agree on a shared ledger of transactions. To prevent anyone from writing fake transactions, the network uses a system called proof of stake.
In proof of stake, participants lock up 32 ETH as collateral to become validators. This deposit is their skin in the game. If they follow the rules, they earn rewards. If they misbehave, a portion of their deposit is destroyed (called slashing).
Validators have two jobs:
- Proposing blocks. Every 12 seconds, one validator is randomly selected to propose a new block of transactions. This 12-second window is called a slot.
- Attesting. All other validators vote on whether the proposed block is valid. If enough validators attest to it, the block becomes part of the chain.
The random selection is important. Any validator might be chosen for any slot, so no single entity controls which transactions go into which block. At least, that is how it was designed to work.
What is Blockspace?
Every block has limited capacity. It can carry a fixed amount of computation (measured in gas) and a fixed amount of data (carried in blobs). This capacity is called blockspace, and it is the scarce resource that Ethereum produces every 12 seconds.
When you submit a transaction, you are competing for a piece of this space. You attach a fee to your transaction, and higher-fee transactions are more likely to be included in the next block.
Think of it as packing a shipping container. Every 12 seconds, a new container is sealed and sent. Transactions that pay more get packed first. The network never runs out of containers, but each individual one fills up fast.
Who Builds the Block?
In early Ethereum, validators built their own blocks. They would look at the mempool (a public waiting area for pending transactions), pick the transactions with the highest fees, order them, and propose the result. This was simple and fair enough when block construction was straightforward.
But as on-chain activity grew, block construction became a competitive, technical challenge. The order in which transactions appear inside a block affects the block’s value. A validator who could strategically order transactions stood to earn significantly more than one who simply sorted by fee.
This created a problem: to stay competitive, validators would need to run sophisticated ordering algorithms and low-latency infrastructure. Solo validators running a node at home could not compete with professional operations. If block construction remained a validator job, the validator set would centralize around a few well-funded operators.
The solution was to separate the two jobs. Let specialists handle block construction. Let validators focus on proposing and attesting. This separation is called Proposer-Builder Separation, or PBS.
Today, over 90% of Ethereum blocks flow through this framework. Builders are operators who assemble the most optimized block they can and compete for the right to have it proposed. They receive transactions from private order flow services, from searchers (specialized algorithms that identify optimization opportunities in pending transactions), and from whatever remains of the public mempool.
Proposer-Builder Separation
PBS is the architectural pattern that keeps Ethereum’s validator set decentralized.
The proposer (validator) selects the highest bid and commits to a block. The builder assembles the best block it can and bids for the right to have it proposed. A relay sits between them, facilitating a fair exchange (we will cover relays in detail below).
Without this separation, validators would need to run the same sophisticated block-building infrastructure that professional builders use. Solo validators running nodes at home would be at a permanent disadvantage, and the validator set would consolidate around well-resourced operators.
PBS keeps the validator role lightweight: accept the highest bid, sign, propose. The complexity of block construction is offloaded to competitive builders. Validators remain decentralized. Block construction concentrates among a small number of builders, but that is a different (and more manageable) concentration than centralizing the validator set itself.
The Mempool and Its Decline
Historically, when you sent a transaction from your wallet, it entered a waiting area called the mempool (short for memory pool): a collection of pending transactions broadcast to the network but not yet included in a block.
The mempool is public. Anyone running a node can see every pending transaction, including its amount, destination, and fee. This visibility can leak information to participants who monitor it. If someone can see your large swap sitting in the mempool before it lands in a block, they can trade around it.
Because of this, the mempool is declining. Today, most sophisticated users and wallets avoid it entirely. Instead, they send transactions through private RPCs, services that route your transaction directly to builders or specialized order flow auctions (OFAs) without exposing it to the public mempool. OFAs run competitive auctions among searchers for the right to interact with your transaction. These services offer protections such as privacy and other services.
The result is a shift from a public commons to a network of private channels. The mempool still exists, but an increasing share of valuable transactions never touches it.
Why Transaction Order Matters
Ethereum executes transactions within a block sequentially, one after another. Each transaction changes the state of the chain, and the next transaction executes against that updated state. A stablecoin transfer that executes first sees one account balance; the same transfer executing after a large preceding transaction sees a different balance. Position in the block affects outcomes.
This means whoever decides the sequence holds an information advantage. If a pending transaction is visible before it lands in a block, an observer who controls ordering can place their own transaction ahead of it, executing against a state the original sender did not anticipate. As long as transactions run one by one and someone decides the sequence, that ordering decision has consequences.
What is a Relay?
Builders and validators need a way to exchange blocks. A builder does not want to reveal their block contents before the validator commits to it, and a validator does not want to commit to a block without knowing it is valid.
A relay facilitates this exchange. It does two things:
- Hides block contents. The relay receives full blocks from builders. It sends only the block header (a summary) and the bid amount to the validator. The validator never sees the transactions inside until after they commit. This prevents the validator from trading around the block contents.
- Validates blocks. Before forwarding a bid, the relay checks that the builder’s block is valid, that it can actually be executed. This protects the validator from committing to a broken block.
- Propagates blocks. After the validator commits, the relay distributes the full block to the network. This offloads propagation from the validator, and validators using relays typically achieve higher consensus rewards as a result.
The relay runs an auction. Builders submit blocks and continuously update their bids throughout the slot as new information is learned. Builders can see the current top bid, so the auction is competitive and open, not sealed. The relay forwards the best available bid to the proposer at the moment they request it. The proposer signs a commitment to that block header, and only then does the relay reveal the full block to the network.
What Comes Next
Now that the fundamentals are in place, PBS 201 dives deeper into the transaction pipeline: the sidecar software validators run, how the block auction works in practice, timing dynamics, and the infrastructure that ties it all together.