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.
In this article, Mlynar and
Schaefer examine the issues that can arise when recording smart contracts
in an immutable system and raise the need for enhanced due diligence before any
transactions are written in "blockchain stone".
Disclaimer: The views expressed in this article are
those of the authors and do not necessarily represent the views of, and should
not be attributed to, their firm, its clients, or any respective affiliates.
This article is for general information purposes only. It is not intended to
be, and should not be taken as, legal advice.
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.
Auditing image via Shutterstock
Disclaimer: The views expressed in this article are those of
the author and do not necessarily represent the views of, and should not be
attributed to, CoinDesk.
No comments:
Post a Comment