Support validator withdrawals from the beacon chain to the EVM via a new "system-level" operation type.
|Author||Alex Stokes, Danny Ryan|
Table of Contents
- Backwards Compatibility
- Security Considerations
Introduce a system-level “operation” to support validator withdrawals that are “pushed” from the beacon chain to the EVM.
These operations create unconditional balance increases to the specified recipients.
This EIP provides a way for validator withdrawals made on the beacon chain to enter into the EVM. The architecture is “push”-based, rather than “pull”-based, where withdrawals are required to be processed in the execution layer as soon as they are dequeued from the consensus layer.
Withdrawals are represented as a new type of object in the execution payload – an “operation” – that separates the withdrawals feature from user-level transactions. This approach is more involved than the prior EIP-4863 but it cleanly separates this “system-level” operation from regular transactions. The separation simplifies testing (so facilitates security) by reducing interaction effects generated by mixing this system-level concern with user data.
Moreover, this approach is more complex than “pull”-based alternatives (e.g. EIP-4788 + user-space withdrawal contract) with respect to the core protocol but does provide tighter integration of a critical feature into the protocol itself.
Beginning with the execution timestamp
FORK_TIMESTAMP, execution clients MUST introduce the following extensions to payload validation and processing:
Define a new payload-level object called a
withdrawal that describes withdrawals that have been validated at the consensus layer.
Withdrawals are syntactically similar to a user-level transaction but live in a different domain than user-level transactions.
Withdrawals have three key pieces of information supplied from the consensus layer:
- a monotonically increasing
uint64value that uniquely identifies each withdrawal
- a recipient for the withdrawn ether
addressas a 20-byte value
amountof ether given in wei as a 256-bit value.
Withdrawal objects are serialized as a RLP list according to the schema:
[index, address, amount].
The execution payload gains a new field for the
withdrawals which is an RLP list of
withdrawal_0 = [index_0, address_0, amount_0] withdrawal_1 = [index_1, address_1, amount_1] withdrawals = [withdrawal_0, withdrawal_1]
This new field is encoded after the existing fields in the execution payload structure and is considered part of the execution payload’s body.
execution_payload_rlp = RLP([header, transactions, , withdrawals]) execution_payload_body_rlp = RLP([transactions, , withdrawals])
NOTE: the empty list in this schema is due to EIP-3675 that sets the
ommers value to a fixed constant.
The execution payload header gains a new field committing to the
withdrawals in the execution payload.
This commitment is constructed identically to the transactions root in the existing execution payload header by inserting
each withdrawal into a Merkle-Patricia trie keyed by index in the list of
def compute_trie_root_from_indexed_data(data): trie = Trie.from([(i, obj) for i, obj in enumerate(data)]) return trie.root execution_payload_header.withdrawals_root = compute_trie_root_from_indexed_data(execution_payload.withdrawals)
The execution payload header is extended with a new field containing the 32 byte root of the trie committing to the list of withdrawals provided in a given execution payload.
execution_payload_header_rlp = RLP([ parent_hash, 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, # ommers hash coinbase, state_root, txs_root, receipts_root, logs_bloom, 0, # difficulty number, gas_limit, gas_used, timestamp, extradata, prev_randao, 0x0000000000000000, # nonce base_fee_per_gas, withdrawals_root, ])
Assuming the execution payload is well-formatted, the execution client has an additional payload validation to ensure that the
withdrawals_root matches the expected value given the list in the payload.
assert execution_payload_header.withdrawals_root == compute_trie_root_from_indexed_data(execution_payload.withdrawals)
withdrawals in an execution payload are processed after any user-level transactions are applied.
withdrawal in the list of
execution_payload.withdrawals, the implementation increases the balance of the
address specified by the
This balance change is unconditional and MUST not fail.
This operation has no associated gas costs.
This EIP suggests a new type of object – the “withdrawal operation” – as it has special semantics different from other existing types of EVM transactions.
Operations are initiated by the overall system, rather than originating from end users like typical transactions.
An entirely new type of object firewalls off generic EVM execution from this type of processing to simplify testing and security review of withdrawals.
The maximum number of withdrawals that can reach the execution layer at a given time is bounded (enforced by the consensus layer) and this limit has been chosen so that any execution layer operational costs are negligible in the context of the broader payload execution.
This bound applies to both computational cost (only a few balance updates in the state) and storage/networking cost as the additional payload footprint is kept small (current parameterizations put the additional overhead at ~1% of current average payload size).
More general processing introduces the risk of failures, which complicates accounting on the beacon chain.
This EIP suggests a route for withdrawals that provides most of the benefits for a minimum of the (complexity) cost.
Consensus-layer validation of withdrawal transactions is critical to ensure that the proper amount of ETH is withdrawn back into the execution layer. This consensus-layer to execution-layer ETH transfer does not have a current analog in the EVM and thus deserves very high security scrutiny.
Copyright and related rights waived via CC0.
Please cite this document as:
Alex Stokes, Danny Ryan, "EIP-4895: Beacon chain push withdrawals as operations [DRAFT]," Ethereum Improvement Proposals, no. 4895, March 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4895.