Update EIP-7251: Move to Last Call

EIPS/eip-7251.md

@@ -4,11 +4,12 @@
 description: Allow validators to have larger effective balances, while maintaining the 32 ETH lower bound.
 author: mike (@michaelneuder), Francesco (@fradamt), dapplion (@dapplion), Mikhail (@mkalinin), Aditya (@adiasg), Justin (@justindrake), lightclient (@lightclient)
 discussions-to: https://ethereum-magicians.org/t/eip-7251-increase-the-max-effective-balance/15982
-status: Review
+status: Last Call
+last-call-deadline: 2025-02-21
 type: Standards Track
 category: Core
 created: 2023-06-28
 requires: 7002, 7685
 ---
 ## Abstract
 
@@ -28,7 +29,7 @@
 
 | Name | Value | Comment |
 | - | - | - |
 | `CONSOLIDATION_REQUEST_TYPE` | `0x02` | The [EIP-7685](./eip-7685.md) type prefix for consolidation request |
 | `CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS` | `0x0000BBdDc7CE488642fb579F8B00f3a590007251` | Where to call and store relevant details about consolidation request mechanism |
 | `SYSTEM_ADDRESS` | `0xfffffffffffffffffffffffffffffffffffffffe` | Address used to invoke system operation on contract |
 | `EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT` | `0` | |
@@ -48,19 +49,19 @@
 | - | - |
 | `COMPOUNDING_WITHDRAWAL_PREFIX` | `Bytes1('0x02')` |
 | `MIN_ACTIVATION_BALANCE` | `Gwei(2**5 * 10**9)`  (32 ETH) |
-| `MAX_EFFECTIVE_BALANCE` | `Gwei(2**11 * 10**9)` (2048 ETH) |
+| `MAX_EFFECTIVE_BALANCE_ELECTRA` | `Gwei(2**11 * 10**9)` (2048 ETH) |
 
 ### Execution layer
 
 #### Consolidation request
 
 The new consolidation request is an [EIP-7685](./eip-7685.md) request with type `0x02` consisting of the following fields:
 
 1. `source_address`: `Bytes20`
 2. `source_pubkey`: `Bytes48`
 3. `target_pubkey`: `Bytes48`
 
 The [EIP-7685](./eip-7685.md) encoding of a consolidation request is as follows. Note we simply return the encoded request value as returned by the contract.
 
 ```python
 request_type = CONSOLIDATION_REQUEST_TYPE
@@ -140,7 +141,7 @@
 
 ##### System Call
 
-If the contract is called as `SYSTEM_ADDRESS` with an empty input data, perform the following:
+At the end of processing any execution block where this EIP is active (i.e. after processing all transactions and after performing the block body withdrawal requests validations), call the contract as `SYSTEM_ADDRESS` and perform the following:
 
 * The contract's queue is updated based on consolidation requests dequeued and the consolidation requests queue head/tail are reset if the queue has been cleared (`dequeue_consolidation_requests()`)
 * The contract's excess consolidation requests are updated based on usage in the current block (`update_excess_consolidation_requests()`)
@@ -534,62 +535,73 @@
 Address: 0x0000BBdDc7CE488642fb579F8B00f3a590007251
 ```
 
-#### Block processing
-
-At the end of processing any execution block where this EIP is active (i.e. after processing all transactions and after performing the block body requests validations) client software **MUST** take the following steps:
-
-1. Call the contract as `SYSTEM_ADDRESS` and empty input data to trigger the system subroutine execute.
-2. Check that consolidation requests in the [EIP-7685](./eip-7685.md) requests list matches the list returned from `dequeue_consolidation_requests()` function of the smart contract respecting the order of the returned requests. If this condition does not hold, the block **MUST** be deemed *invalid*.
-
 ### Consensus layer
 
 The defining features of this EIP are:
 
 1. ***Increasing the `MAX_EFFECTIVE_BALANCE`, while creating a `MIN_ACTIVATION_BALANCE`.*** The core feature of allowing variable size validators.
 2. ***Allowing for multiple validator indices to be combined through the protocol.*** A mechanism by which large node operators can combine validators without cycling through the exit and activation queues.
 3. ***Adding execution layer partial withdrawals (part of [EIP-7002](./eip-7002.md)).*** Allowing Execution Layer messages to trigger partial withdrawals in addition to full exits (e.g., a `100 ETH` validator can remove up to `68 ETH` without exiting the validator).
