Have we learned anything from Curve Finance and DeFi’s susceptibility to attacks?
Curve Finance’s recent near-death experience (and its averted propagation) may seem like a blur in Web3’s rear-view mirror, but it’s actually something that keeps happening in the industry. It’s not the first time that a decentralized finance protocol — or any decentralized app for that matter — has been affected by an attack that is perfectly legal within its own code. More so, the crisis could’ve been prevented if on-chain risk management existed.
All of this points to a broader problem in Web3. That is the problem of limited expressivity and resources that exist in its development environments and how it affects security overall.
Hack or exploit?
When the Curve Finance attacker was able to retrieve US$61.7 million in assets from Curve Finance’s smart contracts, many media outlets and commentators called the event a “hack.” But this was not a hack — it was an exploit. The difference here is key.
In this context, a hack would’ve taken place if the attacker had somehow bypassed or broken an existing security measure. But the attack on Curve was an exploit. Nothing that happened that was out of the ordinary in terms of what the protocol’s Vyper code allowed for. The looter simply took advantage of how the protocol’s design worked.
Who’s to blame for this? No one. Curve’s Vyper code, like most of the (Solidity) code that’s used in Web3 applications, is severely limited in its ability to express complexity beyond relatively simple transaction logic.
This makes it hard for anyone to design security measures that would prevent this or any other attacks. More worryingly, it also makes it hard for anyone to properly design tools to prevent their spread across DeFi’s vast and composable liquidity landscape.
On-chain risk analysis
But it doesn’t mean there was nothing Curve could do to prevent this attack and its spread across DeFi. A simple example of a solution would be on-chain risk analysis.
The generalized version of a problematic pattern that could be solved can be summarized in a hypothetical situation like this one:
- Bad actor Bob buys $5 million worth of the highly volatile $RISKY token via a flashloan.
- The value of $RISKY token is effectively pumped by Bob after the purchase.
- Bob takes out a $100 million loan on Naive Finance backed by $RISKY.
- Naive Finance checks the price of $RISKY and confirms that Bob is “good” for the money.
- Bob runs.
- When Naive Finance liquidates $RISKY it is only worth $5 million.
(Another example of this general pattern can be found in the Euler hack from March.)
Traditionally, this problem is solved by risk analysis solutions that determine how good of a guarantee an asset can be. If they existed on-chain, Naive Finance could check statistical estimations based on the token’s historical price before approving the loan. The protocol would’ve seen through the pump and denied Bob the $100 million.
DeFi is lacking this kind of on-chain risk analysis and management.
Going back to Curve Finance, a spread could’ve been prevented if Aave and Frax had an automated, on-chain limit on loan approvals when they pass a percentage of the collateral token’s circulating supply. This would’ve been a safer and less stress-inducing situation for everybody.
Limited expressivity and resources
The real problem here is that current Web3 ecosystems can’t support something like this on-chain risk analysis solution. They’re limited by the kind of libraries and frameworks that are available in virtual machines like the Ethereum Virtual Machine. They’re also limited in terms of the resources at their disposal.
In order to develop something like this risk analysis and management solution, a decentralized app would need to count on coding libraries that have functions for at least basic mathematical concepts like logarithms and others.
This is not the case in Web3 because dApps don’t have access to NumPy, the math module in Python, for example. The typical toolbox isn’t there and developers have to reinvent the wheel instead.
Then we have another problem. Even if they had these libraries, they would be too expensive to code. Literally expensive. The Ethereum Virtual Machine is designed so that there’s a price for every computation.
While there are valid reasons for this, such as preventing infinite loops and such, it also creates a resource limitation for dApps that might need to scale computationally without incurring unreasonable costs. One could easily see how a risk management solution would cost more to run than what it’s able to save in funds.
Focusing on the right problems
At a localized level, the spread of the Curve Finance impasse could’ve been prevented with on-chain risk management. At a general level, this whole class of attacks could be prevented with more expressivity and resources in Web3.
These are two aspects of blockchain scalability that have long been overlooked because they go beyond affording more shared block space for dApps. They actually involve the creation of development environments in Web3 that emulate those of Web2. They’re about computational scalability and programmability, not just scaling the amount of data that is available on-chain.
Perhaps if protocol developers at Curve, Aave or Frax had the ability to count on a better toolbox and more resources, these and future exploits could be avoided altogether. Maybe we could start with on-chain risk management.
ByYahoofinance
