Ethereum 2.0 Progress Update (June 2019)

I know that you have been screened by Libra in recent days, so there is a little comfort here: this article will not mention Libra's information, here we will review some of the latest Ethereum 2.0 development progress.

The content of this article is not very comprehensive, and there are too many things happening these days. I will sort out the various pieces that have accumulated over the past few weeks into something coherent.

Let's start with the development update. As we all know, the delivery plan of Ethereum 2.0 is divided into three different stages. The most exciting recent development is the progress of Phase 0 (close to the beacon chain client interoperability) and Phase 2 (the beginning of the Ethereum 2.0 computing model) .

Stage 0: Beacon chain implementation

The beacon chain is the coordination layer of the entire Ethereum 2.0 system and may be the most difficult part to deliver. For background on beacon chains, see my previous State of Ethereum Protocol #2: The Beacon Chain [1].

In June last year, the beacon chain was conceived as the future of Ethereum 2.0. Only one year later, the specification of stage 0 will be frozen and finalized on June 30 this year . It's a brand new blockchain design with an unprecedented ambition that includes dozens of major innovations and insights, and eight client implementations are ready: this is an amazing year for the Ethereum community . Frankly speaking, this will make Libra dwarf. Anyone who disagrees with this is living in a different universe than mine.

Since the update on the Ethereum 2.0 specification has been well tracked and documented on Github [2], I have not covered it in detail as before. Today we will introduce relevant progress from a broader perspective.

01. Interoperability

As the specification of Phase 0 stabilizes, the focus now shifts to the interoperability between the various Ethereum 2.0 client implementations . Currently 8 active teams are keeping up with the latest Ethereum 2.0 specification.

Once the beacon chain network is enabled, each client will need to communicate with each other in order to agree on the status of the beacon chain. Every client needs to follow the same rules: even if a bit is incorrect, it will lead to a failure to reach a consensus.

With this in mind, we held a seminar at the Bushwick Generator in Brooklyn called "The Road to Interop." I took some photos [3], and interested people can watch live video recordings for up to four hours [4], as well as the agenda of the seminar [5]. This is a place where several client implementation teams get together and plan how our clients can communicate with each other consistently. Vitalik gave a speech on the idea of ​​Stage 2 in the afternoon (see below). Terence Tsao also released a presentation slide on the Prysm client architecture and design [6].

The next major event in the program is the seminar entitled “Interop Lock-in”, held around the beginning of September. At that time, the client implementation team will be gathering in a remote cottage in Ontario, but only after we have confirmed that all clients are able to get along well.

Jonny Rhea has compiled and published the various stages of the road to interoperability on Github [7], which you can refer to.

02. Networking

The ultimate goal is to make Libp2p a P2P communication protocol based on the Ethereum 2.0 network (Note: Libp2p is a network framework that allows users to develop decentralized peer-to-peer applications).

However, as a simplified step to achieving this goal, each client is implementing a simpler Hobbits protocol , and this article [8] by Trenton van Epps provides a good introduction to the Hobbits protocol. Jonny also elaborated on the basic principles of the Hobbits protocol in the form of a tweet storm [9], and ConsenSys also provided some incentives [10] to encourage teams to integrate the protocol in the client.

At the same time, Whiteblock did some performance tests on Libp2p, and Daniel Choi introduced it at the Scaling Ethereum seminar [11]. Their findings raise some questions about the performance of Libp2p in some cases [12]. However, by working with Prtcocol Labs, we will also conduct some further tests on Libp2p to explore a more realistic range of parameters associated with Ethereum 2.0.

Another interesting development is the Handel: Practical Multi-signature Aggregation for Large Byzantine Committees published by the PegaSys R&D team (Handel: Achieving the Practical Multi-Signal Aggregation of the Larger Byzantine Commission) [13].

The agreement can significantly speed up the speed of attestations collected by the certifiers in Ethereum 2.0, allowing for greater commission sizes, so the finality of the transaction may be achieved faster .

03. Testing (Testing)

During the current development of Phase 0, a large amount of testing work is underway . It is worth noting that Antoine Toulme's work on the test runner, funded by Moloch DAO, can be used to learn about recent progress updates [14], which is well worth checking out by client developers.

The specification is executable, and all cross-client test vectors can be generated directly from the well-written specification [15], which is great.

A lot of work is still needed to fuzz-test the specification and provide a framework for fuzzing the client, as reflected in the latest version of the Ethereum 2.0 specification [16] ].

04. Formal Verification

Runtime Verification has written an audit report on the Ethereum 2.0 deposit contract incremental Merkle tree implementation, which is written in the Vyper language instead of Solidity.

This is an important milestone in paving the way for the deployment of deposit contracts to the current Ethereum 1.0 chain. For readability, Joe Delong of our team (note: PegaSys team) wrote an explanatory article on the implementation of the Ethereum 2.0 deposit Merkle tree [17]. The sparse Merkle number is great!

Runtime Verification will also generate a formal executable specification for beacon chains in the K language [18].

05. Beacon chain online

At the teleconference of the Ethereum 2.0 implementer last week, Justin Drake proposed two target dates for the beacon chain deployment phase:

1. During the DevCon 5 meeting: Deploy the deposit contract to the current Ethereum 1.0 chain. This public ceremony will help to prevent fraudsters from posting fake addresses to steal people's deposits.

2. January 3, 2020: The beacon chain creation zone may be born. At that time, the beacon chain will be officially opened.

