EIP-7251 Higher validator maximum effective balance (Increase the MAX_EFFECTIVE_BALANCE)
Final · Consensus & staking · EIP status Final · created 2023-06-28
Raises the effective balance cap that counts for a single validator from 32 ETH to 2048 ETH. While the 32 ETH minimum stays unchanged, this enables large operators to consolidate validators and solo stakers to compound their rewards.
Why it is needed
As of October 3, 2023, more than 830,000 validators participate in the consensus layer. Because the stake of a single validator is capped at 32 ETH, a single entity ends up running thousands of 'duplicate validators' that sit on the same beacon node and differ only in signing key. This 32 ETH cap is technical debt from the early sharding design, which assumed that a committee had to have an honest majority. Committees are now used only for attestation aggregation, so a single honest participant is enough, and the security reason to keep the cap low is gone. Meanwhile, the growing number of validators keeps increasing the number of P2P messages, the number of BLS signatures that must be aggregated every epoch, and the memory usage of the beacon state (BeaconState). The proposal is therefore to keep the 32 ETH minimum balance and raise only the cap, so that the size of the validator set shrinks.
What changes
Today
- A single validator is credited with an effective balance of at most 32 ETH
- Large operators split the same stake across thousands of validators and signing keys
- To merge validators, you must withdraw and deposit again, going through the activation queue from the start
- Solo stakers do not get compounding rewards, and they can add validators only in units of 32 ETH
After EIP-7251
- The effective balance cap rises to 2048 ETH, and the 32 ETH minimum activation balance is kept
- By sending a consolidation request to an execution layer contract, you can merge validators inside the protocol without going through the withdrawal and activation queues
- A validator switched to the 0x02 compounding credential accumulates rewards in its effective balance and can stake a flexible amount such as 40 ETH
- You can trigger a partial withdrawal from the execution layer and take out the excess balance without exiting the validator
Who is affected
- Large node operators: They can consolidate thousands of validators into a small number of large validators, reducing the number of beacon nodes and signing keys they need to run. The initial slashing penalty is adjusted to a negligible level, which also reduces the risk involved in consolidation.
- Solo stakers: They get the compounding effect of rewards being reflected in the effective balance, and they can stake an intermediate amount such as 40 ETH instead of gathering 64 ETH to run two validators.
- Client teams: With fewer validators, the load from P2P messages, BLS signature aggregation, and beacon state memory goes down. In exchange, clients must implement the consolidation request contract and the end-of-block system call handling.
- Staking service and contract developers: The consolidation request fee changes every block and any overpayment is not refunded, so a contract must first query the current fee and send the exact amount.
In depth
New constants: separating the 2048 ETH cap from the 32 ETH minimum
Previously, a single MAX_EFFECTIVE_BALANCE served as both the minimum threshold for activation and the effective balance cap. This EIP separates the two, defining MIN_ACTIVATION_BALANCE as Gwei(2**5 * 10**9) (32 ETH) and MAX_EFFECTIVE_BALANCE_ELECTRA as Gwei(2**11 * 10**9) (2048 ETH). To have compounding apply up to the cap, a Bytes1('0x02') withdrawal credential, COMPOUNDING_WITHDRAWAL_PREFIX, is required, and has_compounding_withdrawal_credential checks for it. is_eligible_for_activation_queue now uses MIN_ACTIVATION_BALANCE instead of MAX_EFFECTIVE_BALANCE, so the entry threshold for solo staking stays the same.
Structure of a consolidation request
A consolidation request is an EIP-7685 type 0x02 request made up of three fields: source_address (Bytes20), source_pubkey (Bytes48), and target_pubkey (Bytes48). The request is received by a contract predeployed at CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS (0x0000BBdDc7CE488642fb579F8B00f3a590007251). The contract has three paths. If the input is exactly 96 bytes, it adds a request. If the input length is 0, it returns the current fee. If the system address calls it, it dequeues that block's share of requests from the queue. The contract records CALLER (msg.sender) as source_address, so the request is valid only if the address recorded in the 0x01 withdrawal credential in the beacon state makes the call directly.
Fee mechanism and per-block limits
The request fee is computed with fake_exponential(MIN_CONSOLIDATION_REQUEST_FEE, excess, CONSOLIDATION_REQUEST_FEE_UPDATE_FRACTION). The constants are MIN_CONSOLIDATION_REQUEST_FEE=1 and CONSOLIDATION_REQUEST_FEE_UPDATE_FRACTION=17. The per-block target (TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK) is 1 and the maximum (MAX_CONSOLIDATION_REQUESTS_PER_BLOCK) is 2, and the fee rises as usage above the target accumulates. The target of 1 is a value meant to restrain consolidation requests as much as possible, and the maximum of 2 is a value meant to allow a compounding credential switch and a consolidation request to fit in the same block. Before activation, the excess slot holds EXCESS_INHIBITOR (2**256-1), which blocks fee computation before the first system call and is reset to 0 on the first update. Overpaid fees are not refunded, so a contract must first read the fee with staticcall and pay the exact amount. An EOA that requests directly will always overpay, so the original text recommends estimating the appropriate amount through transaction simulation.
End-of-block system call rules
Every execution block in which this EIP is active must call the contract at SYSTEM_ADDRESS (0xfffffffffffffffffffffffffffffffffffffffe) after transaction processing finishes. This call has a dedicated gas limit of 30_000_000. The gas it consumes is not counted toward the block's gas usage and is excluded from the block gas limit check. It also does not follow the EIP-1559 fee burn rule, so there must be no value transfer. The call dequeues requests from the queue (dequeue_consolidation_requests), updates the excess request count (update_excess_consolidation_requests), and resets the block count to 0 (reset_consolidation_requests_count). The dequeued requests must go into the EIP-7685 request list in the same order they were returned. If the address has no code or the call fails, the block itself is invalid.
Consensus layer changes
There are four core changes. First, raise the cap while keeping MIN_ACTIVATION_BALANCE as the floor. Second, add in-protocol consolidation (process_consolidation) that bypasses the withdrawal and activation queues. Third, as part of EIP-7002, allow execution layer-triggered partial withdrawals, so that, for example, a 100 ETH validator can take out up to 68 ETH without exiting. Fourth, make the initial slashing penalty negligible. The previous penalty was 1/32 of the effective balance and grew in proportion to the balance, which made large validators reluctant to consolidate. To support this, the churn limit is changed to be based on weight (balance) rather than the number of validators, and deposits are queued in the PendingDeposit queue and subject to the same rate limit. Top-up deposits also go through the activation queue. Withdrawal churn usage is capped at 256 ETH (equivalent to 8 validators of 32 ETH), and the remaining churn is allocated to consolidation processing. The full specification is in electra/beacon-chain.md.
Consolidation queue hard limit
Admitting up to 2 requests per block can be faster than the consolidation churn processing rate, so there is a risk that the consolidation queue grows without bound. The queue size is therefore given a hard limit of 262,144 entries. This corresponds to 4 MB of data in the beacon state. Consolidation requests beyond the limit are dropped by the consensus layer and must be resubmitted, and the fee already paid is not refunded in that case.
Security analysis: committee, aggregator, and proposer selection
Even in the worst case where all committees are consolidated, the probability that an attacker takes over an attestation committee stays low, and the share of honest validators required remains well below the 2/3 supermajority needed for finality. Aggregator selection used to be a per-validator VRF lottery, which could favor an attacker who had not consolidated. This proposal changes the lottery to be weight-based, so the probability of having at least one honest aggregator does not get worse. Proposer selection is already weighted by the ratio of effective balance to MAX_EFFECTIVE_BALANCE, so it is left as is, but the lower probability slightly increases the time needed to compute the next proposer. Sync committee selection is also already balance-weighted, so no light client protocol changes are needed. This EIP is a specification whose status is finalized as Final.