Views | Ethereum "smart contracts" are too naive, Bitcoin is the real smart contract platform

Written in front: The original author is Conner Brown from Stanford Law School. He believes that there are 5 fundamental problems with smart contracts on platforms such as Ethereum, so it is not a contract in the real sense. How to solve these problems. It concludes that simplicity is crucial for smart contracts because it forms the basis for predictable execution, so it predicts that those smart contracts with the highest usage and value will be constructed in a similar way, using Bitcoin as a carrier .


The original title was: "Bitcoin: The Blockchain for Truly Smart Contracts"

Here is the translation:

Smart contracts sound very attractive. The temptation to lay off lawyers, minus endless paperwork, and high legal fees is what attracted me to cryptocurrency. Unfortunately, my dream was soon dashed. Obviously, the smart contracts in reality have not reached the level of hype and publicity, and the "smart contract platform" has fundamental problems in the nature of contracts.

Many people have encountered these problems, and then concluded that smart contracts will never work. In fact, Bitcoin has made the right design choices, which makes smart contracts possible if others fail.

In this article, I will introduce the basics of contracts, then explain the problems with the naive "smart contract platform", and finally show how Bitcoin allows the dream of smart contracts to continue.

Part I: Contract Basis

First, let us introduce the basic content of the contract. A contract is an executable agreement between consenting parties. Here is a specific example:

Alice agreed that Bob would buy him $ 1,000 worth of coffee beans a month for the next three years. On the first day of each month, Alice pays Bob to Bob.

The contract is an agreement reached between the two parties (Alice and Bob) on the transaction (coffee beans for US dollars), which can be in digital form, written form, or even verbal form.

The key difference between a contract and a simple promise is that the contract can be enforced by a third party. The third party is usually a legal agent, such as a judge, but it can also be a private arbitrator, mutual friend, mob leader, etc. In the event of a breach (that is, Alice does not pay on time), the injured party can give the contract and evidence to its law enforcement authorities, which will use its capabilities to enable the injured party to obtain its due rights under the terms of the contract.

Contracts are an essential part of a functioning economy because it allows individuals to rely on the actions of others. As a result, entrepreneurs can run a business knowing that the required components of the product will arrive on time. This forms the basis for predictable trading, planning and specialization. In this sense, contracts are socially expandable [1] because they "overcome the shortcomings of human thinking … limiting who or how many people can successfully participate." As more and more people can rely on others' Efforts without having to trust them personally, the entire network of possible economic interactions has grown exponentially.

The key feature that makes a contract socially scalable is that it can be concluded and executed without supervision . A businessman may conduct thousands of transactions and contracts with others without having to see a judge to resolve the conflict.

Instead, imagine a world where every contract you sign (i.e. every time you sit down at a restaurant or buy something from Amazon) must have a third party oversee the entire transaction to make sure everything goes according to plan, which is ridiculous !! Transaction costs will be so high that no one will use the contract first. The beauty of a contract is that it doesn't require a third party to be always present, but rather a third party can be present when needed . This fallback option is enough to build trust between strangers.

By signing the contract, we replaced the element of trust with enforceable guarantees, thereby improving the division of labor and adding reliability to our cornerstone world of economic development.

Part 2: The naive "blockchain smart contract" approach

Recently, there has been much discussion on contracts. With the rapid development of blockchain in the past decade, the meaning of the term "smart contract" has also evolved with the emergence of many distributed networks. For the purpose of this article, I define a smart contract as the execution, verification, and performance of a contract by both parties on a distributed protocol.

p1 If only it were that simple

The example above represents the naive vision of smart contracts. The theory is that people can simply accept real-world contracts, put them on the blockchain, and somehow eventually reach a more reliable agreement. In this view, (1) a contract will be encoded into the network, (2) data from real-world events will be processed by the network, and (3) finally the network will perform an operation based on this information.

However, this method has major problems!

1. Oracle problem

If your smart contract system is based on information from the physical world (that is, land ownership, commodity prices, or commodity delivery), then it must rely on a service called Oracle, which can provide this information to the smart contract system . This is a problem because it is impossible to know objectively whether the physical world corresponds to an internal database. Therefore, services require trusted third parties to provide information for their contracts, which first defeats the purpose of using a decentralized network.

In addition, when a problem occurs in a certain part of the property, but the blockchain is not updated correctly, a problem occurs. For example, suppose you are storing land ownership on the blockchain. What happens if the land is intended to be passed to family members, but the private key of the land is lost or destroyed? In this case, there are two possibilities. First, because the ledger is immutable, the land was incorrectly allocated to someone else, or a third party (that is, a government agent or customer support) changed the ledger to reflect what happened.

