# 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](https://github.com/zilm13/withdrawal-simulation) 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](#Changes-in-BeaconChain-)   [1.1 Withdrawal credentials for Eth1 withdrawal](#Withdrawal-credentials-for-Eth1-withdrawal-)     [1.1.1 Message for changing withdrawal credentials](#Message-for-changing-withdrawal-credentials-)   [1.2 Withdrawals](#Withdrawals-)   [1.3 Withdrawal processing](#Withdrawal-processing-)   [1.4 JSON-RPC update](#JSON-RPC-update-) [1.5 Partial withdrawals](#Partial-withdrawals-) [1.6 Queues](#Queues-) [2. Changes in ETH1](#Changes-in-ETH1-)   [2.1 Changes to opcodes](#Changes-to-opcodes-)   [2.2 System contract in Eth1](#System-contract-in-Eth1-) [3. Discussion](#Discussion-) **Warning**: This document is under development ## Changes in BeaconChain [^](#Eth2-to-Eth1-Validator’s-withdrawal-design-WIP) ### Withdrawal credentials for Eth1 withdrawal [^](#Eth2-to-Eth1-Validator’s-withdrawal-design-WIP) Proposed by @djrtwo in [eth2.0-specs#2149](https://github.com/ethereum/eth2.0-specs/pull/2149), approved and merged. Adds `0x01`, `ETH1_ADDRESS_WITHDRAWAL_PREFIX` prefix for `withdrawal_credentials` field of `Deposit` and thereafter `Validator`, setting withdrawal target to specific ETH1 address without any possibility to change withdrawal credentials in future to different target including other ETH1 addresses as no specific public key is left for withdrawal for such deposits. #### Message for changing withdrawal credentials [^](#Eth2-to-Eth1-Validator’s-withdrawal-design-WIP) Proposed in [eth2.0-specs#2213](https://github.com/ethereum/eth2.0-specs/issues/2213), discussion. Message **BLSSetWithdrawal** could be issued and processed one time for each validator. It can't change one BLS withdrawal credentials to another. It can only change BLS creds to non-BLS creds. So, it will include change to the already approved ETH1 address withdrawal target right from the box. ### Withdrawals [^](#Eth2-to-Eth1-Validator’s-withdrawal-design-WIP) We define `Withdrawal` object: ```python= class Withdrawal(Container): validator_index: ValidatorIndex withdrawal_credentials: Bytes32 withdrawn_epoch: Epoch amount: Gwei ``` We expect that `Validator`'s `pubkey` couldn't be reused after `Validator`'s exit and information about slashing and withdrawal epoch could be obtained from appropriate `Validator` object. Next, add `Withdrawal` objects list or similar structure to `BeaconState`. ```python= class BeaconState(Container): # [...] # Registry validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] # Withdrawals withdrawals: List[Withdrawal, WITHDRAWAL_REGISTRY_LIMIT] # Randomness # [...] ``` and define list limits: | Name | Value | Unit | Duration | | - | - | :-: | :-: | | `WITHDRAWAL_REGISTRY_LIMIT` | `uint64(2**40)` (= 1,099,511,627,776) | withdrawals | ### Withdrawal processing [^](#Eth2-to-Eth1-Validator’s-withdrawal-design-WIP) We have two options for withdrawal initiation: - **Withdrawal message.** In this case it should be signed by `Validator` as withdrawals with ETH1 `withdrawal_credentials` already don't have a dedicated withdrawal key. On one side it simplifies withdrawal processing doing it only on request, but it's not clear whether it's `Validator`'s responsibility, as validator key owner could block withdrawal to any period of time with such ability. - **Automatical processing.** We could check validator after exit if it's eligible for withdrawal processing and perform it. If not, keep it unchanged until withdrawal is possible. Looks better but there is a room for mistakes. Therefore we choose automatic processing but it should conform to the following properties: - no `Validator` could be processed to withdrawal 2 times successfully, no double withdrawal - if not processed successfully, `Validator` record should remain unchanged to be processed in future In the near term second case means that `Validator` with `withdrawal_credentials` starting with `BLS_WITHDRAWAL_PREFIX` after exit remains unchanged without successful withdrawal, but if `withdrawal_credentials` are changed to one with `ETH1_ADDRESS_WITHDRAWAL_PREFIX` using appropriate [message](#Message-for-changing-withdrawal-credentials-) it should be reprocessed after that, as withdrawal becomes possible. We've started this approach with boolean flag, but later tend to particular epoch number to omit field duplication in `Validator` and `Withdrawal`. We update `Validator` to change withdrawn epoch from `FAR_FUTURE_EPOCH` after successful `Withdrawal` creation: ```python= class Validator(Container): pubkey: BLSPubkey withdrawal_credentials: Bytes32 # Commitment to pubkey for withdrawals effective_balance: Gwei # Balance at stake slashed: boolean # Status epochs activation_eligibility_epoch: Epoch # When criteria for activation were met activation_epoch: Epoch exit_epoch: Epoch withdrawable_epoch: Epoch # When validator can withdraw funds withdrawn_epoch: Epoch # When balance was withdrawn ``` We set `withdrawn_epoch` to 0 by default in order to compliment partial rewards withdrawals in future. There are several cases where even withdrawn validators could be updated, for example, in deposit processing, which should be avoided. All specifications should be checked and protected from this possibility. Generally, we define withdrawal processing in the following manner: ```python= def process_withdrawal(prefix: Byte1): if prefix == ETH1_ADDRESS_WITHDRAWAL_PREFIX: return process_eth1_withdrawal else: return lambda state, index: None def process_withdrawals(state: BeaconState) -> None: epoch = get_current_epoch(state) eligible_validators = [ (i, v) for i, v in enumerate(state.validators) if v.withdrawable_epoch <= epoch and v.withdrawn_epoch < v.withdrawable_epoch] for (i, v) in eligible_validators: process_withdrawal(Byte1(v.withdrawal_credentials[:1]))(state, i) def process_eth1_withdrawal(state: BeaconState, index: ValidatorIndex) -> None validator = state.validators[index] epoch = get_current_epoch(state) assert validator.withdrawable_epoch <= epoch assert ETH1_ADDRESS_WITHDRAWAL_PREFIX == Byte1(validator.withdrawal_credentials[:1]) withdrawal = Withdrawal( validator_index: index, withdrawal_credentials: validator.withdrawal_credentials, withdrawn_epoch: epoch, amount: state.balances[index] ) state.withdrawals.append(withdrawal) state.validators[index].effective_balance = 0 state.validators[index].withdrawn_epoch = epoch state.balances[index] = 0 ``` ### JSON-RPC update [^](#Eth2-to-Eth1-Validator’s-withdrawal-design-WIP) In order to get proofs for Withdrawals, we should add an appropriate JSON-RPC method, so clients will be able to get all required data. Let's call it ```yaml= '/eth/v1/beacon/states/{state_id}/withdrawal': get: operationId: getWithdrawal summary: Get withdrawal description: Retrieves withdrawal with provided pubkey hash. tags: - Beacon parameters: - name: state_id in: path required: true example: head schema: type: string description: | State identifier. Can be one of: "head" (canonical head in node's view), "genesis", "finalized", "justified", \<slot\>, \<hex encoded stateRoot with 0x prefix\>. - name: validator_index in: query required: true description: Corresponding validator's index. schema: type: string example: '1' responses: '200': description: Success content: application/json: schema: title: WithdrawalWithProofResponse type: object properties: data: type: object description: 'Withdrawal object with proofs up to BeaconBlock root' properties: beacon_block_root: allOf: - type: string example: '0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2' pattern: '^0x[a-fA-F0-9]{64}$' - description: Root of BeaconBlock, proofs are constructed at. slot: allOf: - type: string example: '1' - description: The slot to which beacon_block_root corresponds. proof: description: 'Proof of Withdrawal object as described in [`Merkle multiproofs`](https://github.com/ethereum/eth2.0-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs)' type: array items: allOf: - type: string example: '0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2' pattern: '^0x[a-fA-F0-9]{64}$' - description: Bytes32 index: allOf: - type: string example: '1' - description: '[`Generalized index`](https://github.com/ethereum/eth2.0-specs/blob/dev/ssz/merkle-proofs.md#generalized-merkle-tree-index) of Withdrawal object' withdrawal: type: object description: 'Withdrawal object' properties: validator_index: allOf: - type: string example: '1' - description: validator index withdrawal_credentials: allOf: - type: string example: '0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2' pattern: '^0x[a-fA-F0-9]{64}$' - description: Withdrawal credentials of Validator withdrawn_epoch: allOf: - type: string example: '1' - description: epoch of withdrawal amount: allOf: - type: string example: '1' - description: amount of withdrawal in GWei '400': description: The state ID supplied could not be parsed content: application/json: schema: allOf: - type: object properties: code: description: Either specific error code in case of invalid request or http status code type: number example: 404 message: description: Message describing error type: string stacktraces: description: 'Optional stacktraces, sent when node is in debug mode' type: array items: type: string - example: code: 400 message: 'Invalid state ID: current' '404': description: Either state ID or withdrawal not found content: application/json: schema: allOf: - type: object properties: code: description: Either specific error code in case of invalid request or http status code type: number example: 404 message: description: Message describing error type: string stacktraces: description: 'Optional stacktraces, sent when node is in debug mode' type: array items: type: string - example: code: 404 message: State ID or withdrawal not found '500': description: Beacon node internal error. content: application/json: schema: type: object properties: code: description: Either specific error code in case of invalid request or http status code type: number example: 404 message: description: Message describing error type: string stacktraces: description: 'Optional stacktraces, sent when node is in debug mode' type: array items: type: string example: code: 500 message: Internal server error ``` Example implementation, for general proof methods check [Merkle proof formats](https://github.com/ethereum/eth2.0-specs/blob/dev/ssz/merkle-proofs.md) spec: ```python= def get_withdrawal(state: BeaconState, block: BeaconBlock, validator_index: ValidatorIndex): assert state.hash_tree_root() == block.state_root withdrawals = [ (i, w) for i, w in enumerate(state.withdrawals) if w.validator_index == validator_index] if withdrawals: index = withdrawals[-1][0] withdrawal = withdrawals[-1][1] state_index = get_generalized_index(BeaconBlock, ['state_root']) withdrawal_index = get_generalized_index(BeaconState, ['withdrawals', index]) return { 'root': block.hash_tree_root(), 'slot': block.slot, 'proof': [block.get_backing().getter(index).merkle_root() for index in get_helper_indices([state_index])] + [state.get_backing().getter(index).merkle_root() for index in get_helper_indices([withdrawal_index])], 'index': concat_generalized_indices(state_index, withdrawal_index), 'withdrawal': withdrawal } else: return None ``` ### Partial withdrawals [^](#Eth2-to-Eth1-Validator’s-withdrawal-design-WIP) Let's check how difficult it could be to add partial withdrawals at the top of a full withdrawal scheme. Ability to process partial withdrawals should be examined, but there is a big demand for their implementation. New operation and signed message is proposed for Eth2, `BLSWithdrawRewards`, which could inquire for rewards withdrawal, it requires `Validator`'s BLS withdrawal credentials: ```python class BLSWithdrawRewards(Container): withdrawal_credentials: Bytes32 # Withdrawal credentials for reward withdrawal withdrawal_epoch: Epoch # Epoch at which message should be processed validator_index: ValidatorIndex ``` And `SignedBLSWithdrawRewards` message: ```python class SignedBLSWithdrawRewards(Container): message: BLSWithdrawRewards signature: BLSSignature # Signed by withdrawal BLS key ``` Domain: | Name | Value | | - | - | | `DOMAIN_REWARDS_WITHDRAWAL` | `DomainType('0x07000000')` | And withdrawal delay to be sure we are not spammed with withdrawal messages: TODO: why this delay?? | Name | Value | Unit | Duration | | - | - | :-: | :-: | | `MIN_VALIDATOR_REWARDS_WITHDRAWAL_DELAY` | `uint64(2**14)` (= 16,384) | epochs | ~73 days To initiate rewards withdrawal, `Validator` sends appropriate `SignedBLSWithdrawRewards` message. Next we have processing like this: ```python= def process_rewards_withdrawal(state: BeaconState, signed_reward_withdrawal: SignedBLSWithdrawRewards) -> None: """ Processing SignedBLSWithdrawRewards with rewards withdrawal order """ rewards_withdrawal = signed_reward_withdrawal.message validator = state.validators[rewards_withdrawal.validator_index] # 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 # Withdrawals must specify an epoch when they become valid; they are not valid before then assert get_current_epoch(state) >= rewards_withdrawal.withdrawal_epoch # Verify the validator has been active long enough assert get_current_epoch(state) >= validator.activation_epoch + SHARD_COMMITTEE_PERIOD # Verify signature domain = get_domain(state, DOMAIN_REWARDS_WITHDRAWAL, rewards_withdrawal.withdrawal_epoch) signing_root = compute_signing_root(rewards_withdrawal, domain) assert bls.Verify(validator.pubkey, signing_root, signed_rewards_withdrawal.signature) # Initiate rewards withdrawal initiate_rewards_withdrawal(state, rewards_withdrawal.validator_index) def initiate_rewards_withdrawal(state: BeaconState, message: BLSWithdrawRewards) -> None: """ Initiate rewards withdrawal for the validator with index ``index``. """ # Return if validator already initiated exit validator = state.validators[message.validator_index] if validator.exit_epoch != FAR_FUTURE_EPOCH: return # Compute rewards value rewards_value = state.balances[message.validator_index] - MAX_EFFECTIVE_BALANCE if rewards_value <= 0: return # Check that there were no withdrawals recently if validator.withdrawn_epoch + MIN_VALIDATOR_REWARDS_WITHDRAWAL_DELAY < get_current_epoch(state): return # Process partial withdrawal process_validator_rewards_withdrawal(Byte1(message.withdrawal_credentials[:1]))(state, message) def process_validator_rewards_withdrawal(prefix: Byte1): """ Returns rewards withdrawal function for provided withdrawal_credentials prefix """ if prefix == ETH1_ADDRESS_WITHDRAWAL_PREFIX: return process_eth1_rewards_withdrawal else: return lambda state, message: None def process_eth1_rewards_withdrawal(state: BeaconState, message: BLSWithdrawRewards) -> None: """ Process rewards withdrawal for withdrawal_credentials with Eth1 prefix """ index = message.validator_index validator = state.validators[index] epoch = get_current_epoch(state) # Assert it's Eth1 withdawal assert ETH1_ADDRESS_WITHDRAWAL_PREFIX == Byte1(message.withdrawal_credentials[:1]) # Assert we have something to withdraw withdrawal_value = state.balances[index] - MAX_EFFECTIVE_BALANCE assert withdrawal_value > 0 # Make withdrawal receipt and add it to withdrawals withdrawal = Withdrawal( validator_index: index, withdrawal_credentials: message.withdrawal_credentials, withdrawn_epoch: epoch, amount: withdrawal_value ) state.withdrawals.append(withdrawal) # Update balance and withdrawn epoch state.validators[index].withdrawn_epoch = epoch state.balances[index] = MAX_EFFECTIVE_BALANCE ``` There are several uncertainties in this implementation, especially with dual usage of `withdrawn_epoch` field, which is used both for exit withdrawals and rewards withdrawals. It could be solved with 2 fields and extra dedicated `rewards_withdrawn_epoch` field to make both types of withdrawal less tricky. The main downside of this implementation is inability to process rewards withdrawals for `Validators` with non-BLS prefixed `withdrawal_credentials`, necessity to sign messages with BLS withdrawal key, which is difficult to be shared and inability to restrict withdrawal targets in this case. Most of these disadvantages could be solved with implementation of several `Validator`'s keys as initially proposed by @vbuterin in [Adding PoS validator key changes](https://ethresear.ch/t/adding-pos-validator-key-changes/9264) (see "Control of key switching rights" section). ### Queues [^](#Eth2-to-Eth1-Validator’s-withdrawal-design-WIP) TODO Withdrawals by validator resign or non-automatic partial withdrawals requires message for each action. All messages are bounded by processing queues limits. [Estimates](https://ethresear.ch/t/exit-entry-queue-clogging-after-withdrawals-are-enabled/10400) predicts about 10 months of re-entrance queues after withdrawals are enabled, which is a serious issue and should be avoided. So, withdrawals design should be modified to avoid queues both in regular flow and decrease estimated queues or make a special case on withdrawals enable fork. ## Changes in ETH1 [^](#Eth2-to-Eth1-Validator’s-withdrawal-design-WIP) ### Changes to opcodes [^](#Eth2-to-Eth1-Validator’s-withdrawal-design-WIP) We require only `BEACONBLOCKROOT` opcode for withdrawal operation. `beaconblockroot(<Beacon block/slot number>)` returns root of appropriate `BeaconChain` block or `0x00*32` if data is not available. ### System contract in Eth1 [^](#Eth2-to-Eth1-Validator’s-withdrawal-design-WIP) At address `0x00……ff` (TO BE DEFINED), add a system contract that expects input in the following format: ``` RLP(withdrawal: Withdrawal, proof: [Bytes32], index: UInt64, slot: UInt64) ``` After execution contract pushes the result to the stack, one of: ``` 0x00..00 - FAILED 0x00..01 - SUCCESSFUL 0x00..02 - ALREADY_WITHDRAWN ``` System contract in Eth1 should consists of 3 parts: - verification of proof - saving withdrawal claim - ether mint Verification of proof should look something like this (example in python language, from [Merkle Proof formats](https://github.com/ethereum/eth2.0-specs/blob/dev/ssz/merkle-proofs.md)): ```python= def verify_withdrawal(withdrawal: Withdrawal, proof: Sequence[Bytes32], index: GeneralizedIndex, slot: UInt64) -> bool: return verify_merkle_proof(hash_tree_root(withdrawal), proof, index) == op_beacon_block_root(slot) def verify_merkle_proof(leaf: Bytes32, proof: Sequence[Bytes32], index: GeneralizedIndex, root: Root) -> bool: return calculate_merkle_root(leaf, proof, index) == root def calculate_merkle_root(leaf: Bytes32, proof: Sequence[Bytes32], index: GeneralizedIndex) -> Root: assert len(proof) == get_generalized_index_length(index) for i, h in enumerate(proof): if get_generalized_index_bit(index, i): leaf = hash(h + leaf) else: leaf = hash(leaf + h) return leaf def get_generalized_index_length(index: GeneralizedIndex) -> int: """ Return the length of a path represented by a generalized index. """ return int(log2(index)) def get_generalized_index_bit(index: GeneralizedIndex, position: int) -> bool: """ Return the given bit of a generalized index. """ return (index & (1 << position)) > 0 ``` After that we should save in contract storage consumption of this withdrawal receipt, so it couldn't be claimed anymore. We use `withdrawal_hash_tree_root = hash_tree_root(withdrawal)` for unique reference: ```solidity= //** Solidity code **// // Definition mapping(bytes32 => bool) withdrawn; // Assertion at the beginning of withdrawal processing require(!withdrawn[withdrawal_hash_tree_root]); // Successful withdrawal claim saved withdrawn[withdrawal_hash_tree_root] = true; ``` and after that we "mint ether" like we do it for coinbase rewards ([trinity](https://github.com/ethereum/trinity) codebase example): ```python= def mint_for_withdrawal(withdrawal: Withdrawal) -> None: withdrawal_target = Address(decode_hex(withdrawal.withdrawal_credentials[12:])) withdrawal_amount = withdrawal.amount * denoms.gwei self.vm_state.account_db.delta_balance(withdrawal_target, withdrawal_amount) ``` ## Discussion [^](#Eth2-to-Eth1-Validator’s-withdrawal-design-WIP) There are number of design limitations if we want to use BeaconChain (ETH2) data in Execution Layer (ETH1), which were reviewed making this specification: - we could not expect tight coupling of BeaconChain and Execution Layer clients in the near term and from architecture viewpoint we should avoid it - most VM opcodes are executed in nanosecond/microsecond times, and we should reduce this period, no JSON-RPC or similar kind of interactions could fit in it - any interaction between several pieces of software leads to sync choice and issues It leads us to the safest way of interaction: provide some piece of data (several KBs max) with every query on block construction. Check [Rayonism merge specification#Consensus JSON RPC](https://notes.ethereum.org/@n0ble/rayonism-the-merge-spec#Consensus-JSON-RPC) for preliminary proposal on ETH2<->ETH1 JSON-RPC interaction protocol. `BeaconState` does not fit in it, `BeaconState` changes require stateful interaction. Even several parts of `BeaconState` are way too big for it. What we should definitely fit in it is `BeaconState` root, or, more precisely `BeaconBlock` root to formalize `BeaconState` view momentum. For more on ETH1<->ETH2 interaction, check [Executable Beacon Chain](https://ethresear.ch/t/executable-beacon-chain/8271) by @mkalinin. Also there are several topics which should be solved in future but not yet covered in this specification: - **Burn deposits** In order to make correct deposit processing when putting money in Eth2 and later out of, we should adjust `Deposit` contract balance. We could do it either when `Deposit` is processed and money arrives in `BeaconChain`, or when cashout is processed. Burning it after processing looks like a better way as we could add several deposit and withdrawal options in the future and ethers do not actually exist in Eth1 after deposit is processed. Finally, we could have a penalty which will burn the whole validator’s stack in the future and the validator will not be able to make withdrawal at all, so the second option looks less viable. - **Withdrawal list purge** With the growing number of withdrawals `BeaconState` will grow over time. We could purge old withdrawals not affecting proof generation by collapsing old tree paths, the only caveat is that we could not (and should not) use data whether this withdrawal was already claimed or not, instead we are able only to define age or list quantity expiration thresholds. It should not be an issue for anyone as these limits could be defined per client and if someone wants to keep all withdrawals since the network establishing he would have no issues with it and any historical withdrawal proof will be legit at any time. - **Withdrawal versioning** Later we may want to introduce partial withdrawals or `Validator`'s balance withdrawal will require additional fields, for example, for L2 withdrawals. It will require changes in `Withdrawal` object and handling of all versions in all participating parties including Eth1 system contract. Appropriate mechanism should be developed. - **Partial withdrawals** With such withdrawal claim design we could have partial withdrawals with a few changes on top. - **Good to have Eth1 features (useful for contract development in connection with Eth2)** + `bls.verify`, using [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537) or similar. It will help contracts to verify Eth2 credentials. + system contract providing utilities with Eth2 constants and support (ie updating and following all forks). Example: seconds to epochs calculation.
Last changed by  
 
Dmitry S.
6255

Read more

Untitled

Low participation in Hive issue Anomalies overview Hive counts participation in another manner, not like us. Hive participation data for 1 epoch: ["7","7","7","7","7","7","7","7", "7","0","7","7","7","7","7","7", "7","7","7","7","7","7","7","7", "7","7","7","7","0","7","7","7",

10/4/2022
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

8/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.

6/7/2021
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:

2/24/2021
Read more from Dmitry S.
Published on HackMD