Why is Decred not EVM compatible?

EVM (or Ethereum Virtual Machine) is a virtual computer that creates an environment that allows developers to write, deploy, and execute smart contracts (and DApps) in the Solidity programming language.

There are over 650 blockchains that are EVM compatible, but Decred isn’t one of them. Why? In this article, we’ll find the answer to this question while gaining a deeper understanding about the Ethereum Virtual Machine.

Let’s begin with the basics,

What is the Ethereum Virtual Machine?

What is the Ethereum Virtual Machine

EVM (or Ethereum Virtual Machine) is a virtual computer that creates an environment that allows developers to write, deploy, and execute smart contracts (and DApps) in the Solidity programming language. The EVM also takes the responsibility of maintaining the state of the Ethereum network, storing data and processing transactions.

Key Features of the Ethereum Virtual Machine

Turing- complete machine: Alan Turing proposed the Turing-machine (also known as the automated machine) in 1936 as a device that could use binary code (0s and 1s) to solve any computational problem . A system or (programming language) is considered Turing-complete if it can perform or resolve any computational problem using code. EVM serves as the Turing-complete machine of the Ethereum network by enabling the execution of a wide range of algorithms and programmes.

Distributed State Machine: EVM is considered a distributed state machine  because it maintains the decentralized state of the Ethereum blockchain. The EVM is responsible for executing smart contracts and updating the state of the network based on the outcome of those executions e.g wallet balances when a transaction is carried out.

Isolation: The Ethereum Virtual Machine is completely isolated from the network; this allows the smart contracts in the EVM to run in an environment that is separate from the main network. In the event of a smart contract hack, it wouldn’t affect the rest of the underlying protocol.

Gas Incentives: Gas is a unit of measurement for the computational cost required to execute a particular operation. Usually, it is determined by the complexity of  the operation, e.g deploying a smart contract would cost a higher gas fee than sending a coin to another wallet. The gas fees are paid in $ETH or in the chain's native token (if it's an EVM-chain).

What does it mean for a blockchain to be EVM compatible?

EVM compatibility allows a blockchain to run the EVM and execute Ethereum smart contracts on its network. For developers, it means that they can easily build and deploy Solidity smart contracts and DApps across multiple EVM-compatible chains, without making any significant change to the code.

Why EVM?

Before now, Bitcoin was the only significant network that allowed us to send and receive digital assets without needing a bank. Then came Ethereum, which gave us something different: smart contracts. The introduction of smart contracts led to developers building interesting products on the Ethereum blockchain, thus attracting liquidity from users. Soon, Ethereum became the hub of liquidity, and the easiest way for other blockchains to tap into that was to become an EVM-compatible network (if you can’t beat them, join them).

Aside from syphoning liquidity, most developers find it simpler to support EVM-compatible chains because they can build their so-called "multi-chain" DApps (which are DApps that can be easily migrated to other EVM-compatible chains at the touch of a button, making it easier for the DApps' token to be deployed across multiple EVM chains) by simply copying and pasting their smart contract code.

Is EVM omnipotent?

Problems of the EVM

When you consider the number of blockchains that are EVM-compatible, it is easy to conclude that the EVM is the best option for running a network. On the contrary, the EVM has its own problems, which unfortunately, some developers choose to ignore.

1. Re-entrancy Attacks: This is a type of attack that occurs when there’s a vulnerability in a smart contract that allows an attacker to repeatedly call a function in the contract before the previous call is completely executed. In such an event, the attacker can send funds to his wallet or manipulate the contract’s state. A notable example of a re-entrancy attack occurred in 2016, when a attacker exploited The DAO’s smart contract. The attacker was able to repeatedly call a function in the contract that transferred funds from the smart contract, leading to a loss of over $60 million.

2. Limited Functionality: Considering its "CTRL C+V" model, the EVM smart contract has limited native functionality, forcing developers to build more complex smart contracts. The risk behind building complex contracts is that bugs can’t be easily detected, and with liquidity at stake, attackers can easily rob users of their funds. Additionally, the more complex a contract is, the less efficient it becomes. In 2017, Parity wallet, a smart contract-based crypto wallet, was hacked, resulting in the loss of over $30 million worth of ether. While the Parity wallet smart contract was considered secure based on its sophisticated nature, its complexity led attackers to take advantage of undetected bugs.

3. Outdated: Since inception, the EVM hasn’t seen any significant change in its functionality, which is why it is very limited. When developers resort to building a more complex contract, it introduces security threats.

Despite these cons of the EVM, some developers consider the payoff (liquidity and new users) to be worth the risk.

Does Decred support smart contracts?

Short answer is yes! Unlike EVM-compatible chains, Decred adopts a simple, stack-based programming language called txscript. Txscript is a Turing-incomplete language, which means it lacks some functionalities like loops and other complex structures. This makes Decred's codes less complex and resistant to the halting problem. To grasp the idea better, you can relate it to Bitcoin-like smart contracts that are simpler but powerful.

Is it possible for Decred to become EVM-compatible?

To be clear, it is possible for Decred to become an EVM-compatible chain (and support Ethereum-like smart contracts) without needing to make any rigorous modifications to its consensus rule, using a model like RGB. So, why is Decred not one?

Aside the security risks that comes with being EVM-compatible, running a full ETH node can be resource-intensive (which is the reason some EVM-compatible chains resolve to using centralised services to run nodes). While the liquidity Decred stands to gain from this might be a good lure, adopting an error-prone VM would be considered a naive approach to providing global state storage.

When asked, this is what a community developer had to say:
“Reasons to not support EVM is because great power comes with great responsibility. Turing-complete smart contracts give more ways to programmers to shoot themselves in the feet. And when money is on the table, users and investors also get shot in the feet, hence so many smart contracts hacks and millions (billions?) USD in losses you may have heard about”.