By Ted Mlynar and Ira Schaefer are partners in the Intellectual Property practice at Hogan Lovells in New York City. They advise on patent and other intellectual property issues relating to blockchain and cryptocurrency technologies.

19,000 ethereum smart contracts studied, 44% contained vulnerabilities.

More than 20 years ago, Nick Szabo proposed the use of a ‘smart contract’ to reduce fraud and enforcement costs associated with traditional paper contracts. His smart contract would be implemented as a “computerized transaction protocol that executes the terms of a contract” – in other words, a computer program.

Like any other software, a ‘smart contract’ computer program would receive inputs, run a series of program steps, and supply outputs. For example, the smart contract could wait for a predetermined condition to occur (eg: a stock reaches a particular price), automatically deem the terms of the contract met, and trigger a predetermined series of performance steps (eg: a payment) that would be automatically carried out. Well ahead of its time, the idea did not catch on.

Fast forward now to 2016. Blockchains abound, and there is renewed interest in smart contracts, particularly with decentralized contract execution: smart contracts on the blockchain.

The bitcoin blockchain has been running since 2009 but, despite various efforts, does not appear to lend itself to convenient implementation of smart contracts. By contrast, the original ethereum blockchain, announced in 2014 and launched in 2015, was specifically designed to allow the implementation of smart contracts.

Problems in paradise

Since the launch, smart contracts began to proliferate in the ethereum ecosystem. However, the future immutability of ethereum smart contracts is uncertain after the widely publicized ethereum “hard fork”. The existing ether effectively became “E[i]ther” – ether classic (ETC) and *new* ether (ETH) – leaving market forces to determine whether either, or both, will survive.

The ethereum system, like bitcoin, associates ownership of currency (ether) with an address. Unlike bitcoin however, ethereum also provides an address for executable contract code that runs on the blockchain. When the contract address receives a suitable message from a user or another contract, the code is executed. Ethereum smart contracts are stored on the blockchain and executed on “ethereum virtual machines” (EVMs) by self-selected computer nodes, commonly known as “miners”. Those nodes perform the processing needed to execute the corresponding program steps. For a fee, of course.

The processing fee for each ethereum smart contract is proportional to its complexity and use of computing resources. By charging a proportional fee, resource-intensive misuse of the ethereum system is discouraged.

But overuse of ethereum resources is not the only type of misuse possible. A recent paper noted that among the roughly 19,000 ethereum smart contracts studied, 44% contained vulnerabilities. As smart contract code was copied over and over again, and flawed drafting techniques were repeated, error-filled code propagated. Old, flawed code apparently became the unsteady foundation for towering new smart contracts.

As we are all painfully aware, software bugs and system vulnerabilities are nothing new. The most popular operating systems and application software are “updated” frequently. And more bugs are found all the time. The typical software license agreement includes years of “free” updates.

How to correct an immutable system?

As a software consumer, your “due diligence” is fairly straightforward because an error correction process is built into the software license. When (and not if) something goes wrong, you have some hope that someone is trying to solve the problem.

But smart contracts are not ordinary software. A smart contract is supposed to automatically implement a real-life contract: an actual agreement between two (or more) parties. After the negotiating parties agree to the terms of a deal, those terms are converted into a smart contract – eg: given to a computer programmer to create smart contract code. So how do the parties know if the terms agreed upon were correctly programmed?

Moreover, if a smart contract is stored on an immutable blockchain then, by definition, its stored program code does not change. The certainty that results from such permanence becomes a valuable feature. But that certainty also means that immutable smart contracts lack traditional error correction capabilities. The program code implementing the smart contract cannot readily be debugged after being stored on an immutable blockchain. Any errors or vulnerabilities are set in ‘blockchain stone’.

A smart contract needs to be error-free, error-tolerant or, in at least some way, correctable. Relying on “form” contracts is no guarantee of safety – especially not for smart contracts. Old, buggy software certainly can be exploited and has been to great effect. Look at The DAO hack. A reported $50m-plus of ether was diverted due to a smart contract vulnerability.

There needs to be a new kind of due diligence for this new kind of contract. Smart contracts blend law and computer science. The due diligence on smart contracts should do the same.

Due diligence in the blockchain age

What due diligence is needed for a smart contract?

A traditional analysis of the proposed transaction and the negotiated contract terms should identify practical and legal issues. A source code analysis should identify flaws in programming the smart contract before it is compiled.

In addition, the proposed smart contract should be run on a simulator to see how it operates in response to expected and unexpected messages from users and other contracts. Both the legal issues and the programming issues can then be addressed together. Expected and unexpected contingencies can be identified, evaluated, and mitigated.

To the dismay of some, using smart contracts on a blockchain won’t eliminate the need for lawyers. More likely it will just change what the lawyers need to do.

We predict this new type of due diligence will bring together specialized transactional lawyers who can review the terms of a specific deal, software experts who can analyze smart contract program code and its operation on the blockchain, and ‘smart contract’ lawyers who can bridge the gap between the two.

Obviously, the due diligence team should be engaged well before a smart contract is added to the blockchain – even before the underlying deal is negotiated – to help avoid foreseeable mistakes. By conducting this new type of due diligence with the proper team, smart contracting parties can have much more confidence in achieving their intended results.

More rigorous smart contract due diligence may finally bring some peace of mind.