Written on the 5th anniversary of Ethereum ICO: Talking about the latest development of Ethereum 2.0

The code for phase 0 has been frozen, the client is conducting interoperability testing, and the related research for phase 2 is in full swing… What does this mean for the future of Ethereum?

 

Welcome to Bazaar (marketplace)

I recently re-read the classic book "The Cathedral and the Bazaar" about open source development published by Eric Raymond in 1997. When a large number of developers participate in software development, it will form a very positive situation. He called it the "market" model of open source software development.

This model seems ambiguous and confusing, but it actually inspires the developer's vitality, makes it more productive, and most importantly, it will achieve better results. He compared the “market” model with the traditional “church” model, in which development was carried out in a small and closed form of individual cooperation. Twenty years later, the changes brought about by the “market” model are irresponsible. The Linux operating system currently used in most computer equipment in the world is just one example of the "market" development model.

• Babbitt Column | Yang Wang, International Monetary Research Institute, China National People's Congress: Why Libra Marathon Needs to "Run"
• [Chainge] Technical Salon "Deconstructing Binance DEX"
• Is the halving effect going to fail? There are still 5 days for the Litecoin to be halved. This time it may not rise sharply.

I found this to be an interesting perspective, through which we can see the development of the Ethereum 2.0 blockchain. It has been more than a year since the Ethereum 2.0 project, and it is a good time to reflect.

The Ethereum 2.0 project can be said to have completely adopted this open, "market" development model. However, we have greatly expanded Raymond's vision: in Ethereum 2.0, we are not just building software, we are designing the entire agreement in this completely open way. I am not sure if there has been such a precedent before.

This does not mean an unordered state. Consistent with Raymond's concept, the project is led by a small team at the Ethereum Foundation, which is responsible for setting the route and managing the master repository. But everything is done in a transparent and open manner, and includes as many participants as possible. Here are some examples: 62 people currently contribute code to the specification, and more people are involved in the client-side execution process and R&D discussions on ethresear.ch, as well as a bi-weekly developer conference call (most recently More than 50 people participated).

Yes, although the process sometimes appears chaotic, unorganized, and inefficient, there have been many new designs, repairs, and rewrites. However, in this market-like embarrassment, some wonderful things have emerged, which is also a place that the non-open developer community can hardly hope for.

I have always argued (and will also advocate for a long time) that this development model is the killer of Ethereum. The openness of “radical” has given the community strong participation and support. It is vital that we do this technology that relies on community-driven “network effects”. Just the large-scale participation of the community makes Ethereum unique.

Here's an example of this development model that I often think about. Vitalik recently tweeted that the best thing about the community is that when a problem is raised, someone will volunteer to stand up and solve it. At the end of 2017, Justin Drake appeared and reactivated the research work after a period of sleep in the Ethereum 2.0 program. In 2018, when Ethereum needed better coordination and planning, Danny Ryan stood up. At the beginning of 2019, Diederik Loerakker, who had never heard of it, became a key developer of the Ethereum 2.0 client test suite. Our next challenge is to overcome peer-to-peer networks, and members with expertise have begun to get involved. The examples are too numerous to mention, but the point I want to make is clear: everyone likes the "market."

Does the "market" have a development roadmap? Figure source Microsoft

I am sometimes asked an interesting question, usually asked by companies interested in Ethereum: Where is the road map? Appropriately, although there is a lot of consensus among participants on the direction and development of Ethereum, there is no publicly released, detailed, committed, and “officially recognized” roadmap.

There is no “exact” roadmap in the “Market” mode. A classic article from Linux Weekly News also encountered the same problem, and their conclusions were:

“Trying to develop a roadmap in this process is unlikely to play a catalytic role.”

Having said that, for the Ethereum 2.0 system plan, we did have three separate steps, each of which continued on the basis of the previous phase. The main content of Phase 0 is the beacon chain, which implements the Proof of Interest (PoS) protocol as an alternative to Workload Proof (PoS) to maintain the blockchain network. Phase 1 provides tremendous scalability in the form of a sliced ​​chain, which increases the transaction processing power of the network to more than a thousand. Phase 2 is the executive layer that provides user accounts and smart contracts, and provides support for all distributed applications needed to decentralize the future.

 

