Try   HackMD

Issue: Add operation for withdrawal credentials change operation

What?

New operation and signed message is proposed for Eth2, BLSSetWithdrawal, which could permanently change withdrawal_credentials:

BLSSetWithdrawal

class BLSSetWithdrawal(Container):
    bls_withdrawal_pubkey: Bytes32   # Reveal of withdrawal public key
    withdrawal_credentials: Bytes32  # New withdrawal credentials, shouldn't start with BLS_WITHDRAWAL_PREFIX (0x00)
    validator_index: ValidatorIndex

And SignedBLSSetWithdrawal message:

SignedBLSSetWithdrawal

class SignedBLSSetWithdrawal(Container):
    message: BLSSetWithdrawal
    signature: BLSSignature  # Signed by withdrawal BLS key

Why?

It's already confirmed that at least one extra withdrawal target option will be supported with merge of PR #2149 "Eth1 withdrawal credentials (0x01)" by @djrtwo. While new validators could submit deposits using this option, there were already tons of deposits before this PR was merged and some of their owners could be interested in Eth1 withdrawal. Moreover, for some parties it could be a best flow of withdrawal control during validator lifecycle to start with BLS key 0x00 withdrawal credentials and change it's target to Eth1 address later with 0x01 or another options introduced in future.

How?

  • we verify that current validator’s withdrawal_credentials is started with BLS_WITHDRAWAL_PREFIX (0x00)
  • we verify that new credentials are not started with BLS_WITHDRAWAL_PREFIX (0x00)

There are several assessments when choosing such behavior of this operation:

  • Why don’t allow change to another BLS public key? There are 2 most obvious usages for 0x00 to another 0x00 swaps:
    • Validator's withdrawal key was compromised. For some validators it would mean the validator signing key could be under attack too and the safest way is to withdraw now. Changing credentials to explicit target works in the safest way in this case
    • Validators could be traded on some market by withdrawal pubkey change. Currently there is no mechanism to change validator's signing key and it's not known whether it will be introduced in future. Also it provides additional load on beacon chain network and block size making this type of message to fight for its place under the sun with Deposit, Attestation and other more important network message types.
  • Whether to check that withdrawal_credentials is in the currently supported range. The answer should be “no”, as the deposit contract already doesn’t check it. It’s a kind of risk for the minutest number of user errors, but by changing this we could open a way to a number of bugs that could affect all users.

Draft implementation:

def process_bls_set_withdrawal(state: BeaconState, signed_bls_set_withdrawal: SignedBLSSetWithdrawal) -> None:
    set_withdrawal = signed_bls_set_withdrawal.message
    validator = state.validators[set_withdrawal.validator_index]
    # Verify the validator has BLS pubkey commitment
    assert validator.withdrawal_credentials[:1] == BLS_WITHDRAWAL_PREFIX
    # Verify the validator is active
    assert is_active_validator(validator, get_current_epoch(state))
    # Verify exit has not been initiated
    assert validator.exit_epoch == FAR_FUTURE_EPOCH
    # Verify new withdrawal credentials doesn't start with BLS_WITHDRAWAL_PREFIX
    assert set_withdrawal.withdrawal_credentials[:1] != BLS_WITHDRAWAL_PREFIX
    # Verify BLS pubkey reveal is correct
    assert hash(set_withdrawal.withdrawal_pubkey)[1:] == validator.withdrawal_credentials[1:]
    # Verify signature
    domain = get_domain(state, DOMAIN_BLS_SET_WITHDRAWAL, get_current_epoch(state))
    signing_root = compute_signing_root(set_withdrawal, domain)
    assert bls.Verify(set_withdrawal.withdrawal_pubkey, signing_root, signed_bls_set_withdrawal.signature)
    # Update withdrawal credentials
    validator.withdrawal_credentials = set_withdrawal.withdrawal_credentials

Some concerns

We have two options here, and I'm not sure, which way should we go:

  • allow change of credentials only for validators that doesn't initiate the exit
  • allow change of credentials for exited validators

Second option requires extra processing of withdrawals after withdrawal_credentials are changed for already exited validators. It’s not straightforward and requires thoughtful implementation to avoid bugs. For example, when we have 2 active withdrawal options, we should verify that one was not processed before withdrawal_credentials change, though Eth1 withdrawal is planned to be automatically on validator exit without extra messages on Beacon Chain, while BLS key withdrawal will require new message with processing.

