Add EIP: Prevent using consolidations as withdrawals

EIPS/eip-8071.md

@@ -0,0 +1,166 @@
+---
+eip: 8071
+title: Prevent using consolidations as withdrawals
+description: Cancels consolidation if the max effective balance of the target validator will be exceeded, preventing the withdrawal of the unused balance
+author: Mikhail Kalinin (@mkalinin), Francesco D'Amato (@fradamt)
+discussions-to: https://ethereum-magicians.org/t/eip-8071-prevent-using-consolidations-as-withdrawals/26037
+status: Draft
+type: Standards Track
+category: Core
+created: 2025-10-29
+---
+
+## Abstract
+
+Cancels a consolidation request if the effective balance of the target validator would exceed the max effective balance after processing it, which would result in the excess balance being withdrawn. This is an unintended way to speed up withdrawals when the consolidation queue is faster than the exit queue.
+
+## Motivation
+
+The existing design of consolidation mechanism leaves an opportunity to use consolidation queue for exits which becomes appealing to be abused when there is an imbalance between exit and consolidation queues favoring the latter.
+
+At the date of writing this EIP, the consolidation flaw is being heavily exploited. There are public write ups on how to speed up withdrawals by using this vulnerability.
+
+Even though this is a UX rather than security issue, consolidation queue was never meant to be used for withdrawals, which makes the fix introduced by this EIP an important modification.
+
+## 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](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174).
+
+Starting from the beginning of the epoch when this EIP is activated, Consensus Layer client **MUST** use modified `process_consolidation_request` function which code is outlined below.
+
+### New `get_pending_balance_to_consolidate`
+
+```python
+def get_pending_balance_to_consolidate(state: BeaconState, target_index: ValidatorIndex) -> Gwei:
+    pending_balance_to_consolidate = Gwei(0)
+    for pending_consolidation in state.pending_consolidations:
+        if pending_consolidation.target_index == target_index:
+            source_validator = state.validators[pending_consolidation.source_index]
+            pending_balance_to_consolidate += source_validator.effective_balance
+    return pending_balance_to_consolidate
+```
+
+### Modified `process_consolidation_request`
+
+*Note*: This function is extended with the check of the target's balance after consolidation and cancels consolidation request if the balance exceedes the max effective balance.
+
+```python
+def process_consolidation_request(
+    state: BeaconState, consolidation_request: ConsolidationRequest
+) -> None:
+    if is_valid_switch_to_compounding_request(state, consolidation_request):
+        validator_pubkeys = [v.pubkey for v in state.validators]
+        request_source_pubkey = consolidation_request.source_pubkey
+        source_index = ValidatorIndex(validator_pubkeys.index(request_source_pubkey))
+        switch_to_compounding_validator(state, source_index)
+        return
+
+    # Verify that source != target, so a consolidation cannot be used as an exit
+    if consolidation_request.source_pubkey == consolidation_request.target_pubkey:
+        return
+    # If the pending consolidations queue is full, consolidation requests are ignored
+    if len(state.pending_consolidations) == PENDING_CONSOLIDATIONS_LIMIT:
+        return
+    # If there is too little available consolidation churn limit, consolidation requests are ignored
+    if get_consolidation_churn_limit(state) <= MIN_ACTIVATION_BALANCE:
+        return
+
+    validator_pubkeys = [v.pubkey for v in state.validators]
+    # Verify pubkeys exists
+    request_source_pubkey = consolidation_request.source_pubkey
+    request_target_pubkey = consolidation_request.target_pubkey
+    if request_source_pubkey not in validator_pubkeys:
+        return
+    if request_target_pubkey not in validator_pubkeys:
+        return
+    source_index = ValidatorIndex(validator_pubkeys.index(request_source_pubkey))
+    target_index = ValidatorIndex(validator_pubkeys.index(request_target_pubkey))
+    source_validator = state.validators[source_index]
+    target_validator = state.validators[target_index]
+
+    # Verify source withdrawal credentials
+    has_correct_credential = has_execution_withdrawal_credential(source_validator)
+    is_correct_source_address = (
+        source_validator.withdrawal_credentials[12:] == consolidation_request.source_address
+    )
+    if not (has_correct_credential and is_correct_source_address):
+        return
+
+    # Verify that target has compounding withdrawal credentials
+    if not has_compounding_withdrawal_credential(target_validator):
+        return
+
+    # Verify the source and the target are active
+    current_epoch = get_current_epoch(state)
+    if not is_active_validator(source_validator, current_epoch):
+        return
+    if not is_active_validator(target_validator, current_epoch):
+        return
+    # Verify exits for source and target have not been initiated
+    if source_validator.exit_epoch != FAR_FUTURE_EPOCH:
+        return
+    if target_validator.exit_epoch != FAR_FUTURE_EPOCH:
+        return
+    # Verify the source has been active long enough
+    if current_epoch < source_validator.activation_epoch + SHARD_COMMITTEE_PERIOD:
+        return
+    # Verify the source has no pending withdrawals in the queue
+    if get_pending_balance_to_withdraw(state, source_index) > 0:
+        return
+
+    # [New in EIPXXXX]
+    # Verify that the consolidating balance will
+    # end up as active balance, not as excess balance
+    target_balance_after_consolidation = (
+        get_pending_balance_to_consolidate(state, target_index)
+        + source_validator.effective_balance
+        + state.balances[target_index]
+    )
+    if target_balance_after_consolidation > get_max_effective_balance(target_validator):
+        return
+
+    # Initiate source validator exit and append pending consolidation
+    source_validator.exit_epoch = compute_consolidation_epoch_and_update_churn(
+        state, source_validator.effective_balance
+    )
+    source_validator.withdrawable_epoch = Epoch(
+        source_validator.exit_epoch + MIN_VALIDATOR_WITHDRAWABILITY_DELAY
+    )
+    state.pending_consolidations.append(
+        PendingConsolidation(source_index=source_index, target_index=target_index)
+    )
+```
+
+## Rationale
+
+### Iterating over pending consolidaitons
+
+The new design introduces an iteration over pending consolidations which increases complexity of consolidation processing.
+
+This is done to handle the case when there are multiple consolidations with the same target and each of them doesn't exceed the max effective balance while all of them together does.
+
+## Backwards Compatibility
+
+This EIP introduces backwards-incompatible changes to the Consensus Layer and must be activated via scheduled network upgrade.
+
+## Test Cases
+
+* test_single_consolidation_request_at_max_eb
+* test_no_pending_consolidations_exceeding_max_eb
+* test_single_pending_consolidation_exceeding_max_eb
+* test_multiple_pending_consolidations_at_max_eb
+* test_multiple_pending_consolidations_exceeding_max_eb
+* test_exceeding_max_eb_with_the_target_balance_but_not_eb
+* test_exceeding_max_eb_with_the_source_eb_but_not_the_balance
+* test_multiple_pending_consolidations_exceeding_max_eb_with_the_source_eb_but_not_the_balance
+
+All of the above test cases are implemented [here](../assets/eip-8071/test_process_consolidation_request.py).
+
+## Security Considerations
+
+When consolidation reuqest results in max effective balance exceed it is cancelled on the Consensus Layer,
+neither request fee nor transaction gast cost are refunded in this case.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).