eth2 quick update no. 2

Welcome to the second installment of eth2 quick update.

tldr;

• Spec release of v0.9.0 — Tonkatsu to ensure Phase 0 development can continue unimpeded.
• Work continues in ironing out the details of the modified Phase 1 proposal.
• Quiet client development focused on eth1 -> eth2 infrastructure, general hardening for production, and optimizations.

Tonkatsu Release

As promised on the latest eth2 call, we pushed things forward to release v0.9.0 release — Tonkatsu. This release is largely simplifying with respect to Phase 0. The goal here is to remove any portions of Phase 0 that are opinionated about Phase 1 to ensure Phase 0 development can continue unimpeded regardless of the work-in-progress modified sharding proposal.

Read the release notes for more info.

Ongoing Phase 1 Redesign

As mentioned in the last eth2 quick update, we are almost certainly taking a new and simpler direction for Phase 1. The new sharding proposal facilitates “crosslinks” for all shards at each slot. This drastically simplifies communication between shards and will result in a much better and simpler developer/user experience come Phase 2.

Previous cross-shard communication (approximate)

New shard design proposal

To support this new proposal, the total shard count to start must be reduced from 1024 to the new estimate of 64, with the intention to scale up the number of shards over time (~10 years) as standard resources available to consumer laptops increases. The following are the primary reasons for the requisite reduction in total shards:

• Each shard induces an attestation load on the network and beacon chain at each slot rather than at each epoch
• Each committee must be of a minimum safe number of validators. If there are too many committees per epoch due to high shard count, then there couldn’t possibly be enough 32-ETH validators to safely allocate enough to each committee

[EDIT: the following paragraph was added after initial release of the blog post in response to some discussion on reddit]

To achieve a similar scalability as the previous proposal, target shard block sizes are being increased 8x, from 16kB to 128kB. This provides the system with greater than 1 MB/s of data availability which synergizes well with promising L2 schemes such as ZKRollup and OVM. The network safety of these larger shard block sizes are justified by recent experimental research done on the existing Ethereum network.

Much of the EF research team’s focus in the past few weeks has been around vetting and ironing out the details of this new proposal. For more details, check out the work-in-progress PR or some of the Phase 1 issues.

Quiet, yet effective client development

Eth2 clients continue to quietly develop. As discussed on the latest eth2 call, effort is being put into handling deposits from eth1, generally hardening clients for production, optimization of state transition and BLS implementations, cross-client fuzzing, networking monitoring tooling, and more! Larger single client testnets are in the works as well as continued cross-client experimentation.

Now that v0.9.0 has been released, clients are updating their state transition logic to pass the new test vectors and are introducing the simple attestation aggregation strategy.