The birth of the beacon chain creation block will depend on two prerequisites. First, there must be enough ETHs in the deposit contract. A previous hard target was that the number of pledges exceeded 2 million ETH, but this requirement has been removed [19]. But the goal of the number of pledges will be an order to ensure the safe start of the beacon chain.

The second prerequisite is that the target is 3 (or at least two) "production ready" beacon chain clients and network certifiers. Prior to this, all clients had to do a lot of compatibility, optimization, testing, auditing, improvement, tooling, documentation, and packaging, so I think the goal of January 3 is somewhat ambitious.

Phase 1: Fragmentation data

Recently, the specification of Phase 1 [20] has become an oasis of Serenity.

Phase 2: State Execution

To be fair, just a few months ago, the stage 2 of Ethereum 2.0 to be delivered was still in the fog. Phase 2 is the so-called "execution layer", which makes the Ethereum 2.0 blockchain practically available. This phase will provide the transfer of funds, the implementation of smart contracts and all the features that allow the dapp to be built. However, just in the beginning of April, we still don't know what this stage will look like. Casey Detrio gave a wonderful speech on the history and status of Phase 2 during the Scaling Ethereum conference [21], which is very worthy of five minutes to watch… All questions for this phase were open, design The space is still huge and the possibilities are limitless, when we don't know where to start.

To break the deadlock, Casey posted an exciting proposal on Phase One and Done: eth2 as a data availability engine [22]. Without a deep dive into all the details, this sparked a wave of innovation, and Phase 2 quickly and excitingly became the focus of attention.

Vitalik then silently disclosed the first proposal for Phase 2 [23] and its follow-up [24] in response to Casey's proposal. Will Villaneuva of the newly established Quilt team published an article explaining this in Medium [25]. During Interop Day in New York, Vitalik talked about the latest ideas for Phase 2 (see video [26]) and finally provided more background information during the Scaling Ethereum conference in Toronto (see video [27]).

The main purpose of Vitalik's proposal is to minimize the role of the Ethereum blockchain in executing transactions . In the Ethereum 1.0 chain, there is only one way to execute the transaction, that is, through the EVM. After executing a transaction in a block, the Merkle root of the transaction state will be written to the block. In order to run EVM on transactions in this block, all nodes need to store the status of the entire chain (including account balance, contract storage, etc.).

The current Phase 2 recommends using this model and promoting it. There are now several (and even many) EVM types (we call them execution environments (EEs)) .

The Execution Environment (EE) is code that is written in eWASM and runs (almost) as a pure function . This means that the execution environment itself does not store any state: any information that the execution environment needs to know must be provided along with the transaction. So, if I want to send you a token, then with this transaction, I need to provide a proof (such as a Merkle branch) to prove that there is this token in my balance; the execution environment doesn't know me. How much is the balance because it does not store any information. In fact, this is not entirely true: each execution environment will store a 32-byte value that is some kind of summary or accumulator of its current global state (perhaps a Merkle root, but this is not prescriptive It can be anything safe enough).

Extracting the execution layer in this way provides maximum flexibility. There may be tokens or enterprise-friendly environments such as zk-Rollups, ERC20, Plasam, or EE (execution environment) for smart contracts written in Haskell [28], and so on.

The idea is that anyone can deploy their own EE to support their professional blockchain environment at a very high cost (approximately 100 ETH?). The Ethereum 2.0 segmentation chain focuses only on the basic aspects: transaction sequencing and data availability .

Currently, some issues are still being actively discussed: whether to support synchronous calls between EEs, how to assemble blocks and how to charge gas charges[29], whether EE is permanent or need to pay some storage fees, EE What will be deployed initially in Ethereum 2.0 and so on. But in my opinion, this is undoubtedly the right direction.

If you want to know more about this, you can check out Casey and Alex's Scout library [30], they are doing some possible prototypes [31], and their article on Phase 2 execution Prototyping engine [31].

For those of us who are more familiar with the specifics of current EVM implementations, all of this may sound quite abstract and unfamiliar. Don't worry, adapting to the smooth transition path between Ethereum 1.0 and Ethereum 2.0 has become a priority, and there are some interesting ideas [33] that can be effectively implemented. Although there are still some challenges [34], the related discussion [35] has been carried out in the line.

other information

Here are some pieces of information that I randomly collected in the past month or so:

  • Colin Schwartz of Chainsafe is writing a complete guide to Ethereum 2.0 [36] and the first part on the scalability of Ethereum 2.0 [37];
  • Danny Ryan's “Cautious Optimism” during the Ethereal conference [38];
  • EthGasStation worked with the Prysm team and published a report [39];
  • Alex Stokes wrote an article explaining how Ethereum 2.0 acts as the ultimate gadget for Ethereum 1.0 [40] and an article on the economic security of the Ethereum 2.0 consensus [41];
  • Matt Garnett's list of resources to open Ethereum 2.0 learning [42];

Follow me on Twitter [43] or Peepeth [44] for more information.

More resources

  • Related specification documents [45]

୦ Pull requests [46]

୦ Commits [47]

୦ Issues [48]

  • Certifier Registration Contract [49]
  • Biweekly Ethereum 2.0 Implementer Conference Call [50]
  • Https://
  • Https:// &
  • Eth2.0 Handbook update [51]
  • Sharding Roadmap Update [52]
  • Beacon chain related issues [53]
  • Https://
  • Ethereum Reddit Community Address [54]
  • Cryptocurrency related Twitter account [55]

The links involved in the article:
























































Author | Ben Edgington Compilation | Jhonny

The copyright of the article belongs to the original author, and its content and opinions do not represent the Unitimes position.