Dateline: Woking, 25th September 2021.
A California federal judge has ruled that South Korean crypto project ICON (ICX, a blockchain-powered network that supports smart contracts and was historically considered South Korea's answer to Ethereum) may have acted improperly when it instructed Kraken and Binance to freeze 14 million tokens minted by a crypto "hacker". The word hacker is in quotes here, because it's a matter of some dispute what exactly constitutes a hack when it comes to smart contracts on a blockchain.
In this case, the alleged hacker, Mark Shin, countered that he had never hacked any part of ICON's system, he simply used the code as it had been programmed. Mr. Shin's lawyer was quoted as saying that "if the blockchain says you have certain tokens, and you didn't take those tokens from another individual, the rules of blockchains are that that property belongs to you”, a position that is generally summarised as “code is law”.
(In this view, the ICX issue has nothing to do with hacking and everything to do with redistributing value to, as my friend David Gerard would put it, cryptographically more deserving causes.)
These smart contract issues are not exactly rare, by the way. An investigation conducted by CyberNews found that nearly 3,800 Ethereum smart contracts had vulnerabilities in them and called them a “time bomb”. It is hard to disagree. A detailed paper IEEE paper on “Smart Contract: Attacks and Protections” analysed a number of security tools to detect vulnerabilities in order to assess their effectiveness and found that not all vulnerabilities were detected, providing a dangerous false sense of security that attackers can abuse, and concluded that developing secure smart contracts “remains a challenge”.
Many of these problems with the smart contracts are caused by programming errors. Earlier in the year, I remember looking into another smart contract failure. If you are interested, the detailed analysis is on Medium, but the essence of it is that there was an error in a smart contract where the programmer had set a condition "greater than zero" rather than as it should have been "greater than or equal to zero", result in a couple of hundred million dollars vanishing.
(The developers, rather wonderfully, reported on Telegram that because of a condition "which we have unthought of", the money won't be coming back.)
Not Your Father’s Apps
There is an important point to be made here about persistence. Smart contracts are not like other apps. People are lousy at writing software but when there's a bug in Word then Microsoft can just download a patch and fix it. But blockchains are immutable: that's sort of the point of them. You cannot patch a bug in a smart contract, all you can do is fork the blockchain back to a time before the smart contract was executed.
As I was sitting down to write this piece, I noticed that Poly Network had reported that a person or persons unknown used smart contracts on their network to redistribute some $600m worth of Ether, Binance Coin and USDC to cryptographically more deserving wallet addresses. This was made possible because of bugs in two important smart contracts on the network (you can read about the details here). Poly Network responded by abandoning the code is law ethos and threatening both official legal action and unofficial lynch mobs saying "law enforcement in any country will regard this as a major economic crime and you will be pursued" and the perpetrator eventually returned the funds. I can't decide whether this was actually a real story, a marketing stunt or performance art. My best guess is that the attacker slipped up in such a way that they could be identified by vigilantes, since their IP address and email were discovered soon after the heist, and abandoned the heist.
(In my opinion, "smart contracts" is one of the worst marketing labels in history. Bill Maurer and DuPont nailed this in their superb King's Review article on Ledgers and Law in the Blockchain back in 2015, when they pointed out that smart contracts are not contracts at all but computer programs and so strictly speaking just an "automaticity" on the ledger. In my book "Before Babylon, Beyond Bitcoin" I drew on their work and further mentioned Ethereum inventor Vitalik Buterin's comment that he wished that with hindsight he had used the word "persistent script" instead.)
Some apps are not like other apps, in short. But what is the point of these persistent scripts? Gartner's Avivah Litan summarised the situation by saying "the benefits and logic of smart contracts are not understood by all parties" (or indeed, I might add, any of the parties in some of the use cases I have seen). They are not smart, and they are not contracts. But they are useful. They enable users to form decentralized digital agreements without the need for a third party, which has attracted interest around services including banking, health and insurance. There is the potential here for an entirely new financial infrastructure: that of decentralised finance, or “defi”.
DeFi as RegTech
The St. Louis fed wrote that defi may increase the "efficiency, transparency, and accessibility" of the financial infrastructure and I think that they are right. Moreover, the system's composability allows anyone to combine multiple applications and protocols, thereby creating new and exciting services: this is the world of the "Money Legos" that advocates describe so enthusiastically. The opportunity to build complex, structured products through defi implies the use of smart contracts rather than financial institutions and markets. Such contracts can source liquidity from various on-chain derivatives protocols and pull them together to achieve some specific risk objective, all the while staying 100% transparent.
What is particularly interesting to me is the potential to reduce the costs of financial intermediation by reducing the costs of regulation while simultaneously making it more effective. In a detailed and fascinating paper on the topic Dirk Zetsche, Douglas Arner and Ross Buckley summarise the defi opportunity, noting that it is an opportunity for the development of an entirely new way to design regulation, specifically with the concepts of “embedded supervision” and “embedded regulation” (or as Richard Brown, Salome Parulava and I called it “ambient accountability”) potentially decentralising both finance and its regulation in the ultimate expression of not fintech but regtech.
This approach opens up an entirely new field of finance with significantly more complex instruments and significantly lower costs. However, it has to be noted that smart contracts’ key selling points of flexibility and efficiency could be, at the same time, their biggest challenge to institutional adoption. In the same way that defi offers multiple avenues for users to take advantage of their yields and value propositions, hackers also rely on that flexibility to conduct attacks and simple exploits mean the infrastructure is a gamble.
The more the use of smart contracts expands, the more it catches the attention of potential attackers, both for technical exploits and what you might term market exploits (eg, front running). Many observers think that what we have now (primarily the Ethereum Virtual Machine, or EVM) is just not suitable, and I can see where comments such as “EVM was the first engine of smart contract blockchains. Like with the early automobiles, we do not drive T-Fords today” and “EVM and its programming language @soliditylang are very use case focused and narrow. They can do little computing, slowly, similar to a dumb phone from 1999” are coming from.
Time for Strategy
Security is not the only barrier, of course. A recent webinar from The Block that looked at the issues around scaling discussed other factors ranging from the user experience to discoverability and are to “general agreement” on the need for a central app store-like destination to discover and interact with persistent scripts.
I wonder if the SEC could run some sort of App Store of certified scripts? Clearly I am not the only person thinking this way, because in a recent speech Di Gang, the deputy director of China's central bank Digital Currency Research Institute, said that there is a need for what he called "formal verification" of smart contracts to prevent bugs.
With this sort of structure in place, it is easy to see that the financial services world will be disrupted. Who will do it is hard to say though. If we are to realise the benefits of this new infrastructure we may well need both a different kind of “blockchain” and a different kind of “smart contract”.
I’m not smart enough to know whether defi will be built on Ethereum 2.0 or Solano or Liqudity or whatever, but I am smart enough to know that a market of competing smart contract platforms is growing, that defi will be built on them and it makes sense for financial services organisations to start working on their strategies for exploitation.