Bitcoin: The Blockchain for Truly Smart Contracts
| If you find WORDS helpful, Bitcoin donations are unnecessary but appreciated. Our goal is to spread and preserve Bitcoin writings for future generations. Read more. | Make a Donation |
Bitcoin: The Blockchain for Truly Smart Contracts
By Conner Brown
Posted January 15, 2020
Smart contracts sound enticing. The allure of cutting out attorneys, endless paperwork, and exorbitant legal fees is what drew me into learning about cryptocurrency in the first place. Unfortunately, my dreams were shortly crushed. It was clear that reality didnāt live up to the advertising hype and āsmart contracting platformsā had fundamental problems with the nature of contracts.
Many have encountered these problems and decided smart contracts are something that can never work, I disagree. In fact, Bitcoin has made the proper design choices to make smart contracts possible where others have failed.
In this essay, I will cover the basics of contracts, explain the problems with naive āsmart contracting platformsā, and finally show how Bitcoin is keeping the dream of smart contracts alive.
Part One: Contract Basics
First, letās cover the basics of a contract. A contract isĀ an enforceable agreement between consenting parties. Here is an example:
Alice agrees with Bob to purchase $1000 dollars of coffee beans from him per month for the next 3 years. Alice will pay Bob on the first of each month.
The contract is the agreement between the two parties (Alice and Bob) for the transaction (coffee beans for dollars) and can be digital, written, or even verbal.
The key difference between a contract and a mere promise is that a contract can be enforced by a third party. This third party is often an agent of the law, such as a judge, but can also include private arbitrators, mutual friends, mob bosses, etc. In the event of a_Ā breach_Ā (i.e. Alice misses a payment), the injured party can take the contract and evidence to their enforcement authority who will use their abilities to make the injured party whole under the terms of the contract.
Contracts are a necessary part of a functioning economy as they allow individuals to rely on actions of others. Therefore, an entrepreneur can operate a business knowing that the components needed for their product will arrive on schedule. This forms the basis of predictable trading, planning, and specialization. In this sense, contracts are socially scalable as they āovercome shortcomings in human minds . . . that limit who or how many can successfully participate.ā Ā¹Ā As more people can rely on the efforts of others without trusting them personally, the entire network of possible economic interaction grows exponentially.
The key feature that makes contracts socially scalable is thatĀ a contract can be entered and executed without supervision.Ā A merchant may engage in thousands of trades and contracts with others and never need to see a judge to resolve the conflict.
On the contrary, imagine a world where every contract you entered into (i.e. every time you sat down at a restaurant or purchased something from amazon) there had to be a third party overseeing the entire transaction to ensure that everything went according to plan. That would be ridiculous. Transaction costs would be so high that no one would ever use contracts in the first place. The beauty of contracts is not that a third party is present at all times, but thatĀ there can be a third party if needed.Ā That fallback option is sufficient to generate trust between strangers.
With contracts, we improve the division of labor and add reliability to our world, the cornerstones of economic progress, by replacing the element of trust with enforceable guarantees.
Part Two: The Naive āBlockchainā Approach
Lately, there has been a lot of buzz around contracts. With the blockchain boom of the past decade, the meaning of the term āsmart contractā has evolved in reference to the many distributed networks that have sprung up. For the purposes of this article, I will define a smart contract as the enforcement, verification, and performance of an agreement between two parties over a distributed protocol.
If only it were this simple.
The stock image above represents the naive vision for smart contracts. The theory is that one can simply take real world contracts, āput them on the blockchainā, and somehow end up with an agreement that is more trustworthy. In this view, (1) there is a contract coded into the network, (2) data from the real world event is then processed by the network, and (3) lastly the network performs an action based on that information.
However, there are major problems with this approach.
1. The Oracle Problem
If your smart contract system is based on information from the physical world, (i.e. title to land, the price of a good, or the delivery of an item) then it must rely on a service known as an oracle that can feed that information to the smart contract system. This is a problem because there is no objective way to know if the physical world corresponds to the internal databases. As a result, services require trusted third parties to supply the information for their contracts ā defeating the purpose of using a decentralized network in the first place.
Additionally, problems arise when something happens with a piece of property, but the blockchain is not properly updated. For example, imagine you are storing land titles on a blockchain. What happens if the land is meant to be passed on to family members but the private keys to the land are lost or destroyed? In that scenario, there are two options. Either the ledger is immutable and title is permanently issued to the wrong person, or the ledger can be changed by a third party (i.e. government agent or customer support) to reflect what occurred.
The first scenario means over time the ledger will become increasingly incorrect, and the second demonstrates why a blockchain is unnecessary to begin with . Problems like these are fundamental to their respective networks and demonstrate why smart contracts are not suited for physical world property rights.
2. The Inflexibility Problem
Contracts are never perfect manifestations of the drafters will. Often confusions and misunderstandings occur between parties when drafting. However, when drafting in a smart contract language, there is no room for error. Each word must be drafted from fully-defined computer terms which can be processed by the smart contract platform.
Jeremy Sklaroff explores this problem in a fantastic paper titledĀ Smart Contracts and the Cost of Inflexibility.Ā² Smart contract platforms claim to reduce āinefficiencyā by removing traditional language; however, Sklaroff demonstrates this removal unfavorably increases transaction costs. Hard coded contracts must be rigid and purely self-referential. This means that both parties mustĀ fully and precisely define all expected and possible future states of the contract without traditional language.Ā The possibilities for even a simple contract of coffee bean delivery are dizzying.
It is also common when drafting contracts to reference conventions, customs, and terminology specific to a certain trade, significantly reducing the time required in drafting contract. These commonly understood substitutes would also not be recognized under a smart contract and would need to be entirely defined.
In sum, human activities require human constructs. Natural language has an interpretive richness and flexibility that cannot simply be replaced by computer logic.
3. The Breach Problem
Contracts are often complex agreements with a variety of terms and requirements. Many times whether or not the terms of an agreement have been breached is up for debate. Bob may believe that he acted in accordance to the terms of the contract, however Alice may interpret things differently. For example, what happens if the coffee beans being delivered are the wrong size or type? Should this constitute a punishable breach or a negligible difference? Hopefully this would be negotiated ahead of time, but these problems are often difficult to anticipate.
To make matters worse, breaches are not always intentional or harmful. With standard contracts, a counterparty can give an explanation of their mistake and the injured party can choose take the case to the courthouse, or simply let it slide. This is because a technical violation is not always a detrimental violation.
To illustrate, letās return to the contract between Alice and Bob. There may be a month where bob delivers the wrong type of coffee bean for Alice. He calls her ahead of time, informs of her of the mix-up, but tells her heāll make up for it by giving her 25% off that order. Alice thinks this is a great idea. She will get a discount on this monthās delivery and can use these different coffee beans as a ālimited time offerā in her store to boost sales.
Informal modifications like these are important and possible because they operate in the malleable world of human interaction. On the other hand, a trustless smart contract would simply see the wrong goods were delivered and penalize the offending party ā a costly result that could have been avoided.
This lack of selective enforcement is another massive burden to smart contracts where the flexibility of standard contracts is a feature, not a bug.
4. The Enforcement Problem
As mentioned above, the difference between a contract and a promise is that the third party to an agreement can enforce the terms of the contract. But what about a smart contract? If there is a smart contract for a delivery of coffee beans and Bob doesnāt deliver, who will enforce it? A blockchain is decentralized and has no jurisdiction or ability to affect physical objects, naturally this creates a problem with getting people to be good on their promises.
Defenders of blockchain enforcement generally take one of two positions. First, one might argue that the blockchain canāt enforce it, but it could be used as proof in a court of law. In that case however, youāre still falling back on the same state institutions to enforce the contract. A standard contract would have the same assurances and more privacy!
The alternative to this is a staking model. To use a smart contract, a user would need to post collateral that can be auctioned off in the event of the breach. This also brings its own problems ā itās expensive! Posting collateral for every contract brings its own opportunity costs, especially if dealing with multiple contracts on multiple services.
Neither of these solutions is appealing, and brings us back to the question of why use a blockchain for contracts in the first place?
5. The Scalability Problem
As explained above, a key element of contracts is their ability to scale by providing third party monitoring on anĀ as needed basis. However, smart contracting platforms such as Ethereum, Tron, and EOS, have decided to ignore this basic principle. By allowing users to upload contracts directly to the base layer, any contract that individuals create must be verified and constantly monitored by all other validators of the network.
Their results have been disappointing and predictable. Despite gaining little traction or active users, the major smart contracting platforms are already incredibly difficult to download, verify, and stay synced.Ā This timeless piece by StopAndDecryptĀ does a fantastic job exploring the implications of this design choice which applies to blockchains with expressive languages on the base layer such as Ethereum, Tron and EOS.ā“
Despite claiming to be innovative compared a simpler protocol like Bitcoin, complex base layer scripting is a step backwards. By requiring all validators to verify the entirety of every smart contract on these platforms, the inevitable result is centralization and falling right back into the realm of trusted third parties they claim to remove. Contracts simply donāt work that way.
Part Four: A Judge Like No Other
After seeing these problems, it is tempting to think they cannot be overcome. While most uses of the term āsmart contractsā are merely fluff, we shouldnāt abandon the concept entirely. In fact, Bitcoin has already solved these problems with the Lightning Network.
The Lightning Network is a system of peer-to-peer payment channels that operate on top of the bitcoin protocol. A brief introduction to Lightning can be foundĀ here.
In broad terms, a Lightning Network interaction works as follows. Two parties communicate with each other that they would like to enter into an agreement to open a payment channel. Both parties sign a commitment transaction which memorializes their mutual assent to the agreement and records it on the Bitcoin blockchain. Both parties abide by rules of the Lightning Network protocol, which form the boundaries of their cooperation. After transacting for a period of time, the parties can choose to terminate the contract by signing and publishing a final mutual transaction. In the event that one party tries to break the rules of the network and steal their counterpartās funds, the injured party can publish proof to the bitcoin blockchain and prevent the theft.
These elements line up perfectly with traditional notions of contract, and overcome the problems listed above.
- Terms:Ā The rules of the LN protocol itself are akin to the terms of a contract where both parties to the agreement must act accordingly.
- Signing:Ā Publishing the commitment transaction is a way of signing and agreeing to the terms of the contract.
- Breach:Ā The contract is breached if a party violates the terms of the lightning contract, and injured parties can essentially āhave their day in courtā by publishing cryptographic evidence to the base chain.
- Enforcement:Ā Finally, the bitcoin protocol acts as a virtual judge, logically evaluating the evidence before it and transferring funds to the appropriate party.
The lightning network completely sidesteps the traditional pitfalls of smart contracts by isolating the contract system in a virtual closed loop. A smart contract on lightning lives and dies entirely in the digital realm. The oracle, enforcement, and breach problems only arise with dealing with the gray world of material objects and actions.
There is also a strong flexibility inherent in the network as the agreements are peer-to-peer like traditional contracts. Each set of partners chooses which terms they wish to be bound by. While there are generic lightning contracts, (i.e. the default build of Eclair or LND), these terms can be tweaked to fit the needs of the parties. For example,Ā Bitrefill recently openedĀ the first 1BTC channel by changing the default channel size limit. Contract flexibility will continue to improve as protocol upgrades such as Schnorr Signatures and SIGHASH_NOINPUT are implemented.Ā The eltoo proposalĀ is just one example.
With all this being said, perhaps the most important part of Lightning is its understanding of social scalability. As mentioned earlier, what makes contracts so powerful is that a judgeĀ is not necessary for a transaction, but only as a backup in the event of a breach. Other āsmart contract platformsā such as Ethereum and Tron completely miss this fundamental insight of contracts. Instead, they opt for a model where the ājudgeā (i.e. the blockchain) sits over the shoulder and watches every single transaction as it occurs.
The design of the lightning network fully grasps this contracts concept. With lightning, millions of transactions can take place between two individuals without needing the judge at all.Ā This provides two obvious benefits, reducing transaction costs with users of the network, and increasing the privacy of those entering into contracts.Ā At this point, the size and growth of the network is somewhat unknown because many channels are private. However, in the event that something goes wrong, the benevolent bitcoin judge can step in, evaluate, and resolve the dispute.
Lastly, its important to note that the Lightning Network is only the first of many of such examples.Ā POWSWAP by Jeremy RubinĀ offers a similar type of smart contract for hashrate derivatives, andĀ Lot 49 by Richard MyersĀ for mesh network messaging. These innovative smart contracts are not being built on other chains because of their āexpressivenessā or āturing-completenessā, quite the opposite. They chose bitcoin for its simplicity.
The blockchain space often touts complex base layer scripting as what is best for smart contracts ā but they fail to recognize simplicity is crucial for smart contracts by forming the basis of predictable execution. In this light, bitcoinās simplicity and security shines through.
Going forward, I expect the smart contracts with the most usage and value to be built in a similar way ā leveraging bitcoin as their virtual judge of choice.
Conclusion
Lightning is the first truly smart contract. By tackling the problems plaguing other networks, Lighting has prevailed as a shining example of what is possible on Bitcoin and paints a bright future for smart contract innovation on the network.
I would like to thankĀ Bitcoin Lawyer, Jeremy Sklaroff, and Nick Szabo for their ideas, and the Cato Institute for hosting me to do this research.
References:
- Szabo, Nick. Money, Blockchains, and Social Scalability, 9 Feb. 2017, unenumerated.blogspot.com/2017/02/money-blockchains-and-social-scalability.html.
- Sklaroff , Jeremy. āSmart Contracts and the Cost of Inflexibility .āĀ University of Pennsylvania Law ReviewĀ , vol. 166, 2018, pp. 263ā303.
- Id. at 264.
- For more recent evidence of SADās concerns coming to fruition, I recommendĀ this thread by Eric WallĀ documenting the herculean efforts to sync a full node on Ethereum.