A Guidebook to Arbitrating Disputes Involving Blockchains and Smart Agreements
Part 2 of 3
Where the Disputes Lie: When Blockchain Technology Will Need Help Sorting Out Its Contracts
PETER L. MICHAELSON & SANDRA A. JESKIE
In Part 1 of this article, the authors introduced the types of agreements that u blockchain technology at “A Guidebook to Arbitrating Disputes Involving Blockchains and Smart Agreements. In Part 2, the authors continue their discussion of the types of agreements using Blockchain Ledger technology by completing their introduction with an examination of smart agreements. Then, they move on to the disputes that can ari, and the issues of jurisdiction, enforceability, and antitrust, ahead of Part 3 with its conclusion and focus on the resolution mechanism, arbitration.
****
Becau smart agreements are bad on code, they are, by their very nature, inflexible and incomplete. They are neither designed for general u, nor are they suited for it.
If smart agreements are, as some in the field ascribe them to be, “immutable, unstoppable, and irrefutable computer code,” that code must declare what will happen as a result of every possible contingency that might occur during the life of the contract.11月11日是什么星座>青铜器纹样
Inflexibility results becau the code is completely deterministic, embodying predefined rules typically reduced to codified “if-then-el” conditional programming statements. Any conduct by the parties that does not fall within the rules is simply ignored.
Conquently, the u of smart agreements is usually limited to situations where parties, at the outt of their transactions, can anticipate every contingency that might ari affecting their contractual performance. The underlying transactions tend to be relatively simple, as their performance is predicated only on whether particular conditions are satisfied or not, which, in turn, can be easily translatable into rule(s) of performance that can be readily codified.
But, for many legal contracts that are less simplistic, contractual performance is not so easily assd becau it is not simply a question of whether predefined conditions have been objectively satisfied or not. Rather, for tho contracts asssing performance calls for a determination that requires some degree of human subjectivity.
Specifically, the parties or an adjudicator may need to subjectively asss the effect on the parties’ contractual rights and obligations resulting from an intrinsic or extrinsic contingency that occurred and/or prior conduct by one or more of the parties.
汤圆怎么煮好吃In tho situations, significant portions of the parties’ agreement cannot be coded, as they are encompasd by non-deterministic concepts and general claus, such as good faith, reasonableness, intent, excud performance, and many others, which collectively form the foundation of contract law. Pietro Ortolani, The impact of blockchain technologies and Smart Contracts: arbitration and court litigation at the crossroads, 24(2) Uniform L. Rev. 438 (June 2019) (available at bit.ly/3t04zwX). Conquently, the legal agreements, by their very nature, are inappropriate for codification and implementation as smart agreements.
Further, for many such less-simplistic legal contracts, deterministic completeness is unattainable. In practice, it is often extremely difficult, if not impossible, for contract drafters, dealing with anything other than relatively simple, straightforward transactions, to anticipate every such contingency that might possibly ari, no matter how small its probability of occurrence.
Conquently, many commercial legal contracts are incomplete. By leaving certain contingencies an
d hence their outcomes undefined, the drafters introduce, whether intentionally or not, ambiguities and gaps into commercial legal contracts for later resolution.
Oftentimes, it is simply too costly to proceed otherwi. Parties may also recognize and intentionally retain ambiguities and gaps in their legal contracts so that, if a corresponding situation aris later, the incompleteness can be exploited in a way that results in a better contract for them, ex-ante.
Renegotiation is a common way that ambiguities are resolved and contractual gaps filled. Larry D. Wall, “`Smart Contracts’ in a Complex World,” Notes from the Vault, Federal Rerve Bank of Atlanta (July 2016) (available at bit.ly/2M1lheY). Parties need some degree of flexibility in resolving contractual incompleteness that avoids locking themlves into rigid commitments and outcomes which they did not anticipate and do not want. Houman B. Shadab, What Smart Contracts Need to Learn, Lawbitrage (Sept. 4, 2014) (available at bit.ly/2KWfuXq).
Conquently, for other than relatively simple, completely deterministic transactions, it is quite possible that the code in smart agreements will fail to reflect some contingencies. Code is not subject to renegotiation. Smart agreements, once they are embodied into code, are fixed. If parties decide to modify their smart agreement, they then need to change its code accordingly.
Some smart agreement adherents vociferously advocate that “The Code is Law”--i.e., that the code itlf is the ultimate arbiter of a deal it reprents, a standalone, lf-enforcing agreement not subject to interpretation by outside entities or jurisdictions. David Siegel, Understanding the DAO Attack, Coindesk (June 25, 2016) (available at bit.ly/2LZUdwB).
赛螃蟹的做法
Yet, what happens in a smart agreement if an unanticipated (non-coded) contingency occurs? Does the contract just assume a default or error state, pending some human intervention to clear that state—which lies directly contrary to the autonomous, lf-executing nature of a smart agreement? Should the contract simply report that event to the blockchain and then ret itlf once that event ceas and then return to normal execution?
At prent, there are no definitive answers. When such a situation aris—as with, e.g., the DAO exploit (discusd below)—an errant result can flow from execution of a smart agreement which, in turn, could lead to a dispute between the contracting parties with potentially significant attendant legal liability. Likely Disputes
Bill Gates famously said, “Software is a great combination between artistry and engineering.” But like artistry and engineering, perfection is illusive".
清的成语
Smart contracts are nothing more than software code written by humans, and are therefore imperfect by their very nature. Any number of issues could ari in the design, development, or execution of software code, and smart agreements are not immune to such problems. A few of the more common technical issues associated with smart agreements are briefly discusd below.
Technical Issues: Design Flaws--Software design is the process by which a programmer translates ur requirements into software code. A flawed software design will likely lead to unexpected results and, sometimes, catastrophic conquences.
Sadly, a design flaw in the software for a new flight-control system on the Boeing 737 MAX plane was responsible for veral plane crashes killing 346 people. David Slotnick, “The DOJ is reportedly probing whether Boeing’s chief pilot misled regulators over the 737 Max,” Business Insider (Feb. 21, 2010) (available at bit.ly/3opXFgS).
Another design flaw that caught widespread attention occurred when a smartphone application developed for the Iowa Democratic Party was rushed into u with technical and design flaws that caud a significant delay in reporting Iowa 2020 presidential caucus results.Ben Popken & Maura Barrett,
滔滔不绝的近义词是什么“Iowa caucus app was rushed and flawed from the beginning, experts say,” NBC News (Feb. 5, 2020) (available /36kIdfQ).
While it is unlikely that most design flaws in a smart agreement could have such tragic or newsworthy conquences, such a flaw could result in significant financial loss and complex business disputes, among other things.
Flaws could occur anywhere in the design, such as in the underlying algorithms or the communications protocol. No matter what the cau, design flaws can lead to significant issues and therefore liability on any number of theories, such as negligence, product liability, or breach of contract resulting from injury to a participant or third party proximately caud by a defect in a smart agreement.
To mitigate risks, appropriate steps should be taken both during the development and the coding of smart agreements to prevent, detect, and remediate design flaws and coding errors. Further mitigation can be achieved by the procurement of adequate insurance coverage against any potential residual exposure.
Potential liability can also ari when smart agreements are operated beyond their design limits, i.e.,
under conditions that were not contemplated, particularly where they invoke unintended, possibly even adver, results. While the underlying code itlf may not be flawed, the design, in not accommodating and properly handling such extreme conditions, may contain flaws.
Technical Issues: Coding Errors/Bugs--As blockchain technology begins to permeate every industry, the importance of smart agreements will increa dramatically with the underlying software code supporting tho smart agreements eventually controlling billions of dollars of digital asts. Kai Sedgwick, “The Billion-Dollar Quest to Eliminate Smart Contract Bugs,” (July 12, 2018) (available at bit.ly/3iT5aft).
小虫儿
While software development has existed for decades, development platforms for Smart Contract code were only developed in 2015, with software ecosystems and standardization efforts being developed through, for example, the Accord Project and the GLBC, respectively, having started just within the past few years.
Becau the platforms have only been in existence for a short time, there are no handbooks for software developers to u in coding smart agreements, and particularly Smart Contracts. Yos Riady, Best Practices for Smart Contract Development (Nov. 10, 2019) (available at bit.ly/39nY
hzp). The development of smart agreements and associated development platforms and related software tools are still in their embryonic stages.
While tho platforms are likely to mature quickly, no matter what the technology, coding errors can and will happen, and the risk associated with such errors increas as the code complexity increas. Like design flaws, coding errors may lead to unexpected conquences and attendant legal liability.
It is currently estimated that the amount of cryptocurrency lost to coding errors is quickly approaching $1 billion. The most well-known episode involves “The DAO” exploit, discusd below.
The DAO Incident--Distributed Autonomous Organizations, or DAOs, are early-stage investment funds that lack a manager. A DAO is run by programming code and constitutes a collection of Smart Contracts operating independently of any human intervention, as long as funding covers a DAO’s survival costs and provides a uful rvice to its participant ba.
[Ethereum is a global, open source, blockchain-bad distributed computing platform and operating system (so-called Ethereum Virtual Machine), featuring Smart Contract functionality, for building decentralized applications. While blockchains can process code, most are verely limited in what th
ey can do. Rather than providing a limited t of operations, the Ethereum Virtual Machine allows developers to create whatever applications they want on the Ethereum network, including, e.g., DAOs. See Blockgeeks, What is Ethereum? (available at bit.ly/2YXC1X5).]
An initial funding period exists during which a DAO's participants add funds, typically through what is referred to as a “crowd sale,” to provide the DAO with operating resources. Investors vote on which projects to fund, with the code implementing the Smart Contracts doing the rest.
On April 30, 2016, a particular DAO called “The DAO” was launched with a 28-day funding window. It raid more than $150 million from more than 11,000 participants.
In June 2016, one of its participants exploited a known vulnerability in The DAO’s code and drained about $53 million from The DAO into an account the person controlled. The specific error in the code was known to The DAO’s creators, but it was not remedied in time to prevent the error from being exploited.
The appropriate respon to the attack created an interesting dilemma. If “the code is the law,” as some Smart Contract proponents asrted, what happened was perfectly legal becau the code executed as it was intended.
As such, some participants in The DAO took the position that the transfer did not violate the Smart Contract itlf and, instead exploited a code vulnerability. Other participants felt their funds had been stolen and allowing the attack to stand would discourage participants from making future investments.
Ultimately, the Ethereum organization, which implemented the code, voted to restore the funds to the original investors. Since an error existed in the code, The DAO sought to renegotiate the terms—notwithstanding the fact that renegotiation is arguably contrary to the fundamental notion of Smart Contracts.
Technical Issues: Security Vulnerabilities--Smart agreements are often designed to manipulate and hold funds denominated in Ether, a payment mechanism for Smart Contracts’ transactions, making them tempting targets becau a successful attack would result in stealing funds from the contract. Daniel Perez & Benjamin Livshits, ‘Smart Contract Vulnerabilities: Vulnerable Does Not Imply Exploited” arXiv:1902.06710 [cs.CR] (October 2020) (available at bit.ly/3rB2Z30). While exploited vulnerabilities have captured headlines and imaginations, recent academic rearch reported that, out of 21,270 vulnerable Smart Contracts, at most only 504 have been subjected to exploits, likely due to the fact that a majority of Ether is held by only a small number of contracts. Ibid.
While the number of exploited vulnerabilities may be relatively low currently, as the technology becomes more widely accepted and more money is exchanged through smart agreements, there can be little doubt that vulnerabilities will be substantially exploited. Such vulnerabilities will therefore expo parties directly or indirectly responsible for the problem to liability, including developers, contract administrators, or the entity that hosted the contract.
Technical Issues: Privacy--Information stored on a Blockchain Ledger may identify aspects of a ur’s identity and include financial, medical, or consumer personal information. Care must therefore be taken to ensure compliance with applicable privacy laws.
Over the past few years, there have been a proliferation of new privacy laws, each one placing more emphasis on the right of consumers to protect their own personal information. The General Data Protection Regulation, or GDPR, addressing data protection in the European Union and the European Economic Area, and the California Consumer Privacy Act, or CCPA, addressing personal information of California consumers, are recent additions to ever-expanding privacy regulations.
Both GDPR and CCPA expansively define “personal information” to include information that directly or indirectly identifies a person and therefore could impo significant obligations, as well as risk, on
Blockchain Ledger administrators to ensure that personal information is properly cured.
GDPR and CCPA also prent interesting questions about how an individual who personal information appears on a Blockchain Ledger can exerci his or her right to have that personal information deleted (also known as the “right to be forgotten” under GDPR).
By 2023, Gartner predicts that 65% of the world’s population will have its personal information covered under modern privacy regulations, up from 10% in 2020.Susan Moore, Gartner Predicts for the Future of Privacy 2020, Smarter with Gartner (Jan. 20, 2020) (available at gtnr.it/3cTPaZr). As such, privacy and curity of personal information on a Blockchain Ledger and/or associated with Smart Contracts could po a significant liability.
Consideration should also be given to whether the Smart Contract is stored on a public, private or hybrid blockchain. Public blockchains are visible to all urs, while private blockchains are permission-bad and visible only to persons or entities with appropriate permissions.
Another option is a hybrid blockchain that includes both public and private aspects. Decisions regarding the storage of a Smart Contract on a public, private, or hybrid blockchain may depend on the nature of the information stored.
Jurisdiction, Enforceability, Antitrust
室外台阶高度Jurisdiction--Blockchains prent a unique jurisdictional challenge that may bar lawsuits that directly involve them. To date, while a small number of lawsuits has been filed that implicate blockchains, the related mainly to claims of curities fraud and misreprentation in the public sale of initial coin offerings, or ICOs, where the ICOs were to be implemented on blockchains. See, e.g., In re Tezos Sec. Litig., No. 17-CV-06779-RS, 2018 WL 2387845 (N.D. Cal. May 25, 2018) and related litigations Baker v. Dynamic Ledger Sols. Inc., No. 17-CV-06850-RS, 2018 WL 656012 (N.D. Cal. Feb. 1, 2018); MacDonald v. Dynamic Ledger Sols. Inc., No. 17-CV-07095-RS, 2017 WL 6513439 (N.D. Cal. Dec. 20, 2017); Okusko v. Dynamic Ledger Solutions Inc., Ca No. 17-cv-6829; GGCC LLC v. Dynamic Ledger Sols. Inc., No. 17-CV-06779-RS, 2018 WL 1388488 (N.D. Cal. Mar. 16, 2018); e also, e.g., Renl v. Centra Tech Inc., 17-cv-24500-JLK (S.D. Fla.); Hodges v. Monkey Capital LLC, 17-81370 (S.D. Fla.); Balestra v. ATBCOIN LLC, 17-10001 (S.D.N.Y.); Stormsmedia LLC v. Giva Watt Inc., 17-00438 (E.D.Wash.); Davy v. Paragon Coin Inc., 18 00671 (N.D. Cal.). Also, for SEC concerns regarding ICOs, v/ICO.
The authors are not prently aware of any lawsuits that yet exist directly concerning transactions that occurred on blockchains themlves or issues surrounding execution of the blockchains theml
ves, though it is fair to predict that such lawsuits will occur eventually.
For an adjudicator, whether a court or an arbitral tribunal, to consider and rule on a dispute, it is canonical law that the adjudicator must be ized with jurisdiction: over the parties for in personam jurisdiction or over an object for in rem jurisdiction. In either instance, the location of the person or object determines whether jurisdiction aris.
A blockchain is a decentralized structure of information: stored bits of information (code and data) effectively disburd over many different “locations,” as is an entire blockchain infrastructure implemented as “blockchain-as-a-rvice.”
One cannot point to a blockchain or reach out and touch it as it is not physical; it is a data structure, nothing more. It has no physical prence. It is not a physical object. It is an abstraction: a collection of either the prence or abnce of electronic charges in parate memory locations respectively reprenting binary “ones” and “zeroes” typically accesd by virtualized rvers that execute blockchain code and process its data, all residing, often piecemeal, somewhere in a cloud or even across multiple interconnected clouds. Even a virtualized rver is nothing more than an abstraction: computer code that, when executed, collectively emulates a physical rver.
[See the accompanying article by the authors, Key Issues in Arbitrating Disputes Involving Blockchains and Smart Agreements, on page XX. But as the concept of hardware virtualization is well beyond the scope of this paper, it will not be addresd in any detail. For further insight, the reader is referred to virtualization software providers, such as VMWare Inc. () and Microsoft Corp. (/en-us/windows-rver/virtualization/virtualization).] That code, too, can be stored and executed virtually anywhere on a cloud, or even, like any code, transferred from storage in one location to another so that, rather than executing on one physical host computer, it will execute on another, perhaps half a world away. Hence, the traditional notion of a “location,” as a physical situs of a person or an object and upon which adjudicators asss jurisdiction, has no meaning for a blockchain.
Conquently, traditional physical measures of national court jurisdiction would fail. Abnt an agreement by the parties conferring jurisdiction on a particular court, no national court could exert requisite physical jurisdiction over a blockchain.
