Part 4: Web3 Smart Contracts
This is the fourth in a series of articles on Web3.
A smart contract is a program stored on a blockchain that runs when a predetermined condition is met. In other words, it's just like any piece of software that stored on a computer except that it operates in the context of a blockchain. The table below outlines some of the characteristics of a smart contract.
Smart Contract Operation
To understand a smart contract, it helps to walk through its operation. Two parties agree to terms and code them into software. That software is then committed to a blockchain. The program below is an example of a simple escrow smart contract. ?
A smart contract cannot self-execute. It sits on the blockchain until it is triggered to run by either an on-blockchain event, such as a royalty payment from an NFT sale, or, in the case of a real-world event, by a trusted 3rd party called an ‘oracle.’ Once run, the smart contract can only directly affect things on the blockchain. In the case of that NFT royalty payment, the smart contract can transfer cryptocurrency tokens between parties on the blockchain. For real world events, a trusted authority called a ‘listener’ waits for a message from the smart contract before authorizing, say, a movement of inventory.
Smart contracts are the ultimate embodiment of the ‘Code is Law’ school of thought where business interactions can be reduced to pure programmatic transactions. Execution is encoded in an immutable program. No central authority can intervene in these transactions. Business runs with the precision and certainty of a Swiss watch. Advocates list the following benefits of a smart contract:
In reality, none of these are absolutely true.
Ambiguity
Nearly everything that happens in the real world has some level of ambiguity. Consider the seemingly obvious word ‘chicken’ and the case of Frigaliment Importing Co. v. BNS International Sales Corp.
‘[The] contract called for the delivery of 100,000 pounds of “US Fresh Frozen Chicken, Grade A, Government Inspected, Eviscerated.” The buyer thought that chicken" meant “a young chicken, suitable for broiling and frying.” The seller thought it meant “any bird of that genus.” The court considered dictionary definitions, the text of the contract, the parties’ negotiations (in a mixture of English and German), evidence of trade usage in the chicken-evisceration industry, USDA inspection standards, and prevailing market prices, only to conclude that there was evidence on both sides ...’ In short, “chicken” was ambiguous.’ James Grimmelmann, All Smart Contracts are Ambiguous, J.L. & INNOVATION 2: 1, 10 (2019).
Fortunately for a programmer tasked with reducing this transaction to code, no smart contract can inspect a shipment of chickens to see if they’re young, old or middle-aged. This is left to an inspection process, which as we’ve seen, lives in the real world full of ambiguity. Any definitional dispute will land the Frigaliments of the world back in the courts, smart contract or no.
Even within the code itself, ambiguity exists. Smart contract are written in higher level languages such as Solidity and Vyper and compiled into native, interpreted Ethereum Virtual Machine bytecode. How that code is generated and how it’s interpreted isn’t constant. For example,
“If a Solidity code deals with overflow or underflow issues, there may be a significant difference between the calculation’s actual outcome and expected results. This will undermine the contract’s inherent logic and result in the contract’s funds being lost... Overflow will not generate an error in Solidity versions up to 0.8, but it will in versions after 0.8.” Top 10 Smart Contract Vulnerabilities: That can Lock your Crypto Assets. (immunebytes.com)
The same article shows the different outcomes of seemingly identical code.
“Let’s have a look at a simple mathematical example of this: A= (10*30*18)/ 30= 180. [Now solve] the same equation but performing division before multiplication. A= (10/30)* 30*18= 179.99999. [T]hese two terms are quite close but not the same. In the case of a Solidity smart contract, it is going to yield 179.”
Whether through lax version control, code execution details, bugs or the definition of a chicken, ambiguity exists in smart contracts whether or not it interacts with the real world.
Self-Enforcing
The servers on which smart contracts live have no way of knowing when to execute the code. If the trigger for execution is an on-blockchain event, such as the sale of an NFT, execution of the smart contract is initiated by that transaction. For real world events such as the delivery of a load of chickens, a third party called an ‘oracle’ is required. An oracle can be anything, a company, a person, a community. The oracle is a trusted process which confirms that an off-blockchain event has occurred, whether it be a weather event, the close of escrow or that Hayseed came in 3rd at Hialeah.
Oracles can fail in a number of ways. The oracle could be corrupt and report incorrect events. Multiple voting oracles could be out of sync; for example, reporting different stock prices at slightly different times. The oracle could go out of business and never report an event. There is no way to code a smart contract to recover from these errors because if the smart contract is never triggered, it will never execute. If it is triggered with incorrect inputs, there is no way for the smart contract to determine ‘truth’ because the oracle is defined as the source of transactional ground truth.
On the output side, a smart contract itself can’t perform off-blockchain events. This requires a ‘listener,’ an external service set up to execute that intention. As with an oracle, listeners can go out of business or incorrectly perform the requested task. There is no known way for a smart contract to recover from these failures.
领英推荐
Secure and Immutable
Theoretically, once a smart contract is committed to a blockchain it cannot be changed. It can only be deleted by the agreement of the contracting parties. Immutability is both a positive and negative. As mentioned in earlier articles, business relationships are generally complex and fluid. It's quite common for parties to ignore the contract for the greater good of the relationship. This makes smart contracts a poor choice where the intent of the parties changes over time. Rather than executing a contract amendment, or just ignoring a contract term, the parties must delete the old contract, entirely recode and recommit it to the blockchain.
While not generally acknowledged, it's possible for a smart contract to be deleted, effectively declared null and void by the consensus of the blockchain community. The most famous example involved an entity called ‘The DAO’. We’ll dive into DAO’s generically in a later article, but in this case a group of investors committed $150M to The DAO, to be managed by group vote and smart contract. Since smart contract code is viewable by anyone, a hacker did, discovered a bug, and siphoned off $60M.
Some in the Ethereum blockchain community said that if the bug was in the code, it was not a bug, it was code and Code is Law. The hacker who took the $60M in fact argued exactly that to the community, saying he was living within the terms of the smart contract as written. Those who invested the funds had a different opinion. They believed the parties never intended that the code be exploited as it was. Normally this would lead to a picnic for lawyers, but ‘the Ethereum blockchain community’ through a consensus vote decided to turn back the transaction by creating what is called a hard fork in the blockchain. A hard fork is where the blockchain truncated and restarted before the hack. All transactions after this hard fork were erased, including the smart contract and the hacker’s transactions.
Rolling back transactions on a blockchain was previously believed to be both theoretically and practically impossible, but it happened. Many rejected the consensus decision, saying that the rollback was antithetical to the concept of the smart contract. Immutable was immutable. No external authority should be allowed to decide otherwise. The rollback so offended some in the community that to this day there exist two Ethereum blockchains: Ethereum and the un-forked Ethereum Classic.
The DAO notwithstanding, in the vast majority of transactions, smart contracts placed on a blockchain are immutable. Amendments and modifications are impossible. The only way to change it is to terminate it and recode a new one. Let’s just say this is difficult. And as with all software, the more complex the code becomes the more it is subject to cyberattack and coding errors. Since coding errors are code, and Code is Law, the parties must live with the outcome. Well, most of the time.
Efficient
Smart contracts are not free to establish or frictionless to run. Based on recent costs of Ethereum ‘gas,’ the basic escrow agreement above can cost between $18 to $2,523 to set up and execute on the Ethereum blockchain.
Why this wide range exists is because ‘gas’ fees vary based on demand. This makes smart contract transaction costs unpredictable.
Cost and complexity aren’t limited to the smart contract itself. For real world business transactions, especially those involving ongoing relationships at scale, the cost of tuning the business relationship to the smart contract can be large. A study of an olive oil supply chain is instructive.
In 2016, news broke that 80% of extra-virgin olive oil sold in the market was fake. Oil was mislabeled, adulterated in transit, incorrectly certified. The brand damage done led the industry to study using blockchain and smart contracts to secure the supply chain. All transactions would be transparent, unambiguous, fast and inexpensive. The group first studied the supply chain and found it had the following characteristics, many of which will be found in typical at-scale supply chains:
The working group proposed tracking devices and procedures to avoid fraud at each point in the chain. They proposed that each player in the chain reconcile their heterogeneous data formats to avoid the ambiguity of different labels and trigger criteria. To avoid adulteration, they proposed tamper resistant RFID-based certification tools to implement automated event triggers with associated implementation obligations that drove detailed definitions of what those events meant.
The costs to address these issues were significant. The negotiations around implementation introduced new friction into the business. High-confidence event triggers exposed the proprietary business data of each party in the chain, data that most companies didn’t want either public known or known to the other parties in the chain. Because the results would be automatic based on definitions, these definitions became critical and subject to disagreement. The question of what extra virgin olive oil was became as problematic as the definition of a chicken. ?
In the end, it was concluded that automated blockchain-based certification and tracking was both too costly and too rigid. The cost of adapting the real world of olive oil to blockchain automation dwarfed the benefits of blockchain automation. Just, Kristoffer, Blockchain in Supply Chain (2017). The broader learning to take from this study is that any use of smart contract should begin with the goal, business relationships and existing processes. Only once those are understood should you move on to whether a smart contract or some other process is best.
Enforceability
Lawyers who have weighed in on the issue generally advise that smart contracts should be viewed as unenforceable in a court of law. Whether they are or not will depend on litigation and the facts presented in each state, since state law governs contracts. A judge would certainly view a smart contract as evidence of the parties’ intent, but courts are ill-equipped to interpret code fragments. In addition, many oracles and listeners are themselves blockchain-based consensus devices. There might be no party to which to issue a writ of mandamus ordering an oracle or a listener to trigger a smart contract or to respond to its output in a prescribed way.
Those same lawyers suggest that except for the simplest transactions, smart contracts are best used in a hybrid form, with a standard natural language contract executed in parallel with the blockchain-based code. The court would likely enforce the contract based on reading of the document with the code being used as evidence of the parties’ intent.
Summary
Smart contracts are most useful for simple events that occur on the blockchain on which they’re stored. Examples include voting contracts for Distributed Autonomous Organizations, the creation of new cryptocurrency tokens and escrow agreements. If a smart contract is intended to implement an ongoing and complex real world business relationship, its rigidity makes it hard to track the changing the intent of the parties. If the parties already have business processes established, the cost of adjusting their business practices to automate things like payments or fraud detection can be high. ?
Determining whether to use a smart contract should follow a Why-What-How process. First determine what value you intend to enable. Then decide what transactional steps are needed to implement it. Only then choose either a smart contract, traditional contract or something else.
Opinions expressed are solely my own and do not represent the views or opinions of others, including my employer.
Creator
2 年reminds me of that famous Train innovation story; the british calling the French engineers, the moment the big front window of the High speed train kept braking in the collision trials….’’ the test was conducted with a cannon and a bird, shot at high speed towards the window… The british explained the problem of the apparent weakness of the window. the French responded ‘’Thaw the chicken’’………….