Ethereum validators to adopt new roles with EIP-7732

Ethereum’s validators are set to take on new roles with the introduction of EIP-7732, the Enshrined Proposer-Builder Separation proposal.

This proposal fundamentally changes how Ethereum blocks are validated by splitting execution validation from consensus validation both logically and temporally.

Validators get overhauled

Validators now have new responsibilities, including the option to become builders and the duty to submit payload timeliness attestations.

The EIP addresses multiple key issues in the current system. Most beacon block proposers outsource the construction of the execution payload to a third party, known as a builder.

They request the hash tree root (HTR) of a promised execution payload and submit a SignedBlindedBeaconBlock to a trusted party. This party then replaces the HTR with the full execution payload from the builder before broadcasting.

The EIP guarantees fair exchanges between the beacon block proposer and the builder. It ensures that an honest beacon block proposer gets paid by the builder, and an honest builder’s payload becomes the canonical head of the chain.

Currently, validators have a short window to perform both consensus and execution state transitions, check blob data availability, and evaluate the new head of the blockchain.

This EIP changes that by separating execution and consensus validation, allowing validators to focus on consensus state transition before attesting.

Execution and data availability validation is deferred, allowing validators to perform these tasks in the remaining slot time.

Motivation behind EIP-7732

Removing the full execution payload from the consensus block allows for faster network propagation. It reduces the likelihood of reorganization when including blob transactions due to increased timelines for data availability checks.

Validators no longer miss attestations, strengthening fork choice properties when builders produce invalid payloads. The EIP also eliminates the need for trusted middleware for block construction delegation.

The EIP doesn’t require changes to the execution layer. However, the consensus layer undergoes several modifications, detailed in the consensus-specs GitHub repository.

These include changes to the Beacon Chain, fork choice, P2P protocols, validator guides, and the introduction of a new builder guide.

The Beacon chain changes involve constants, presets, and various container classes to handle the new payload attestations and signed execution payload headers.

The BeaconState container is modified to track the latest block hash, the latest slot with an execution payload, and the latest withdrawals root.

The BeaconBlockBody now includes a signed execution payload header and a list of payload attestations. The ExecutionPayloadHeader is simplified to track minimal information for builder’s payload commitments.

State transition logic changes include new functions for processing payload attestations, execution payload headers, and withdrawal requests.

Fork choice changes involve new constants and container classes to handle child nodes, latest messages, and store modifications. New handlers are introduced for payload attestation messages and signed execution payload envelopes.

Reporting by Jai Hamid