A look into Virtual Machines and Smart Contract Runtimes

Karel Kubat

Published in

WASM conference

5 min readJun 16, 2022

Written by Karel Kubat, CTO of Composable Finance

Post Material after WASM conference 2022

Virtual machines form the basis of execution environments for smart contracts. The EVM is the most dominant solution at the moment. Still, many models exist, some with only performance differences, others with changed semantics, such as an entirely different storage backend, account model, and calling convention.

Why should you care as a smart contract developer?

To write a smart contract, one does not really need to know the internal implementation of the VM, aside from the account model and some general APIs. However, as substrate developers, we need to have a clearer understanding of the pallets we build and the different tradeoffs with regard to security and performance. To be a senior developer, you do not need to be able to read assembly, but it sure helps out a lot.

Choosing an actual ecosystem to develop on should then be related to current token prices, which contracts are easiest to copy-paste over, and what best suits the products you are trying to build.

How does a chain actually run your contracts?

Smart contracts are essentially Javascript runtime included in your browser or the operating system loading a binary. Code is loaded in some format from the chain’s storage, loaded into the VM instance, and passed the bytes from the transaction. The contract deserializes it into the types that the smart contract developer specifies, and then we enter the method written by the actual developer.

Depending on the execution environment, the VM might allow the contract to directly access storage (using a cache for transactionality) or emit a UTXO for more exotic architectures. The same goes for reading storage of other contracts and directly calling them. Although the EVM did set a standard for these procedures, recently, a lot of cool work is being done on innovative runtimes deviating from the EVM’s model. On the surface, it seems to overcomplicate the smart contract logic, but the advantages are very significant overall.

There can be fairly obvious advantages, such as the ease of adding a precompile to Wasmer versus the full suite of changes needed to the EVM, opcode handling and logic with the EVM. In other cases, a UTXO based model better protects against re-entrancy, as the next contract call means that execution and in-memory state from the caller is wiped.

Alternative model and its advantage: CosmWasm

CosmWasm is very similar to ink! in many regards. Both are an eDSL (an embedded, domain-specific language -basically a fancy macro-), and libraries that do not depend on ink! or Cosmwasm host functions are fully compatible. In the end, all that their respective instances require are well-formed WASM programs with certain exports.

The differences become more apparent when we look at the calling of the contract. In CosmWasm, instead of calling a contract by methods and providing the arguments in some serialized format, the contract exports one top-level entrypoint. This entrypoint accepts a per contract defined Message type, which is usually some algebraic data type, and internally handles the message; an example of this contract can be seen here. This has consequences for actually interacting with other contracts as well. Instead of importing them into your smart contract and calling them by methods, as if they were instantiated classes, you exit the current smart contract execution with a vector of messages handled by further smart contracts. Transactionality is dependent on the order of messages, replies and if they are propagated to other chains. Each contract maintains a mailbox and logic to handle replies based on earlier dispatched messages.

This actual model is referred to as the actor model, the most well-known ones in the Rust ecosystem being Actix and Lunatic, and brings big advantages. First of all, CosmWasm contracts are safe from reentrancy attacks, as they have no in-memory state after sending messages. In non-pallet contexts, CosmWasm contract execution can also be (eagerly) parallelized, by constructing a growing DAG out of emitted messages and executing the contracts in parallel. This has the caveat of needing to revert some execution if contracts send messages to each other at the same height, but the initial block producer only incurs this cost. (more on that in a future article).

Finally, the actor model scales really nicely to cross-chain contract calls, as they are essentially the same as a regular contract call.

Tying it all together with XBI and IBC

XBI is current research being done on the XCM interface for cross-chain contract calls. It defines calls such as:

call_wasm: trigger smart contract callcaller: AccountIddest: MultiAddress<AccountId, ()>value: Balanceinput: Bytesadditional_params: Option<Vec<ABIType>>

which cleanly map to our CosmWasm actors. Each contract can emit a contract call message that cleanly maps back to XBI.

Obviously, CosmWasm was designed with IBC in mind, and thus we already have tooling and integrations with that in mind. However, it is not limited to the Cosmos. We at Composbale Finance are working at actually bringing the best of both worlds together, connecting Polkadot and the Cosmos.

The Composable XCVM is not only the next step in Wasm smart contract development — we believe it has the potential to become DeFi’s end game. CosmWasm developers utilizing the XCVM will not have to worry about what chains, dApps, or contracts they interact with. Instead, they can specify a function, and let the XCVM Routing Layer assure that the optimal route is taken at the time of execution. This new approach to smart contract development unlocks the true potential of native composability across several DeFi ecosystems. Composable’s vision is to facilitate the creation of interoperable, modular applications which are capable of functioning across entire ecosystems.

Check out Composable Finance’s socials: