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.
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.
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.
compute_exit_epoch_and_update_churnThe only modification is this addition at the start of compute_exit_epoch_and_update_churn:
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:
The decision to democratize access to this unintended feature, rather than removing it or keeping it as is, is driven by:
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.
This EIP introduces backwards-incompatible changes to the Consensus Layer and must be activated via scheduled network upgrade.
<-- TODO -->
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 and related rights waived via CC0.