Expose beacon chain state roots in the EVM
|Author||Alex Stokes, Danny Ryan|
Table of Contents
- Backwards Compatibility
- Test Cases
- Reference Implementation
- Security Considerations
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.
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.
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.
Beginning at the execution timestamp
FORK_TIMESTAMP, execution clients MUST:
set the value of the
ommersHashfield in the block header to the Keccak256 hash of the
beaconStateRoot = <32 byte value> # provided by consensus client ommers = RLP([beaconStateRoot]) # in the block body ommersHash = Keccak256(ommers) # in the block header
- Add the block validation that the
ommersHashdoes indeed match the expected commitment given the
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.
beacon_state_root = block.ommers sstore(HISTORY_STORAGE_ADDRESS, block.number, beacon_state_root)
Beginning at the execution timestamp
FORK_TIMESTAMP, introduce a new opcode
OPCODE_VALUE. This opcode consumes one word from the stack encoding the block number for the root. The opcode has a gas cost of
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
See the rationale for EIP-4399 for discussion about this general strategy of reusing execution block elements for beacon chain data.
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 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.
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).
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.
The suggested gas cost is just using the value for the
BLOCKHASH opcode as
BEACON_STATE_ROOT is an analogous operation.
BLOCKHASH opcode could be repurposed to provide a beacon block 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.
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
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.
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.
Copyright and related rights waived via CC0.
Please cite this document as:
Alex Stokes, Danny Ryan, "EIP-4788: Beacon state root in the EVM [DRAFT]," Ethereum Improvement Proposals, no. 4788, February 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4788.