Beacon chain push withdrawals as operations
EIP-4895 proposes that all withdrawal transactions be placed at the back of every block where they are applicable, which facilitates optimizations for withdrawal processing. This relates to withdrawals in Ethereum and the Beacon chain because it ensures that the proper amount of ETH is withdrawn back into the execution layer and that the consensus-layer to execution-layer ETH transfer is secure.
PEEPanEIP#68: EIP-4895: Beacon chain push withdrawals as operations with Alex stokes
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 approach introducing a new transaction type 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 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:
System-level operation: withdrawal
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 provide key information from the consensus layer:
- a monotonically increasing
index, starting from 0, as a
uint64value that increments by 1 per withdrawal to uniquely identify each withdrawal
validator_indexof the validator, as a
uint64value, on the consensus layer the withdrawal corresponds to
- a recipient for the withdrawn ether
addressas a 20-byte value
- a nonzero
amountof ether given in Gwei (1e9 wei) as a
index for each withdrawal is a global counter spanning the entire sequence of withdrawals.
Withdrawal objects are serialized as a RLP list according to the schema:
[index, validator_index, address, amount].
New field in the execution payload: withdrawals
The execution payload gains a new field for the
withdrawals which is an RLP list of
withdrawal_0 = [index_0, validator_index_0, address_0, amount_0] withdrawal_1 = [index_1, validator_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.
New field in the execution payload header: withdrawals root
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, ])
Execution payload validity
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
Recall that the
amount is given in units of Gwei so a conversion to units of wei must be performed when working with account balances in the execution state.
This balance change is unconditional and MUST not fail.
This operation has no associated gas costs.
Why not a new transaction type?
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.
Why no (gas) costs for the withdrawal type?
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).
Why only balance updates? No general EVM execution?
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.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.View all