forked from DecentralizedClimateFoundation/DCIPs
108 lines
5.2 KiB
Markdown
108 lines
5.2 KiB
Markdown
|
---
|
||
|
|
eip: 4863
|
||
|
|
title: Beacon chain push withdrawals
|
||
|
|
description: Support validator withdrawals from the beacon chain to the EVM via a new "push-style" transaction type.
|
||
|
|
author: Alex Stokes (@ralexstokes), Danny Ryan (@djrtwo)
|
||
|
|
discussions-to: https://ethereum-magicians.org/t/eip-4863-beacon-chain-push-withdrawals/8465
|
||
|
|
status: Stagnant
|
||
|
|
type: Standards Track
|
||
|
|
category: Core
|
||
|
|
created: 2022-02-28
|
||
|
|
---
|
||
|
|
|
||
|
|
## Abstract
|
||
|
|
|
||
|
|
Introduce a new [EIP-2718 transaction type](./eip-2718.md) 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](./eip-4788.md) + 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](./eip-2718.md) 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](../LICENSE.md).
|