Beacon chain [stage 0]

After one year of centralized development, the Ethernet 2.0 beacon chain specification was frozen on June 30, that is, research and design have been completed, and we are fully in the delivery phase. The beacon chain is based on the Ethereum 2.0 system. It manages the equity certification agreement and coordinates all independent parallel shards, which is the most complex part of development.

In July last year, the idea of ​​the beacon chain was born in Berlin and set the future direction of Ethereum 2.0. Although this concept is from nothing, it is by no means out of nothing. The ideas can be traced back to the earliest days of Ethereum. The specification was formed through in-depth insights, discussions, inspections, and testing processes.

At the same time, there are currently more than nine teams from different backgrounds and regions that implement the specification in different programming languages ​​and add an engineering infrastructure that makes it fully operational (although the specification itself is the engine, we want to have it Complete functionality, there are many other things to do, such as adding networks, databases, tools, etc.). Some teams have released proof-of-concept public testing networks that allow people to try to become certifiers in Ethereum 2.0, such as Prysmatic Labs.

Sometimes the norms change very quickly, but we have been keeping up. The recent freeze on the beacon chain specification is an important milestone and will bring two good effects.

First, the beacon chain specification can now be formally verified . This involves translating it into a special-purpose language called “K” for rigorous analysis and proof of correctness. Runtime verification will perform this work. An analysis of the verifier's pledge contract has been completed and will be deployed at Ethereum 1.0 for the verifier to move to Ethereum 2.0.

The second effect of the specification freeze is that it keeps all clients in sync and starts the next critical phase: interoperability. The Ethereum 2.0 beacon client is similar to current Ethereum nodes, such as Geth, Parity, and Pantheon. These nodes running the Ethereum network communicate with each other, and it is indispensable to reach a consensus all the time. It is possible that a divergence caused by a small error will cause the network to split.

Brooklyn Interoperability Workshop

To achieve interoperability is a process in itself. First, all clients need to pass the universal reference test. A very interesting feature of the specification is that it has been implemented to run the specification itself to generate client-side tests directly. Some people may prefer narrative styles compared to the current specifications written in Python, but despite this, the current specification is indeed a very useful tool. Another type of test is "fuzzy testing" . In the past, it successfully tracked the problem of the Ethereum 1.0 client, which repeatedly input random invalid data to the client to find out the case that caused the client to run abnormally. This type of fuzzing tool is currently being developed for the beacon chain.

Once each Ethereum 2.0 client team is guaranteed to be up and running, it is up to the client to communicate on the network. The problem is that when there is a problem with the distributed system, it is difficult to find out. Therefore, the first step is to have each client execute a simplified protocol (Hobbit), making it easier to troubleshoot and analyze before performing a full network stack. To this end, the plan is for all client teams to gather somewhere in Ontario, Canada this September: no one can leave until all client executions are properly interoperable.

Successful interoperability will pave the way for a common, long-term public test network that will be launched this year. At that time, any user who wants to join the test network can choose to install an Ethereum 2.0 client, pledge to test ETH tokens, participate in verification activities in the test network, or find test network vulnerabilities. People who find bugs and defects have a chance to get rewards.

Finally, if the progress goes well, the beacon chain will start in early 2020. It has been suggested that the launch date is scheduled for January 3, 2020, as this is the anniversary of the birth of the Bitcoin creation block. But it is still too early for the beacon chain to be fully productized, and I think it is most likely to be released by the end of the first quarter of 2020.

The final step required before the beacon chain is launched is to deploy the verifier pledge contract to the current Ethereum 1.0 blockchain. The pledge contract stipulates that any user who wants to be a certifier will need to mortgage 32 ETH. The plan is to be deployed during the fifth developer conference (DevCon V) in early October. Once the number of ETH pledges in the pledge contract reaches about 2 million, which means that the number of certifiers is sufficient (about 65,000), we can safely officially launch the beacon chain to make it safe against attacks. degree.

Slice chain [stage 1]

Although the delivery schedule of Ethereum 2.0 is carried out in stages, each phase is actually carried out in parallel.

