EVM Evolution Roadmap

Towards a More Aggressive Ethereum Execution Engine

The EVM isn’t going away anytime soon. We should invest in improving the EVM ahead of ewasm, while making the transition to ewasm smoother.

runevm.com

What is the EVM?

The Ethereum Virtual Machine (EVM) is the part that runs the smart contracts, transfers of value, and any other change to the consensus state. It defines what is possible to do with the platform.

Why Should You Care?

At today’s exchange rate, there is roughly $15 billion USD worth of Ether. This doesn’t account for any other assets that run on top of the platform: securities, real estate, digital collectables, bounties, and so on. It also doesn’t capture valuable aspects such as new forms of governance. In short: this is a system that is very important to the future of the world financial system (and more!)

Further, it is possible for smart contracts to be effectively “ownerless”, and run forever on the system. By default, they cannot be updated (though there are manual workarounds). You can think of these as essentially long-living services in the “web services” sense.

One would expect that a platform that controls so much value, and with code that is difficult-or-impossible to update, and backed by cryptographic guarantees on distributed consensus and accounts would be airtight. Unfortunately this is not the case. There have been many subtle bugs that cost tens- and hundreds-of-millions of dollars. While possible to analyze, the EVM as it exists today does not lend itself to formal methods.

With so much value on-platform, we should have better tools to automatically check if the code does what you (a human developer or consumer) expect it to, doesn’t include any number of common bugs, and performs its task for the lowest possible cost (both time and gas).

Performance

A quick note on performance: while most implementations have not been optimized for performance, this is entirely possible to do. While the EVM is almost certainly not the primary scaling bottleneck, better performance does mean lower system resource usage, more energy efficiency, and higher throughput when other components are running efficiently.

ewasm is Coming! Why Bother Updating the EVM?

ewasm

A major proposal for updating Ethereum is swapping out the EVM for ewasm. Wasm (AKA WebAssembly) is the new hotness, with adoption in browsers, edge computing, and more. Sadly it’s not tuned for an adversarial and deterministic environment like Ethereum. As such, a subset of Wasm has been proposed, which has been dubbed “ewasm” (i.e. Ethereum flavored WebAssembly).

The major advantages of ewasm include: access to the Wasm toolchain (including LLVM), better performance (because of design and raw optimization), expanded language support (primarily via LLVM). This would in theory allow some (not all!) precompiles to migrate to plain ewasm code and be regular smart contracts.

There are nontrivial challenges facing migration to ewasm. We still need to maintain our own ewasm-specific tools, including restricting the output to certain opcodes (some rewrite rules will not apply), improving the compiled performance of many languages to run under the gas limit, and so on.

The most optimistic timelines for direct ewasm support place it at 2 hard forks away (i.e. ~18 months). Less optimistic schedules place it in the 3-5 year range.

Even when it does land, there are still questions about what happens to existing smart contracts and the EVM. Do both VMs run next to each other and interact over message passing? Then we need to support the EVM. You can write an EVM in ewasm and have it run as a precompile. Then you need to continue to support the EVM. Drop the EVM completely and have people redeploy their code as ewasm. Then it would be good to have automatic (or semi-automated) tools to help migrate to the new platform. Then you should evolve the EVM design to be more similar to Wasm / Wasm-friendly. You may be noticing a pattern here 😉

High-Level EVM Improvements

Some of these changes require hard forks, others are purely internal to clients. They’re not totally separate, as many of the hard fork changes make client optimization much easier.

Goals

1. Smart Contract Safety
2. Execution Performance
3. Alignment with ewasm
4. Simplicity / Clean Up
5. Improvements to the Spec Itself

High-Level Overview

We will break out more detail for each of these in follow-up articles. In the meantime, here is a very high-level summary.

Safety / Correctness

• Subroutines
• Static jumps
• Non-overflowing arithmetic
• Ephemeral storage (ie: single transaction lifetime)

Memory

• Arbitrary local memory alignment (easier to solve for and much faster symbolic execution than byte-aligned)

Raw Performance

• SIMD
• MIMD (potentially)
• Variable-width VM word size (example: flag to enable native 32-bit arithmetic on the EVM)

Analytic Optimization

Client-specific, but can write general guidelines and reference implementations in Parity, EeVeeM, &c

• VM-level tail call optimization
• Incremental JIT optimization
• EVM-to-native smart contract compilation
• Automatic naive wordsize detection (e.g. sequences of ADDMOD 32 can be done hardware-natively / optimize away the 256-bit words)
• Adjust gas cost to make native wordsize (or easily aligned) operations cheaper
• Decoupled gas metering / gas aggregation
• Shared bytecode linking (improve contract size)

Simplicity / Clean Up

• Deprecate dynamic jumps
• Deprecate several precompiles (controversial!)
• Move cryptographic primitives into the mostly empty 0x20 opcode range

Expand Language Support via LLVM

The LLVM is what gives Wasm most of its language support. It is a major modern compiler infrastructure project, backed by companies like Apple, Google, Microsoft, Facebook, Cisco, Fastly, and more. It boasts some of the top R&D in the area, and is in use in a huge number of major production systems.

The LLVM is modular and designed to be easy to integrate with. An LLVM-to-EVM backend would unlock many languages for smart contract development on ETH 1.x wile maintaining full compatibility with today’s smart contracts (i.e. Wasm is not required to get better language support).

Adapted from this article

Some of these languages include (but are not limited to) C, C++, C#, JavaScript, Rust, Python, Ruby, Swift, Kotlin, Scala, Haskell, Lua, Fortran, Scheme, and Ada. This also enables most (all?) of the LLVM ecosystem, such as code optimizers, static analysis & security tools, and compile targets that LLVM ecosystem enjoys (e.g. native machine code).

Industrial-Strength Formally Verified Infrastructure

Ethereum is responsible for enough value — and is an adversarial enough platform— that putting in the effort to formally verify key infrastructure to route out edge cases and major bugs makes sense. In essence, formal proofs (“for all cases”) are better than tests (“these specific handful of cases”), and complete specs are better than ones with unspecified behaviours.

• Replace the Yellow Paper as the canonical spec with a formally verified version (e.g. extend the Jello Paper to the entire client)
• Maintain the Yellow and Beige Papers for non-formalists
• Keep the client spec ahead of the hard fork schedule
• A complete (spec-generated) test suite
• Develop a formally-verified client, likely in Idris or F*

Wrap Up

The EVM can (and should!) be improved. We will expand on each of the points above in follow-up articles.

Key Takeaways

1. The EVM is critical infrastructure, and will be for some time. ewasm is still a ways off from being Ethereum’s execution engine, and the EVM is used in more places than Ethereum mainnet.

2. The current EVM design leaves something to be desired, but is absolutely possible to improve. We propose a programme of “EVM Evolution” to both improve the execution engine that we have today, and make it easier to interoperate with — and migrate to — ewasm when it comes.

One More Thing

RUN EVM: Opcode 1

Interested in these topics? Join a community interested in improving the EVM! We’re hosting the first in a series of events on EVM improvements, the ETH 1.x Roadmap, side chains, and more the week of April 15, 2019 in Berlin, Germany.

This meeting will include work on the Ethereum mainnet, other public and private chains that make use of the EVM, and specific side chain approaches.