The Trouble with Smart Contracts – Rivet Magazine
Enter the smart contract. While the analogy to traditional contracts has been useful to explain the potential for blockchains to automate the previously unautomatable, the idea has incited a debate that — like drawing 8.5 x 11 pieces of paper on iPhone screens—is a skeuomorphic analogy taken far to literally.
How so? Put simply, it’s not that what we call smart contracts aren’t smart. Smart is subjective. It’s that they’re not contracts.
What is a contract, really?
If you Google the word “contract”, you get a sterile description of a thing that sounds a lot like what we think of when we think of smart contracts. It looks something like:
“A contract is a legally binding agreement that recognises and governs the rights and duties of the parties to the agreement. A contract is legally enforceable because it meets the requirements and approval of the law. An agreement typically involves the exchange of goods, services, money, or promises of any of those.”
Let’s break that down.
1. An agreement between at least two parties
This one seems fairly straightforward, but it comes loaded up with some not so straightforward questions:
What makes an agreement an agreement?
When can an agreement be said to exist?
Who (or what) can be a party?
Do parties have to be uniquely identified before an agreement can exist?
For now, just put a pin in these questions — we’ll come back to them later.
2. That recognizes and governs
This one is pretty simple. The purpose of a contract must be made clear, and consequences for failing to meet that puprose must be defined.
3. legally enforceable rights and duties
Rights are things to which a party is entitled, and duties are things expected from a party. The law may circumscribe the scope of what rights and duties qualify as enforceable.
4. because it meets the requirements and approval of the law
This element seems redundant based on the preceding element, but it really isn’t. In this element, the law’s requirements and approval are applied to the whole set of criteria (i.e. 1–3) that make a contract.
For example, an otherwise-enforceable contract isn’t binding on a child, and parties who can otherwise legally be bound may not ask the court to enforce an agreement to commit a crime.
5. typically they involve the exchange of
— goods
— services
— money
— promises of any of those
While the subject of a contract can go beyond the typical, I’ve included it as an element to highlight another interesting question:
What qualifies as a promise?
Pin this one with the questions we raised above — we’ll address all of them — in the context of the mythical smart contract — in just a little bit.
The (so-called) Smart Contract
Google defines a smart contract accordingly:
“A smart contract is a computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of a contract. Smart contracts allow the performance of credible transactions without third parties. These transactions are trackable and irreversible.”
Broken into elements and simplified:
1. a protocol
2. intended to digitally facilitate, verify or enforce
3. negotiation or performance of a contract
See the first hint of a problem? This definition of a smart contract incorporates without defining the term ‘contract’, while asserting that the role of a smart contract relates to the execution of an existing contract.
So it is already somewhat intuitive that smart contract ≠ contract. To find out why that intuition is correct, we must dig deeper.
Consider this hypothetical:
Alice opens a DEX dapp because she wants to swap 10 MBGN tokens for some ETH. She taps through the interface, first selecting MBGN from the ‘I want to Trade’ dropdown. Next, she selects ETH from the ‘in exchange for’ dropdown. Then she enters the number ‘10’ in the ‘quantity’ text field next to the first dropdown.
After a moment, the display is updated with how much ETH she can get for her MBGN. Satisfied with the number, she then selects the ‘Swap’ button — and the dapp gets to work.
What’s happening in the background is now on autopilot, sending the necessary calls to the necessary ‘smart contracts’ to complete the process of fulfilling her expressed intent.
Then, the page refreshes, indicating success. Alice’s new balances are indeed correctly reflected in her wallet.
Meanwhile, Bob receives a notification that the order he listed the other day — requesting 5 MBGN in exchange for 0.1 ETH has been accepted and filled.
CAI, a trading bot, receives a similar notification about its own order (5 MBGN for 1 ETH).
Remember the questions we pinned earlier? Dust them off—we’re going to apply them to our hypothetical.
Now is a good time to refresh yourself on what they were. Don’t worry, I’ll wait. Or, you can forge ahead and skip this little intermission. Your call.
Reader, please note: I’ve rephrased the questions to target the facts of the hypothetical. You have been warned.
At what point does an agreement exist between Alice and Bob|CAI?
When an agreement is reached among a set of identified parties, it is typically indicated by some affirmative act. This can take a variety of forms, such as a handshake, a signature on a page, or — on the web — selecting a button in an interface (e.g. “Accept” on terms of use).
In this case, Bob and CAI had already posted orders, marking their pre-agreement to anyone willing to fill those orders. But without some action by another party willing to fill them, no agreement between parties exists. Bob and CAI have instead made binding offers on the terms they specified.
Only when Alice selected the “Swap” button did it become possible for some agreement come into being.
However, the agreement she made did not specify Bob and CAI as parties. She agreed to trade with anyone whose signed orders matched her criteria, and the software subsequently identified them.
Because a binding agreement requires specific parties to be identified, no agreement could have existed until after the software selected Bob and CAI.
And since no 3rd party existed to facilitate the transaction, the code itself was the only thing holding Bob and CAI to their word, or ensuring that when Alice clicked “Swap”, the trade she wished to execute would indeed take place as described in the interface.
This means that Alice, Bob and CAI never really agree to transact explicitly with one another at all — so if an agreement is deemed to exist, that agreement could only be said to exist after the exchange was complete.
Can Alice, Bob, and CAI all be considered parties?
As parties can only exist with respect to an agreement, they can be considered parties — but again, only after the exchange is complete.
While one might reasonably ask whether CAI, an autonomous trading bot, could be considered a party at all, the question is moot. By the time the exchange could be deemed an ‘agreement’, the terms were already immutably fulfilled. Thus, no declaration of law could effectively nullify CAI’s participation in the transaction.
If so, did the parties have to be uniquely identified before an agreement could be reached?
Since the agreement can only be deemed to exist in hindsight, the answer is no. This stands in contradiction to modern conceptions of the law of contract.
Was there ever a promise made to Alice with respect to Bob|CAI?
Again, the answer must be no.
Bob and CAI signed their orders before Alice ever came into the picture. Because the code itself would have necessarily validated Bob and CAI’s orders, the possibility of non-performance was no longer under the control of Bob or CAI. Hence they can’t really be said to have ‘promised’ anything — as any reasonable conception of ‘promise’ implies some future action to fulfill it.
With these questions settled, take a second look at our definition:
“A contract is a legally binding agreement that recognises and governs the rights and duties of the parties to the agreement. A contract is legally enforceable because it meets the requirements and approval of the law.
(Emphasis added.)
Reading through the definition, it becomes clear that if a contract could even be said to exist, it could only be said to exist in retrospect. And because the result of any hypothetical on-chain exchange is immutable, a contract in retrospect doesn’t serve any meaningful purpose.
So the thing we call a smart contract isn’t really a contract at all.
While it is true that it might look more or less like a contract under different facts, what we’ve demonstrated is that the analogy breaks down if we take it too literally. And we’re hardly served by imposing the limitations of the past on the future.
So we must evolve—and leave the term smart contract behind.
Or at the very least, we must be wary of anyone using The Law of Contract™ to circumscribe the way blockchain technology ought to be used.
So what else can we call it?
Anything we want, as long as we don’t call it a contract—smart or otherwise.
Note: While I didn’t write this post to come up with an alternative to ‘smart contract’, I’d propose: Decentralized Autonomous Regulator. Please leave a comment in the comments section if you’d like to know the why behind my proposal.
Published at Tue, 11 Feb 2020 15:37:30 +0000
{flickr|100|campaign}
