Ethereum 2.0: A Complete Guide. Ewasm.

Image Courtesy of CC Search. By Stan Levandovsky

In articles one, two and three of this series, I explored various features of the anticipated Ethereum update Eth 2.0. Article one gave an introduction to the update and offered general information about its structure and expected features. Article two, Part One and Part Two, examined layer 2 scaling and sharding respectively, and Article 3 dove into the details of Casper and the Beacon Chain. This fourth article will explore the Ethereum Virtual Machine (EVM) and Ethereum WebAssembly (Ewasm). Ewasm will replace the EVM as the state execution engine of the Ethereum network and is expected to be one of the final aspects of Eth 2.0 to be integrated.

What is the Ethereum Virtual Machine?

In order to understand Ewasm and its implications for the Ethereum network, we must first become familiar with the Ethereum Virtual Machine (EVM) that Ewasm will replace. The EVM is a lightweight virtual machine, designed to run smart contracts on the Ethereum network.¹ As a virtual machine, the EVM functions a little differently from a traditional operating system such as Windows, which only needs to run on one machine at a time. Generally speaking, virtual machines (VMs) are high level abstractions that are built on a native operating system to emulate a physical machine.² They allow the same platform to run on many different hardware architectures and operating systems.² This makes VMs well suited to a distributed network like Ethereum that must be accessible through several clients on various machines all over the world. The EVM is built to emulate operations that could be executed by a physical CPU and is in charge of many of Ethereum’s key functions.

In addition to being a virtual machine, the EVM is also a “stack machine” and a “state machine” (I know, it’s a lot of adjectives, bear with me). A state machine is simply a machine that can read inputs and transition to a new state based on those inputs.³ A stack-based VM is one in which the memory structure is organized and accessed as a stack. This is opposed to a register based VM in which the memory structure is stored on a CPU’s register.² To carry out an operation on a stack based VM, data called an “operand” is “popped” from the stack, processed by being subjected to an operation, and then “pushed” back onto the stack according to the principle of LIFO (Last in First Out).² Addition using a stack based machine would work in the following way:

1. POP 20
2. POP 7
3. ADD 20, 7, result
4. PUSH result

https://markfaction.wordpress.com/2012/07/15/stack-based-vs-register-based-virtual-machine-architecture-and-the-dalvik-vm

One of the main advantages of using this stack-based system is that the EVM does not need to explicitly know the address of the operands it is dealing with because calling the stack pointer (SP) will always provide the next operand. This helps the EVM to increase efficiency and reduce storage requirements.

In addition to the stack, the EVM can also store data to the memory (RAM) and to disk storage. Sending data to the disk storage requires the most gas, sending to the stack requires the least.¹ The EVM decides where certain data will be sent based on its intended purpose and anticipated gas cost. On a macro level, the EVM consists of a world state, a machine state and a virtual ROM.⁴ The world state is the storage of all the accounts on the network while the machine state includes program counter, gas available, stack and memory. The virtual ROM is immutable “EVM bytecode,” a special language that only the EVM can understand.⁴ It is important to understand bytecode, and its relation to high level languages like Solidity in order to fully grasp the functions of the EVM. From the network’s inception, Ethereum developers have written code in the Solidity programming language.¹ Solidity is a “high level” programming language which means that while developers can understand Solidity, machines cannot.¹ To make the Solidity code comprehensible to a computer, it must be compiled using a solidity compiler called solc. The compiler will translate Solidity into bytecode which is a binary representation of Solidity opcodes.¹ The EVM treats all values as binary and cannot understand anything else so compilers are an important feature that allow developers to be understood by the EVM.¹

What Does the Ethereum Virtual Machine Do?

The EVM facilitates most of the transactions and operations on the Ethereum network including the execution of smart contracts. It is in charge of various data structures which contain instructions and operands, the data processed by the instructions. The EVM also includes an instruction dispatcher or “virtual CPU” which fetches and executes instructions and decodes operands.² At a high level the EVM keeps track of network components such as World State, Storage State and Block Information.³ The EVM also creates a Runtime Environment for smart contracts on the Ethereum network.⁴ Information from the runtime environment is used to execute specific transactions. This information includes:

Gas price — “Current gas price as specified by the initiator of the transaction”³

Codesize — “The size of the transaction codebase”³

Caller — “The address of the account that is executing the transaction”³

Origin — “The address of the transaction’s original sender”³

