VeRT: VM-emulation RunTime for WebAssembly-based Smart Contracts
Since Ethereum, modern blockchains that support smart contracts include virtual machine to perform deterministic computation for the state change. Unlike Ethereum which developed its virtual machine, a.k.a. EVM, other blockchains like EOSIO, Cosmos (zones), or Polkadot (parachains) adopted the standard technology, WebAssembly (WASM). WebAssembly was developed to run code at native-like speed in a Web environment, but can be utilized to run smart contracts too.
The significant benefit of using WebAssembly as a smart contract runtime is compatibility. Modern browsers and JavaScript runtimes such as node.js or deno support built-in WebAssembly, and LLVM is leveraged to generate and optimize its bytecode.
Even though each blockchain uses a different WebAssembly runtime implementations — EOSIO (eos-vm), Cosmos (wasmer), Polkadot (wasmi) — in its project, but still we can run their smart contracts on the same WebAssembly runtime if we provide a proper set of host functions (imports).
VeRT is developed to run smart contracts on browsers (Firefox, Chrome, etc.) or JavaScript runtimes. It would be suitable for tests rather than imitating real blockchain behavior because it doesn’t implement the full specification of the blockchain. However, you can write all remaining parts and make it work as a full-node implementation written in JavaScript.
Currently, VeRT supports EOSIO only (Refer to examples, here and here), but Cosmos and Polkadot (truly, CosmWasm and Substrate) will be supported in the near future.
To write tests with VeRT, you need to meet the following requirements.
- WebAssembly binary with the exported memory
A WebAssembly binary generated by eosio.cdt doesn’t export the memory. To access the memory from the outside of the WebAssembly instance, it should be exported. You can get the binary with the exported memory by building the contract with Blanc v.0.9.2 or higher.
- JavaScript runtime with WebAssembly BigInt support
In Javascript, whether a number has the fractional part or not, it is a floating number internally, so can represent only the integer with 53-bit or smaller width. However, WebAssembly has i64 (64-bit integer) type, so it is not interoperable with JavaScript number type. node.js v16 or higher supports JavaScript BigInt for WebAssembly i64, but if you want to use VeRT with node.js v14, you need --experimental-wasm-bigint option when running node command.
Caveat
You can write unit tests in most cases for your user-level contracts, but there are features not implemented yet:
- inline / deferred action
- long double (quadruple-precision floating point number)
- chain / permission / privileged / transaction APIs
- newly-added APIs by protocol features
VeRT is under active development and this is the alpha version release, so there can be unknown issues or breaking changes. Reporting a bug or making a contribution is always welcome.
