Ethereum 2.0 Progress Update: Simplified Phase 0 and Phase 1

Welcome to the second edition of the Ethereum 2.0 development progress update.

The original author is Danny Ryan from ethereum.org.

Long story short:

1. The developer released the Tonkatsu specification for version 0.9.0 to ensure that the Ethereum Phase 0 phase can continue unimpeded;
2. The developer is still continuing to modify the details of the Phase 1 proposal;
3. Client development focuses on the transformation and optimization of eth1 -> eth2 infrastructure;

• 8 moats for blockchain entrepreneurship and investment in the 2020s
• Babbitt column | We are talking about the blockchain, is the same concept?
• Because of DeFi, Ethereum is now impossible to fork

(Image courtesy of ethereum.org)

Publish Tonkatsu

As we promised at the recent Ethereum 2.0 conference call, the recent focus is on the release of Tonkatsu version 0.9.0 . This version greatly simplifies Phase 0. The goal here is to delete the part of Phase 0 that is associated with Phase 1 to ensure that the development of Phase 0 can continue unimpeded, regardless of the ongoing patch revision. jobs.

For more information about Tonkatsu, you can read the release notes .

Redesigning Phase 1

As mentioned in the last progress update, we will almost certainly adopt a new, simpler direction for Phase 1. (Translator's Note: It is very likely that it is a simplified solution proposed by Vitalik). The new shard proposal helps to "crosslink" each shard in each slot cycle. This greatly simplifies communication between shards and will provide a better experience for developers and users during the Phase 2 phase.

Previous cross-sliced ​​communication diagram (approximate)

New shard design

In order to support this new proposal, the total number of shards must be reduced from the initial set of 1024 to the new estimate of 64, and then the number of shards will continue to increase over time (about 10 years). The following are the main reasons for reducing the total number of shards:

1. Each slice in each slot cycle induces a proof load on the network and beacon chain, rather than each epoch cycle;
2. Each committee must have a minimum number of certifiers. If there are too many committees per epoch period due to the high number of shards, then there is not enough certifier (please pledge 32ETH) to be safely assigned to Each committee;

[Edit: The following content was added after the blog post was first released in response to some discussions on reddit]

In order to achieve similar scalability to the previous sharding scheme, the target sharding block size of the new proposal will increase by 8 times, from 16kB to 128kB. This provides the system with data availability greater than 1MB/s, which works well with promising L2 solutions such as ZKrollup and OVM .

The network security of these larger fragment sizes is demonstrated by experimental research on the existing Ethereum network.

In the past few weeks, most of the Ethereum research team has focused on reviewing and collating the details of this new proposal.

Client development work

The client of Ethereum 2.0 continues to evolve quietly. As discussed in the recent Ethereum 2.0 conference call, we are working hard to deal with deposit issues from Ethereum 1.0, such as optimizing state transitions and BLS implementations, cross-client fuzzing, Network monitoring tools and more! A larger single-client test network is underway and we are continuing to experiment with cross-clients.

Now that version 0.9.0 has been released, clients are updating their state transition logic to pass new test vectors and introduce a simple proof aggregation strategy.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!