Increases the constant MAX_EFFECTIVE_BALANCE, while keeping the minimum staking balance 32 ETH. This permits large node operators to consolidate into fewer validators while also allowing solo-stakers to earn compounding rewards and stake in more flexible increments.
As of October 3, 2023, there are currently over 830,000 validators participating in the consensus layer. The size of this set continues to grow due, in part, to the MAX_EFFECTIVE_BALANCE, which limits the stake of a single validator to 32 ETH. This leads to large amounts of "redundant validators", which are controlled by a single entity, possibly running on the same beacon node, but with distinct BLS signing keys. The limit on the MAX_EFFECTIVE_BALANCE is technical debt from the original sharding design, in which subcommittees (not the attesting committee but the committee calculated in is_aggregator) needed to be majority honest. As a result, keeping the weights of subcommittee members approximately equal reduced the risk of a single large validator containing too much influence. Under the current design, these subcommittees are only used for attestation aggregation, and thus only have a 1/N honesty assumption.
With the security model of the protocol no longer dependent on a low value for MAX_EFFECTIVE_BALANCE, we propose raising this value while keeping the minimum validator threshold of 32 ETH. This increase aims to reduce the validator set size, thereby reducing the number of P2P messages over the network, the number of BLS signatures that need to be aggregated each epoch, and the BeaconState memory footprint. This change adds value for both small and large validators. Large validators can consolidate to run fewer validators and thus fewer beacon nodes. Small validators now benefit from compounding rewards and the ability to stake in more flexible increments (e.g., the ability to stake 40 ETH instead of needing to accumulate 64 ETH to run two validators today).
| Name | Value | Comment |
|---|---|---|
CONSOLIDATION_REQUEST_TYPE | 0x02 | The EIP-7685 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 | |
CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT | 1 | |
CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT | 2 | Pointer to the head of the consolidation request message queue |
CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT | 3 | Pointer to the tail of the consolidation request message queue |
CONSOLIDATION_REQUEST_QUEUE_STORAGE_OFFSET | 4 | The start memory slot of the in-state consolidation request message queue |
MAX_CONSOLIDATION_REQUESTS_PER_BLOCK | 2 | Maximum number of consolidation requests that can be dequeued into a block |
TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK | 1 | |
MIN_CONSOLIDATION_REQUEST_FEE | 1 | |
CONSOLIDATION_REQUEST_FEE_UPDATE_FRACTION | 17 | |
EXCESS_INHIBITOR | 2**256-1 | Excess value used to compute the fee before the first system call |
| Name | Value |
|---|---|
COMPOUNDING_WITHDRAWAL_PREFIX | Bytes1('0x02') |
MIN_ACTIVATION_BALANCE | Gwei(2**5 * 10**9) (32 ETH) |
MAX_EFFECTIVE_BALANCE_ELECTRA | Gwei(2**11 * 10**9) (2048 ETH) |
The new consolidation request is an EIP-7685 request with type 0x02 consisting of the following fields:
source_address: Bytes20source_pubkey: Bytes48target_pubkey: Bytes48The EIP-7685 encoding of a consolidation request is as follows. Note we simply return the encoded request value as returned by the contract.
The contract has three different code paths, which can be summarized at a high level as follows:
96 byte input, concatenated public keys of the source and the target validators.If call data input to the contract is exactly 96 bytes, perform the following:
msg.value >= get_fee())1 for the current block (increment_count())insert_consolidation_request_into_queue())Specifically, the functionality is defined in pseudocode as the function add_consolidation_request():
The following pseudocode can compute the cost of an individual consolidation request, given a certain number of excess consolidation requests.
When the input to the contract is length zero, interpret this as a get request for the current fee, i.e. the contract returns the result of get_fee().
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 consolidation requests validations), call the contract at CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS as SYSTEM_ADDRESS with no calldata. The invocation triggers the following:
dequeue_consolidation_requests())update_excess_consolidation_requests())0 (reset_consolidation_requests_count())Each consolidation request must appear in the EIP-7685 requests list in the exact order returned by dequeue_consolidation_requests().
Additionally, the system call and the processing of that block must conform to the following:
30_000_000.CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, the corresponding block MUST be marked invalid.The functionality triggered by the system call is defined in pseudocode as the function process_consolidation_requests():
The consolidation requests contract is deployed like any other smart contract. A special synthetic address is generated by working backwards from the desired deployment transaction:
The defining features of this EIP are:
MAX_EFFECTIVE_BALANCE, while creating a MIN_ACTIVATION_BALANCE. The core feature of allowing variable size validators.100 ETH validator can remove up to 68 ETH without exiting the validator).The 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.
COMPOUNDING_WITHDRAWAL_PREFIX and MIN_ACTIVATION_BALANCE constants, while introducing the updated value of MAX_EFFECTIVE_BALANCE (MAX_EFFECTIVE_BALANCE_ELECTRA).PendingDeposit container, which is used to track incoming deposits in the weight-based rate limiting mechanism.BeaconState with deposit and partial withdrawal queues, fields needed for deposit, and exit queue weight-based rate limiting.is_eligible_for_activation_queue to check against MIN_ACTIVATION_BALANCE rather than MAX_EFFECTIVE_BALANCE.get_validator_churn_limit to depend on the validator weight rather than the validator count.compute_exit_epoch_and_update_churn to calculate the exit epoch based on the current pending withdrawals.initiate_validator_exit to rate limit the exit queue by balance rather than the number of validators.initialize_beacon_state_from_eth1 to use MIN_ACTIVATION_BALANCE.process_registry_updates to activate all eligible validators.process_pending_deposits, to consume some of the pending deposits.get_validator_from_deposit to initialize the effective balance to zero (it's updated by the pending deposit flow).process_deposit to store incoming deposits in state.pending_deposits.compute_weak_subjectivity_period to use the new churn limit function.has_compounding_withdrawal_credential to check for the 0x02 credential.is_fully_withdrawable_validator to check for compounding credentials.get_validator_excess_balance to calculate the excess balance of validators.is_partially_withdrawable_validator to check for excess balance.get_expected_withdrawals to use excess balance and process pending partial withdrawals.process_consolidation to initiate in-protocol validator consolidation and switch a validator to compounding withdrawal credentials.Full consensus layer specification can be found in ./electra/beacon-chain.md
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.
MAX_EFFECTIVE_BALANCE, while creating a MIN_ACTIVATION_BALANCEWhile 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.
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.
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.
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.
The consolidation smart contract uses a fee mechanism to rate limit the number of requests per block. Details of the fee mechanism are available in EIP-7002.
TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK is chosen to be 1 to rate limit consolidation requests as much as 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.
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.
This change modifies committees and churn, but doesn't significantly impact the security properties.
Given full consolidation as the worst case, the probability of an adversarial takeover of a committee remains low. Even in a high consolidation scenario, the required share of honest validators remains well below the 2/3 supermajority needed for finality.
In the original sharding roadmap, subcommittees were required to be secure with extremely high probability. Now with the sole responsibility of attestation aggregation, we only require each committee to have at least one honest aggregator. Currently, aggregators are selected through a VRF lottery, targeting several validator units that can be biased by non-consolidated attackers. This proposal changes the VRF lottery to consider weight, so the probability of having at least one honest aggregator is not worse.
Proposer selection is already weighted by the ratio of their effective balance to MAX_EFFECTIVE_BALANCE. Due to the lower probabilities, this change will slightly increase the time it takes to calculate the next proposer index.
Sync committee selection is also already weighted by effective balance, so this proposal does not require modifications to the sync protocol. Light clients can still check that a super-majority of participants have signed an update irrespective of their weights since we maintain a weight-based selection probability.
This proposal maintains the activation and exit churn invariants limiting active weight instead of validator count. Balance top-ups are now handled explicitly, being subject to the same activation queue as full deposits.
Calls to the system contract require a fee payment defined by the current contract state. Overpaid fees are not returned to the caller. It is not generally possible to compute the exact required fee amount ahead of time. When adding a consolidation request from a contract, the contract can perform a read operation to check for the current fee and then pay exactly the required amount. Here is an example in Solidity:
Note: the system contract uses the EVM CALLER operation (Solidity: msg.sender) to get the address used in the consolidation request, i.e. the address that calls the system contract must match the 0x01 withdrawal credential recorded in the beacon state.
Note: the above code reverts if the fee is too high, the fee can change significantly between the creation of a consolidation request transaction and its inclusion into a block, thus, this check is very important to avoid overpayments.
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.
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.
Although the likelihood of a failed system call to CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS is extremely low, the behavior in such cases is well-defined: the block is marked as invalid. This consideration directly follows from EIP-7002
This EIP should not have been activated if there is no code present at CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS (i.e., if the chain is not "ready"). This is also similar to the consideration in EIP-7002
Copyright and related rights waived via CC0.