February 8, 2019
Smart Contracts
BY: Scott A. Nerlino
It’s all the rage. Bitcoin this. Blockchain that. And now, Ethereum smart contracts are gaining steam. According to David Petersson in a recent Forbes article, “Due to its open nature, and due to the fact that the contract code is known in advance and it cannot be changed or altered by malicious actors, many suggest that smart contracts could replace traditional contracts. Smart contracts are fast, they execute immediately and autonomously and there is no way any party could influence it.” It sounds great, but what are the nuts and bolts of a smart contract? The following is a short primer to help get you started on the subject as smart contracts start to become real contracts. Since Ethereum is widely used, we will look at their implementation.
The History
One of the first descriptions of a smart contract was written by Nick Szabo in 1996. He conceived of a technology protocol which could be automatically executed upon the successful completion of established conditions. The typical use case in this model goes something like this: Contractor A agrees to install a roof for Person X. At the completion of Phase 1, Phase 2, and Phase 3 of the work, a payment of one-third of the total price will be made from Person X to Contractor A. The goal of a smart contract, assuming a definition of completion for each Phase, is to automate the payment upon the completion of the conditions.
The technology first became available in 2008 when the Bitcoin Blockchain white paper was released. The creation of an immutable decentralized ledger was the missing piece of technology. That is, a record of transactions that cannot be altered and can be stored amongst other computers which can then validate if a transaction is valid and, if so, store the new transaction. Five years later, the Ethereum platform was born, combining blockchain and Szabo’s vision.
Inner Workings
Ethereum Smart contracts are written in a programming language called solidity. This language expresses the actions of the contract in a way that can be executed by a computer; typically smart contracts do not include boilerplate language. As an example, consider a smart contract representing a blind auction and the function to handle the end of the auction:
- function auctionEnd() public {
- require(now >= auctionEndTime, “Auction not yet ended.”);
- require(!ended, “auctionEnd has already been called.”);
- ended = true;
- emit AuctionEnded(highestBidder, highestBid);
- beneficiary.transfer(highestBid);
}
Let’s look at the actual lines of code and what they do. Line 1 declares that a block of code is to be executed. Lines 3 and 4 are preconditions to the end of the auction, in this case that the time for the auction has elapsed (3) and that the auction has not already been ended before to prevent the contract from being executed multiple times (4). The line 6 declares the contract ended, line 7 notifies everyone that the auction has ended, and finally line 9 transfers the highest bid to the appropriate party.
Unresolved Questions
There are many more facets to smart contracts, but what we have discussed so far can lead us to a few questions that will likely soon be tested in the courts. Let’s start with Virginia Rules of Professional Conduct Rule 1.1:
Competence
A lawyer shall provide competent representation to a client. Competent representation requires the legal knowledge, skill, thoroughness and preparation reasonably necessary for the representation.
In order to argue a case about a contract, it is necessary to understand the contract. In the case of a standard contract we are tasked with understanding the meaning of word written in the English language and the grammar associated it. But in the case of a smart contract, the language is not exactly English. This scenario begins to approach the situation of asking a court to interpret a contract in a foreign language, which can be very challenging for many lawyers and judges. Will it become necessary to understand the basics of programming for a lawyer to take this case or a judge to hear it?
A similar question arises when the parties don’t understand the exact terms of the contract. Can a doctrine of mutual and unilateral mistake apply to software that is testable? In other words, since a coder can test their code, if that coder writes a contract for a business which is then used with another party, who made the mistake? Does it matter whether the coder is an employee of the business? What happens when there is perfectly functional code and both parties agree that they looked it over and agreed to it, but it wasn’t what they meant? What if the code isn’t entirely functional, such as if the auction could close multiple times or take bids after it closes?
Is a mistake such as an incorrect closing date considered a scrivener’s error? Should the contract be interpreted against the drafter given that there is likely to be an even bigger disparity in knowledge between the general public and the business drafting it than in a typical contract?
Conclusions
I’ll leave the questions for the reader because I believe there are multiple ways the courts could come down on the issue. It’s very likely that one of you could wind up drafting the first arguments over this emerging issue. There is no question the law must adapt as we enter a new world of efficiencies and technology. This is just a minuscule window into a gigantic new world; will you be ready?