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:
- POP 20
- POP 7
- ADD 20, 7, result
- PUSH result
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.
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.
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. I hope you enjoyed this article as well as the previous articles in this series: Article One, Article two, Part One and Part Two, and Article 3. This will be the last article in this series but stay tuned for more on Ethereum and other exciting new blockchain projects.
Special thanks to Lane Rettig for fact checking this article and making several excellent suggestions!
- “Solidity Bytecode and Opcode Basics.” https://medium.com/@blockchain101/solidity-bytecode-and-opcode-basics-672e9b1a88c2
- “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
- “Ethereum Virtual Machine Explained.” https://www.mycryptopedia.com/ethereum-virtual-machine-explained/
- “Ethereum EVM Illustrated: exploring some mental models and implementations.” https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf
- “Ethereum 2.0.” https://medium.com/rocket-pool/ethereum-2-0-76d0c8a76605
- “ewasm Design Overview and Specification.” https://github.com/ewasm/design.
- “Web Assembly Concepts.” https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
- Lane Rettig, core contributor to Eth 2.0.
- “eWASM Replaces the Heart of Ethereum.” https://www.coinwire.com/ewasm-replaces-the-heart-of-ethereum
- “Trying to understand the EVM and eWASM.” https://www.reddit.com/r/ethdev/comments/87rrt6/trying_to_understand_the_evm_and_ewasm/
- “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/
- “On Adding Precompiled Contracts without Hard Forks.” https://that.world/~classic/2017/09/14/nonfork-precompiled/
- “A Prehistory of the Ethereum Protocol.” https://vitalik.ca/general/2017/09/14/prehistory.html
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/