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/2022Currently 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
9/7/2021[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/2021In 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/2021or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up