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 and RFC 8174.
Starting from the beginning of the epoch when this EIP is activated, Consensus Layer client MUST use the modified process_consolidation_request function which code is outlined below.
New get_pending_balance_to_consolidate
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 exceeds the max effective balance.
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 exist
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 consolidations
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 do.
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.
Security Considerations
When consolidation request results in max effective balance exceeded, it is cancelled on the Consensus Layer,
neither request fee nor transaction gas cost are refunded in this case.
Copyright
Copyright and related rights waived via CC0.
