The Decentralized Virtual Machine

Virtual Machines (VM) have been around for quite some time. In simple terms, they are mechanisms for creating isolated instances of software that emulate real machines.

If that sounds complicated, don't worry. You can think of VM's like a conductor orchestrating a symphony: the symphony is the machine hardware, and the conductor is the VM, telling your computer what to do.

The benefits of a VM are many, but we will focus on only two:

1. They allow you to write code in a way that is easily understandable to humans, through a process called compiling. Compiling is where an intermediary language gets automatically compiled (or transformed) into the corresponding machine language of the VM. In essence, without VMs, programmers would have to write low-level machine code that consists of telling CPUs exactly which actions to perform (if you're gagging, don't worry — so are we).
2. VMs also create consistent environments across different machines and hardware. For example, Windows is a VM. This VM allows computers of all shapes and sizes (with different graphic cards, memory, and hard disk space) to maintain a state of normalcy and predictability.

Decentralized VMs

The idea of a decentralized VM (which we will call a DVM for this post) could be more easily thought of as a decentralized operating system. Every node on the network of a blockchain has to have some consistency and awareness of the rest of the network, or the network would be very difficult to maintain and scale.

If you're unsure of what nodes on a network are, read our Blockchain Deep Dive.

Photo by JJ Ying / Unsplash

Furthermore, if a decentralized network wants to perform any sort of computation, then a DVM is required to access those capabilities on the network.

An important aspect of a DVM vs. a VM, though, is that there isn't a single physical machine that one can pinpoint like you do with traditional VMs. Instead, you can visualize a DVM as the entire network itself, where computations are performed within containers called Smart Contracts.

Within these Smart Contracts, a programmer now has access to machine code (through compilation as we stated above), and almost any computation can now be performed.

Why did I say almost? It would be helpful here to divert briefly to explain a phrase you may have heard: turing-complete.

Turing-Complete

This phrase gets tossed around a lot, but many newcomers to the blockchain space do not know what it means.

Thankfully, the definition is really simple: turing-completness is the capability of a machine to perform any given task with code.

In essence, if a machine is turing-complete, then it can do whatever you program it to do. This is important, because some VMs are not turing-complete, and limit the ability for programmers to make their visions of the future come to light.

DVM Examples

There are many DVMs, but we'll focus on only three to give you a few examples: the EVM, IELE, and the KEVM.

Ethereum Virtual Machine (EVM)

The Ethereum Virtual Machine (EVM) was the first VM to be deployed onto a blockchain network. This is why many refer to Ethereum as the computing blockchain; it was the first to allow programmers to run computations on the blockchain.

This, at the time, was opposed to Bitcoin, which can only store transaction data (essentially read/write). The approach was a milestone in the blockchain space, and it has really good capabilities to boot:

1. It is turing-complete (140 opcodes, or machine commands, are available to the VM).
2. It has an intermediary language compiler that converts Solidity to the opcodes.

The problem, however, is that while the EVM is turing-complete by definition, it is not so by execution. What we mean by that is (you guessed it): gas fees.

Photo by Timon Studler / Unsplash

The EVM introduced a novel approach to keeping the decentralized network self-sustaining called gas. Every time a Smart Contract wants to execute some machine code, it needs to have a balance of gas provided by the issuer.

If the provided amount of gas runs out before the SC is finished, the whole thing fails and the SC resets until more gas is added. This prevents badly-coded contracts from bogging down the DVM with potentially costly functions, such as infinite recursions (where a function runs itself infinitely until the system crashes).

It also provides an economic engine to keep the network running and incentivizes node operators to keep mining in return for payments from these gas fees.

The problem, as many have experienced, is that while the EVM may be turing-complete by definition, it is limited by the available gas provided to the smart contract. In essence, it can only do as much as it is allowed to do, thus prevent true turing-completness.

IELE

IELE is the native DVM developed by Cardano, and approached building of the DVM from a completely different approach to that of the EVM.

Most virtual machines are coded by humans; that is, some programmers specialize in low-level machine code, and write these VMs by hand.

IELE is not created by hand. Instead, it is built on top of the K Framework, a semantic framework that allows you to build a specification of a language. The value prop of K is that it follows a correct-by-construction process, essentially guaranteeing that the language you are building works, just by following the process.

Photo by Jamie Morrison / Unsplash

At this point, your eyes might be melting inside your head, so here's a way to think about it. Take these two scenarios:

1. You want to build a boat, so you start building it and come up with the plans as you go. Sure, you may have some ideas on how you're going to construct it, but it's mostly a labor of love and passion, mixed with some expert knowledge on boat-building.
2. You want to build a boat, so you draw it out on paper. You meticulously measure every dimension, defining the features before ever touching the wood. At long last, your masterpiece is finished. You turn around, put the paper in your scanner, and your 3D printer spits out a real-life, 100% accurate replica of your specification.

That's what the K framework does, and you're probably thinking option #2 is going to be more reliable. We think so too, and that's what IELE is. It's a decentralized virtual machine that was meticulously specified with formal verification, and then the code was generated automatically.

The code language for the VM was Haskell, a low-level, functional programming language used by mission-critical platforms, including NASA, Tesla, and more.

This allows for easier compilation from higher-level languages (essentially any that you can think of), since it's easier to compile a loose language to a strict language. It also removes a lot of the issues with the poorly coded smart contracts we see on the EVM today.

KEVM

Lastly, we wanted to highlight the KEVM. This is another DVM built by Cardano that offers compatibility with EVM, and stands for K Ethereum Virtual Machine.

Photo by raffaele brivio / Unsplash

The idea is to offer interoperability for Solidity developers who have coded their smart contracts on the Ethereum network, and allow a plug-n-play bridge to execute their smart contracts on the Cardano network.

KEVM does everything EVM can do, but also adds the ability for type checkers, equivalence checkers, and debuggers, which are difficult to do within the Ethereum Virtual Machine. And since it is verified in the K Framework, it can formally verify the input — thus producing more secure Solidity code compilation.

A Stronger Future

All decentralized virtual machines have to accomplish several things, but to name a few:

1. Turing-completeness
2. Efficiency
3. Security
4. Sustainability

With these, we won't see decentralized applications the same way we see them on our personal computers. But with them, we could very well see a revolution in the way applications are built and interacted with.

Whether it happens through EVM, KEVM, IELE, or something else entirely — it's safe to say that we're only at the beginning stages of the decentralized computing revolution.