Welcome to the second part of fast eth2 update.
tldr;
- Specification version v0.9.0 — Tonkatsu to ensure that development of Phase 0 can continue unhindered.
- Work continues to refine the details of the amended Phase 1 proposal.
- Discreet customer development focused on eth1 -> eth2 infrastructure, general hardening for production and optimizations.
Tonkatsu Release
As promised last eth2 callwe pushed things forward to get out v0.9.0 version — Tonkatsu. This release greatly simplifies Phase 0. The goal here is to remove all parties from Phase 0 that have an opinion on Phase 1 to ensure that development of Phase 0 can continue unimpeded, regardless of the partitioning proposal modified during work.
Read the release notes for more information.
Redesign in progress of phase 1
As mentioned in the last fast eth2 updatewe are almost certainly taking a new and simpler direction for phase 1. new sharing proposal facilitates “cross-linking” for all fragments at each location. This greatly simplifies communication between fragments and will result in a much better and simpler developer/user experience in phase 2.
Previous inter-fragment communication (approximate)
New Fragment Design Proposal
To support this new proposal, the total number of fragments must be reduced from 1,024 to the new estimate of 64, with the intention of increasing the number of fragments over time (~10 years) as standard resources available for consumer laptops are increasing. Here are the main reasons for the required reduction in the total number of fragments:
- Each shard incurs an attestation load on the network and beacon chain at each location rather than at each epoch
- Each committee must be of one minimum security number of validators. If there are too many committees per epoch due to a high number of shards, then there could not be enough 32-ETH validators to safely allocate enough to each committee.
(EDIT: The following paragraph was added after the blog post was originally published in response to a discussion on Reddit)
To achieve similar scalability as the previous proposal, the size of the target fragment blocks was increased by 8, from 16 KB has 128 KB. This provides the system with more 1 MB/s of data availability that pairs well with promising L2 programs such as ZKRollup and LMO. The network security of these larger shard block sizes is justified by recent experimental research performed on the existing Ethereum network.
Over the past few weeks, EF’s research team has focused largely on reviewing and refining the details of this new proposal. For more details, see the work in progress RP or some of the Phase 1 Issues.
Quiet but effective customer development
Eth2 clients continue to grow quietly. As discussed in the last eth2 callefforts are put into managing eth1 repositories, generally hardening clients for production, optimizing state transition and BLS implementations, cross-client fuzzing, network monitoring tools, and much more ! Larger single-client test networks are in the works as well as continued multi-client experimentation.
Now that v0.9.0 has been released, customers update their state transition logic to pass the new test vectors and introduce the simple attestation aggregation strategy.
