update EIP with validator_index and more info around index (ether…

…eum#5835)

EIPS/eip-4895.md

@@ -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
 
@@ -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]
 ```
 
@@ -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?