The first case means that over time, the ledger will become more and more incorrect, and the second case explains why you don't need to use the blockchain from the beginning. Issues like this are fundamental to blockchain networks and explain why smart contracts are not applicable to property rights in the physical world.

2.Lack of flexibility

Contracts are never a perfect expression of the will of the drafters. When drafting a contract, there is often confusion and misunderstanding between the parties. However, when drafting in the smart contract language, there is no room for error. Each word must be drafted from a well-defined computer term, and they can be processed by a smart contract platform.

Jeremy Sklaroff explores this issue in a wonderful paper entitled "Smart Contracts and the Cost of Inflexibility" [2] . Smart contract platforms claim to reduce "inefficiencies" by removing traditional languages, however, Sklaroff has proven that removing traditional languages ​​can adversely increase transaction costs . Hard-coded contracts must be strict and purely self-referential. This means that both parties must fully and accurately define all expected and possible future states of the contract without traditional language. Even a simple contract for the delivery of coffee beans can be dazzling.

When drafting contracts, it is also common to refer to specific trade conventions, practices and terminology, which greatly reduces the time required to draft a contract. These commonly understood alternatives will not be recognized by smart contracts, and they need to be fully defined.

In short, human activity requires human composition. Natural language has rich explanatory power and flexibility, and it cannot be simply replaced by computer logic.

3. Default issues

Contracts are usually complex agreements with various terms and requirements. Whether the terms of an agreement have been violated is often open to debate. For example, Bob may believe that he is acting on contract terms, but Alice may interpret things differently. For example, what happens if the coffee beans are delivered in the wrong size or type? Does this constitute a punishable breach or a trivial difference? We naturally hope to negotiate in advance, but these issues are often difficult to predict.

To make matters worse, violations are not always intentional or harmful . With a standard contract, the other party can explain their mistakes, and the injured party can choose to bring the case to the court or simply open one eye and close the other. This is because technical violations are not always harmful.

To illustrate this, let's go back to the contract example between Alice and Bob. Maybe a month, Bob gave Alice the wrong coffee beans. He called Alice in advance to inform her of this and was willing to give her a 25% discount as a make up. Alice thinks it's a good idea to save money and use these different coffee beans in her shop as "time-limited offers" to boost sales.

Informal modifications like this are important and possible because they play a role in the plastic world of human interaction. On the other hand, a trustless smart contract will only see the wrong goods being delivered and punish the offending party, which is a costly result that could have been avoided.

This lack of selective execution is another major issue with smart contracts. The flexibility of standard contracts is a feature, not a bug.

4. Implementation issues

As mentioned above, the difference between a contract and a promise is that the third party to the agreement can enforce the terms of the contract. What about smart contracts? If there is a smart contract used to deliver coffee beans, but Bob does not actually deliver the coffee beans, who will enforce them? Blockchain is decentralized, and it has no jurisdiction or ability to affect physical objects, which naturally brings problems.

Defenders of blockchain smart contracts usually take two approaches: First, one might say that blockchain cannot be enforced, but it can be used as evidence in court. However, in this case, you still have to rely on the same state agency to execute the contract. A standard contract will have the same guarantees and more privacy !

Another option is the staking model . To use smart contracts, users need to collateral in order to auction their collateral in the event of a default. This also brings its own problems, it will be expensive ! Providing collateral for each contract comes with its own opportunity cost, especially when dealing with multiple contracts for multiple services.

Neither solution is attractive, and let us return to the question of why blockchain is used to execute contracts?

5.Scalability issues

As mentioned above, a key element of the contract is that it can be scaled up by providing third-party monitoring as needed. However, smart contract platforms such as Ethereum, Tron, and EOS have decided to ignore this basic principle. They do this by allowing users to upload contracts directly to the base layer, and any contract created by an individual must be verified and continuously monitored by all other validators of the network.

The results of these platforms are disappointing and predictable. Although they haven't captured many active users, major smart contract platforms have faced difficulties in downloading, verifying, and maintaining synchronization. This article by StopAndDecrypt did an excellent job exploring the implications of this design choice, which is suitable for blockchains with expressive languages ​​on the base layer, such as Ethereum, Tron, and EOS [3] .

Although these platforms are considered more innovative compared to protocols such as Bitcoin, complex underlying layer scripting is a step backwards. By requiring all validators to verify the integrity of each smart contract on these platforms, the inevitable result is centralization, and then back to the realm of trusted third parties they claim to be removed, and the contract does not work at all .

