What Ethereum Validators Actually Do to Produce a Block

Since Fusaka shipped on December 3, 2025, Ethereum validators have sampled more data but still perform the same core job: select the chain head, sign one locally built or builder-supplied block, broadcast it, and vote on blocks from others. The upgrade changed data availability through PeerDAS, but did not abolish the off-protocol builder auction. That division is the component traders must understand: a validator makes a payload canonical; a builder often determines what sits inside it.

What does an Ethereum validator do in a 12-second slot?

An Ethereum validator’s proposal duty is to publish one valid block before its 12-second slot expires. Its consensus client applies fork choice to select the parent, adds the slot, proposer signature and RANDAO reveal, then asks an execution client or external builder for an execution payload. Publishing two blocks for one slot is slashable.

Receiving validators check the parent, proposer and signatures, then their execution clients replay every transaction against the prior state. Committees attest to the result; those votes drive fork choice and later finality. A proposer therefore cannot make an invalid swap valid. It can, however, deliver a valid sequence that changes who trades first.

Who decides transaction order: validators or block builders?

A block builder decides transaction order whenever the proposer accepts its MEV-Boost bid; the validator chooses the winning header and signs it without first seeing the full payload. Follow one decentralized-exchange swap through that route:

• The wallet signs a nonce, gas limits and swap constraints, then sends the transaction to the public mempool or a private endpoint.
• Searchers may bundle it with an arbitrage; builders simulate candidate sequences and offer relays a payload plus a proposer payment.
• A relay validates the payload and exposes its header and bid. MEV-Boost selects the best valid relay response; absent an acceptable bid, the beacon client can use its local payload.
• The validator signs the blinded block, receives the revealed payload, broadcasts it, and peers re-execute the ordered list.

Current MEV-Boost defaults allow 950 milliseconds for getHeader and 4,000 milliseconds for getPayload. Those bounds expose the bargain. Compared with local building, an auction can capture more arbitrage value for the proposer, but adds relay latency and a payload-withholding failure point. The trader keeps the same protocol fee rules yet may receive different execution because placement around other swaps changes. My verdict: outsourced building improves competition for proposer revenue, not execution fairness. The latency-sensitive trader bears ordering risk; the validator bears missed-slot risk.

How did Fusaka change validator data work?

Fusaka made blob verification lighter by having nodes sample authenticated columns of erasure-coded blob data instead of requiring every node to download every full blob. Subsequent parameter-only forks raised the per-block blob maximum from 9 to 21, a 133% increase; regular non-validating nodes custody one-eighth of the data, while validators carry additional custody duties.

This improves rollup data availability, not a validator’s power to guarantee settlement. The distinction also matters when reading Universal Bridge’s reserve test: inclusion can prove a submitted transaction passed Ethereum’s rules, but it cannot certify bridge economics or promise a specific slot.

How can traders verify what a validator did?

Traders can verify production by matching the receipt’s block number, transaction index, effective gas price, status and output against the block’s ordered transaction list. Check the proposer fee recipient, compare the slot with public relay payload records, and query the block from two independent RPC endpoints. For a practical test, submit two small, equivalent swaps through public and private routes and record submission time, inclusion slot and received amount. That evidence separates validator validity from builder ordering—and shows whether the live route improved the fill.