Finally, in addition to all of these other duties, the EVM handles account information as it pertains to block number, gas price, addresses and balances.³ Because the EVM is in charge of so many important functions on the Ethereum network, the speed with which it is able to handle operations and transactions affects the overall speed and performance of the entire network. Similarly, the efficiency with which the EVM is able to execute code directly affects the efficiency of the network. As a result, increased load on the Ethereum network in recent years has caused the EVM itself to become a bottleneck that often reduces throughput and increases transaction times.⁵ This issue of efficiency is one of the major reasons why Ethereum plans to transition from the EVM to Ewasm.

What is Ewasm?

One of the central aspects of the Ethereum 2.0 update will be a transition from the EVM to Ewasm. Wasm stands for WebAssembly, an open standard instruction-set developed by a W3C community group. Wasm is built for the web and is being actively developed by engineers from Mozilla, Google, Microsoft and Apple.⁵ Ewasm (Ethereum WebAssembly), is a “restricted subset of Wasm” that has been modified specifically for the Ethereum network.⁶ Wasm was designed with a specific set of goals in mind. Primarily, Wasm is designed to be fast, efficient and portable. This means that it can take advantage of common hardware capabilities in order to execute at “near-native speed.”⁷ The software is also designed to be easily readable and debuggable. This is achieved through a text format that can be read by humans, allowing code to be viewed, written and debugged by hand.⁷ Finally, Wasm is designed to be secure, by enforcing a host browser’s permissions policies, and highly compatible, through maintaining backwards compatibility.⁷ The team that created Ewasm has also laid out several more specific project goals. One of the major targets is to provide an EVM transcompiler and a metering injector, preferably as an Ewasm contract.⁶ Another is a clear specification of the Ethereum interface and Ewasm contract semantics.⁶ Finally, the team aims to implement an Ewasm backend for the Solidity compiler and to provide instructions and a library for writing contracts in C and Rust.⁶ The differences between Ewasm and wasm can be thought of in the following way: Ewasm = Wasm — nondeterminism (floating point) + metering + EEI methods (used to interact with Ethereum).⁸ Ethereum will join projects like Polkadot, Cardano, EOS, Tron, Spacemesh and NEAR protocol, who have either already adopted or are in the process of adopting Wasm.⁹

Ewasm vs EVM

From its inception, the EVM was designed to emphasize correctness rather than efficiency. This is reflected in the fact that all nodes on the network must run the EVM with complete accuracy. Wasm, while similar to the EVM, was invented for the web.¹⁰ Rather than correctness, Wasm emphasizes efficiency and quick loading.¹⁰ Ethereum developer Lane Rettig states that the EVM was created without “an enormous amount of design thinking.”¹¹ He believes the EVM was designed theoretically rather than practically, so while it is internally sound it does not function optimally in real world applications.¹¹ Nick Johnson agrees that the EVM is “optimized for theoretical purity, rather than practical use.”⁹ He explains how although the EVM is “very internally consistent… it’s not built with real-world implementation in mind.”⁹ By comparison, Wasm was written closer to real hardware instructions, which makes it more efficient at translating actual coding logic.⁹ The fact that Wasm instructions can directly map one-to-one to the instructions used by a machine will allow for significant improvements in performance over the EVM.⁹

Speed and Efficiency

One of the most important outcomes of the transition from the EVM to Ewasm will be a major increase in speed and efficiency. Ewasm will increase transaction throughput by significantly raising the number of transactions that can be processed and added to each block per second.⁵ It is still unclear exactly how much extra speed Ewasm will add to Ethereum but there will be a direct correlation between execution and transaction throughput: if Ewasm is able to execute twice as fast as the EVM, it will enable twice as many transactions to be added to each block.⁵ This does not mean that the actual block size will increase, simply that the process of adding data to each block will be far more efficient. Along with sharding and layer two solutions, Ewasm will thus help to increase the scalability of the Ethereum network.

Lane Rettig has likened the EVM to a swiss army knife: “…it does a bunch of things but not incredibly well.”¹¹ By contrast, Wasm has been designed with production readiness as a top priority, and is geared specifically towards web applications like Ethereum.¹¹ A good example of the increased efficiency of Ewasm over the EVM can be found in how each system compiles code. The EVM cannot always efficiently compile large amounts of code. A browser’s Javascript engine will often have to do a lot of guesswork to figure out the optimized “hot paths” for certain operations which can slow down the EVM and reduce throughput.¹⁰ By contrast, Wasm can transition directly from its common representation into compiled code without having to do any guess work. This is one of many features that allows Ewasm to load and run faster than the EVM.¹⁰ Another example has to do with the type of bytecode used by the EVM. Because the EVM uses 256-bit bytecode, computations smaller than 256 bits must be converted to a 256 format before the EVM can process them. Many developers believe that this function is now redundant and not having to convert smaller values will be another feature that makes Ewasm faster than the EVM.¹¹ Rettig metaphorically summarized the extent to which Ewasm will be faster and more efficient than the EVM in an interview with Coinwire: “Ethereum is at the point where it’s transitioning from a clunky homebrew custom build job that we’ve been riding around our farm to a real racecar that we can take out on the highway and open up…”⁹ An article published by Mozilla agrees that frameworks such as Ethereum will be able to use Wasm to “…confer massive performance advantages and new features while still making functionality easily available to web developers.”⁷

