Welcome to the fourth part of fast eth2 update. There are a lot of moving topics to talk about this week. Besides the heroic development of the eth2 client underway, here are the highlights:
tldr;
Differential fuzzing subsidy
Sigma Prime received a grant to lead the differential fuzzing effort for eth2 clients. This effort is critical to the successful launch of a multi-client network by helping to detect consensus issues before the mainnet.
The act of “fuzzing” involves throwing lots of random inputs at software to see how it reacts. When fuzzing a single piece of software, the goal is often to find inputs that lead to unexpected crashes. When we find such inputs, we then determine what went wrong and harden the software to that type of input.
Differential fuzzing is a little different. Instead of explicitly looking for crashes, we look for cases in which different implementations of a protocol have different output for the same input. In a blockchain context, we use differential fuzzing to find cases in which a series of blocks leads to a different resulting state on two different clients. Ideally, in production, such cases do not exist.
Thin Client Working Group
Safe/North Starrecipient of a grant from the Ethereum Foundation for eth2 light client research and development, formed the Thin Client Working Group. This group took on the responsibility of ensuring that thin clients are first class citizens in eth2. To this end, they organize a monthly call aimed at facilitating research, standards, specifications and customer education.
The need for a rich ecosystem of thin clients and thin client servers is only amplified in a fragmented protocol like eth2. Even if a client synchronizes a subset of the protocol (e.g. just a few fragments), a user will very often need to obtain information about accounts, contracts, and the general state of affairs on another fragment. A client could inefficiently sync the entire additional shard, but more often than not, casually requesting information about specific accounts on the shard with succinct evidence will be the way to go.
Connect to the next Call to the Thin Client Working Group to stay up to date with everything light related in eth2.
eth1 -> eth2
In the early days of eth2, the transfer of ether from the existing Ethereum chain (eth1) to the new beacon chain (eth2) will be one-way. In other words, ether staked on eth2 will not be transferable (to begin with) to eth1. The choice of a one-way transfer to validation aims to minimize the risk profile induced by eth2 on eth1 and to enable a faster development cycle on eth2 without having to fork eth1 in the process. There is some movement around creating a two-way bridge, but I’ll save the discussion of bridge mechanics and trade-offs for a later article. Today I would like to go deeper how this one-way transfer works and how it can be implemented securely without modifying eth1.
On the existing Ethereum PoW chain, we will deploy the eth2 validator contract. This contract has a single function called deposit which takes into account a number of parameters to initialize a new validator (e.g. public key, withdrawal credentials, ETH deposit, etc.). There is no withdrawal function on this contract. Barring a fork to add a two-way bridge, this deposited ETH now only exists in eth2 on the beacon chain.
It is then up to the beacon chain validators to reach consensus on the state of this contract so that new deposits can be processed. This is done by eth2 block nominators who embed recent eth1 data into a beacon block field called eth1_data. When a sufficient number of block nominators during a voting period agree on recent proposals eth1_datathis data is entered in the state of the beacon chain allowing the processing of new deposits.
An important note about this mechanism is that the eth1_data is deep in the eth1 PoW chain – ~1,000 blocks “following distance”. This tracking distance induces high latency in the processing of new validator deposits, but provides a high degree of security in the coupling of these two systems. The eth1 chain would need to be reorganized over 1,000 blocks to break the link, and in such a case it would require manual intervention to overcome it.
We are researching and prototyping the use of the beacon chain to finalize eth1 (i.e. the finality gadget). This would require eth1 to defer its choice of fork to the beacon chain, thereby gaining security from PoS validators and allowing much faster eth1 to eth2 deposits. The finality gadget also opens up other fun things like bidirectional bridging and exposing the eth2 to eth1 data layer. More on all this in a future article 🚀.
