Author’s note: While I felt that I could have done better illustrating the details of the concepts written here, I understand that there is a segment of readers who will find the article to have too much detail. If you feel that you’re getting past the point of diminishing returns, I suggest that you quickly scan the rest by just reading the sentences in bold.
Brief History of Smart Contracts
The advent of smart contracts created a plethora of use cases in distributed ledger technology.
Ethereum, which has had the first-mover advantage in the DeFi space, built the Ethereum Virtual Machine (EVM). This tool computed arbitrary code logic and built decentralized exchanges, lending protocols, and NFT use-cases; providing novel proof of concept of what frictionless, decentralized, and open systems could enable. Together, we call this Decentralized Finance, “DeFi”. Over the past year, the Cambrian explosion of DeFi demand has caused congestion in its network resulting in exorbitant transaction fees that have made the network unusable for new user looking to enter into the space. This has untapped an opportunity for market participants to look for better scaling solutions to keep transaction fees reasonable. Much of the marketing gimmicks revolve around the broadcast of a promise of high Transactions Per Second (TPS).
While most of the space focus on the issue of scalability, there seems to be a lack of attention in another problem, much more pertinent for facilitating a global adoption of decentralized finance: that is safe smart contract execution.
There are several susceptibilities in the current smart-contract design paradigm. For instance, there has been an account of over 16 common vulnerabilities on Ethereum. These often repeated vulnerabilities has resulted in a loss of $2.3 Billion worth of assets over the last few years in DeFi. These issues infiltrate the current paradigm, making it extremely tricky to write smart contracts. These complications are rooted both in the Solidity language and the highly dynamic behavior of the EVM, therefore making the EVM fundamentally unsafe.
Some argue that Solidity is easy to learn because it is modeled after JavaScript. Additionally, many programming boot camps claim that their program could make you a Web3.0 developer in only three weeks. However, while learning how to program in the language is one thing, building a safe and functional application is another. The reality is, developing a safe, robust, and functional DeFi application takes years of experience. Much of the long lead time to talent on Ethereum is due to a few problems.
The EVM doesn’t have safeguards to error check code logic, guarantees no protection at runtime, or built-in guardrails that enforce the safety of asset behaviors. This is because the EVM has no built-in intuition to what assets like tokens are. It doesn’t understand how assets should behave, nor know how to protect it from unintended behavior of sloppy code or malicious code.
What is a token? What does transferring a token mean? How does the execution platform understand the mechanics of borrowing assets? The answers to these questions should be native to the execution platform.
The current methodology for programming smart contracts places a hefty burden on the developer. The responsibility requires them to handle several critical areas, such as simulating how assets work from scratch; as a result, creates additional complexities, difficult-to-read code, and difficult to audit code which makes the role of audits almost meaningless.
In Diem’s white paper on their asset-oriented approach on Move, they’ve identified that Solidity lacked these features that make DeFi functionalities unsafe:
1. Assets are not recognized by the EVM platform: Interacting with assets in smart contracts requires special language support.
2. Solidity lacks flexibility in allowing programmers to provide custom access control policy for DeFi functionalities.
On Ethereum, assets are just encoded integers stored in some mutable data structure inside of a central smart contract. The problem here lies in that integers are not natively recognized as assets with special conditions in the EVM; it just understands them as numbers in a smart contract, creating a problem for developers when attempting to simulate finance behaviors. Further, not having special language support means that the language lacks features in which the EVM can intuitively understand how the developers want to interact with assets. Thus, these Ethereum smart contracts that hold the balance of your tokens and other assets do not have guarantees of their safety from being tampered with by malicious code or accidental exploits].
Taking these characteristics into consideration, the confluence of an increasing complexity in the codebase that’s difficult to understand, a compiler that can’t effectively catch errors at runtime, and an execution platform that doesn’t have a built-in intuition of how assets should be protected is a recipe for laying the infrastructure for DeFi on unsteady ground. These issues make the Ethereum smart contract development paradigm a poor foundation for global DeFi adoption.
If we anticipate DeFi protocols that developers build to be composed amongst each other in unique ways that harness the liquidity of the crypto markets, the programming paradigm has to evolve. Likewise — if we anticipate developers to create DeFi protocols in ways that surpass what TradFi could ever provide for the global financial system, the programming paradigm must change.
The Quest for a Solution
Projects such as Cardano, Flow, Ergo, Kadena, Diem, and Chia have made advancements towards improving the security in smart contract development. An example of this is that Cardano, Ergo, and Chia all use EUTXOs as an attempt to provide better asset security (with Cardano employing functional programming for easier code verifiability). For instance, EUTXOs eliminate double spends or balances of coins being edited. (EUTXO/UTXO models explained here will describe the concept more effectively, since it lies outside the scope of this article.) Both Diem and Flow have a compelling approach to using an asset-oriented programming paradigm while Kadena is exploring the use of their turing-incomplete language. I found that these projects have an interesting approach to securing smart contracts. However, none of the projects mentioned have been as innovative as Radix and the Radix Engine.
Radix engineered their smart contract execution platform, the Radix Engine, from first principles, designed and purpose-built for DeFi. Radix does this through:
- Developing Scrypto, an asset-oriented programming language.
- The Radix Engine employs a Finite State Machine (FSM) design to manage assets.
Asset-Oriented Programming as a DeFi Standard
The DeFi space revolves around the interaction of assets. When we deposit collateral into Aave, make swaps on Uniswap, or collect NFTs, we are interacting with assets. Yet, ironically, there is no special language support to make assets first-class citizens on the platform, which makes the treatment of assets as an afterthought rather than a priority.
Like Diem and Flow, Radix uses an asset-oriented programming paradigm. Scrypto, which borrows syntax from Rust, was designed with asset-oriented features for developers to have interaction of assets in mind as native, first-class citizens. Employing asset-oriented paradigm means that assets are recognized globally at the platform level with special considerations (as opposed to having to be re-implemented as ERC-20 contracts with no special language support from Solidity). To illustrate, when transactions are made to execute components on Radix, the compiler and the Radix Engine understands that the component is interacting with an asset — which has tangible value — and any code logic that gets passed through has to follow special rules that will maintain the integrity of the asset.
The power of Scrypto’s asset-oriented programming is engraved in the Radix Engine with built-in intuition to understand concepts such as a vault, a place to securely store tokens or other assets. The Radix Engine understands assets must be safely transferred from one vault to another. Developers can instruct the Radix Engine by writing Scrypto code in what are called “components” (the Radix equivalent of smart contracts). When developers instruct the Radix Engine to move assets from one vault to another, it does this by “taking” a token from one account’s vault and “putting” it into another account’s vault.
Additionally, the Radix Engine also has intuition for performing DeFi functionalities. When developers write a Decentralize Exchange component to instruct the Radix Engine to perform a “swap” of token A to token B, developers can instruct it, almost as clearly as plain English.
Granted, you would intuitively understand what it means to “take” something and “swap” it for something else then putting that into some kind of storage or vault. You must then wonder why this isn’t the programming standard. To put it in perspective, because the EVM lacks native intuition of what assets are and how they should behave, your “assets” are simply entries in a siloed ERC-20 smart contract. This is one entry that lives amongst the balance of thousands and potentially millions of people’s “assets”. As a result, because your assets aren’t directly stored in your own vault, it becomes difficult to design proper access controls. For example, when you’re performing a swap on Uniswap, you are giving permission for Uniswap to change the entry of your balance in this siloed ERC-20 contract on your behalf. You must then trust Uniswap doesn’t have any vulnerabilities in their smart contract code to be able to do this.
Frankly, if this sounds confusing, the crux is that — it is confusing. The deep dive explanation to portray the complexity of developing in Solidity is much too exhaustive to encapsulate in the scope of this article. I’ll reference to this video here for those who want to study the details.
Alternatively, I want to borrow Radix’s explanation in a blog post they’ve published that exemplifies the complexity of writing smart contract code on Ethereum as the explanation is elegantly explained with the graphics provided. The article states:
a smart contract that allows users to automatically swap one token for another from a pool (ie. Uniswap) sounds pretty simple, and you would expect a functional diagram of its implementation to look something like this:
However, with the tools the Ethereum platform provides for creating smart contract logic, Uniswap’s developers are forced to build it like this:
And as DeFi grows, the development challenges and opportunities for failure caused by this sort of code rapidly multiply as dApps become more complex, and are combined together. DeFi simply cannot grow, or expand its base of developers, much further with this approach.
The consequence of Solidity lacking native asset-oriented design push the burden onto the developer. It is then up to the developer to mimic how assets should behave. Likewise — the consequence of the EVM platform lacking native intuition of assets results in the inability for developers to interact with the assets directly. As a substitute, developers simulate DeFi mechanics (such as a swap, lend, or borrow) by cleverly sending complex messages to different ERC-20 contracts to perform safety checks of balances and perform actions. The hope is that auditors can catch the vulnerabilities created in the web of complexities as a result of this lack of native support. Simulating asset-like behaviors with “safeguards” from scratch not only adds complexity to the code base which ironically adds more attack vectors, but because these “safeguards” are not globally enforced by the EVM, these “safeguards” are almost impractical since interactions with other smart contracts in a DeFi ecosystem can create a myriad of unintended behaviors.
With Scrypto and the Radix Engine, these intuitions are built-in allowing the developer to instruct the Radix Engine to perform behaviors in the clearest way.
The concept of asset-oriented approach is not entirely new since the idea was first featured in 2018 by obscure ‘flint’ programming language out of Imperial College. Applying the concept to DeFi came with a few iteration attempts from Flow, Diem, and Radix with what the best implementation approach is. Yet, despite the variation of how asset-oriented concept is implemented, these projects have opined the need for asset-oriented standardization in DeFi.
Assets are not only just tokens, but they can also be a data structure that provides special permissions, or a non-fungible token. Alternatively, they can be referred to as “resources”, but for simplicity, we’ll continue to use assets in this article.
Finite State Machine
Radix Engine uses a well-constrained finite state machine (FSM) model to guarantee assets behave like physical objects.
FSM’s are computational models that have very strict and defined behaviors. Given a set of inputs only certain output states are possible. To a layman, that may be confusing, but bear with me, I’ll attempt to parse it out here.
Modeling systems using an FSM design gives a tractable way to reason about the design and operation of systems that:
1. Have an entity where behavior changes are based on some internal state
2. All of the entity’s state can be explicitly defined into a finite set
3. The entity responds to a finite set of inputs
In other words, consider a light switch. It can only either be on or off and flicking the switch… well… turns it on or off (#1). The light switch can be modeled into two states: the state in which the switch position indicates the “off” state; and the state in which the switch position indicates the “on” (#2). Your inputs are: you can flick the switch on, the state then transitions to the “on” state or you can flick the switch off in which the state transitions to the “off” state (#3).
This design predictably evaluates the behavior of a system when it is in a certain state, and a specific event happens. Using the light switch example, when we flip the light switch on, we expect its state to be “on”. Further, knowing the state of the light switch, we can determine what other options we can do with the light switch. Once you flip the switch on, you can’t flip it on again. You can leave it on, but the only option to change its state is by switching it off.
Isolating the set of states of an entity into finite options and implementing specific rules in how entities can behave in each state by the set of inputs it is given makes systems easily verifiable in a formal way. This consequently allows a design architecture ideal for mission critical systems. A characteristic optimal to be the bedrock for the future financial infrastructure of the world.
When this design is applied to how assets are managed in the Radix Engine we can recognize the safety guarantees it provides since it creates a computational model that exhibits behavior that prohibits any undesired states. Assets by their nature only have a finite set of states that they can transition through in their lifetime. For instance, an asset can have a state that defines how much quantity it has in a particular vault, whether there is an increase when more assets get passed into the vault or decrease when they are moved out of the vault.
The FSM creates a specific set of states where these assets can be in. When a transaction occurs, The Radix Engine executes the instructions written in the component code. The assets then transition through the states by the given inputs with guarantees between each transition of states making it impossible for assets to be double spent or lost.
On the EVM, managing a smart contract’s state is complicated. Developers are bound to create a laundry list of “if-else” checks to simulate every possible state change that introduces exploits. The Radix Engine is built where these exploits are not possible to begin with as the developer only needs to focus on what *can* be possible. It abstracts away the complexity with having to simulate how assets should behave from scratch that creates lots of complexities and open the door to expensive programming mistakes.
The Unreal Engine for DeFi
Game developers used to spend an insurmountable amount of time designing how physics ought to work in a game environment — instead of spending time on what they’re good at: creating great games.
The Unreal Engine paved the way for a new era of games with breath-taking immersive worlds and rich environments.
The Radix Engine takes that inspiration to transform the DeFi space by implementing an engine with platform-level assets and providing a syntax that makes it intuitive to manage them. The combination of these features emboldens developers by equipping them with tools capable of creating a myriad of DeFi protocols we’ve yet to see in the current DeFi space or in the TradFi space.
With these foundations, we can imagine a future for DeFi with dApps composing with each other to bring about new services never been thought of before.
A famous quote by Steve Jobs once said,
The combined value of our global financial system accumulates to $400 Trillion. This seemingly massive figure does not include the unbanked population in developing countries of the world. Scrypto and the Radix Engine provide us the tool to engineer a more viable system than the one we’ve had for over 300 years — the chance to build an inclusive and democratized financial system. This system will source the world’s liquidity and efficiently allocate capital to accelerate economic growth, expand opportunity, and increase personal sovereignty. Today, the DeFi market only accounts for merely 0.5% of the total value of global finance. If we expect developers to create DeFi protocols in ways that surpass what TradFi could ever provide for our financial systems, then it’s vital to consider a project with innovative and intuitive tools that can enable the proliferation of DeFi adoption. I believe that Radix not only promises a vision — but Radix has the capability in delivering this future.