Greetings to the second edition of eth2 swift update.
tldr;
- Specification release of v0.9.0 — Tonkatsu to guarantee unimpeded Phase 0 development.
- Efforts persist in refining the particulars of the revised Phase 1 proposal.
- Subdued client development centered on eth1 -> eth2 infrastructure, overall fortifying for production, and enhancements.
Tonkatsu Release
As assured during the most recent eth2 call, we advanced to release v0.9.0 — Tonkatsu. This version largely aims to simplify aspects concerning Phase 0. The objective here is to eliminate any elements of Phase 0 that are prescriptive about Phase 1 to ensure Phase 0 development can proceed without hindrance irrespective of the in-progress modified sharding proposal.
Consult the release notes for additional details.
Continuing Phase 1 Redesign
As indicated in the previous eth2 swift update, we are decisively pursuing a new and more straightforward course for Phase 1. The new sharding suggestion allows “crosslinks” for all shards at each slot. This significantly streamlines inter-shard communication, promising a considerably enhanced developer/user experience upon reaching Phase 2.
Prior cross-shard communication (approximate)
Fresh shard design proposition
To accommodate this new proposal, the overall shard count at inception must be diminished from 1024 to the revised estimate of 64, with the intention to gradually increase the number of shards over the next decade as typical capacities of consumer laptops rise. The following are the main justifications for the necessary reduction in total shards:
- Each shard imposes an attestation burden on the network and beacon chain at every slot rather than at every epoch
- Each committee must consist of a minimum safe quantity of validators. If there are too many committees per epoch owing to an excessive shard count, then it wouldn’t be feasible to have enough 32-ETH validators to securely allocate sufficient members to each committee
[EDIT: the following paragraph was appended post-initial publication of the blog entry in response to certain discussions on reddit]
To attain comparable scalability as the preceding proposal, target shard block sizes are being raised 8x, from 16kB to 128kB. This enhancement equips the system with over 1 MB/s of data availability, which synergizes effectively with promising L2 frameworks such as ZKRollup and OVM. The network security concerning these larger shard block sizes is substantiated by recent experimental findings carried out on the current Ethereum network.
A considerable amount of the EF research team’s attention in recent weeks has been directed towards evaluating and refining the details of this new proposal. For more information, explore the in-progress PR or some of the Phase 1 concerns.
Subdued, yet productive client development
Eth2 clients are continuing to evolve quietly. As discussed in the latest eth2 call, efforts are focused on managing deposits from eth1, generally fortifying clients for production, optimizing state transitions and BLS implementations, cross-client fuzzing, networking oversight tools, and beyond! Larger individual client testnets are being developed alongside ongoing cross-client experimentation.
Now that v0.9.0 has been deployed, clients are modifying their state transition logic to meet the new test vectors while implementing the basic attestation aggregation strategy.
