Execution Environments

We’ve made significant progress on prototyping and building early Execution Environments. First, we needed to validate whether an Execution Environment would even work in a stateless model. Would the required proofs/witnesses be too large? Would the time to execute using a proof be too expensive? To answer these questions, we built a number of Execution Environments and used those to explore these questions further, but first, we needed an execution prototyping engine: Scout.

Scout

Scout is an Ethereum 2.0 Phase 2 execution prototyping engine (originally developed by Alex Beregszaszi). It builds a wrapper on the Ewasm API to allow for prototyping and benchmarking of Execution Environments. There is also an assembly script and C++ port.

EEs — Eth1 Related

In order to support the eth1 switchover into eth2, we’ll need to build eth1 as an EE in eth2. Main challenges in the switchover include converting eth1 to a stateless model and bringing the EVM and transaction/account model into an execution environment. The EEs described below are precursors to the eth1 EE. A recent working group has formed to ramp up efforts around building the eth1 EE. They have put together an initial plan to guide efforts and have kindly introduced themselves on eth research.

Stateless Merkle Patricia Trie (SMPT) token

Main Resources: Github, Presentation by Sina Mahmoodi at Devcon 5

The first prototype of a stateless token EE aimed at mimicking Eth 1.0’s model. It used parity’s libraries for the eth1 trie (Hexary Merkle-Patricia) and RLP. It also included a basic relayer implementation to generate multiproofs for a transaction set.

Benchmark: 70 Transactions and 5,000 accounts/leaf nodes

Time: 5 seconds

Proof Size: 235 kb

Both execution time and proof size needed significant improvement but progress was shown through early results. One of the issues revolved around compiling Parity’s rust-based libraries to wasm. It resulted in far too many memcopy operations and other inefficiencies. In general, compiling rust to web assembly has shown to have a number of gotchas and difficulties. Additionally, signature verification made up 4 seconds of the total 5 second time period.

Turbo Token

Main Resources: Turboproofs Overview, Turboproof Rust Github, Turbo Token Github, Guillaume Ballet’s Devcon 5 presentation on Turboproof, Sina Mahmoodi Devcon 5 Presentation on Turbo Token

Turbo token utilizes turboproofs, which Alexey Akhunov originally investigated for eth1 stateless light clients. It provides a performant way of generating, merging and serializing multiproofs for the eth1 trie and supports efficient single pass updates on the trie. Casey Detrio and Sina built an initial single-branch prototype in assembly script and rust to verify decent performance could be accomplished. After initially accomplishing positive results on a single branch, Casey produced a simple, minimal turbo proof token EE in assembly script. Sina Mahmoodi forked this implementation then ported Guillaume’s comprehensive rust turbo proof library and generator into typescript.

Benchmark: 70 Transactions and 5,000 accounts/leaf nodes

Time: 140 ms

Proof Size: 50 kb

Execution time and proof size improved significantly from the SMPT prototype. Additionally, signature verification dominated 105 ms of the total benchmark time. Benchmarks from Casey Detrio, suggest the 105ms can be reduced to ~1/3 the time through further optimizations of signature verification. As can be seen, 5,000 accounts does not represent a real world value like the current # of accounts in the eth1 trie. Sina is now working on expanding the benchmark for this EE to run on a real life workload.

EVM Interpreter EE

Main Resources: Github, Devcon 5 Presentation

We need to build an EVM interpreter (web assembly) in an execution environment to support the eth1 EE. Hugo produced an initial prototype with tests around an add and mul256 contract. To advance the current prototype further, more contracts and benchmarking will be introduced.

Eth1 EE

All the experimentation above is intended to lead to an implementation of the eth1 execution environment. We can already begin prototyping it, but a number of performance concerns still need to be reviewed. As mentioned above, a recent working group has been established to hyperfocus on building the eth1 EE and making eth1 stateless.

Execution Environments — Eth2 Centric

