Abstract
This EIP allows exits to be routed through the consolidation queue when it is shorter than the exit queue, consuming churn that is allocated to consolidations. This democratizes access to a feature that is currently only available to validators with at least 2048 ETH through a loophole in the consolidation logic. The protocol then makes more efficient usage of the churn that its security parameters (weak subjectivity period) allow, and is able to process more exits without any security reduction.
Motivation
The existing design of consolidation mechanism allows validators with at least 2048 ETH to use the consolidation queue for exits through a loophole in the consolidation logic. When there is an imbalance between exit and consolidation queues favoring the latter, as has been the case since the introduction of the consolidation feature, this becomes an appealing way to speed up withdrawals. However, this feature is only available to a subset of validators, creating an unfair advantage.
Rather than removing this unintended feature, this EIP democratizes it by making it available to all exits. This approach preserves fairness by ensuring equal access to this efficiency improvement, while also providing concrete benefits to the network. When consolidation activity is low, the consolidation churn would otherwise go unused. By allowing exits to use this churn, we ensure it is not wasted and can be put to productive use. This is particularly important given the current state of exit queue congestion, as the exit queue has been longer than forty days for an extended period of time. Long queues degrade user experience, slow operator response to market or operational events, and reduce the network's ability to reconfigure stake more quickly after adverse events. Besides, solo stakers are arguably the participants that suffer the most from a lack of liquidity today, as they do not have the ability to issue a liquid staking token or maintain liquidity reserves.
By allowing exits to use consolidation churn when available, the maximum exit throughput increases significantly, without any security reduction since we are only reallocating churn that the protocol has already accounted for. In particular, the maximum exit churn that can be processed becomes get_activation_exit_churn_limit(state) + 3 * get_consolidation_churn_limit(state) // 2, where the 3 // 2 factor comes from the fact that one unit of exit churn corresponds to 2/3 of a unit of consolidation churn. With current parameters and with the current total stake approximately 35.7M ETH, this results in 256 (the capped exit churn) + (544 - 256) * 3/2 (the consolidation churn adjusted by the 3/2 factor) = 688 ETH per epoch, representing approximately a 2.5x increase over the current maximum exit churn of 256 ETH per epoch.
Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Starting from the beginning of the epoch when this EIP is activated, Consensus Layer clients MUST use the modified compute_exit_epoch_and_update_churn function which routes exits through the consolidation queue when it is shorter than the exit queue.
Modified compute_exit_epoch_and_update_churn
The only modification is this addition at the start of compute_exit_epoch_and_update_churn:
if state.earliest_exit_epoch > state.earliest_consolidation_epoch:
return compute_consolidation_epoch_and_update_churn(state, 2 * exit_balance // 3)
In particular, we route exits through the consolidation queue whenever state.earliest_exit_epoch > state.earliest_consolidation_epoch, by using compute_consolidation_epoch_and_update_churn. Note that the exit_balance passed to the latter is only 2 * exit_balance // 3, because each unit of exit churn corresponds to 2/3 units of consolidation churn from a weak subjectivity perspective. This way, we keep the weak subjectivity impact of the consolidation queue the same regardless of whether it is used by consolidations or by exits, maximizing the amount of operations we can process while keeping the same security guarantees.
The full function is as follows:
def compute_exit_epoch_and_update_churn(state: BeaconState, exit_balance: Gwei) -> Epoch:
activation_exit_epoch = compute_activation_exit_epoch(get_current_epoch(state))
earliest_exit_epoch = max(state.earliest_exit_epoch, activation_exit_epoch)
# NEW in this EIP
earliest_consolidation_epoch = max(state.earliest_consolidation_epoch, activation_exit_epoch)
if earliest_exit_epoch > earliest_consolidation_epoch:
return compute_consolidation_epoch_and_update_churn(state, 2 * exit_balance // 3)
# UNCHANGED FROM HERE
per_epoch_churn = get_exit_churn_limit(state)
# New epoch for exits.
if state.earliest_exit_epoch < earliest_exit_epoch:
exit_balance_to_consume = per_epoch_churn
else:
exit_balance_to_consume = state.exit_balance_to_consume
# Exit doesn't fit in the current earliest epoch.
if exit_balance > exit_balance_to_consume:
balance_to_process = exit_balance - exit_balance_to_consume
additional_epochs = (balance_to_process - 1) // per_epoch_churn + 1
earliest_exit_epoch += additional_epochs
exit_balance_to_consume += additional_epochs * per_epoch_churn
# Consume the balance and update state variables.
state.exit_balance_to_consume = exit_balance_to_consume - exit_balance
state.earliest_exit_epoch = earliest_exit_epoch
return state.earliest_exit_epoch
Rationale
The decision to democratize access to this unintended feature, rather than removing it or keeping it as is, is driven by:
- Fairness: All validators gain equal access to this efficiency improvement, rather than it being restricted to those with at least 2048 ETH who can exploit the loophole.
- Efficiency: When consolidation activity is low, the consolidation churn would otherwise go unused. By allowing exits to use this churn, we ensure it is not wasted and can be put to productive use, improving staking liquidity with unchanged security guarantees.
To summarize, fairness is a strong motivation to either remove the feature or democratize it, and democratizing it is preferable to removing because we get a lot of efficiency benefits from it without any security cost.
Backwards Compatibility
This EIP introduces backwards-incompatible changes to the Consensus Layer and must be activated via scheduled network upgrade.
Test Cases
<-- TODO -->
Security Considerations
Weak subjectivity period
This EIP does not impact the weak subjectivity period at all. The total churn remains the same, it is just allocated differently. In particular, the conversion factor (exit_balance * 2 // 3) preserves the same weak subjectivity impact regardless of whether consolidation churn is allocated to exits or to consolidations.
Copyright
Copyright and related rights waived via CC0.
