This is the second article about exploring a custom WebAssembly runtime environment for Tezos. The first article was about comparing Michelson and WebAssembly. As we are not the first to explore running smart contracts on WebAssembly, it makes sense to look at prior art.
Ethereum has been exploring WebAssembly for over 4 years (https://www.youtube.com/watch?v=YW6hszjjMqo). Initially they started with using existing runtimes and the desire to stay as close to the existing Ethereum VM as possible, which caused several problems for them:
- Browsers only support synchronous imports, which conflicts with their existing asynchronous approach. As a result they dropped support for browsers.
- JIT bombs which caused a combination of instructions to take a considerable time.
Overall these problems are related to not owning the wasm runtime. Which they eventually did.
Other blockchains have also started using wasm runtimes.
The Elrond Network and Spacemesh are using wasmer (https://wasmer.io), an existing WebAssembly runtime which includes several WebAssembly engines and has support for measuring the cost of instructions. The Elrond Network has also implemented the Ethereum VM functions. Although this strategy is efficient, I see problems regarding control and incompatibility with Tezos amendment process.
See:
https://github.com/ElrondNetwork/arwen-wasm-vm
https://github.com/spacemeshos/svm
EOS used several existing WebAssembly engines which caused security issues and unpredictable performance: https://github.com/EOSIO/eos-vm#motivation. Eventually they created their own wasm vm as well: https://github.com/EOSIO/eos-vm/tree/master/include/eosio/vm. What’s interesting here is that they made the floats deterministic and have time bound execution.
Parity created a separate wasm runtime, wasmi (https://github.com/paritytech/wasmi), for their Polkadot blockchain. Their runtime focuses on correctness over performance.
Dfinity stores WebAssembly applications on their network and give the illusion that applications keep running. Basically trying to be a decentralized AWS. What’s interesting is that their use of WebAssembly includes a simple form of GC.
Beyond using WebAssembly, there are also those who argue for a limited form of WebAssembly or not even using WebAssembly at all. The creator of JS and co-creator of WASM, Brendan Eich, makes the argument against using wasm for smart contracts: “this means you did not need WebAssembly in full. But the extra degrees of freedom thereby unnecessarily bundled add cost in complexity, code size, security attack surface. The winning trick to design is leaving things out.” - https://twitter.com/BrendanEich/status/1009688828041281536
I have probably missed an implementation here or there. If I made any big omission, feel free to add.
Comments
Using an existing WebAssembly VM is problematic and should be avoided, as it doesn’t match with the demands of Tezos. Also, by using WebAssembly as-is you are bound to the same level of maximum security. I would argue that this isn’t sufficient for Tezos, and we need a custom solution for our specific use case - which we will discuss in the next article about exploring a custom WebAssembly runtime environment for Tezos.