In general, this section describes execution environments which are not necessarily focused on the eth1-> eth2 switchover. Eth1’s account and transaction model should be iterated on for a new account based execution environment in eth2 since the transaction, account and accumulator models eth1 uses is not optimal. Additionally, other EE models should be explored such as optimistic rollups, ZK rollups and more. The design space for eth2 EEs is wide open, and the following are early ideas and prototypes.

C Merkle Token

Main Resources: Github, Devcon 5 Presentation

Paul Dworzanski’s implementation in C for a stateless merkle token uses a binary trie (not sparse). It uses a unique multiproof format for optimal memory layout on both the verification and the update of the trie. The update and verification is all done in a single pass (avoids memcopy and duplication) and can most likely be adapted to the eth1 hexary trie if needed. It is unknown, however, whether the update algorithm could be applied to the eth1 trie (since eth1 based models typically utilize multiple passes).

Benchmark: 2²² accounts and 40 accounts in the proof

Time: 20 ms (no signature verification)

Proof Size: 25kB

At this time, this implementation is the most performant. The benchmarks did not include signature verification, but we may only expect a ~30ms increase. There are a number of ways to optimize further. We may decrease the time and size by caching hashes and proofs. Adaptive hash length (the hash length would increase as the network grows) could also decrease the proof size further. Finally, the time could be decreased by using a better hashing implementation.

ZK Rollup

Main Resources: General ZK Rollup Overview, Devcon 5 Presentation, EE stark verifier example, WASM proof verifier, web snarks

ZK rollups is a layer 2 scaling mechanism which does not require complex exit games or lockup periods (UX issues that plague existing L2 solutions). As compared to other token-transfer techniques we have explored, ZK Rollup requires significantly reduced data-availability requirements. The implementation utilizes web snark— a wasm generator for needed snark verifications and other pairing functions. In order to build the EE, Jared adapted from websnark to create a standalone wasm library for verifying Groth16 proofs. It’s an early prototype and work continues on this EE.

Shard Ether (Sheth)

Main Resources: Github, Matt Garnett Devcon 5 Presentation, Internal Quilt Presentation (more detailed), SSZ overview

Sheth is a precursor to the eth2 contract EE (eth1 but iterated model which is more wasm/eth2 centric). Sheth is based on the simple serialize (SSZ) spec used for eth2. It uses a sparse merkle tree and an alternative format from turboproof’s opcode approach to manage in place read, writes and updates. Devised by Diederik Loerakker, it operates by storing a list of offsets which determine how to traverse the tree appropriately. The advantage of a proof being sparse is that you can statically define at compile time the general index of data you’re referencing. It also drastically simplifies the logic needed to update the state since nodes are never deleted or inserted but comes with its own set of tradeoffs (higher degree of hashing). Sheth also includes a command line client which acts in the capacity of a relayer or state provider.

Benchmark: 50 accounts and 50 transactions

Proof Size: 517 kb

The current implementation takes up too much space (517 kb is quite a bit!) and is slower than we would like to see . The size can be drastically reduced by removing zero padding or de-duping the amount of zero hashes. The speed should be improved by introducing host functions to manage 256 bit operations (as described in a subsequent section) as well as needed code optimizations. Diederik Loerakker has opened a new issue on how to make this design more performant. In general, using a sparse tree is going to be heavier on hashing and its effects can be seen from the initial benchmark.

SimpleUmbrella — Eth2 Smart Contract EE

Main Resources: Eth Research Proposal, execute code host function PR

The eth2 EE is a stateless smart contract execution environment. It runs smart contracts similarly to the eth1 EE, but the contracts are Wasm centric (not EVM). Additionally, it will likely support alternative accumulators vs. the hexary patricia merkle tree used in eth1. Sparse Merkle trees show promise, but further benchmarking is needed in order to make a concrete decision. Matt Garnett put together an early specification of how an eth2 EE would spawn runtimes and share callee/caller data in its child contracts. An early implementation of this EE gave ideas on a general API or set of host functions. More recently, we built a prototype of host functions, in response to a recent discussion, needed to spawn or execute child contracts within the eth2 EE. A new repository has been opened and we’ll be running basic smart contracts soon!