Smart Contract Basics — A Legal Contract Perspective Part II: Verifiability
Part II: Verifiability
Introduction
Continuing with Part II this week, the second contractual design for smart contracts is verifiability: the “ability of the principals [of the smart contract] to prove to an arbitrator that a contract has been performance or breached” or for the arbitrator to determine if performance/breach of the smart contract has occurred.[i] As a refresher, smart contracts are “a consensual arrangement between at least two parties…an automated, independent commercial result from the satisfaction or non-satisfaction, determined objectively through code, of a specific factual condition.”[ii] Once the parties have agreed to the terms of the smart contract and performance has commenced, the parties will need to verify that they, and the opposing party, are keeping to the explicit terms of the agreement.
Verifiability relies on two underlying themes: (1) open access to information by the arbitrator and (2) the parties honoring their obligations to provide such information. Access to performance information is necessary for the arbitrator to verify performance has occurred; it requires open access by the arbitrator or reliance on the parties to push data to the arbitrator. Honoring obligations to provide relevant data to the arbitrator is also necessary given the secure and decentralized nature of a blockchain. Overall, verifiability requires performance data to be openly shared amongst the parties, especially the arbitrator, in order for smart contracts to act as legitimate agreements between parties.
Verifiability and Identity
In traditional contracts, it is easy for the contracting parties to determine performance, or non-performance, by the other party. Using an example from my previous article in this series (available here), if a contract requires a package to be delivered by a company by 2:00 P.M., it is easy for the receiving party to determine if performance has occurred. Likewise, it is easy for the parties in this contract to enter a dispute with an arbitrator. If the package arrives late or damaged, the parties can enter into a formal dispute to decide who is responsible for the costs of replacing the contents of the package.
Smart contracts present a novel issue for verifying and arbitrating between parties because of the decentralized nature of blockchain technology, what is considered the “digital divide” between the parties. Smart contract parties never come face to face, so it is difficult to verify identities and build trust like what occurs in a traditional contract. For example, while a homebuyer may never “see” their bank, it is relatively easy for a homebuyer to verify the identity of a large U.S. bank to secure their home mortgage. In large part, we use contracts because they are “designed to reinforce trust and reduce risk” between trusted parties with verifiable identities and performance.[iii]
In comparison, a smart contract relies on unconfirmed, hard-to-verify parties. While normal contracts generally allow for a certain level of trust between the parties, Blockchain technology is “tamper-free, an assumption that requires a sufficiently untrusted peer” (emphasis added).[iv] Smart contracts do not rely on a single input of data for verification, such as traditional databases. A traditional database “uses a client-server architecture…control of the database remains with a designated authority, which authenticates a client’s credentials.”[v] However, the decentralized architecture of a blockchain seeks to remove the critical flaw of central databases; “since this authority is responsible for administration of the database, if the security of the authority is compromised, the data can be altered, or even deleted.”[vi]
To demonstrate the difficulty in verifying identities, think about a verifiable identity characteristic such as a bank pincode, which is stored in a central database. When a customer uses their code at an ATM to withdraw money, the ATM verifies the pincode entered with the value stored in the database. Smart contracts utilize a different process of verification “with minimal reliance on centrally provided systems or services.”[vii] Thus, verifiability in a smart contract is theoretically more secure than traditional means of verification since a blockchain cannot be altered or deleted.
Notwithstanding verifying the identities of the parties, which will be discussed in a later article, the term verifiability is mainly concerned with how the parties to a smart contract can enter into arbitration proceedings to resolve conflicts. So, how does arbitration for smart contracts work?
Arbitrating Smart Contracts
Arbitrating smart contracts is a relatively new field of law with limited understanding of how traditional legal precedents operate in the realm of blockchain technology. Several law firms and other commentators have offered some guidelines that have formed the foundation to legitimize and verify smart contracts through arbitration proceedings. What is consistent amongst the sources is an agreement that “disputes can and will arise” between parties in smart contracts.[viii]
One of the primary suggestions to allow for verifiability is to draft a dispute resolution clause into the smart contract code. Similar to a dispute resolution provision in a traditional contract, “it is vitally important for the parties to agree on how and where disputes are to be resolved…without consensus there is an enormous scope for disputes…particularly where decentralized organizations run on a blockchain housed on servers in different countries.”[ix] The decentralized and irreversible design of blockchain technology makes it difficult for disputes to be resolved without explicit agreement between the parties. An article written by Herbert, Smith & Freehills LLP perhaps illustrates this issue best; “the irreversible nature of the blockchain makes it crucial that any self-enforcing aspects of parties’ agreement are anchored within a valid legal framework and that the parties identity at the outset the applicable dispute resolution mechanism.”[x]
Once a dispute arises between parties to a smart contract, arbitration is generally handled in the traditional way: by human operators. For those non-lawyers, “arbitration is a method of resolving disputes outside of courts” where “parties refer their disputes to an arbitrator who reviews the evidence, listens to the parties, and then makes a decision.”[xi] This arbitrator is a neutral third party, generally a lawyer who specializes in serving as an arbitrator for specific categories of disputes or in certain industries. The parties would retain an arbitrator and their respective counsels to decide the result of the dispute without entering the formal court legal system.
Intuitively, it would seem smart contracts might have some automated arbitration that sits within the same blockchain? However, smart contract disputes still rely on decidedly traditional means of arbitration, with some innovations. As most commentators on the issue have made clear, “‘you cannot eliminate the bespoke legal work and analysis that attorneys do with codes and with algorithms,’” a neutral human arbitrator is still needed to resolve complex disputes.[xii] Smart contract arbitration still offers efficiency for smart contract parties despite the human influence, particularly its speed and flexibility. Arbitration often takes a fraction of the time a court case and additionally “arbitration’s flexibility provides a neutral venue to enable parties to efficiently resolve disputes, wherever they are located.”[xiii]
Some services have been developed to fulfill the necessity of arbitrators for smart contract disputes. One entrant is CodeLegit, a software that operates a “smart contract arbitration library” which allows the parties which store contracts in that library to “pause, resume, modify and end a smart contract” as well as “connects the software with human beings acting as arbitrators.”[xiv] This eco-system model utilizes codified blockchain arbitration rules to resolve disputes by first instituting a grace period that pauses execution of the smart contract before full performance has been rendered and consideration exchanged.[xv] The arbitrator then has time to collect information and make a decision, which then causes the smart contract to be terminated, continued or modified.[xvi]
Despite new smart contract arbitration techniques, verifiability still relies on open access to information regarding the parties’ performance and the parties honoring their obligations to provide such information to the arbitrator.
Access to Information
For the arbitrator to settle a dispute between the smart contract parties, the arbitrator must have access to the information required to verify their performance. While this sounds intuitive, smart contracts make the process of accessing information personal to each party very difficult. Beyond the issue of confirming the identity of the parties as discussed earlier, the arbitrator must verify performance information often contained outside of the blockchain. Sources of such performance information can be elsewhere in the blockchain, from a 3rd party oracle (see my previous post for a discussion on oracles) or from other sources. This present two dilemmas: how does the arbitrator get access to such information to consider in their review of performance and how much information is enough for a decision?
As discussed in detail in Part I: Observability of this series, access to information related to performance is difficult to obtain due to the secure design of a blockchain.[xvii] Getting performance data such as when a delivery has been made or even weather data requires some third party to either push or pull that information on to the blockchain network.[xviii]
For verifiability to be satisfied by a smart contract, the arbitrator needs to gain access to the performance data, in effect collecting enough evidence to make a decision. The arbitrator needs two distinct sets of information: information referred to as “off-chain elements” and access to a “plain-English version of the contract…for human arbitrators to understand [the smart contract].”[xix] This sounds simpler that it is operationally; the parties would have to either give the arbitrator access to their data (such as their shipping data or other metrics) or allow the arbitrator to “dig around” in their systems to find enough data to make a decision. Both are invasive forms of information gathering for parties who, presumably, chose smart contracts as a safe, secure and non-intrusive method of contracting.
Thus, parties utilizing smart contracts should first decide whether they want to allow for arbitration by drafting dispute resolution provisions into the smart contract’s code. Secondly, parties should understand that if arbitration proceedings occur, both parties should be able and willing to provide the necessary information to the arbitrator.
Honoring Obligations
In addition to the arbitrator gaining access to the performance-related data, the parties to a smart contract must honor their obligations to provide relevant information to the arbitrator. Given the decentralized nature of blockchain technology, information held by individual parties to a smart contract is secure from all other parties, including 3rd parties acting as arbitrators.
As some commentators like to point out, “at the end of the day, ‘smart contracts’ are neither smart nor contracts,” because they exist to automatically execute finite computational operations between two parties on a blockchain.[xx] They are not (at least yet) held to the same standard as a contract written on paper would be, especially in the eyes of a court.[xxi] In effect, the parties utilizing smart contracts are reliant on the other party honoring the transaction’s theoretical authority and legitimacy. If arbitration is to occur between parties, both must be willing participants in the matter if the smart contract has already begun, partial performance has been rendered, or especially if the contract has already been executed and consideration exchanged.
Similar to a subpoena for records by a party in an actual trial, smart contract parties may be asked by an arbitrator to submit information for consideration as evidence to the dispute. However, unlike a legally-enforceable subpoena, there are no laws or statutes governing a smart contract party’s requirement to disclose requested information. Nor are there any laws governing punishment for parties who refuse to turn over the information to the arbitrator. While some may argue this loophole makes smart contracts unverifiable, it is still to be determined whether more advanced codes or arbitration standards may fill the gap for smart contracts to be satisfy the verifiability standard.
Honoring Obligations
Verifiability of smart contracts continues to be one of the more complex legal issues surrounding the use and legitimacy of smart contracts. Verifying identities, retrieving data and enforcing arbitration provisions on parties will be at the forefront of the legal industry’s push to understand and service smart contracts in the future. Check back next week for the third installment of this series, Part III: Privity.
About the Author
Jared Arcari is a third year law student at Fordham University School of Law. Jared currently serves as the president of two student organizations, the Fordham Business & Law Association and the Entrepreneur Law Society. He is also a Notes & Articles Editor at the Fordham Journal of Corporate and Financial Law. When he isn’t writing about blockchain-related legal issues, Jared enjoys serving as a research assistant to prof. Bernice Grant researching entrepreneurial topics including non-compete alternatives and improving access to capital. To contact the author, please email him at jarcari@law.fordham.edu.
Disclaimer
Any information contained in this post is for informational purposes only. The information, opinions and commentary contained herein does not constitute legal advice. It also does not constitute tax advice. This post is not a complete overview or analysis of the topics presented and may contain information that varies in different jurisdictions. The transmission of information to the reader does not create a lawyer-client relationship. The reader should not rely upon this post or treat it as a substitute for legal advice. The reader should consult a lawyer familiar with their particular circumstances and licensed in the proper jurisdiction for legal advice.
[i] Nick Szabo, Smart Contracts: Building Blocks for Digital Markets (1996), http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html (last visited July 10, 2018).
[ii] David M. Adlerstein, Are Smart Contracts Smart? A Critical Look at Basic Blockchain Questions, CoinDesk (June 26, 2017), https://www.coindesk.com/when-is-a-smart-contract-actually-a-contract/.
[iii] Deepak Malhotra, When Contracts Destroy Trust, Harv. Bus. R. (May 2009), https://hbr.org/2009/05/when-contracts-destroy-trust.
[iv] Oz Nathan & Guy Zyskind, Decentralizing Privacy: Using Blockchain Personal Data, IEEE CS Security & Privacy Workshops, 180, 182 (2015), http://homepage.divms.uiowa.edu/~ghosh/blockchain.pdf.
[v] Shaan Ray, Blockchains Versus Traditional Databases, Hackernoon (Nov. 5, 2017), https://hackernoon.com/blockchains-versus-traditional-databases-c1a728159f79.
[vi] Id.
[vii] Smart Identity: SmartId-Contracts, GitHub (Aug. 4, 2017) https://github.com/SmartIdentity/smartId-contracts#what-is-smart-identity.
[viii] James Rogers, Harriet Jones-Fenleigh & Adam Sanitt, Arbitrating Smart Contract Disputes, International Arbitration Report — Norton Rose Fulbright LLP, 21–24 (Oct. 2017), http://www.nortonrosefulbright.com/knowledge/publications/157162/arbitrating-smart-contract-disputes.
[ix] Lee Bacon, Nigel Brook & James Contos, Arbitrating Smart Contract Disputes: Will Smart-Contracts Require Smart Arbitration?, (July 11, 2016), https://www.clydeco.com/insight/article/arbitrating-blockchain-disputes-will-smart-contracts-require-smart-dispute.
[x] Craig Tevendale & Charlie Morgan, Blockchain and Smart Contracts: Novel Opportunities for Improving Efficiency in Contract Execution and Dispute Resolution (Feb. 21, 2018), https://www.herbertsmithfreehills.com/latest-thinking/blockchain-and-smart-contracts-novel-opportunities-for-improving-efficiency-in.
[xi] Barbara K. Repa, Arbitration Basics, NOLO Legal Encyclopedia (2018), https://www.nolo.com/legal-encyclopedia/arbitration-basics-29947.html (last visited July 8, 2018).
[xii] Caroline Simson, Arbitration Uniquely Situated to Benefit from Blockchain, Law360: Analysis (Mar. 29, 2018), https://www.law360.com/articles/1027899/arbitration-uniquely-situated-to-benefit-from-blockchain.
[xiii] The Rise of Blockchain Arbitration, Aceris L. LLC (Mar. 3, 2018), https://www.acerislaw.com/the-rise-of-blockchain-arbitration.
[xiv] Michael Reuter, CodeLegit Conducts First Blockchain-based Smart Contract Arbitration Proceeding, CodeLegit Blog (Jul. 16, 2017), http://codelegit.com/2017/07/16/codelegit-conducts-first-blockchain-based-blockchain-arbitration-proceeding/.
[xv] See id.
[xvi] See Markus, How Smart Contract Arbitration Works, CodeLegit Blog (June 24, 2018) http://codelegit.com/2017/06/24/how-smart-contract-arbitration-works/.
[xvii] See Jared I. Arcari, Smart Contract Basics — A Legal Contract Perspective Part I: Observability, Medium: Fordham Bus. L. Ass’n. 3 (July 5, 2018), https://www.scribd.com/document/383170212/Smart-Contract-Basics-a-Legal-Contract-Perspective-Part-I-Observability.
[xviii] See id.
[xix] Federico Ast, A Smart Contract Law Standard for the Internet Age, Medium: Kleros (Oct. 19, 2017), https://medium.com/kleros/a-smart-contract-law-standard-for-the-internet-age-c3512a357f46.
[xx] Andrew Glidden, Should Smart Contracts be Legally-Enforceable?, Medium: Blockchain at Berkeley (Feb. 27, 2018), https://blockchainatberkeley.blog/should-smart-contracts-be-legally-enforceable-599b69f73aea.
[xxi] See generally Jared I. Arcari, Smart Contracts: Error! Code Note Found!, Medium: Fordham Bus. L. Ass’n. 6–8 (June 26, 2018), https://www.scribd.com/document/382567586/Smart-Contracts-Error-Code-Not-Found.
