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",

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

[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

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.

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:

topic: Eth1.x Research tags: stateless It's a reply to @pipermerriam's Explorations into using DHT+SkipGraph for chain and state data retrieval. Piper has been gradually researching this topic starting with The Data Availability Problem under Stateless Ethereum post and several other related articles. Thanks for pushing it forward! There are several issues connected with sharded state and routing (lookup and discovery of current state and history objects) is one of them and should be solved by Discovery protocol. However, I want to oppose the way it's attempted to be answered. Why it's important Current state of Ethereum is already huge and continues to grow. Even non-archive nodes require 300Gb of space to be in sync and this number is getting bigger and bigger every day. Though Ethereum 2.0 is going to solve part of the problems with its shards, Ethereum 1.0 is going to be single shard in it and the accumulated user base will be the guarantee of “Shard 0” further expanding. Even if other shards will keep small size for a while after creation, the future is the same for all: shard size is very big to keep it’s whole state and historical data on disk by regular users. Yes, we could move to the point where core blockchain p2p consists only of full nodes maintained by Consensys, Infura, Ethereum Foundation and few other well known authorities in order to back their services, but it’s not a way blockchain should look like. Decentralization is the crucial feature of Ethereum and all other non-private blockchains. When you require to have free 300Gb (and growing) SSD drive space and an hour to reach a recent state after overnight of downtime, you restrict nodes to professional members. And the more you raise the bar, the bigger share of professional members you have in the network.

by TX/RX Research Intro (you are here) Advertisement solutions a. Advertisement in Kademlia b. Advertisement in Discovery V5 c. Advertisement in ENR Requirements a. Ethereum 1.x requirements b. Ethereum 2.0 requirements

Intro (you are here) Closeness: how it works Do we need neighbors and closeness in Discovery? Neighbors lookup change in Discovery V5 Simulator A. Simulator description B. Simulator simplifications C. Simulator test cases Simulation results A. Modern network

--- title: Shmatko CV --- ## Dmitrii Shmatko ### Overview **Full-stack software engineer** <img src="https://i.imgur.com/uZp42E3.jpg" width="150" style="float:right"> **Birthday:** June 8, 1984 **Education:** Omsk State University (not finished) **Area of Study:** applied mathematics and computer science; economics **English:** upper intermediate, conversational written and verbal skills **E-mail:** zilm@zilm.net **Github:** github.com/zilm13 ### Skills - Backend: Java, Python,

--- title: Discovery v5 by Dmitrii Shmatko tags: description: --- # Discovery v5 *Dmitrii Shmatko* ### .. slides: https://hackmd.io/@0klO-1bXTU-4eDnt-ZnrHg/d#/ --- ## Who am I? - Dmitrii Shmatko from Harmony team - Last 5 years: Java, Ethereum, Python, Node.js, Financial apps - Before: small IT enterprenuer, development management, databases ---  --- ### Specification Read full [Discovery v5 specification](https://github.com/ethereum/devp2p/blob/ma