For Ethereum to fulfill its mission by becoming the World Computer on which distributed applications coordinating vast numbers of humans and autonomous machines run, it needs a lot more platform stability and security than it currently has.

One source of platform instability is the continued evolution of EVM, the Ethereum Virtual Machine that has required a few technical hard forks in the past and may require some in the future. The next one is already in the works. This makes Ethereum appear as if its creators had not anticipated future requirements, and it is in constant need of costly and risky hard forks, requiring difficult coordination outside of the framework provided by the blockchain.

To understand why this is a problem and why this problem exists, we need to delve a bit deeper into the fundamentals. Ethereum’s value proposition and main distinguishing feature is its Turing-completeness, which – in theory – means that it can perform arbitrary computations, including the emulation of other Turing-complete machinery.

The Halting Problem, a classical computer science result implying that one computer program cannot, in general, assess the resource requirements of another computer program without requiring just as many resources (time and storage) itself, has been worked around by metering: in Ethereum, storage and processor time are prepaid to avoid unbounded resource consumption.

However, this puts a hard limit on the complexity of smart contracts in general and the depth of emulation in particular. With the current EVM architecture, this limit is so severe that complex cryptographic calculations, which are very important for securing the financial applications that are expected to run on Ethereum, cannot be implemented using the primitives provided by EVM within the complexity limits imposed by the blockchain.

The current workaround for this problem is the use of the so-called precompiled: virtual contracts executing well-defined operations at a fraction of the cost of actually implementing them with EVM primitives. Some, including myself, believe this approach is unsustainable for a number of reasons: each extension of EVM with new precompileds requires a hard fork, expands the trusted code base that each implementation of Ethereum needs to maintain, and increases the attack surface that needs to be covered in a reliably bulletproof fashion. Furthermore, there is little hope that we will ever run out of new cryptographic primitives to be implemented as precompileds.

Fortunately, Ethereum is not alone. Another, much bigger distributed computing system is grappling with related, albeit somewhat different problems: the World Wide Web needs a secure and future-proof architecture for web-based applications to harness the immense and continually increasing computing power available on the client side.

W3C, the governing body of WWW standards has already achieved considerable success in bringing together major players behind WebAssembly or WASM, a high-performance, secure virtual machine on which web applications can run computationally heavy tasks. Its detailed and highly formalized specification together with already existing support in major web browsers makes it a very attractive “thin waist” abstraction layer hiding the OS and the underlying hardware from distributed applications, while providing them with a very secure sandbox.

In particular, cryptography implemented in WASM could run at almost native speed. Also, the current EVM can be very efficiently implemented in WASM. Finally, if the WASM implementation becomes the common trusted code base of the Web and Ethereum, the developers of Ethereum implementations will be relieved of the major burden of maintaining it, although of course they can still help.

How do we get from here to there? First, we need Ethereum WASM (eWASM), a special dialect of WASM used for smart contracts. It has only two differences from general WASM: all floating-point arithmetics are excluded (the reasons for this are beyond the scope of this article) and it has metering.

Now, it is very straightforward to trans-compile eWASM so that it runs on an already existing WASM implementation: first, it should be checked for the absence of floating-point operations, and then metering needs to be injected.

Note that the latter can be done at the branch level and is an entirely reversible operation. Next, we need to implement the current EVM in eWASM, so that the existing contract base remains usable. If eWASM metering is done in units that are small fractions of Ethereum’s “gas,” reflecting the fact that eWASM has much higher performance than EVM, then it becomes possible for the emulated EVM to have the same gas costs for its operations as it currently has, including those for the precompileds.

Thus, introducing eWASM could be the last in the series of painful technical hard forks required by EVM’s evolution. Unlike the ones before it, it would dramatically reduce the code base that needs to be maintained in lockstep by every Ethereum implementation. Tracking future developments in cryptography would be a matter of deploying eWASM contracts implementing the new primitives on the blockchain, without forking. Fortunately, it is already common practice to represent cryptographic objects as Lisp-like S-expressions, which also happens to be the native format of WASM.

Programming directly in eWASM is very labor-intensive. While there are many projects for compiling high-level programming languages to WASM, currently only the one supporting the C language is sufficiently mature. Writing smart contracts and, generally, security-critical code in C is a bad idea for reasons outside of the scope of our discussion, so in order to speed up the transition outlined above, Ethereum might need a Lisp-like high-level language of its own that is easy to compile to eWASM not only programmatically but also mentally, so that software authors can have a reasonably accurate picture of what their code is going to become after compilation.

In the future, this language can supplant Solidity for the purpose of writing smart contracts, while the latter of course can also be compiled directly to eWASM. Eventually, even the compiler of this new language can be written in itself, making Ethereum a truly self-contained universe, on its way to become the ultimate world computer.

Acknowledgement: I would like to thank Alex Beregszászi and Martin Becze for the enormous work they have done for eWASM to become reality.