Some important notes

  • this approach means once withdrawal_credentials are changed from BLS_WITHDRAWAL_PREFIX (0x00) to any other, withdrawal target could not be changed anymore. But this is already concreted by PR #2149
  • BLSSetWithdrawal could be added already, as nothing prevents to submit withdrawal_credentials to Deposit Contract today with a prefix other than BLS_WITHDRAWAL_PREFIX (0x00)

Simple eth1 withdrawals (beacon-chain centric) with BLSSetWithdrawalAddress proposal by @djrtwo inspiring this issue

Eth1 withdrawal credentials (0x01) #2149 by @djrtwo - PR merged in specs

Withdrawal credential rotation from BLS to Eth1 - some alternative approaches of withdrawal credentials change

Allow withdrawal_credentials to point to an eth1 address #2040 by @dapplion - Issue to add eth1 withdrawal prefix

Last changed by 
 
Dmitry S.
0
648

Read more

Low participation in Hive issue

Hive counts participation in another manner, not like us.Hive participation data for 1 epoch:

Oct 4, 2022
Eth2 to Eth1 Validator's withdrawal design [WIP]

Currently Ethereum 2 supports deposits with the only option, deposits from Ethereum 1 and there are no options for validator's stack or its part to be withdrawn. We want to add an option for Ethereum 1 withdrawals following validator exit as the simplest approach for validator owners to get their deposit back with rewards. No option for partial withdrawal is suggested due to higher complexity and lower safety of possible solutions and minor losses on reentry which should take about a day. Our highest priority is to make deposit-withdrawal processes handled with maximum level of autonomy and separation of validator and funder's roles to make possible creation of shared owned validators. Concept of Ethereum shared stacking pool is created according to the specification and currently in testing. Withdrawal implementation requires a set of changes in both ETH2 BeaconChain and ETH1. Contents: 1. Changes in BeaconChain   1.1 Withdrawal credentials for Eth1 withdrawal     1.1.1 Message for changing withdrawal credentials   1.2 Withdrawals   1.3 Withdrawal processing

Sep 7, 2021
Using total difficulty threshold for hardfork anchor: what could go wrong?

[by TXRX Team, Dmitriy Shmatko and Mikhail Kalinin(link), evaluation code is here] In the upcoming Merge Fork which encloses the current PoW chain into the Beacon chain as an Execution Layer, total difficulty was chosen as a point of transition instead of a block number (see Terminal total difficulty vs block number). This approach negotiates the risk of forking a wrong chain backed by minor hash-power but could lead to other risks during transition. In this post we are going to measure these risks and propose changes to fork schema if any is required to decrease the possibility of unforeseen transition flow. Happy flow It's expected that merge client settings will be known in a month before merge happens, so client developers could update their software and validator owners could update their nodes. At some announced epoch number, say, MERGE_FORK_EPOCH the action begins: Beacon chain nodes calculates votes in the last voting period to get some major-backed Eth1Data with block_hash reference to the block in the Mainnet. The corresponding block is called anchor block and becomes a point from which merge total_difficulty on PoW chain side is calculated with the following formula (see spec): def compute_transition_total_difficulty(anchor_pow_block: PowBlock) -> uint256: seconds_per_voting_period = EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH * SECONDS_PER_SLOT pow_blocks_per_voting_period = seconds_per_voting_period // SECONDS_PER_ETH1_BLOCK

Aug 16, 2021
Purging BeaconState ever-growing Lists

In our approach for providing Validator withdrawal feature we use BeaconState List to store withdrawal receipts from processed requests and automatical withdrawal tasks. Such method assumes data is growing with the time and nothing limits its size. The obvious downside of it is growing size of BeaconState, when every non-light client needs to keep old Withdrawals in state. We propose to purge old Wihdrawals up to client settings, so some clients could store all historical Withdrawals and others could be ok with storing only latest few thousands. Also similar approach could be applied not only for Withdrawals but for other growing parts of state. Accumulators Accumulators are already proposed solution for growing state data. It works in following manner: we have circle buffer for items, for, say, 16384 entities. And we have list for old buffer roots. So, this list grows with time but 16384 times slower in this example. There are several downsides we see in accumulators and want to solve it with purging approach: Old items are still needed by some clients. There should be a mechanism to sync them, there should be a mechanism for clients to request old item which is more than buffer size older. Buffer size is part of a specification. Every client should follow it and cannot have its custom history settings. Accumulators still grows with time. It could be not an issue at the launch, but with grown usage it could become an issue to.

Jun 7, 2021
Read more from Dmitry S.
Published on HackMD