DCIPs/EIPS/eip-4863.md

eip	title	description	author	discussions-to	status	type	category	created
4863	Beacon chain push withdrawals	Support validator withdrawals from the beacon chain to the EVM via a new "push-style" transaction type.	Alex Stokes (@ralexstokes), Danny Ryan (@djrtwo)	https://ethereum-magicians.org/t/eip-4863-beacon-chain-push-withdrawals/8465	Stagnant	Standards Track	Core	2022-02-28

Abstract

Introduce a new EIP-2718 transaction type to support validator withdrawals that are "pushed" from the beacon chain to the EVM.

Add block validations to ensure the withdrawal transactions are sound with respect to withdrawal processing on the beacon chain.

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 block as soon as they are dequeued from the beacon chain.

This approach is more involved than "pull"-based alternatives (e.g. EIP-4788 + user-space withdrawal contract) with respect to the core protocol (by providing a new transaction type with special semantics) but does provide tighter integration of a critical feature into the protocol itself.

Specification

constants	value	units
FORK_TIMESTAMP	TBD
WITHDRAWAL_TX_TYPE	0x3	byte

Beginning with the execution timestamp FORK_TIMESTAMP, execution clients MUST introduce the following extensions to transaction processing and block validation:

New transaction type

Define a new EIP-2718 transaction type with TransactionType WITHDRAWAL_TX_TYPE.

The TransactionPayload is an RLP-encoded list RLP([index, address, amount]) where the index is a 64-bit value uniquely labeling a specific withdrawal, the address refers to an execution layer account and the amount refers to an ether value given in units of wei.

These values are provided by the consensus layer.

Block validity

If a block contains any transactions with WITHDRAWAL_TX_TYPE type, they MUST come after ALL other transactions in the block.

If the execution client receives a block where this is not the case, it MUST consider the block invalid.

Transaction processing

When processing a transaction with WITHDRAWAL_TX_TYPE type, the implementation should increase the balance of the address specified by the WithdrawalTransaction by the amount of wei specified.

This balance change is unconditional and MUST not fail.

This transaction type has no associated gas costs.

TODO: add logs?

Rationale

Push vs pull approach

This push approach gives validators a small subsidy with respect to processing, in lieu of needing to buy gas via normal EVM processing that would be required for a pull-based approach.

This style also happens automatically when the requisite conditions are met on the beacon chain which is nicer UX for validators.

Why a new transaction type?

This EIP suggests a new transaction type as it has special semantics different from other existing types of EVM transactions.

An entirely new transaction type firewalls off generic EVM execution from this type of processing to simplify testing and security review of withdrawals.

Why no (gas) costs for new transaction type?

The maximum number of this transaction type that can reach the execution layer at a given time is bounded (enforced by the consensus layer) and this limit is kept small so that any execution layer operational costs are negligible in the context of the broader block execution.

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.

Why new block validations?

The beacon chain must be able to efficiently validate that the withdrawal transactions in a given execution block are the ones expected based on its own internal scheduling logic to maintain the soundness of the withdrawal mechanism.

By requiring all withdrawal transactions to be at the back of every block where they are applicable, the algorithm to check consistency becomes a straightforward linear walk from the start of the set until a known, bounded (small) number.

Having a simple ordering scheme like this facilitates optimizations clients may do with respect to withdrawal processing, which would be hampered if withdrawal transactions could be placed in the block freely.

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.