eth2 quick update number 2

Welcome to the second article. eth2 quick update.

tldr;

• Specifications released v0.9.0 – Tonkatsu Ensures that Phase 0 development can continue uninterrupted.
• Work continues to refine the details of the revised Phase 1 proposal.
• Quiet client development focused on: eth1 -> eth2 General hardening and optimization for infrastructure, production.

pork cutlet release

As recently promised eth2 callWe’ve been pushing things forward for launch v0.9.0 Release – Tonkatsu. This release has been greatly simplified with regard to Phase 0. The goal here is to eliminate all parts of Phase 0 that have opinions about Phase 1, so that Phase 0 development can continue unhindered under any circumstances. Revised sharding proposal in progress.

read release notes For more information.

Phase 1 redesign in progress

As mentioned last time eth2 quick updateWe are almost certainly taking a new, simpler direction in Phase 1. New sharding proposal Facilitates “cross-connecting” to all shards in each slot. This will greatly simplify communication between shards and provide a much better and simpler developer/user experience in phase 2.

Previous inter-shard communication (approximately)

New shard design proposal

To support this new proposal, the total number of shards to start with will need to be reduced from 1024 to the new estimate of 64, with the intention of scaling the number of shards over time (up to 10 years) as the standard resources available in consumer laptops increase. The main reasons why the total number of shards necessarily decreases are:

• Each shard drives proof load on the network and beacon chain at each slot rather than each epoch.
• Each committee minimal safety Number of validators. If there are too many committees per epoch due to a high shard count, there may not be enough 32-ETH validators to safely allocate to each committee.

(Edit: The following paragraph was added to the blog post after it was first published in response to some discussion on Reddit.)

To achieve similar scalability as the previous proposal, the target shard block size was increased by 8x. 16kB to 128kB. This is in the system 1MB/sec Data availability in synergy with promising L2 methods such as ZKRollup O.V.M.. The network safety of these larger shard block sizes is justified as follows: Recent experimental studies It is performed on the existing Ethereum network.

Over the past few weeks, the focus of the EF research team has been examining and refining the details of this new proposal. For more information, please see: Ongoing Promotion or some of them Step 1 Problem.

Quiet yet effective client development

The Eth2 client continues to be quietly developed. As recently discussed eth2 call, efforts are generally focused on handling eth1 deposits for client hardening for production, optimizing state transitions and BLS implementations, cross-client fuzzing, networking monitoring tools, and more! A larger single-client testnet is underway, and cross-client experimentation continues.

Now that v0.9.0 Once released, the client updates its state transition logic to pass the new test vector and Simple proof aggregation strategy.