Under the hood: Blockchain Virtual Machines for Decentralized Applications

Currently, there are more than 2000 dApps running on Etherem’s main blockchain. It’s inevitable to say that supporting dApps is one of the key functionalities when one designs a new blockchain platform. If anyone has tried developing a smart contract on the Ethereum blockchain, or have been in the space for a while, one may be familiar with the term “EVM”, short for Ethereum Virtual Machine. Virtual machines essentially create a level of abstraction between the executing code and the executing machine. It provides the “sandbox” to let the executing code safely run inside the virtual machine, preventing contaminating the main blockchain if anything goes wrong. This layer is needed to make sure applications are separated from each other, and separated from their host.

SperaX, as one of the most innovative and prospective blockchain projects today, supports two categories of the virtual machine in layer-2. The first one is EVM(Ethereum Virtual Machine) which supports running dApps, and the latter one is called SVM(SperaX Virtual Machine) which handles not-Turing complete financial programs and focuses on the security side.

EVM

The Ethereum Virtual Machine (EVM) is a powerful, sandboxed virtual stack embedded within each full Ethereum node, responsible for executing contract bytecode. Contracts are typically written in higher-level languages, like Solidity, then compiled to EVM bytecode.

Under the hood, regardless of what language was used in the higher level, contracts are breaking into parts called opcodes. And those opcodes are loaded from the EVM and stack and get executed.

While EVM is one of the most successful and popular blockchain virtual machines, there are still several design flaws and things could be improved.

First, People often believed that EVM is Turing-complete, but this is actually not true. Turing-completeness is defined as the following: If a machine can solve any computable problems, it’s turning-complete. However, since the calculation of instructions on EVM is restrained by gas, the times of calculation is also limited. Thus, EVM is not Turing-complete.

EVM also lacks the standard library support. Even the most fundamental type — string, is not supported in EVM. Hence, it’s very hard to perform basic operations such as string splicing, cutting, and searching. All those features need to be implemented by the developers, which left security vulnerabilities. Also, the self-implemented libraries may be too high in time and space complexity, resulting in unnecessary consumption of gas.

Debugging EVM is also a painful task. Unlike most of the programming languages, EVM does not throw out-of-gas errors and print logs. As a developer, it’s hard to step in EVM line by line and set up breakpoints. Thus, the design of the EVM made debugging extremely hard and inefficient.

Another design flaw is the incapability of upgrading the smart contract. It’s common to have bugs and exploitable features in the early version of apps. However, since EVM does not support any form of upgrading or patching, it makes fixing known bugs extremely hard, costly, and laborious.

Although EVM might have various design drawbacks and flaws, it’s important to realize that EVM is one of the earliest blockchain virtual machines that support smart contracts and it is EVM, made Ethereum known as the decentralized computation platform.

Later blockchain virtual machines adopted better designs and are more reliable. For example, in the design of Sperax’s virtual machine, data are separated so that financial transactions could be better protected and less vulnerable from attacks.