The decentralized finance industry is perhaps the most promising use case of blockchain technology to emerge so far. What started with Bitcoin and a simple, alternative payment mechanism has evolved into an entire industry of alternative financial services powered by Ethereum and other cryptocurrencies.
The big promise of DeFi is greater financial inclusion. By eliminating banks and other centralized entities required to authorize transactions, DeFi opens the doors for anyone to participate, without any kind of ID or the need to undergo credit checks. The incredible growth of the DeFi industry to date serves to underline the potential of this alternative financial ecosystem. In March 2022, the global DeFi sector was valued at more than $77 billion.
DeFi has grown to an impressive size but it has a long way to go if it’s ever going to be able to replace traditional finance. If DeFi and crypto are to become truly mainstream, the industry needs to establish much stronger foundations than the current architecture it is built upon.
The Problem With DeFi
The major weakness of DeFi is that it’s built atop of an extremely vulnerable architecture, namely smart contracts.
That statement might raise some eyebrows because smart contracts are the key concept behind DeFi. They’re what enable transactions to be processed without any kind of middleman. Smart contracts are software-based agreements hosted on the blockchain that self-execute only when certain conditions are met. They are open-source, meaning that anyone can see how they work, ensuring the entire process is transparent.
Smart contracts are all well and good when they work, but the major issue with DeFi is that they often fall short, as illustrated by the more than $2 billion in value that has been lost to hackers and scammers this year alone. The reason for this loss? Vulnerabilities.
Smart contracts are in essence just a string of code. However, these strings of code are often extremely long and complex, and it’s this that makes them vulnerable to bugs and exploits that can be abused by hackers. Bugs in software have existed for as long as code has been around, and it’s clear that humans don’t really have an answer to this problem. After all, humans are only human, and as smart as humans are, they’re also notoriously prone to mistakes. We can audit software code all we want, but there will always be a risk that something escapes our attention.
It follows then that the best way to prevent vulnerabilities slipping into software code is to keep that code to an absolute minimum, and it’s here that the current smart contract paradigm falls apart. Existing smart contracts, as first conceptualized on Ethereum, and later copied by just about every other major blockchain platform that has emerged since, are created using masses of spaghetti code that’s just too unwieldy for developers to keep secure.
What’s needed then is a complete revamp of the way smart contracts are built, with an entirely new development paradigm that makes them easy, safe, reusable and composable. In this way we can cut out the spaghetti code and minimize the learning curve. If we can do that, we can make it possible for anyone to safely create simple smart contracts with less chance of vulnerabilities going unnoticed.
The Complexity Of Today’s Smart Contracts
To understand how bad today’s smart contract development paradigm is, we can take a look at how a very basic transaction is executed on the Ethereum blockchain.
Let’s look at Uniswap, which is one of the most widely used decentralized exchanges in the DeFi industry. On Uniswap, one of the most basic transactions is where a liquidity provider contributes a pair of tokens into a liquidity pool for other users to trade against. In return for doing this, the LPs are given a special “LP token” that serves as a receipt for the tokens they deposited into the pool. Within the pool, traders can then buy and sell these token pairs using a complex formula that applies small fees to compensate the liquidity providers.
One might think that this process would be fairly straightforward to implement. For instance, with the initial swap, you might expect it to work somewhat similar to the diagram below:
So according to this diagram, the trader has an amount of A tokens in an account that are sent to Uniswap’s smart contract. The smart contract’s algorithm does some math to figure out the exchange rate between token A and token B, in order to send the trader the correct amount of B tokens. It couldn’t be simpler, surely?
Unfortunately, it doesn’t quite work like that. Rather, the above diagram is an incredibly simple rendition of how Uniswap’s smart contract really works. In reality, it’s far more complex:
Oh dear. A pretty lengthy explanation is required.
The problem with keeping things simple is that Ethereum doesn’t have any notion of what “tokens” are. So token A and token B have to be represented as standalone ERC-20 smart contracts, each of which holds an internal list of balances. In reality, users don’t send their cryptocurrency tokens anywhere. What they’re doing is sending messages to different smart contracts, telling them to update their balances. What’s more, traders don’t even hold any tokens in their “account”. Rather, the entire crypto universe is just a mass of smart contracts with balances that can be accessed using a private key.
As a result of this complex architecture, a token transfer involves sending messages to those smart contracts that hold each token, using the Uniswap smart contract. Further complicating things, because Uniswap’s A and B reserve pools are just balance lists in other smart contracts, Uniswap’s main smart contract must keep and update an internal cache of both balances, which must be updated with each call to ensure it’s able to calculate the A/B exchange rate correctly.
There’s yet more intrigue. Users who submit a transaction to Uniswap are always required to “approve” a token before it can be traded. This is due to the pink line in the above diagram. Uniswap must perform “sends” of both the A and B tokens on behalf of the user, so it requires a separate transaction to tell each token’s smart contract to enable the swap. This is a security consideration that’s necessary to prevent transactions by malicious dApps and users from being approved.
While all of this is going on, Uniswap’s smart contract must keep its internal balance list of the LP token up to date, using a similarly complex interface.
Don’t forget, this is all just a simple token swap! Many DeFi dApps can perform far more advanced transactions with numerous steps – adding to the complexity for developers and increasing the likelihood of vulnerabilities slipping into the numerous smart contracts that make everything work.
Keeping It Simple
The cause of all this chaos is that blockchains like Ethereum, Polkadot, Solana, Cosmos and Avalanche do not have any concept of “assets” such as cryptocurrency tokens and NFTs. This is a key design failure. It means developers have no choice but to create elaborate smart contract mechanisms to power every function of DeFi.
If we want developers to be able to create simpler smart contracts, quickly, without any vulnerabilities, we need a fundamentally different platform to build them on – one that recognizes digital assets.
What we need to do is make the simpler Uniswap diagram shown above become a reality. We need a way to simplify smart contracts, so actions can be boiled down to things like “send”, “put” and “take”. If those things can be made a feature of the platform, it will be possible to massively simplify smart contract design with composable, reusable and feature-rich code. This is what Radix is working on.
Radix refers to its smart contract architecture as “asset-oriented programming”, which is an approach wherein assets are a key feature of the underlying platform. Because they’re a native feature of the Radix blockchain, there’s no requirement to implement them over and over as balance lists within smart contracts.
Radix has created an application development environment called the Radix Engine, which is radically different from the Ethereum Virtual Machine and other, similar environments. With Radix Engine, it’s possible to create tokens by requesting them directly from the platform. The key difference with this is that the platform treats these assets as physical objects, which are stored in users’ accounts and moved between them – much like in our simpler Uniswap diagram above. Remember, this is completely different from Ethereum, where tokens are not stored in accounts but rather, as entries on thousands of different smart contract balance sheets, accessible by a private key.
Radix reduces the complexity of how assets are handled because it recognizes them for what they are – a key element of DeFi.
Radix is able to do this because it uses a unique finite state machine (FSM) model that guarantees the correct physicality of asset behavior. In Radix Engine, the Tokens FSM can be thought of as a delivery service that ensures each token will arrive at its intended destination when transferred from one vault to another.
.
As the diagram shows, sending tokens is simplified immensely. Instead of sending a message to a smart contract instructing it to update a list of balances, the user simply tells Radix Engine that he or she wants to send tokens held within their vault to another. This eliminates errors such as double spending, because it simply isn’t possible to send tokens twice if the assets are no longer there.
Added to the asset-oriented approach, Radix has created a Rust-based programming language called Scrypto that’s used to send messages between smart contracts and create logic for them. Scrypto has the effect of expanding the Tokens FSM into a “Resources FSM” that adds far greater functionality to native assets.
This unique architecture turns smart contract logic on its head. With the Resources FSM, sending tokens becomes more straightforward and intuitive. As a result, the code for smart contracts doesn’t need to be nearly as complex. Moreover, the number of messages sent between smart contracts is kept to an absolute minimum, as they only need to convey user requests rather than manage the movement of assets and update balance sheets.
In summary, Radix Engines’ resources eliminate the need for specialized code for each and every transaction. They enable developers to create and reuse code that is simpler and therefore much safer for everyone.
Because Radix Engine’s smart contracts are so much simpler, Radix has created a more fitting name for them. They’re called “components”, and thanks to their modularity and composability, they enable developers to create new DeFi applications simply by piecing these components together, similar to how someone might build a model using lego bricks.
As a result, Radix has completely redesigned the DeFi development paradigm with an entirely new application environment that keeps coding to an absolute minimum. Developers are less burdened with the prospect of vulnerabilities creeping into their code, meaning they can spend more of their time making their ideas for decentralized finance a reality.
