2020 has been an interesting year for Ethereum and its programming language Solidity. While much of the news regarding Ethereum has been about high gas fees and 2.0’s imminent arrival, there is a shiny new kid on the block that has received most of the attention: DeFi (Decentralized Finance), which is almost exclusively built on Ethereum. But with the advent of DeFi has come a significant uptick in hacks and security problems. These are bringing changes, for example, Agoric announced a partnership with Chainlink, planning to integrate data from its decentralized oracle network. This is notable because Agoric allows developers to build smart contracts using JavaScript, a much more widely used and battle-tested language than Solidity. In tech-speak, PICNIC stands for “Problem In Chair Not In Computer“—meaning that the software and hardware are working fine, while the person operating the computer is the problem. We think that Solidity’s problem is a PICNIC too, or rather a combination of PICNIC and a compiling process that is not well understood.
Lexicon
We’re going to deal with a few technical issues common to Ethereum development. So, it is worth starting with some definitions.
Compiler: A compiler is a computer program that is designed to convert a source program language into a lower-level language that is closer to what the machine executes. Ultimately, all computer languages are compilers of machine language to some degree. However, that degree as well as the steps in-between can vary greatly.
DeFi: Decentralized Finance is a new area of development, where tokens are exchanged, lent, or borrowed. Often, this generates a “yield” or income stream that is moderated by a smart contract—rather than a single, centralized legal entity or person—and/or controlled by a multiparty, decentralized governance mechanism (e.g. a DAO).
Ethereum: Ethereum is both a protocol and an application layer, invented by Vitalik Buterin in 2015.
EVM: The Ethereum Virtual Machine can execute code of arbitrary algorithmic complexity within the Ethereum protocol.
Solidity: Solidity is an object-oriented programming language, loosely modeled after the ubiquitous and accessible JavaScript language. It is used for writing smart contracts that work on Ethereum or other EVM-compatible chains. Solidity is compiled to bytecode that is executable on the EVM and it is designed to be almost English-language-readable. Yet, there is a great number of transformations that turn Solidity into the bytecode that it executes. Most Solidity developers know little about the way in which Solidity is compiled to bytecode, and the number of people who are familiar with auditing at the bytecode level is very small as well.
There is an uptick in hacks?
It is worth revisiting some history because Ethereum smart contracts have gotten hacked since the dawn of Ethereum. Ethereum went live on July 30, 2015. The original DAO, which was launched on April 30, 2016, and raised over $100M in ETH by May 15, had a recursive bug in its smart contract. That bug allowed someone to steal all the funds and eventually forced a fork to get those funds back—the rest is history.
The most notable recent hack in terms of risk was probably the MakerDAO vulnerability that was white-hatted and announced at Devcon in 2019. MakerDAO, the decentralized organization that runs on Ethereum, had a single enormously dangerous security flaw in its smart contract, which could have allowed an attacker to steal collateral backing its Dai stablecoin with a single transaction. Intelligently, MakerDAO ran a bug bounty program and awarded the White Hats the full $50,000 their program allowed.
2020, however, has seen a never-ending run of weekly hacks on DeFi platforms and their smart contract oracles, as well as other flash trade hacks taking advantage of lack-of-security flaws. These are just some of the DeFi hacks that occurred in 2020:
- February 15 – bZx lost $350,000 in an attack and $600,000 more in a copycat attack. Those two hacks in February were primarily market attacks focused on where bZx took its pricing data from, which is a flaw that got ironed out in main markets 20-30 years ago. Plus, the fact that everyone was at ETHDenver probably didn’t help.
- March 12 – On MakerDAO’s Black Thursday, an estimated $9M in funds were lost. Again, this was not so much a hack but a design flaw in the smart contract oracles, which failed to catch a falling knife as the market moved aggressively and collateral positions were over-liquidated.
- April 18 – The imBTC Uniswap pool lost approximately $300,000 in an attack on its ERC-777 smart contract token standard, which had no reentrancy guard in place. This allowed the hacker to increase his ability to borrow assets on the platform repeatedly. However, this turned out to be the test run.
- April 19 – It was probably the team that had been responsible for the imBTC Uniswap hack on the previous day, who took advantage of the same exploit again and drained dForce’s lending protocol LendF.Me of about $25M. This truly highlights the importance of audits and rapid updates, which are standard in general Fintech.
- June 29 – Now it got really ugly. Missing an exploit the day before was one thing, but ignoring several bugs for two months? Not so clever. The Balancer automated market maker protocol was hacked for over $500,000 in a single ETH transaction. The hack was facilitated once again by a dYdX flash loan relying on a feature of STA—a deflationary token—which Balancer’s smart contract didn’t account for, along with another reentrancy guard missing in action. A security researcher and the STA team accused Balancer of ignoring a bug report that had been submitted almost two months before. In deleted tweets, Balancer CTO Mike McDonald admitted the mistake.
- September saw two attacks that were caused by flawed code in the smart contract. On September 14, bZx lost $8.1M (again), due to flaws in the code that audit firms PeckShield and CertiK had failed to pick up. On September 28, Eminence’s smart contract code was hacked and $15M were stolen ($8M were returned). However, this was more of an oracle-level error not accounting for undercollateralized positions.
- October 26 saw the Harvest Finance platform get hacked for $24M. Again, this was more of an arbitrage attack using a flash loan.
Finally, CipherTrace reported on November 10 that about 20% of all crypto hacks in 2020— “roughly $98 million, came from ‘decentralized finance’ or DeFi, which are transactions on platforms that facilitate lending outside of banks.” CipherTrace noted that there had been almost no DeFi hacks in 2019. “Companies and individuals have rushed DeFi products to market that have not gone through security verification and validation,” said CEO Dave Jevans. “So people are figuring out that there’s a weakness here.”
The problem is Solidity?
In interviews, many developers have complained about the difficulty of coding in Solidity. Robert Leshner, CEO of Compound Finance, made this comment during a phone interview with Cointelegraph:
“Building on-chain is merciless; security requires a team’s full attention. When teams redeploy code they haven’t written, it makes it impossible to know how, or why, the code works, or what the risks are… anything less is an injustice to users. And users should demand better.”
Some have raised the challenges of bug fixing in Solidity and the difficulty of following possible outcomes, while others have pointed to the pressure on teams and complained about last-minute fixes leading to instability in the code.
Really, the issue is PICNIC and Solidity.
Many of the issues highlighted above are common to most fast-moving developer projects. But if DeFi wants to save its reputation, it will have to slow down and focus more on fixing bugs. Greater care has to be taken when something gets built that could cause people to lose money.
Ultimately, we think there is a twofold problem. Solidity is a young language. While Solidity code may look simple, the process of turning those simple lines of code into EVM bytecode is anything but simple. Most people who are auditing or fixing bugs attempt to do so in Solidity, although that work really should be done at the level of the bytecode. People who are more familiar with highly developed languages like Java know that the complexity lies in interacting with the libraries you didn’t write, but that still compile into the same stream of bytecode that is mechanically executed by the virtual machine. But without that experience, it is difficult to communicate the deceptive lure of simple Solidity, as well as the difficulties of bug fixing and auditing secure smart contracts that happen to be written in Solidity.
Furthermore, several of the exploits, including the bZx and Eminence hacks in September, are ultimately trading behaviors that have been prohibited in conventional markets, but that are being rolled out by audacious hackers to attack DeFi’s vulnerabilities. When you use Solidity to recreate the pieces of the financial system in a decentralized manner, it is common sense to expect to face the same types of vulnerabilities and attacks from which the centralized version has suffered and against which it has since been immunized.
Recommendations
While neither one of us is deeply involved in the trenches of DeFi, that may be exactly what gives us the advantage of a top-down perspective. These are our recommendations for future DeFi projects:
- Don’t copy and paste found snippets of Solidity code and call it a DeFi project.
- If you must build on Solidity and use other people’s libraries or deployed contracts, take time to learn how the Solidity language compiles and how the EVM executes. Take time to understand common flaws in smart contracts that have already been exploited in DeFi. Finally, spend time doing optimizations, code hardening and due diligence at the bytecode level if you can.
- Try to involve at least one developer who has experience building complex integrated systems using other languages, such as C++, C#, Java and Python.
- Ensure that your software testing encompasses threat modeling by including someone with significant experience in high-frequency trading or other aggressive main-market trades. Get that person to give you a list of common attacks. Unfortunately, there isn’t a ‚textbook describing “Main-market hacks through the ages.” But the existing material on the Dr. Evil trade should give you significant insights into the way that attacks using a market flood and crash are executed. With code being deployed to public chains like Ethereum, all bugs will eventually be exploited. It is just a matter of when it is profitable enough for one person to decide to do it.
Emma Channing – is the founder of the Satis Group, a blockchain advisory firm with expertise in security tokens. Channing has led the digital asset industry, for the last four years, as a subject matter expert on broad use cases for blockchain technology including, security token offerings, blockchain-for-capital-markets platforms, custody, stablecoins, CBDCs, digital identity, and various aspects of associated compliance and governmental communication strategies. Channing also co-founded Global Blockchain Convergence, a 150+ person global blockchain policy laboratory and think tank, and founded NodeWomen, a 100+ person group to support women in Fintech, blockchain, crypto, and digital assets. As an attorney, Channing has directed international teams and working groups across several verticals, including the C-Suite, board members and investors, and technical experts/engineering teams, to deliver compliant and robust digital asset projects. Channing is a graduate of Stanford Law School (LLM) and Durham Law School (LLB, LLM) and is admitted in the UK, California, Colorado and New York. She holds FINRA Series 63 and 79 licenses.
Chris Tse (@christse) is a technologist and designer focused on improving the usability of decentralized applications. In 2014, he founded Cardstack, where he leads a team of open-source contributors to build the world’s first cooperative SaaS platform. He is also a co-founder of Verifi Media, where he pioneered the use of distributed ledger technology to create media registries. Chris has more than a decade of experience leading R&D and innovation teams for Fortune 500 companies. He holds a degree in Computer Science from Columbia University.