Recently, blockchain technology has been promoted as a game changer for many industries. The distributed ledger technology that grew out of Bitcoin has promising applications beyond digital currencies.
One of the most promising use cases of blockchain technology is the development of smart contracts.
Smart contracts are self-executing contracts, where the terms are specified in code. Basically, this means implementing legal contracts in computer code, which executes them automatically.
While the concept has been around for a long time, at least since Nick Szabo wrote the concept in 1996, it was not until the advent of the Ethereum blockchain with the ability to express any computation (“Turing complete”), that the use of the smart contract it became common.
Ethereum contracts exist at contract addresses and can be invoked via transaction calls.
Executing contracts that are written in code and stored on an immutable public blockchain creates certain risks and issues, which we will discuss in general in this post. In an upcoming second part, we will look at more specific examples of smart contract security vulnerabilities
Code is Law?
A literal interpretation of the smart contract idea leads to the “Code is Law” paradigm, which means that smart contracts are binding and are interpreted as if they were legal documents. Any software engineer aware of the impossibility of creating a completely error-free code would throw his hands in his head at the idea that a computer program is legally binding. There are a number of obvious problems:
- The code contains errors. It is extremely difficult to write bug-free code, and even if all possible precautions are taken, there will always be unexpected execution paths or potential vulnerabilities in reasonably complex software.
- Legal contracts are subject to interpretation and arbitration. It is very difficult to create watertight contracts. In any large contract, typos can creep in and some clauses need to be interpreted and arbitrated. That is what the courts do in the event of a dispute. If in a legal contract the sales price is specified as $100 on 39 of 40 pages and an additional zero is entered on one page, a court will rule “in the spirit of the contract”. A computer simply executes the clause as it is written. The immutability of the blockchain adds to this problem, as the contracts cannot be easily modified.
- Software engineers are not legal experts and vice versa. . A different skill set is required to write a good contract, not necessarily compatible with writing a good computer program.
Two Examples of High-profile Smart Contract Attacks
The DAO Attack
Much has been said about this case, which we will not repeat here. A good description of the attack and the aftermath can be found here.
In short, in June 2016, an attacker managed to siphon off a large amount of crowdsourced funds (3.5M ETH, roughly 15% of total ETH at the time) into his own derivative contract (child DAO), in which the Funds were blocked for 28 days, leading to a race against the clock to find a solution.
The important point to note in this case is that the contract was attacked making it behave in an unexpected way. In this particular case, reentrant code vulnerabilities were exploited. We will look at this type of vulnerability in detail in a sequel to this post.
Parity Hack
In fact, this was the second “attack” on the multi-signature wallet contract provided by Parity. The multi-wallet contract, used by many start-ups, had most of its logic implemented in a library contract. Each wallet consisted of a thin client contract that connected to this single point of failure.
Multisig Parity Architecture
There was a crucial bug in the library contract, which was an initialization function that could be called once.
In November 2017, someone did initial the contract and by doing so became the owner of the contract. This allowed him to invoke owner functions, a privilege he used to call the following function:
This is the equivalent of a self-destruct button, rendering the contract useless. Calling this function caused all clients contract funds to be frozen, probably forever.
At the time of this writing, it is still unclear whether the incident constituted a deliberate attack or was accidental, with the perpetrator claiming accidental actions.
Both attacks show that even relatively simple contracts, written by major players in the blockchain ecosystem, are prone to basic errors with serious consequences.
What can be done?
Recent history has shown that smart contract security execution on public blockchains is dangerous and nowhere secures enough to replace more traditional legal systems with their precise language, room for interpretation and arbitration.
This does not mean that we should abandon smart contracts. They are extremely useful tools and open interesting applications. However, we should not consider them as substitutes for legally binding contracts, but as complementary tools for automation.
