Beacon chain push withdrawals as operations

Abstract

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.

Motivation

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.

Specification

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:

1. a monotonically increasing index, starting from 0, as a uint64 value that increments by 1 per withdrawal to uniquely identify each withdrawal
2. the validator_index of the validator, as a uint64 value, on the consensus layer the withdrawal corresponds to
3. a recipient for the withdrawn ether address as a 20-byte value
4. a nonzero amount of ether given in Gwei (1e9 wei) as a uint64 value.

NOTE: the 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 data.

For example:

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 withdrawals.

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.

To illustrate:

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,
])

NOTE: field names and constant value in this example reflect EIP-3675 and EIP-4399. Refer to those EIPs for further information.

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)

State transition

The withdrawals in an execution payload are processed after any user-level transactions are applied.

For each withdrawal in the list of execution_payload.withdrawals, the implementation increases the balance of the address specified by the amount given.

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.

Rationale

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.

Backwards Compatibility

No issues.

Security Considerations

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

Copyright and related rights waived via CC0.