Part 4: Judges are unique

After seeing these problems, it is easy to think that these problems are insurmountable. Although most uses of the term "smart contract" are nonsense, we should not completely abandon this concept. In fact, Bitcoin has solved these problems with the Lightning Network.

Lightning Network is a peer-to-peer payment channel system based on the Bitcoin protocol. You can read about this system here .

Broadly speaking, the working principle of Lightning Network interaction is as follows: The two parties communicate with each other and hope to sign an agreement to open a payment channel. The two parties signed a commitment transaction to signify their agreement to the agreement and record it on the Bitcoin blockchain. Both parties abide by the rules of the Lightning Network Agreement, forming a boundary of cooperation. After a period of trading, both parties may choose to terminate the contract by signing and publishing the final mutual transaction. If one party tries to violate the rules of the network and steal the other party's funds, the victim can issue evidence to the Bitcoin blockchain to prevent theft.

These elements are fully consistent with the traditional concept of contract and overcome several of the issues mentioned above.

  1. Terms: The rules of the LN agreement itself are similar to the terms of the contract, and the parties to the agreement must act accordingly;
  2. Signing: Publishing a commitment transaction is a way to sign and agree to the terms of a contract;
  3. Breach of contract: If one party violates the terms of the Lightning Network contract, the contract is breached, and the injured party can subject it to "tribunal" sanctions by publishing encrypted evidence to the basic chain;
  4. Enforcement: Finally, the Bitcoin protocol acts as a virtual judge, logically assessing the evidence before it, and transferring funds to the appropriate party;

Lightning Network completely avoids the traditional trap of smart contracts by isolating the contract system in a virtual closed loop.

The flexibility inherent in the network is also strong because protocols are peer-to-peer, just like traditional contracts. Each group of partners chooses which terms they wish to be bound by. Although there is a general Lightning Network contract (ie, the default version of Eclair or LND), these terms can be adjusted according to the needs of both parties. For example, BitRequill recently opened the first 1BTC channel by changing the default channel size limit. With the implementation of Schnorr signature and SIGHASH_NOINPUT and other protocol upgrades, the flexibility of the contract will continue to increase. The eltoo proposal is just one example.

However, perhaps the most important part of the Lightning Network is its understanding of social scalability. As mentioned earlier, what makes a contract so strong is that the judge is not required by the exchange, but only as a backup when a default occurs.

Other "smart contract platforms" such as Ethereum and Tron completely ignore this basic insight into contracts. Instead, they chose a model in which a "judge" (i.e., the blockchain) sits on his shoulders and observes each transaction as it occurs.

The design of the Lightning Network fully follows this contract concept. With the Lightning Network, millions of transactions can be made between two people without the need for a judge at all. This provides two distinct benefits, one is that it reduces transaction costs with network users, and the other is increased privacy for contract signers. At this point, the scale and growth of the Lightning Network is partly unknown because many channels are private. However, once a problem arises, a benevolent Bitcoin judge can step in, evaluate, and resolve the dispute.

Finally, it is worth noting that the Lightning Network is only the first of many such examples. Jeremy Rubin's POWSWAP provides similar types of smart contracts for hash power derivatives, and Richard Myers' Lot 49 provides similar contracts for mesh network messaging. These innovative smart contracts were not built on other chains because of the so-called "expressive power" or "Turing completeness". On the contrary, they chose Bitcoin because of its simplicity.

People in the blockchain field often advertise that complex base-layer scripts are best for smart contracts, but they fail to realize that simplicity is essential to smart contracts because it forms the basis for predictable execution . From this perspective, the simplicity and security of Bitcoin's choice is very wise.

Going forward, I expect that those smart contracts with the highest usage and value will be constructed in a similar way and utilize Bitcoin as their virtual choice.

in conclusion

Lightning Network is the first real smart contract. By solving the problems that plague other networks, the Lightning Network has become the first glorious example of Bitcoin, which paints a bright future for network smart contract innovation.

I want to thank Bitcoin lawyers Jeremy Sklaroff and Nick Szabo for their ideas, and the Cato Institute for inviting me to do this research.


1. Nick Szabo: "Currency, Blockchain, and Social Scalability", February 9, 2017, ↵

2. Jeremy Sklaroff: "Smart Contracts and Inflexible Costs", University of Pennsylvania Law Review, Vol. 166, pp. 263-303, 2018; ↵

3. For the latest evidence that SAD is concerned about the upcoming realization, I recommend this tweet from Eric Wall, which records the difficulty of synchronizing a full node on Ethereum ; ↵