Solidity/EVM Compatibility for Radix?
Originally posted 6th January 2021 Radixdlt.com/blog’
As you know if you’ve read our DeFi Whitepaper, Radix is taking a unique approach to smart contracts, with Components and Scrypto. These developer tools offer the same kind of power and flexibility that Ethereum does to create DeFi and other dApps, but work very differently from Solidity and the Ethereum Virtual Machine (EVM).
A member of our community recently asked, “why not offer Solidity compatibility on Radix? Wouldn’t this attract developers and dApps to Radix faster than something new?” It’s a reasonable question; in fact, most of the recent Ethereum competitors are playing the compatibility game, often using not only Solidity, but more importantly the fundamental EVM-style computing model that underpins it on Ethereum.
The Allure of EVM Compatibility
In the short-term, that compatibility is probably a smart move. For example, Binance’s recent Smart Chain platform (BSC) pulls across 100% Solidity/EVM compatibility from Ethereum. And BSC has already started drawing many DeFi apps by making it trivial for both developer and user tools (like Metamask) to be moved across (while offering some relief from Ethereum’s low throughput and high fees).
Implementing Solidity/EVM on Radix is entirely possible. In fact, the smart people at Noether have already demonstrated exactly that — offering Solidity smart contract execution on a higher throughput Radix consensus base. We’re thrilled about this and are working with the Noether team to bring an open source implementation of this capability to the Radix public network. We think this will brilliantly solve some real near-term problems for developers and applications.
We can’t stop there though.
Building for the Future with Radix Engine
The philosophy behind Radix’s technology roadmap is the long-game however. And while Solidity/EVM is fine for now, it falls apart when you try to apply it to a truly global-scale, mainstream public DLT platform. This isn’t just a simple matter of a language choice; it’s a deeper matter of optimizing the relationship of the computation model to the ledger data structure and consensus design that together define the network’s performance, security, and suitability for applications. We had to design something new that is optimized for DLT — and optimized for Radix.
For example, let’s consider scalability. Many newer “scalable” DLT platforms improve on Ethereum’s throughput, but still hit a ceiling we’re not willing to live with. For global adoption, we can’t have a DLT that does 10x or 100x Ethereum throughput before hitting a new ceiling again. We need a DLT that scales limitlessly as more network capacity is added — just like the infrastructure of the internet itself. Anything short of that doesn’t really get the world running on a public DLT. To achieve that type of scalability, Radix needs the unique style of sharding/consensus embodied in Cerberus. And taking full advantage of Cerberus’ scalability advantages requires the Radix Engine that underpins our Component-style of smart contracts. Pure EVM-style computation gets some scalability advantages from Cerberus, but is fundamentally incompatible with achieving the limitless scalability that we ultimately need. We talk more about the tight relationship of Cerberus and Radix Engine in our Cerberus Consensus Whitepaper.
Solidity/EVM poses other problems for predictability of state, composability, and deployment maturity as well. Some of these problems just make development a pain in the ass; some of them create money-losing smart contract exploits. Ethereum devs are running into these problems already, but they suck it up because the Ethereum user base, asset base, and developer ecosystem is huge. We get it. And practically, the shortcomings of Solidity/EVM aren’t standing in the way of deploying high-risk, Chad-style DeFi dApps for today’s risk-taking crypto heads. In order to move DeFi into the broader world of finance and everyday users, however, we think those problems are insurmountable brick walls.
So years ago we decided that the only viable path forward was for Radix to design a new style of decentralized computation that meets the longer-term need rather than just fighting everybody else for the easy win of Solidity migration. And the FSM-based approach behind the Radix Engine and Components turns out to be a very elegant match for both our ledger/consensus model and for solving all of the above problems. Fundamentally, EVM-style computation was never designed for the incredibly specific needs and environment that a public DLT represents; the Radix Engine is. Our blog post on Radix Engine Components goes into a little more detail on why.
