eth2 quick update no. 4

Welcome to the fourth installment of eth2 quick update. There are a lot of moving pieces to talk about this week. Other than the heroic eth2 client development going on, these are the highlights:

tldr;

Differential fuzzing grant

Sigma Prime has been awarded a grant to lead the differential fuzzing effort for eth2 clients. This effort is critical to the success of launching a multi-client network by aiding in catching consensus issues prior to mainnet.

The act of “fuzzing” is the act of throwing many random inputs at a piece of 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 figure out what went wrong and harden the software to this type of input.

Differential fuzzing is a bit different. Instead of explicitly looking for crashes, we look for instances in which different implementations of a protocol have a 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 there are no such cases.

Light client task force

Chainsafe/Lodestar, the recipients of an Ethereum Foundation grant for research and development on eth2 light clients, has formed the Light Client Task Force. This group has tasked themselves with ensuring that light clients are first class citizens in eth2. To this end, they are hosting a monthly call aimed at driving light client research, standards, specs, and education.

The need for a rich ecosystem of light clients and light client servers is only amplified in a sharded protocol like eth2. Even if a client is syncing some subset of the protocol (e.g. just a couple of shards), a user will very often need to get information about accounts, contracts, and the general state of things on another shard. A client could inefficiently sync the entire additional shard, but more…

Source Link