9 months ago, the Ethereum 2.0 specification was still blank on HackMD. It is now a full-featured GitHub library with a pre-release version of version 5. 54 contributors submitted approximately 13,000 lines of approximately 23,000 lines and deleted 19,000 lines. The specification now runs through 12 separate documents covering different aspects of the protocol, which is not included in the different code bases for the verifier management contract. The specification continues to grow rapidly.
The Ethereum 2.0 design includes some excellent innovations and existing technology applications such as LMD GHOST fork selection rules, BLS signature aggregation, hash tree root, quadratic leak, escrow certificate and many more.
In short, this is a magnificent project. This is exciting. Just nine months ago, in the basement of Berlin, the author never thought that he would achieve so many achievements in such a short period of time. This does not include the Ethereum 2.0 client implementation.
- Market Analysis: No fears have been seen yet, it will take time to stop falling
- How to understand the layer 2 data availability solution ZK Rollup?
- It is possible to reduce production by 10 times in two years, CME will launch Ethereum futures, and ETH will welcome two pounds at night!
- Let the transaction speed reach 1 million TPS in the future, and the Ethereum expansion solution officially released
- Tornado: Introducing hidden trading mechanism for Ethereum
Three phases are planned before Ethereum 2.0 can be considered for delivery and operation. How is the current progress? Let's take a look!
Phase 0 is the Beacon Chain , which is the Proof of Entitlement (PoS) coordination layer for the entire system. Currently, the specification of Phase 0 is in the completion period, and the pace of revision of the specifications for this phase has slowed down rapidly. In fact, the specification is already in an executable and testable state. All that's left is to choose a serialization algorithm (sorry! Just kidding?).
The beacon chain client implementation has been created by multiple teams in multiple languages and the test network is being assembled . We still have a long way to go before debugging, networking implementation and compatibility testing, but the way forward is clear. Some believe that we can deploy an Ethereum main network that really pledges ETH by the end of 2019. What is certain is that it will be realized in early 2020. This phase is probably the most challenging phase of implementation.
Phase 1 is a sharded data layer: transactions are distributed among more than 1,000 independent blockchains (ie, sliced chains) that are anchored to the equity certification beacon chain. Currently, the specification of Phase 1 is progressing very well and may be finalized shortly after the Phase 0 specification is completed. That is to say, the specification of Phase 1 will be finalized in the next few months. The Phase 1 implementation is primarily a peer-to-peer network design challenge and is currently underway.
Phase 2 is a sharded layer and an execution layer . There is no specification document in Phase 2, and there is still a lot of research and development work to be done. The question is not how we will do these things, but how to consider which of the available solutions is the best choice for all stakeholders in the future system. Developers are about to begin to address these tough issues: see below for more details.
This is the current situation of Ethereum 2.0. The past nine months have been a shocking period. I think we have probably gone a quarter to a third. At this rate, Ethereum 2.0 will be delivered before the UK officially retreats…
There is currently an experimental pattern recognition for viewing the effects of generating RST/Sphinx (ReadTheDocs format) from all specification documents.
1. Beacon chain specification (stage 0)
Since the last Ethereum 2.0 update document two weeks ago, the beacon chain specification has not yet released a new major specification version.
But there is a bug fix for the minor release, so the beacon chain specification we are using now is v0.5.1 .
Looking ahead, Justin Drake (the core developer of Ethereum) has confirmed that we will use SHA256 as a standard hash function (previously Keccak256, before that was Blake2b). The main reason for choosing the SHA256 function is cross-chain standardization and compatibility.
Other changes include splitting and making the fork selection rules executable. This allows test vectors to be generated directly from the beacon chain specification, which is also very good. Validator exiting The relevant specifications have also been re-adjusted and simplified.
The 0.6 version of the Beacon Chain Specification is expected to be released in the next few weeks , and changes to this version will include a complete simplification of the previous version.
2. Segmentation chain specification (stage 1)
The main update for Phase 1 is to replace the proof of custody game with JABS (JABS is Justin's Awesom Bit Sum). The 500 lines of code have been removed, so no matter what it is called, this is definitely a major simplification. During the developer conference call, Justin Drake mentioned that the Phase 1 specification will be split into two parts, with Part 2 containing updates to the beacon chain to support the proof-of-custody game.
It should be possible to complete the specification of Phase 1 shortly after the completion of the Phase 0 specification.
3. Status execution (stage 2)
Last week, the author was happy to see Brooklyn Zelenka 's article on Actor Modul (participant mode) . Brooklyn and Boris Mann also convened a discussion group to discuss what a cross-shard communication model might look like in Ethereum 2.0. One reason the author likes the Ethereum field is that smart, knowledgeable people always come to the right time to solve problems. Cross-segment messaging is one of the key parts of the research phase.
4. Simple Serialization (Simple Serialize)
Based on Peter Szilagyi's SOS serialization, Piper Merriam proposed an update to SSZ that allows efficient indexing of serialized data.
5. Light client specification
This is a new section that contains the beginning of an important document on Matthew Slipper's RPC interface:
Matthew also called a phone to discuss the wire protocol.
7. Implementation related (Implementation)
About the test:
@protolambda has joined Ethereum 2.0's testing and infrastructure related work during the Ethereum Developers Conference. In addition, he will work on buzz testing and randomised inputs.
Diederik Loerakker, https://github.com/protolambda
The specification is now basically executable, and many of the devices used to build and run tests on the specification are imported into the code base, and even CircleCI can be set up automatically.
In addition, formal test build libraries are being moved to the specification library to make them more consistent. This will greatly help implementers to keep the test suite in sync with the specification version.
Some implementation teams have recently announced test networks:
- Prysmatic's Gorli test network is almost complete:
Https://our.status.im/the-nimbus-mvp-testnet-is-here/ As for the cross-client test network, Danny Ryan made some suggestions. One method he suggested was: (1) each team runs its own long-term client test network, (2) the client passes all consensus test vectors, and (3) only then can it be done with another client team. A 1-to-1 collaboration to achieve compatibility with the public version of the specification.
A lot of work has been done on the so-called proof of custody game. This is the core part of Phase 1 (the fragmented data layer) and is a mechanism for the verifier to be responsible for viewing the fragmented block data they have verified. @dankrad has a good article on how to use PRF (Pseudo-random function) to achieve this in the form of a Legendre symbol instead of the currently proposed hash function. This will allow efficient calculation of proof of custody in a multi-party computing environment. For this reason, the previous RANDAO was changed to BLS signature.
In other respects, Vitalik gave some formulas for calculating the "safety" of the finalized block. That is, if a different finalized block conflicts with an existing block, how many certifiers must be slashed in view of the number of certifiers entering and exiting the certifier's set?
9. Other items
The Ethereum 2.0 work plan continued before the Sydney EDCON meeting. We will meet you during the EDCON hackathon event on April 9. Some people on the PegaSys team will also go there.
Information and registry are here:
The Artemis team is considering an ETH2 client implementer workshop during the May 12th New York blockchain week. (Note: Artemis is the beacon chain Java client)
Although Hsiao-Wei Wang's demo "Life of An Ethereum Beacon Chain Validator" does not include the latest developments, it is worth a look:
Vitalik's reply on r/EthTrader:
Vitalik has some concerns about PoS:
Vitalik's interview at Ethhub: