Preventing DeFi Hacks & the Need for Better DeFi Developer Experience
Disclaimer: The Industry Talk section features insights by crypto industry players and is not a part of the editorial content of Cryptonews.com.
For developers of decentralized finance applications, the odds are well and truly stacked against them. Today’s DeFi landscape is littered with dozens of dApps that have been hacked, exploited and bled dry, despite being built by some of the most experienced and careful developers.
Building DeFi is hard and it’s not going to change without a major overhaul of the way dApps are created. One of the core problems is the code – there’s so much of it that it’s almost impossible to make sure it doesn’t contain any exploits.
The biggest pitfall of creating reliable dApps is that even the most simple function must be written with complex and extremely difficult to analyze code. Smart contract development requires an in-depth knowledge, not only of the programming language, but also of how the underlying blockchain platform operates. The stakes are incredibly high, with one simple mistake potentially resulting in millions of dollars worth of value lost.
A common complaint of Ethereum developers is that they only spend around 10% of their time actually writing code, with 90% of their effort spent ensuring that it’s safe for deployment. But even with such care and attention, the history of DeFi is one that’s littered with stories of hacks and exploits, leading to enormous losses that will never be recovered.
It’s not that the developers are at fault. Rather, it’s the result of an unsuitable development paradigm. With smart contracts, the focus is firmly fixed on managing assets correctly and ensuring that actions can only be taken by authorized users. However, developers are forced to implement these concepts from scratch with every new application, and there’s no safety net available. Once created, the developer must knit this bespoke functionality with the unique logic of the dApp they’re building, while ensuring they can safely integrate with other dApps along the way. As a result, developers are left with a jumble of code that’s likely to be pockmarked with vulnerabilities. There are simply too many opportunities for mistakes to be made. For patient hackers, it’s just a matter of taking the time to study the code, find and expose them.
Smart Contract Complexity
To fix DeFi’s vulnerabilities and put an end to the hacks, we can’t just make do with audits. Rather, what’s required is an entirely new development paradigm that eliminates the potential for errors.
Today’s DeFi is based on a fundamental notion established by Ethereum and the Ethereum Virtual Machine application environment. With EVM, the Ethereum network serves as a public platform that’s able to perform complex transactions using code deployed by third-party developers. Each smart contract, as the code is known, has its own internal state, which can be updated by its underlying logic.
For these smart contracts to be useful, they need to be able to communicate with others. Let’s say we require a smart contract for a DeFi app to be able to hold tokens. In that case, the smart contract must have a way to communicate with an independent ERC-20 contract that implements that token through a list of balances, plus methods to adjust those balances. To create this messaging functionality, we need yet more smart contracts.
Everything in DeFi is a smart contract and all of the actions DeFi takes is implemented in little smart contract silos. As dApp complexity increases, developers find themselves faced with a tangled mess of smart contract-based messages being thrown around the network, with complex logic that’s meant to ensure those smart contracts perform the correct actions in response to those messages. At the same time, those smart contracts contain masses of data recorded within their state, to be able to keep track of everything. The amount, and complexity, of this code, quickly reaches epic proportions.
Unfortunately this is inescapable – it’s the result of developers being forced to work within the confines of an inflexible EVM application environment that was never specifically designed for DeFi. Although some very clever developers have made it work, it’s a terribly inefficient and error-prone process with considerable room for automation and improvement.
Making DeFi Safer
The good news is that work is underway to change this development paradigm and create something more workable. Radix, which has created a protocol for decentralized finance, has come up with a radically different approach that sees assets like tokens as a critical feature of the platform itself, rather than implementing them at the smart contract level.
Radix’s basis for DeFi is based on the observation that interaction with assets is a fundamental part of every single transaction. As such, it believes those assets need to be made a feature of the platform itself.
The Radix Engine differs from EVM in that tokens aren’t implemented within smart contracts. Instead, they’re created by requesting them from the underlying platform together with the desired parameters. In this way, tokens are treated as “physical objects” that must be held in “accounts” and moved between them, rather than implemented through smart contracts. These accounts can be thought of as vaults of tokens that are controlled by users. That’s different to EVM, where a user’s tokens are spread across multiple smart contracts with their own public keys.
Radix Engine is designed as a development engine that minimizes the risk of smart contract hacks and exploits by keeping the code down to a minimum. It comes with unique features that make it easier to build and deploy scalable DeFi apps, with high-quality templates for dApps that are referred to as “DeFi Lego bricks”. It even has its own functional programming language, called Scrypto, which makes it simple to build with these bricks. Programmability within the Radix Engine is derived from Finite State Machines, which are used in mission-critical systems that require predictable correctness at all times.
The “DeFi Lego bricks” are known as “components”. They’re the closest thing to smart contracts in Radix and are written using Scrypto and behave more intuitively than Ethereum-based smart contracts, providing more consistent and reliable outcomes. These components can easily be integrated into other dApps. They can be accessed via the Component Catalog, which is a ledger-based inventory of templates that anyone can use to build dApp functionality on Radix.
The components can be activated when they’re instantiated using a “component template”. Once activated, they can be applied to multiple applications safely in the knowledge that they’ll act in the same way each time they’re used. This is especially useful when there’s a need to create multiple components with the same parameters. Instantiating a component can be done easily using an API, rather than writing code. Modularity is further encouraged through the use of “blueprints”, which are on-network templates containing more specific functionality for each component. This enables any dApp developer to safely execute smart contracts without needing to learn Scrypto itself.
The Next Generation Of DeFi Apps
The beauty of Radix is that it enables developers to lean more heavily on Radix Engine’s resources to handle the bulk of their dApp’s transactions. Instead of creating specialized code every single time, developers can use resources to implement code that’s simpler and much safer.
What’s more, Radix offers a Developer Royalties System that provides an incentive for developers to deploy their applications on its blockchain and create code that others can reuse. Developers are rewarded for building contacts and blueprints that other developers later use.
All in all, Radix provides a far simpler development environment that eliminates many of the headaches associated with smart contract deployment. Not only does it make DeFi safer, but it frees developers from the burden of ensuring that safety. As a result, developers can focus their time and effort on implementing their ideas for the next generation of DeFi applications and bring us closer to the dream of revolutionizing global finance.
