EIP-4788: Beacon state root in the EVM

Abstract #

Commit to the state root of the beacon chain in the ommers field in the post-merge execution block. Reflect the changes in the ommersHash field of the execution block header.

Store each beacon chain state root into a contract and add a new opcode that reads this contract.

Motivation #

Exposing the beacon chain state root allows for proofs about the beacon state to be verified inside the EVM. This functionality supports a wide variety of use cases in smart contracts involving validator status and finality produced by the consensus layer.

In particular, this functionality is required for beacon chain validator withdrawals to the EVM.

Specification #

Background #

The method of injecting the beacon state root in this EIP follows the general strategy of EIP-4399 to make a post-merge change to the EVM integrating information from the beacon chain. This EIP along with EIP-3675 should be taken as relevant background to understand the particular approach of this EIP.

The method for exposing the state root data via opcode is inspired by EIP-2935.

Block structure and validity #

Beginning at the execution timestamp FORK_TIMESTAMP, execution clients MUST:

1. set the value of the ommers field in the block to an RLP list with one element: the 32 byte hash tree root of the beacon state from the previous slot to this block.

2. set the value of the ommersHash field in the block header to the Keccak256 hash of the ommers field.

beaconStateRoot = <32 byte value> # provided by consensus client
ommers = RLP([beaconStateRoot])   # in the block body
ommersHash = Keccak256(ommers)    # in the block header

3. Add the block validation that the ommersHash does indeed match the expected commitment given the ommers value.

EVM changes #

Block processing #

At the start of processing any execution block where block.timestamp >= FORK_TIMESTAMP (i.e. before processing any transactions), write the beacon state root provided in the block into the storage of the smart contract at HISTORY_STORAGE_ADDRESS. This data is keyed by the block number.

In pseudocode:

beacon_state_root = block.ommers[0]
sstore(HISTORY_STORAGE_ADDRESS, block.number, beacon_state_root)

New opcode #

Beginning at the execution timestamp FORK_TIMESTAMP, introduce a new opcode BEACON_STATE_ROOT at OPCODE_VALUE. This opcode consumes one word from the stack encoding the block number for the root. The opcode has a gas cost of G_beacon_state_root.

The result of executing this opcode leaves one word on the stack corresponding to a read of the history contract's storage; in pseudocode:

block_number = evm.stack.pop()
sload(HISTORY_STORAGE_ADDRESS, block_number)

If there is no root stored at the requested block number, the opcode follows the existing EVM semantics of sload returning 0.

Rationale #

General strategy #

See the rationale for EIP-4399 for discussion about this general strategy of reusing execution block elements for beacon chain data.

Fork mechanics #

This EIP requires the consensus layer and execution layer to execute a network upgrade in lockstep. To carry out this task, a FORK_EPOCH (of the beacon chain) will be chosen and then used to compute a timestamp FORK_TIMESTAMP. This FORK_TIMESTAMP can be used in the execution layer to identify when the protocol change should be deployed.

This technique works because the timestamps in post-merge execution blocks are aligned to beacon chain slots and thus serve as a proxy for the slot number.

Another option for the fork definition would be to pick a beacon chain epoch and an execution payload block number. This design however is not reliable due to the presence of skipped slots on the beacon chain.

Execution layer validations #

By including the beacon state root in the execution block in the deprecated ommers field, execution clients can still verify the chain in a self-contained way without relying on an available consensus client. This property is important during syncing (and likely other phases of execution node operation).

Minimizing client code change #

By including the ommersHash validation, clients can use existing code with only minimal changes (supplying the actual state root) during block production and verification. Having the beacon state root value in the ommers field means that it is fairly straightforward to provide the value from the block data to the EVM execution context for client implementations as they stand today.

Gas cost of opcode #

The suggested gas cost is just using the value for the BLOCKHASH opcode as BEACON_STATE_ROOT is an analogous operation.

Why not repurpose BLOCKHASH? #

The BLOCKHASH opcode could be repurposed to provide a beacon state root instead of the current execution block hash. To minimize code change and simplify deployment to mainnet, this EIP suggests leaving BLOCKHASH alone and adding a new opcode with the desired semantics.

Why not bound history of state roots? #

Marginal state growth; adding every single root results in an additional ~84MB of state growth per year compared to ~30 GB of state overall.

TODO: say something about statelessness TODO: get latest numbers on state size, and compare against predicted growth

Beacon state root instead of block root #

Each slot on the beacon chain containing a block has both a block root and a state root (reflecting the state after applying said block). The beacon block includes the state root so a proof about the state could also be authored against a block root at the cost of a few additional hashes. Given that most use cases want to prove data encapsulated in a given state, rather than a given block, this EIP suggests exposing state roots over block roots.

Block number in lieu of slot #

The state roots are keyed by the number of the execution block. Another option is to key roots by the beacon chain slot they belong to. While at first pass this may seem more direct, the beacon chain can have "skipped" slots where a beacon proposer failed to produce a block that was included at a given slot. Handling roots of skipped slots would complicate the EVM mechanism so this EIP suggests to use the execution block number where each distinct block number is guaranteed to have a distinct root.

Backwards Compatibility #

No issues.

Test Cases #

TODO

Reference Implementation #

TODO

Security Considerations #

TODO

Copyright #

Copyright and related rights waived via CC0.