Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update EIP-4895: validator_index and more info around index #5835

Merged
merged 1 commit into from
Oct 25, 2022
Merged

Update EIP-4895: validator_index and more info around index #5835

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 11 additions & 8 deletions EIPS/eip-4895.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,12 +40,15 @@ Beginning with the execution timestamp `FORK_TIMESTAMP`, execution clients **MUS
Define a new payload-level object called a `withdrawal` that describes withdrawals that have been validated at the consensus layer.
`Withdrawal`s are syntactically similar to a user-level transaction but live in a different domain than user-level transactions.

`Withdrawal`s have three key pieces of information supplied from the consensus layer:
1. a monotonically increasing `index` as a `uint64` value that uniquely identifies each withdrawal
2. a recipient for the withdrawn ether `address` as a 20-byte value
3. an `amount` of ether given in wei as a 256-bit value.
`Withdrawal`s 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 on the consensus layer the withdrawal corresponds to
3. a recipient for the withdrawn ether `address` as a 20-byte value
4. an `amount` of ether given in wei as a 256-bit value.

`Withdrawal` objects are serialized as a RLP list according to the schema: `[index, address, amount]`.
*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

Expand All @@ -54,8 +57,8 @@ The execution payload gains a new field for the `withdrawals` which is an RLP li
For example:

```python
withdrawal_0 = [index_0, address_0, amount_0]
withdrawal_1 = [index_1, address_1, amount_1]
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]
```

Expand Down Expand Up @@ -145,7 +148,7 @@ An entirely new type of object firewalls off generic EVM execution from this typ
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).
This bound applies to both compuggational 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?

Expand Down