Welcome to the fourth article. eth2 quick update. We have a lot of touching things to talk about this week. Besides the ongoing heroic eth2 client development, highlights include:
tldr;
Grant differential fuzzing
Sigma Prime has received a grant that will lead to: Differential fuzzing efforts For eth2 clients. These efforts are critical to the success of a multi-client network launch by helping identify consensus issues prior to mainnet.
The act of “fuzzing” is the act of randomly throwing a lot of input at software to see how it reacts. When fuzzing a single piece of software, the goal is often to find inputs that cause unexpected crashes. When we find such inputs, we figure out what’s wrong and harden our software for these types of inputs.
differential Fuzzing is a bit different. Instead of explicitly looking for conflicts, we look for instances where different implementations of the protocol have different outputs for the same input. In the blockchain context, we use differential fuzzing to find cases where a series of blocks lead to different resulting states in two different clients. Ideally, this would not be the case in production.
Light Client Task Force
Chain Safe/lodestarreceived an Ethereum Foundation grant for research and development on the eth2 light client, Light Client Task Force. This group is tasked with ensuring that light clients become first-class citizens of eth2. For this they monthly currency It aims to drive light client research, standards, specifications and training.
The need for a rich ecosystem of light clients and light client servers is only amplified in sharded protocols like eth2. Even when a client only synchronizes some subset of the protocol (e.g. a few shards), users often need to obtain information about accounts, contracts, and the general state of other shards. Although clients may inefficiently synchronize entire additional shards, it is usually better to lightly request information about specific accounts in a shard using concise proofs.
Listen to the next episode Light Client Task Force Convened Stay up to date on all things lighting on eth2.
eth1 -> eth2
In the early days of eth2, Ether transfers from the existing Ethereum chain (eth1) to the new beacon chain (eth2) will be one-way. This means that ether staked on eth2 cannot be transferred back to eth1. The choice of a single-direction transition to validation is part of an effort to minimize the risk profile that eth2 imposes on eth1 and allow for faster development cycles on eth2 without forking eth1 in the process. There are several moves toward creating a two-way bridge, but I’ll leave discussion of the bridge mechanism and its pros and cons to a later post. Today I want to take a closer look. how Here’s how this one-way transfer works and how to implement it safely without changing eth1.
On the existing Ethereum PoW chain, we eth2 validator contract. This contract has the following single features: deposit It uses several parameters (e.g. public key, withdrawal credentials, ETH deposit, etc.) to initialize a new validator. does not exist withdrawal Features of this Agreement. Aside from the fork to add to the two-way bridge, this deposited ETH now only exists on eth2 on the beacon chain.
It is then the responsibility of the validators on the beacon chain to reach agreement on the state of this contract so that new deposits can be processed. This is done by the eth2 block proposer inserting recent eth1 data into the beacon block field. eth1_data. If a sufficient number of block proposers agree to the most recent block proposal during the voting period. eth1_dataThis data is stored in the beacon chain so that new deposits can be processed.
An important note about this mechanism is eth1_data It’s deep in the eth1 PoW chain — its “follow distance” is ~1000 blocks. This subsequent distance causes high latency in processing new validator deposits, but provides a high level of safety in combining these two systems. The eth1 chain requires over 1000 blocks to be rebuilt to break a link, which requires manual intervention to overcome.
We are researching and prototyping utilizing a beacon chain to complete eth1 (i.e. the final gadget). This would require eth1 to ultimately defer fork selection to the beacon chain, ensuring security from PoS validators and allowing much faster eth1 to eth2 deposits. The final gadget also provides other interesting features, such as a two-way bridge and exposing the eth2 data layer to eth1. More details on all this in a later post 🚀.