-4. ***Removing the initial slashing penalty (still in discussion).*** This reduces the risk of consolidation for large validators.
+4. ***Making the initial slashing penalty negligible.*** This reduces the risk of consolidation for large validators.
 
 The [Rationale](#rationale) section contains an explanation for each of these proposed core features. A sketch of the resulting changes to the consensus layer is included below.
 
-1. Add `COMPOUNDING_WITHDRAWAL_PREFIX` and `MIN_ACTIVATION_BALANCE` constants, while updating the value of `MAX_EFFECTIVE_BALANCE`.
+1. Add `COMPOUNDING_WITHDRAWAL_PREFIX` and `MIN_ACTIVATION_BALANCE` constants, while introducing the updated value of `MAX_EFFECTIVE_BALANCE` (`MAX_EFFECTIVE_BALANCE_ELECTRA`).
 2. Create the `PendingDeposit` container, which is used to track incoming deposits in the weight-based rate limiting mechanism.
-3. Update the `BeaconState` with fields needed for deposit and exit queue weight-based rate limiting.
+3. Update the `BeaconState` with deposit and partial withdrawal queues, fields needed for deposit and exit queue weight-based rate limiting.
 4. Modify `is_eligible_for_activation_queue` to check against `MIN_ACTIVATION_BALANCE` rather than `MAX_EFFECTIVE_BALANCE`.
 5. Modify `get_validator_churn_limit` to depend on the validator weight rather than the validator count.
 6. Create a helper `compute_exit_epoch_and_update_churn` to calculate the exit epoch based on the current pending withdrawals.
 6. Modify `initiate_validator_exit` to rate limit the exit queue by balance rather than the number of validators.
 7. Modify `initialize_beacon_state_from_eth1` to use `MIN_ACTIVATION_BALANCE`.
 9. Modify `process_registry_updates` to activate all eligible validators.
-10. Add a per-epoch helper, `process_pending_balance_deposits`, to consume some of the pending deposits.
+10. Add a per-epoch helper, `process_pending_deposits`, to consume some of the pending deposits.
 10. Modify `get_validator_from_deposit` to initialize the effective balance to zero (it's updated by the pending deposit flow).
-11. Modify `apply_deposit` to store incoming deposits in `state.pending_balance_deposits`.
-12. Modify `is_aggregator` to be weight-based.
-13. Modify `compute_weak_subjectivity_period` to use the new churn limit function.
-14. Add `has_compounding_withdrawal_credential` to check for the `0x02` credential.
-15. Modify `is_fully_withdrawable_validator` to check for compounding credentials.
-16. Add `get_validator_excess_balance` to calculate the excess balance of validators.
-17. Modify `is_partially_withdrawable_validator` to check for excess balance.
-18. Modify `get_expected_withdrawals` to use excess balance.
-
-
+11. Modify `process_deposit` to store incoming deposits in `state.pending_deposits`.
+12. Modify `compute_weak_subjectivity_period` to use the new churn limit function.
+13. Add `has_compounding_withdrawal_credential` to check for the `0x02` credential.
+14. Modify `is_fully_withdrawable_validator` to check for compounding credentials.
+15. Add `get_validator_excess_balance` to calculate the excess balance of validators.
+16. Modify `is_partially_withdrawable_validator` to check for excess balance.
+17. Modify `get_expected_withdrawals` to use excess balance and process pending partial withdrawals.
+18. Add `process_consolidation` to initiate in-protocol validator consolidation and switching a validator to compounding withdrawal credentials.
+19. Limits the usage of exit churn to 256 ETH (equivalent to 8 validators with 32 ETH effective balance), and defers the surplus of the churn to process consolidations.
+
+Full consensus layer specification can be found in [`./electra/beacon-chain.md`](https://github.com/ethereum/consensus-specs/blob/834e40604ae4411e565bd6540da50b008b2496dc/specs/electra/beacon-chain.md)
 
 ## Rationale
 
 This EIP aims to reduce the total number of validators without changing anything about the economic security of the protocol. It provides a mechanism by which large node operators who control significant amounts of stake can consolidate into fewer validators. We analyze the reasoning behind each of the core features.
 
-1. ***Increasing the `MAX_EFFECTIVE_BALANCE`, while creating a `MIN_ACTIVATION_BALANCE`.***
-    * *While increasing the `MAX_EFFECTIVE_BALANCE` to allow larger-stake validators, it is important to keep the lower bound of `32 ETH` (by introducing a new constant – `MIN_ACTIVATION_BALANCE`) to encourage solo-staking.*
-2. ***Allowing for multiple validator indices to be combined through the protocol.***
-    * *For large staking pools that already control thousands of validators, exiting and re-entering would be extremely slow and costly. The adoption of the EIP will be much higher by allowing in-protocol consolidation.*
-3. ***Adding execution layer partial withdrawals (part of [EIP-7002](./eip-7002.md)).***
-    * *For validators that choose to raise their effective balance ceiling, allowing for custom partial withdrawals triggered from the execution layer increases the flexibility of the staking configurations. Validators can choose when and how much they withdraw but will have to pay gas for the EL transaction.*
-4. ***Removing the initial slashing penalty (still in discussion).***
-    * *To encourage consolidation, we could modify the slashing penalties. The biggest hit comes from the initial penalty of `1/32` of the validator's effective balance. Since this scales linearly on the effective balance, the higher-stake validators directly incur higher risk. By changing the scaling properties, we could make consolidation more attractive.*
+### Increasing the `MAX_EFFECTIVE_BALANCE`, while creating a `MIN_ACTIVATION_BALANCE`
+
+While increasing the `MAX_EFFECTIVE_BALANCE` to allow larger-stake validators, it is important to keep the lower bound of `32 ETH` (by introducing a new constant – `MIN_ACTIVATION_BALANCE`) to encourage solo-staking.
+
+### Allowing for multiple validator indices to be combined through the protocol
+
+For large staking pools that already control thousands of validators, exiting and re-entering would be extremely slow and costly. The adoption of the EIP will be much higher by allowing in-protocol consolidation.
+
+### Adding execution layer partial withdrawals (part of [EIP-7002](./eip-7002.md))
+
+For validators that choose to raise their effective balance ceiling, allowing for custom partial withdrawals triggered from the execution layer increases the flexibility of the staking configurations. Validators can choose when and how much they withdraw but will have to pay gas for the EL transaction.
+
+### Making the initial slashing penalty negligible
+
+To encourage consolidation, we could modify the slashing penalties. The biggest hit comes from the initial penalty of `1/32` of the validator's effective balance. Since this scales linearly on the effective balance, the higher-stake validators directly incur higher risk. By changing the scaling properties, we could make consolidation more attractive.
+
+### Consolidation contract parameter values
+
+The consolidation smart contract uses fee mechainsm to rate limit a number of requests per block. Details of the fee mechanism are available in [EIP-7002](./eip-7002.md#fee-update-rule).
+
+`TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK` is chosen to be `1` to rate limit consolidation requests as much as it's possible.
+`MAX_CONSOLIDATION_REQUESTS_PER_BLOCK` is chosen to be `2` to allow for switching a validator to compounding credentials and requesting a consolidation in the same block.
+
+One consolidation per block is still higher than the size of consolidation churn which can lead to unbounded growth of the consolidation queue.
+Thus, there is a hard limit on the consolidation queue size equal to 262,144 requests which is `4 MB` of data in the beacon state.
 
 ## Backwards Compatibility
 
-This EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork. These changes do not break anything related to current user activity and experience.
+This EIP introduces backward incompatible changes to the block validation rule set and must be accompanied by a hard fork. These changes do not break anything related to current user activity and experience.
 
 ## Security Considerations
 
@@ -644,6 +656,11 @@
 
 Using an EOA to request consolidations will always result in overpayment of fees. There is no way for an EOA to use a wrapper contract to request a consolidation. And even if a way existed, the gas cost of returning the overage would likely be higher than the overage itself. If requesting consolidations from an EOA to the system contract is desired, we recommend that users perform transaction simulations to estimate a reasonable fee amount to send.
 
+### Consolidation queue hard limit
+
+Consolidations exceeding the hard limit of the consolidation queue (262,144 requests) will be discarded by the consensus layer and will need to be re-submitted,
+note that the fee is not refunded in this case.
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).