EWASM (Ethereum Flavored WebAssembly) Explained
Last Updated: 12th March 2019
Ethereum 2.0, also known as Serenity, is a series of planned upgrades that is expected to take place on the Ethereum platform. These changes will be rolled out incrementally over the next few years, and once implemented, it is hoped that these upgrades will produce a more efficient and scalable Ethereum platform that is capable of handling thousands of transactions per second.
As the image above shows, the core upgrades expected to be implemented on Ethereum include:
- Phase 0: Beacon Chain
- Phase 1: Shard Chains
- Phase 2: Execution Engine
Phase 2 is expected to see the implementation of a new execution engine on the Ethereum platform, and there is rough consensus that that execution engine will be ewasm.
Virtual Machines
Blockchain nodes need to process the transactions that they receive. To this end, they run a virtual machine capable of executing the instructions encoded in these transactions. The Bitcoin virtual machine is relatively simple, but a virtual machine for a general-purpose blockchain, capable of supporting Turing-complete smart contracts, requires a more complex instruction set.
The Ethereum Virtual Machine (EVM) is specified in an appendix of the Ethereum yellow paper. The EVM constitutes a runtime for executing general-purpose smart contracts. A number of predefined opcodes can be used to implement a variety of functionalities. The EVM's opcodes are the equivalent of a processor core’s instruction set. Smart contracts, usually written in Solidity, are compiled into EVM code consisting of a sequence of these opcodes in the same way that high-level programming languages are compiled into hardware instructions. Each opcode is represented by a numerical code and is given a human-readable name in the specification. For instance, the opcode ADD (as is identified in code by the number 0x01) is interpreted by the EVM to calculate the sum of two 256-bit numbers on the EVM’s stack.
The current EVM has evolved from the early specification, with little change, and has found its limits in terms of performance and flexibility. The EVM’s initial opcode specification is not optimized for speed on different hardware platforms, nor is it aimed at portability, meaning that tool and language support for writing smart contracts is limited. Now, with Ethereum 2.0 approaching, a new EVM specification is being drawn up, which is based on WebAssembly.
WebAssembly (WASM)
WebAssembly is a highly optimized binary format for virtual machines. Defined by the World Wide Web Consortium (W3C) as an open standard, the binary instruction format is natively supported by a number of JavaScript engines and other runtime environments, making WebAssembly executable in most modern web browsers. Current adoption rate and tool support means that a variety of languages can compile directly into WebAssembly, including Go, Rust, and C/C++.
WebAssembly is a stack-based virtual machine specification, which provides several advantages, such as the ability to adapt easily to any low-level target architecture and high performance. The standard includes an instruction set, intermediate source format (akin to byte code) and an encoding format. The instruction set has been specifically designed to leverage features common to most contemporary hardware architectures. Therefore, WebAssembly can execute close to native speed on most platforms.
EWASM
The current proposal to re-specify and migrate the EVM to WebAssemly is motivated by the advantages mentioned above. Primarily, a wasm-based EVM can leverage improved hardware features and can build on a wide ecosystem of tooling and language support. With such an EVM, it should theoretically be possible to write smart contracts in any language that compiles into WebAssembly.
However, there are some caveats. Most importantly, blockchain virtual machines need to be deterministic in their execution, as the code needs to execute exactly the same way on each node. Otherwise, transaction verification and confirmation would not be possible. Therefore, any WebAssembly feature that may introduce a source of non-determinism must be excluded. Furthermore, the W3C WebAssembly specification is very wide, covering aspects simply not required by Ethereum.
To comply with Ethereum’s specific requirements, the proposal for a wasm-based EVM in Ethereum 2.0 introduces the concept of Ethereum flavored WebAssembly (ewasm). The ewasm specification consists of a subset of WebAssembly components suitable for Ethereum’s needs, namely determinism and relevant features. It also includes a number of system smart contracts that provide access to Ethereum platform features.
While new contracts can be written in high-level languages, the ewasm project targets backward compatibility by also supporting the current opcode instruction set and including transcompilation options in its specification.
Conclusion
The advantages of ewasm are clear: faster execution speed, improved hardware support, large existing tool support, language portability, and access to the large WebAssembly community and ecosystem. However, like most of the Ethereum 2.0 specification, the ewasm project is still a work in progress and may be subject to change.
