Ethereum Phase 2 progress (2019-12)
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)
Ethereum enthusiasts (ID: ethfans)
, Author: Will Villanueva, translation & proofreading: A Jian & Zeng Mi, reproduced by Odaily with authorization.
Work on Ethereum 2.0 Phase 2 continues to advance. This article describes the latest developments as of now. Most of the work in Phase 2 was done in collaboration between the Ewasm team and the Quilt team at the Ethereum Foundation.
The content in different parts of this article often points to different fields, and there is little intersection. Therefore, please choose the part you like to read. Before reading this article, I highly recommend that you first understand the background knowledge of Phase2 and the execution environment proposal (EE) through the following materials:
The road to Eth 2 Phase 2 and the Phase 2 testnet (this is the talk from Devcon 5, and the slides used for the talk)
EthHub's in-depth interpretation of Ethereum 2.0 Phase 2
Travel around Eth2 Phase2 (some knowledge points are outdated)
Ewasm 2.0: State Enforcement in Eth2.0 (advanced reading)
first level title
Protocol Layer Changes Affecting Phase 2
Vitalik's Proposal 2 refines Proposal 1 and the new concept of Eth2 as a stateless protocol (this blog post has a section titled "Shard Chains Don't Need State", which briefly explains what statelessness is).
The current Phase 2 design does not deviate significantly from Proposition 2 ideas. Historically, parts of the proposal did change when the concept of beacon chain load balancing was introduced. This idea of load balancing proposes to understand a shard chain as a pure computing process, then EE can dynamically run on the pre-specified shard chain. Essentially, this idea is to balance the computing load to different shard chains through the load balancing contract defined on the beacon chain. It is worth emphasizing that this design concept is very interesting, and multiple different modes of cross-shard synchronous transactions can be realized through cooperating relayers. It deserves more effort for our research. If reliable, we can add this tool to the shard chain in the future (maybe after it goes online).
first level title
Scout
We have made significant progress building prototypes and early implementations of the execution environment. First, we need to verify that an execution environment can operate in a stateless mode. Will the amount of proof/witness data required for this execution environment be too large? Would it take too long to use proofs to perform state transitions? In order to answer these questions, we have made many execution environments and used them to study these questions. However, first we need an engine for building prototypes: Scout.
secondary title
Scout is an Ethereum 2.0 Phase 2 execution process prototyping engine (originally developed by Alex Beregszaszi), which has developed a wrapper for the Ewasm API, so developers can use it to build a prototype of the execution environment and conduct benchmark tests ( benchmarking). And it also has assembly script and C++ ports.
secondary title
EEs related to Eth1
In order to support the switching from Eth1 to Eth2, we need to make the state transition rules of Eth1 into an execution environment in Eth2. The main challenge of this switch is to convert Eth1 to a stateless model, and then convert the EVM and transaction/account model to an execution environment. The EEs mentioned below are the predecessors of Eth1 EE. A working group has recently been formed to focus heavily on development around Eth1 EE. They put together an initial work plan and kindly introduced themselves on the eth research forum.
Stateless Merkel Patricia Tree (SMPT) token
Primary sources: Github, Sina Mahmoodi's presentation at Devcon 5
The first prototype of stateless token EE aims to mimic the architecture of Eth 1.0. It uses parity's code base to implement the Eth1 state tree (Hexary Merkle-Patricia Trie) and RLP encoding rules. It also incorporates a basic relayer implementation that lets relayers generate multiple proofs for a set of transactions.
Benchmark: 70 transactions and 5000 accounts/leaf nodes
Turbo Token
Time taken: 5 seconds
Evidence size: 235 kb
Significant improvements are still needed in execution execution and evidence size, but progress is also evident from these early results. One of the issues involved compiling Parity's rust library into wasm code, which resulted in a lot of memcopy (memory copy) operations and other inefficiencies. In general, compiling rust to web assembly has proven to be quite difficult. Also, the signature verification item took 4 seconds (out of 5 seconds total).
Main information: Turboproof overview (Editor's note: see the hyperlink at the end of the article for the Chinese translation), Turboproof Rust Github, Turbo Token Github, Guillaume Ballet's Devcon 5 speech, Sina Mahmoodi's Devcon 5 speech
The turboproofs technology used in the Turbo Token model was initially researched by Alexey Akhunov to implement the Eth1 stateless light client. It can efficiently generate, merge and serialize the multiproof of the Eth1 data tree, and also supports a single operation (single pass ) efficiently updates the data tree. Casey Detrio and Sina developed an initial single-branch prototype in assembly script and rust to verify that turboproof is efficient enough. After initially obtaining satisfactory results on the single-branch prototype, Casey implemented a simple and most basically usable turbo proof token EE with assembly scripts. Sina Mahmoodi copied this implementation and then ported Guillaume's turbo proof full rust codebase and generators to typescript.
Benchmark: 70 transactions and 5000 accounts/leaf nodes
Elapsed time: 140 ms
Evidence size: 50 kb
EVM interpreter EE
Summarize
We need to develop a (web assembly available) EVM interpreter in an execution engine to support Eth1 EE. Hugo made a prototype and tested it around an add and mul256 contract. In the future, more contracts and benchmarks need to be introduced to improve this prototype.
Summarize
All the experimental work mentioned above is to make an implementation of the Eth1 execution environment. We've started prototyping construction, but there are still a lot of performance issues to consider. As mentioned above, a working group has recently started to focus on developing Eth1 EE and creating an Eth1 stateless model.
C Merkle Token
secondary title
EEs Centered on Eth2
This section will introduce EEs that are not fully developed for Eth1 -> Eth2 migration. Eth2 will use a new account-based execution environment, which is different from the account and transaction model of Eth1, because the transaction, account and accumulator models used by Eth1 are not optimal. In addition, models such as optimistic rollups and ZK rollups should also be studied. The design space for Eth2 EE is wide open, and the following are early ideas and prototypes.
Main information: Github, Devcon 5 Presentation
Paul Dworzanski's C implementation of stateless Merkle tokens using binary Merkle trees (instead of sparse Merkle trees). The verification and update of the data tree use the optimal memory distribution, and arrange a unique multiproof format. The verification and update data tree operations of this model are completed in one pass (single pass) (thus avoiding memory copy operations (memcopy and duplication)), and it is very likely that it can be used on the hexadecimal data tree of Eth1. However, it is not clear whether the data tree update algorithm can be used on the Eth1 data tree (because the Eth1-based model generally uses multiple passes).
Benchmark: 40 of 222 accounts involved in the proof
ZK Rollup
Elapsed time: 20 ms (excluding signature verification)
Evidence size: 25 kb
Shard Ether (Sheth)
Currently, the implementation used in the test is already the most efficient. Signature verification is not included in the benchmark, but we estimate that it only takes an extra 30 milliseconds. And there are many further optimization solutions, such as caching hashes and proofs to reduce computing time and size. An adaptive hash length scheme (the length of the hash increases as the network grows) can also further reduce the proof size. Finally, better hash function implementations lead to shorter computation times.
Main information: General ZK Rollup Overview (Editor's Note: For the Chinese translation, see the hyperlink "ZK rolup vs. Optimistic rollup" at the end of the article), Devcon 5 speech, EE stark verifier example, WASM proof verifier, web snarks
ZK rollups is a Layer-2 extension solution. Because it does not use complex exit challenge mechanisms and locking mechanisms, it can avoid common user experience problems in existing Layer-2 solutions. Compared with other token transfer schemes listed here, ZK Rollup greatly downgrades the requirements for data availability. The implementations listed here use web snark - a generator implemented in wasm that can be used for snark verification or other pairing functions. To develop the EE, Jared adapted websnark, developing a separate wasm library for validating Groth16 proofs. This EE is still an early prototype and has to continue to be developed.
Primary sources: Github, Matt Garnett's Devcon 5 talk, Internal Quilt talk (in more detail), SSZ overview
Sheth is a precursor to Eth2 contract EE (based on Eth1, but iterated to make it more suitable for wasm/Eth2). Sheth is based on the Simple Serialization Encoding Specification (SSZ) used in Eth2, which uses a sparse Merkle tree scheme, borrows turboproof opcodes but uses a different form to manage read, write and update requirements. Diederik Loerakker's design idea is to decide how to traverse the entire data tree by storing a list of offsets. The strength of sparse Merkle tree proofs is that you can statically define at compile time the overall index of the data you are referencing. It also greatly simplifies the logic required to update the state, since nodes are never deleted or inserted into the data tree; however, there are some sacrifices (high-intensity hash calculations) for this. Sheth also includes a command-line client that can act as a relayer or status provider.
Benchmark: 50 accounts and 50 transactions
Evidence size: 517 kb
SimpleUmbrella — Eth2 Smart Contract EE
Main material: Proposal in Eth Research forum, execute code host function PR
first level title
Ewasm - Interpreter, Compiler, and Computational Metrics
secondary title
translater
secondary title
interpreter
secondary title
Computational metrics
Paul Dworzanski explored this area in depth in his Devcon 5 talk. To measure computation, the use_gas call injects wasm bytecode (whether it's running in EE or umbrella EE) when the wasm contract is deployed and verified. The complexity of injection and verification will undoubtedly affect the cost of contract deployment. Current benchmarks show that wasm code runs 1.04-2.4 times slower after injecting compute metrics. Benchmarking better patterns of the injection process and registry assembly will point to further optimizations.
Phase 1 and 2 prototypes in Lighthouse client or Phase 2 simulation
We wanted to simulate how Phase 1 and 2 clients would end up being built and how the teams developing the implementation would be supported. We also hope to use this work to simulate and test EE running across multiple shards in a real-world environment. During Devcon 5, I gave a talk about the simulation we built. We developed/introduced a very simple Phase 1 prototype (no networking components added) in the Lighthouse client and included a phase 2 Ewasm runtime in the client. We interact with Sheth (Sheth acts as a relayer and state provider) and are able to simulate basic EE or token transfers in Lighthouse.
Because the Lighthouse client is still actively being developed, we realized that maintaining a fork of the Lighthouse client and developing on top of it would likely be harder than we initially thought. So, we decided to take the nutrients from the initial prototype and develop an abstract stub version inside Scout. We will continue to simulate the operation of the beacon chain and the shard chain, but we can greatly simplify the logic, because our focus is on the research of the execution environment and cross-shard benchmarking. This part of the work is being managed by two new members of the Quilt team.
first level title
John Adler has written a very comprehensive overview on this topic. His article also tells an interesting evolution of the Eth2 proposal. To summarize, Vitalik's latest sharding simplification proposal eliminates many of the problems we had with the relayer model in the first place. However, there are still many open questions about how state providers send transactions to block producers, and how block producers incorporate transaction bundles into a suitable multiproof. One of the proposals is to deploy a new execution environment with a proof merge script.
Eventually, the relayer or state provider will inherit the RPC endpoint that web3.js or ethers.js is connected to. It is critical to come up with a set of standards for these operations across multiple EEs.
first level title
Cross-shard transactions
secondary title
Asynchronous cross-shard transactions
Vitalik's latest Phase 0 & 1 proposal is good news for both cross-shard transactions and composability. In the new proposal, a cross-shard call can be completed with only one time slot (6 seconds) of delay, while in the past proposal, a call had to wait for a delay of 12 to 18 minutes to be finalized. Therefore, transferring your state (or eth) between shards becomes very fast. Previously, we wanted to use optimistic roots to speed up the call, but found that these solutions were very complicated.
From the perspective of a dApp developer, cross-shard calls only need to follow the asynchronous paradigm and method in multi-threaded programming. When writing smart contracts, HLL (Slodity) and DSL (Vyper) need to provide the necessary tools to abstract cross-shard behavior into an asynchronous paradigm. The entire schema will most likely look like this:
Simple asynchronous calls (async await, callback, etc.)
Two-phase confirmation (atomicity)
Locks - Read/Write (Contract Yanking)
How to support these patterns in EE or in the underlying contract needs further research. The simulations mentioned above (and the orchestration tools mentioned below) should provide the basis for our experiments with these models, but really, we would say that this is an important area of research and if people are willing to get involved, we would be very happy. Specifying pre-process and post-process behavior at a lower level, as described in this post, may provide a reasonable framework for suspending and subsequently continuing execution within a contract.
Synchronize cross-shard transactions
Previously, Vitalik published a post discussing state schemes. The essence of these solutions is the Layer-2 mode on the chain, and the fragmentation is only used as a data availability layer. These models (that is, the previously legendary "delayed state execution" model, "lazy execution" model or "shadow chain") are actually the predecessors of the so-called optimistic rollups. Using multiple shards as a data availability layer for an optimistic rollup scheme makes it possible to synchronize transactions across shards. We may develop a prototype based on this concept in the not too distant future.
secondary title
Do we really need to call across shards?
Another point of view worthy of further study is that the main body of Eth2 should lean towards state channels, optimistic rollups, and zk rollups (after these schemes are mature). In this line of thinking, Eth2 itself is a data availability layer, and cross-shard calls are only used when bridging these schemes or during exit challenges/false proofs. Rollups still have to be defined within the boundaries of the Eth1 or Eth2 execution environment, however, calculations only need to be performed on-chain when error proofs need to be submitted.
first level title
Phase 2 Toolchain
To advance our research, we propose a toolchain that developers need to use. As mentioned in the "Phase 1 and Phase 2 prototypes in Lighthouse" section above, we are actively developing a set of simulations to test and run execution environments across shards. However, in order to optimize the smart contract operation mode, we have to add a lot of orchestration tools. This post explains these tools in more depth.
Phase 1 & 2 Simulation
Insert the runtime environment of the Phase 1 client
Reliable multi-proof backend (allows clients to generate, merge and manage multiproofs)
Relayer, state provider tools for interacting with web3.js (see "Relayers, state providers and fee markets" section)
Eth1 ->first level title
Vitalik's other contributions to Phase2
Vitalik has also discussed Phase 2 related topics in other posts recently, but I didn't quote directly above, hereby pointing out:
Eth2 Migration
Realize cross-shard transactions
Formalizing and Improving Eth2's Approach to Deterministic Response to Invalid Shard Blocks
Contracts saved on the beacon chain
Cross-shard DeFi composability
If you are interested in helping us, please get in touch and get involved. Please join this telegram channel for updates or questions. We have made progress, but there is still a lot of work to be done.
in conclusion
Finally, we'll start our monthly video conference. The first meeting is scheduled for Tuesday, December 3rd at 10:00AM ET.
first level title