Phase 1 mainly covers the design and delivery of the fragmented data link. At this stage, we will add 1024 separate blockchains (shards) to the system, each chain connected to the beacon chain. The phase 1 protocol is much simpler than the beacon chain phase, and the nearly completed total code line for the protocol is only about half of the beacon chain.

Ethereum 2.0 will be an unprecedentedly scalable peer-to-peer network source Daniel Aleksandersen

The main challenge of Phase 1 is that the design of the point-to-point network requires accurate and accurate information transfer to and from the correct verifiers once the verifier is distributed over the 1024 slice chain. Related work is being done concurrently with client interoperability.

Executive layer [stage 2]

The most exciting recent development is the final delivery phase of Ethereum 2.0, the executive level, with a clear direction. As a person with writing experience, I clearly know how great the challenge is when faced with a blank sheet of paper. In the same way, when the design space is huge and unconstrained, the problem of “difficult to start” is very tricky. Therefore, the implementation layer design of Ethereum 2.0 has experienced such a difficult period.

Until a few weeks ago, no one was quite sure where to start: What kind of procedures would we be able to run on Ethereum 2.0? What will the user account look like? How will each shard communicate with each other? The idea is endless, and the possibilities are endless, but how to achieve it step by step is puzzling.

Breaking the deadlock is Casey Detrio, who made a short historical summary at the Scaling Ethereum conference in Toronto. In addition, he announced a proposal, which was then effective. Sex is proven. Casey's advice was adopted by Vitalik and further expanded, and other developers were enthusiastically involved in experimenting and defining it.

There is only one execution environment on the current Ethereum blockchain, the Ethereum Virtual Machine (EVM). EVM was previously written into the Ethereum protocol, so each smart contract can only be executed via EVM, the execution of the contract is charged in some way (ie gas), and only specific cryptographic signatures and replay attack protection schemes ( Replay-protection) get permission. EVM is very powerful, but it is subject to some restrictions: even if users only want to send a small amount of ERC20 tokens, they need to recharge ETH in the account; full anonymous transactions are difficult to achieve; using some innovative encryption technology also costs.

In short, the Ethereum 2.0 proposal is to separate these issues. The Ethereum 2.0 blockchain no longer enforces these mechanisms. Instead, it provides users with many different execution environments , each of which will be based on its intended use to develop appropriate rules and operate on this basis.

For example, in addition to the general execution environment for smart contracts compiled in eWASM, there may be other execution environments in place to optimize anonymous token transactions, support new smart contract languages ​​(language like Haskell), and handle A high-capacity Plasma chain that joins licensed and privacy features to serve enterprise users. There may even be an execution environment that can run the Move virtual machine in a Libra project.

Ethereum 2.0 is still in the rapid development phase, and more details will be discussed in subsequent articles. I will also mention here that the "market" development model has an important impact on Phase 2. All along, we hope to place the entire current Ethereum 1.0 chain as a piece chain in Ethereum 2.0. This not only protects the future of the existing Ethereum application, but does not prevent us from eventually removing the Workload Proof (PoW) mechanism. We already have a practical solution for this, and we are working on a detailed design for this solution. “Eth1+Eth2” is not necessary to be implemented in the early days of Ethereum 2.0, and it can still be deployed in the later stage, so we still have time to strengthen this solution.

Conclusion

Busy market (Diego Delso)

As far as the current development speed is concerned, I am more optimistic about the future of Ethereum 2.0 than ever before. I don't like to talk about it, but I can't help but wonder: According to the current development, stage 2, which is the final delivery stage of Ethereum 2.0, seems to be put into use by 2020, which is earlier than originally planned (only as a personal assumption). .

From reality to implementation, we still have a lot of work to do, but it will never be like a headless fly, because our road ahead is very clear, developers and community members provide strong support, and there is a constant stream of The new force of power joins us. The energy of the Ethereum “Market” is amazing. This is an exciting stage. I believe that with so many outstanding and high-spirited participants, the final result must be extraordinary!

Ethereum “Market” is open to everyone, don’t you join us on github?

Original link: https://media.consensys.net/ethereum-2-0s-latest-strides-forward-13f63652e57d

Reprinted please specify: ECN Ethereum China

Source: WeChat public number: ETH Chinese network

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