Greetings to the fourth edition of eth2 quick update. There are numerous dynamic elements to discuss this week. Aside from the remarkable eth2 client advancement taking place, here are the key points:
tldr;
Differential fuzzing grant
Sigma Prime has secured a grant to spearhead the differential fuzzing initiative for eth2 clients. This initiative is vital for ensuring the successful launch of a multi-client network by assisting in identifying consensus problems ahead of mainnet.
The process of “fuzzing” involves submitting a multitude of random inputs to a software application to observe its reactions. When fuzzing one specific software, the aim is frequently to detect inputs that result in unforeseen crashes. Upon discovering such inputs, we analyze what occurred and strengthen the software against this type of input.
Differential fuzzing differs slightly. Rather than directly searching for crashes, we examine situations where various implementations of a protocol produce different outputs for identical inputs. In the context of blockchain, we apply differential fuzzing to identify instances in which a series of blocks results in differing states on two separate clients. Ideally, such discrepancies should not occur in production.
Light client task force
Chainsafe/Lodestar, the recipients of an Ethereum Foundation grant for research and development on eth2 light clients, have constituted the Light Client Task Force. This assembly has committed to guaranteeing that light clients are treated as priority components within eth2. Their initiatives include hosting a monthly meeting dedicated to promoting light client research, standards, specifications, and education.
The necessity for a diverse ecosystem of light clients and light client servers is heightened within a sharded protocol like eth2. Even when a client is synchronizing a subset of the protocol (e.g. merely a few shards), users will frequently need to acquire information regarding accounts, contracts, and the overarching state of affairs on another shard. A client could inefficiently sync the entire additional shard, yet more commonly, lightly querying information about specific accounts on that shard with succinct proofs will be preferable.
Join the next Light Client Task Force call to keep informed about everything light in eth2.
eth1 -> eth2
In the formative phases of eth2, the transfer of ether from the current Ethereum chain (eth1) to the new beacon chain (eth2) will be one-sided. In other words, the ether transferred into staking on eth2 will initially not be transferable back to eth1. This decision for a unilateral transfer into validation is aimed at minimizing the risk exposure that eth2 imposes on eth1, while facilitating a faster development cycle on eth2 without necessitating a fork of eth1. There is some progress in the creation of a bi-directional bridge, but I will reserve our discussion on bridge mechanics and trade-offs for a subsequent post. Today, I would like to delve deeper into how this one-sided transfer operates and how it can be securely implemented without altering eth1.
On the current Ethereum PoW chain, we will deploy the eth2 validator contract. This contract features a single function named deposit which accepts numerous parameters to initialize a new validator (e.g. public key, withdrawal credentials, an ETH deposit, etc.). There is no withdrawal capability within this contract. Unless a fork is conducted to incorporate a bi-directional bridge, this deposited ETH currently only resides in eth2 on the beacon chain.
It is then the responsibility of the validators on the beacon chain to achieve consensus on the state of this contract to enable the processing of new deposits. This is achieved by eth2 block proposers embedding recent eth1 data into a beacon block field designated as eth1_data. When sufficient block proposers during a voting period concur on recent eth1_data, this information is enshrined in the beacon chain state permitting new deposits to be processed.
A crucial point pertaining to this mechanism is that the eth1_data is located deep within the eth1 PoW chain — approximately 1000 blocks of “follow distance”. This follow distance results in significant latency in processing new validator deposits, but provides a substantial level of safety in the linkage of these two systems. The eth1 chain would need to re-org deeper than 1000 blocks to sever the connection, which would then necessitate manual intervention to rectify.
We are currently investigating and prototyping the use of the beacon chain to finalize eth1 (i.e., the finality gadget). This would entail eth1 ultimately deferring its fork choice to the beacon chain, benefiting from the security provided by the PoS validators while facilitating much quicker eth1 to eth2 deposits. The finality gadget also opens the door for exciting possibilities such as a bi-directional bridge and exposing the eth2 data layer to eth1. More details on all of this will be shared in a future post 🚀.
