Welcome to the second post in the ROTA Chain introductory series!

Here is a quick recap of the salient points from our last post:

• ROTA is an emergent L1 (Layer-1) blockchain / Web3 game-changer.
• No dependency on other blockchains.
• Many big improvements in functionality, speed, privacy, security, and stability.
• The biggest one: successfully combining EVM (Ethereum Virtual Machines) and WASM (WebAssembly) on one blockchain.
• EVM is the longtime standard for smart contracts and dApp (decentralized applications) development and is based on Solidity (proprietary, not so much documentation / community).
• WASM supports almost every language, is easy to use for developers, works out of the box across browsers and devices, everybody already uses it, and is has a huge community and great documentation.
• Combining EVM + WASM on one chain = traditional Web2 developers can build Web3 stuff without changing their comfy current workflow.

Today we’ll take a deep dive into how we’ve combined EVM and WASM onto one chain, and take a high-level glance at some of the hurdles we had to jump to get here.

Functional overview of the benefits of ROTA’s EVM + WASM support.

Step 1: Evaluating VM Formats

Just as Baskin Robbins features many sub-varieties within the parent variety of chocolate ice cream, so too are there many different VM (Virtual Machine) options to choose from for each of EVM and WASM.

There were no benchmarks established for various EVM & WASM VMs in the research community, so we had to make our own, primarily revolving around the level of support for WASM and EVM on various blockchains. Some of the key considerations were:

1. Does the blockchain client support a code-level install of WASM (and if so, how many hoops do we have to jump through to make it happen)?
2. Is there a match or compatibility in code library requirements? If not, any reasonable workaround?
3. Does the blockchain client follow the same coding conventions as WASM, or a compatible coding convention?
4. Is there a match or compatibility in bytecode size? If there’s a mismatch, is there a way to manage the additional overhead generated?

Engines We Tested

1. ROTA is an official implementation of the Ethereum protocol. It is one of the most popular Ethereum implementations available either as a standalone client that installs on operating systems or as a library. We used the ROTA client to deploy and execute the WASM-based modules.
2. WASMD is a Cosmos SDK-based blockchain application that supports CosmWasm contracts. The base of the code is forked from Cosmos Hub’s Gaia with the addition of one module, x/wasm, which adds smart contract support. Specifically, we tried WASMD v0.39.

Summary of the WASM engines we selected for dual-engine viability testing.

How We Tested

We added the EVM and WASM modules to ROTA and WASMD and executed on a local machine.

To ensure the robustness of experiment results, we ran repeated experiments, in every iteration we manually tried to transform the entry point, export functions and library functions of the WASM & EVM modules we were adding.

EVM Bytecode Compatibility

High-level summary of EVM bytecode.

The native data type of EVM is a 256-bit integer, and supports as low as 8-bit integer calculations. However, computations smaller than 256-bit must be converted to a 256-bit format before the EVM can process them. Although there are ways to optimize EVM execution via just-in-time compilation, the existing implementations of EVM are rather primitive.

WASM Support for EVM Blockchain Clients

Cosmos & Tendermint are the two common layers among the two VMs, yet the versions of the same are inconsistent with each other. The deployment and execution process of WASM modules still encounters several unexplained exceptions.

Compatibility of Coding Conventions

The WASM modules to be deployed and executed in an EVM-based blockchain must follow a specific format. We are currently not able to run the project when including the WASM-based module:

Trying to run CosmWasm in parallel on Go = no-go :(

EVM-WASM Support: Library

A specific library needs to be included when developing ROTA modules for the WASMD blockchain client. These libraries provide APIs for chain-dependent smart contract functionalities, provide templates for data types, and delegate memory allocation.

EVM-WASM Support: 64-bit vs. 256-bit

The ROTA and WASMD modules have different data types. The native data type of EVM is a 256-bit integer with support down to 8-bit integer calculations. Thus, switching the data type introduces an error during the execution of the module on the WASMD engine:

Inconsistencies in structure, libraries, and byte size = no-go on WASMD :(

Our findings reveal that support for the WASM module on Ethereum-based blockchain clients is far from ideal. Attempts with both the ROTA and WASMD modules generated runtime errors. We analyzed the errors and found that there is an incompatibility in the block structures of the VMs, which are generating the roadblock during runtime. Second, many libraries are inconsistent among the blockchain modules, which makes them cumbersome and error-prone. Moreover, different bits (64-bit and 265-bit) have caused execution problems on the WASM engine, as the native data type of WASM bytecode is 64-bit.

We are now proceeding with two different ways to accommodate both EVM and WASM VMs in the ROTA blockchain:

1. Build generic core components like blocks, transactions, contracts, RPC queries, etc. from scratch that will be compatible with EVM & WASM VM modules.
2. Develop EVM & WASM VM blockchains in parallel and then connect them via the consensus service layer.

Token Bridge Support

The below block structures are incompatible with each other. We concluded that we need to build a generic block structure from scratch which can accommodate both EVM & WASM VM-based blockchains. This will address the EVM- and WASM-based token bridge barriers.

High-level Block Structure of EVM vs. WASM

We have studied the block structure of EVM- and WASM-based blockchains. As per our experimentation with the different module integrations in the blockchain clients, we observed that there are dependency conflicts that could be addressed by building the blockchain core components like blocks, transactions, contracts, RPC queries, etc. from scratch. The new generic core structures in the blockchain will accommodate both EVM- and WASM-based modules.

Thank you for taking the time to learn about ROTA Chain’s game-changing combination of EVM and WASM onto one chain! To get more involved, we strongly recommend joining the chatter in our community channels:

Telegram Announcement Channel: https://t.me/rota_ann_official
Telegram Discussion Group: https://t.me/rota_official
Discord: https://discord.gg/rotachain
Twitter: https://twitter.com/rotachain