Precompiles

Another major benefit of Ewasm is its potential to reduce or even eliminate the need for precompiles. Precompiles (precompiled contracts), are special bits of EVM bytecode. If a call is issued on a precompiled contract, the EVM will execute a pre-defined native code and return the results.¹² The precompiles are specific to a certain protocol for common operations such as signature schemes and hashes, and help users to save on gas costs which would be much higher without them.¹³ Unlike regular code, the EVM will have to evaluate only the precompile, rather than the entire code at the contract address.¹² Precompiles are needed because various complex cryptographic computations on the Ethereum network would incur a gratuitously high gas cost without them. In some cases, this gas cost can even exceed the block limit, meaning that certain operation are impossible to process through the EVM without using precompiles. A serious downside of precompiles is that introducing new ones into the network usually requires a consensus wide hard fork.¹² Hard forks are often contentious and usually hard to implement so this is a major drawback.¹¹ Nick Johnson believes that Ewasm is efficient enough at computation that the majority of current precompiles could be eliminated and replaced with Ewasm contracts. These smart contracts can be simply rewritten and redeployed without necessitating a hard fork, which gives Ewasm an advantage over the EVM.⁹ This means developers can leverage the increased efficiency of Ewasm to simplify the network, ease the development process and avoid hard forks when new code in added.⁹ Like any new system, Ewasm is not without its critics. Ethereum developer Greg Colvin is skeptical of the ability of Ewasm smart contracts to eliminate precompiles.⁹ He also warns that Ewasm’s reliance on compilers to enable the support of multiple languages could become a single point of failure.⁹ However, the overwhelming majority of experts that I have researched and developers that I have spoken to do not see these as major concerns, and are excited for the significance performance improvements that Ewasm will bring to the Ethereum network.

Interoperability

A third area in which Ewasm exceeds the performance capabilities of the EVM is interoperability. Ewasm will support more languages and will benefit from a more extensive set of tools than the EVM.⁹ Some prominent examples of additional languages supported by Ewasm include, C, C++ and Rust.⁷ Ewasm will also enjoy native support from many prominent JavaScript engines, including but not limited to: Microsoft’s Chakra engine (Microsoft Edge), Google’s V8 engine (Node.js and Chromium-based browsers), and Mozilla’s Spidermonkey engine (Firefox and Thunderbird).”⁶ Ewasm will also be supported by several non-browser implementations such as ml-proto (the OCaml reference interpreter), wasm-jit-prototype (a standalone VM using an LLVM backend) or wabt (a stack-based interpreter).⁶ Although Wasm has its own native language that is separate from JavaScript, it is not intended as a replacement. Rather, it is intended to work alongside JavaScript, which allows developers to take advantage of the strength of both languages, and to avoid their weaknesses.⁷

In addition to being compatible with more languages and engines, the fact that Ewasm was built according to the World Wide Web standard means it will be easy to have in-browser support for an Ethereum light client.¹¹ Ewasm will also benefit from a wider array of tooling and compilers than the EVM does. Since Wasm is already used by a high number of projects outside of Ethereum, it has a much larger and more active developer community than the EVM which has led to better tooling options. As a result, Wasm includes various toolchains that can emit opcodes from several different compilers. They can compile C code and Rust code among others. Contributors from the ethdev subreddit posit that one of the major goals in converting to Ewasm was to piggyback “…on existing tooling, rather than trying to convince people to build tooling that targets the EVM.”¹⁰ Therefore, tooling is another way in which Ethereum will benefit from a transition to the more well established and widely used Wasm.

To summarize, Ethereum’s anticipated transition from the EVM to Ewasm is expected to bring an array of exciting new performance upgrades and other advantages. These include increased speed and efficiency, superior interoperability and the reduction or elimination of precompiles.

Thanks for reading! If you enjoyed this article and want to find out more about Eth2, check out my other articles in this series:

Eth2.0: Introduction

Eth2.0: Scaling Part 1

Eth2.0: Scaling Part 2

Eth2.0: Casper and the Beacon Chain

Special thanks to Lane Rettig for fact checking this article and making several excellent suggestions!

1. “Solidity Bytecode and Opcode Basics.” https://medium.com/@blockchain101/solidity-bytecode-and-opcode-basics-672e9b1a88c2
2. “Stack based vs Register based Virtual Machine Architecture, and the Dalvik VM.” https://markfaction.wordpress.com/2012/07/15/stack-based-vs-register-based-virtual-machine-architecture-and-the-dalvik-vm
3. “Ethereum Virtual Machine Explained.” https://www.mycryptopedia.com/ethereum-virtual-machine-explained/
4. “Ethereum EVM Illustrated: exploring some mental models and implementations.” https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf
5. “Ethereum 2.0.” https://medium.com/rocket-pool/ethereum-2-0-76d0c8a76605
6. “ewasm Design Overview and Specification.” https://github.com/ewasm/design.
7. “Web Assembly Concepts.” https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
8. Lane Rettig, core contributor to Eth 2.0.
9. “eWASM Replaces the Heart of Ethereum.” https://www.coinwire.com/ewasm-replaces-the-heart-of-ethereum
10. “Trying to understand the EVM and eWASM.” https://www.reddit.com/r/ethdev/comments/87rrt6/trying_to_understand_the_evm_and_ewasm/
11. “Ethereum Virtual Machine (EVM) To Be Replaced By EWASM Making The Ethereum Network Smarter And Stronger.” https://xbt.net/blog/ethereum-blog/ethereum-virtual-machine-evm-to-be-replaced-by-ewasm-making-the-ethereum-network-smarter-and-stronger/
12. “On Adding Precompiled Contracts without Hard Forks.” https://that.world/~classic/2017/09/14/nonfork-precompiled/
13. “A Prehistory of the Ethereum Protocol.” https://vitalik.ca/general/2017/09/14/prehistory.html

Works Cited

Asolo, Bisade. “Ethereum Virtual Machine Explained.” My Cryptopedia. November 1, 2018. https://www.mycryptopedia.com/ethereum-virtual-machine-explained/

Buterin, Vitalik. “A Prehistory of the Ethereum Protocol.” Vitalik Buterin’s Website. September 14, 2017. https://vitalik.ca/general/2017/09/14/prehistory.html

Coinwire. “eWASM Replaces the Heart of Ethereum.” September 19, 2018. https://www.coinwire.com/ewasm-replaces-the-heart-of-ethereum

Github. “ewasm Design Overview and Specification.” Ewasm Design Repository. Accessed Feb 21, 2019. https://github.com/ewasm/design.

Katalyse.io “Blockchain Basics — What is EVM. ” Medium. Jul 12, 2018. https://medium.com/the-mission/blockchain-basics-what-is-evm-d0ebebaded47

Langley, Darren. “Ethereum 2.0.” Medium. Aug 7, 2018. https://medium.com/rocket-pool/ethereum-2-0-76d0c8a76605

Mozilla. “Web Assembly Concepts.” MDND Web Docs. September 27, 2018. https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts

“On Adding Precompiled Contracts without Hard Forks.” 2019. https://that.world/~classic/2017/09/14/nonfork-precompiled/

Peh, Bernard. “Solidity Bytecode and Opcode Basics.” Medium. Sep 15, 2017. https://medium.com/@blockchain101/solidity-bytecode-and-opcode-basics-672e9b1a88c2

Reddit. “Trying to understand the EVM and eWASM.” R/ethdev. Accessed Feb 26, 2019. https://www.reddit.com/r/ethdev/comments/87rrt6/trying_to_understand_the_evm_and_ewasm/

Sinnathamby, Mark. “Stack based vs Register based Virtual Machine Architecture, and the Dalvik VM.” Engineering the Code. July 15, 2012. https://markfaction.wordpress.com/2012/07/15/stack-based-vs-register-based-virtual-machine-architecture-and-the-dalvik-vm/

Takenobu, T. “Ethereum EVM Illustrated: exploring some mental models and implementations.” March, 2018. Accessed Feb 18, 2019. https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

XBT Network. “Ethereum Virtual Machine (EVM) To Be Replaced By EWASM Making The Ethereum Network Smarter And Stronger.” XBT. Sep 21, 2018. https://xbt.net/blog/ethereum-blog/ethereum-virtual-machine-evm-to-be-replaced-by-ewasm-making-the-ethereum-network-smarter-and-stronger/