Smart Contracts

Fulfilling Nakamoto's Dreams

Publié le March 7, 2018

Contracts are essentially about strengthening human relationships in business and beyond

But they suffer from the vagaries of textual interpretation. As a remedy, computer code execution is objective. Can blockchains by way of ‘smart contracts’ enlighten this ancient human activity with its objective code execution and trustless economics?

Business could be such a breeze — if it weren’t for those pesky humans…

Not-so-clever contracts, The Schumpeter blog, The Economist

Contracts aim to secure us from counterparty risks. But legal texts mean1 different things to different people, thereby leaving room for the parties to act on it in their own way. This is unlike computer code that executes the same way for the same set of inputs on the same kind of computer.

Code is objective, human language is not.

Imagine contracts written in computer code that are executed automatically under the conditions set in the contract. That is the promise of smart contracts.

Smart contracts are self-executing programs that run on blockchains and accept digital signatures to record the agreement between stakeholders.

  • Car Sales Contract — “Transfer the title of the car” only if “the asked amount has been paid”.

  • Fish Sales Contract — “Allow this fish to be sold” only if “it is organic and fair trade in the supply chain”.

  • Crowdfunding Contract — “Transfer a part of the fund to a project owner” only if ”the supermajority of backers have approved to do so”.

A network of computers periodically checks whether the conditions of any of these programs are ripe for execution. If most of the computers approve that it is so, the program is executed without needing the parties to do anything.

Currently, smart contracts are supported by most major blockchains and distributed ledger platforms, such as Ethereum, Hyperledger and Corda; the most popular of which is Ethereum, and will be the primary reference for this article.

1 The Case of the DAO

Consider one of the most pivotal smart contracts in the Ethereum blockchain, The Decentralized Autonomous Organization, or The DAO. It was basically a decentralized crowd funding application, as conceived on May 2016.

On June 17, 2016, someone was able to draw out a sizeable portion of the fund in a highly unexpected way. It was beyond the expectations of the creators and the funders of the contract. They claimed it to be a “hack”, thereby demanding that it be rolled back or blacklisted.

But for the “unexpected” transaction to have been executed in the first place, it had to get approved by the majority of the network as is the case with all programs in a blockchain. The code, devoid of human interpretation, was executed correctly by the computing machines.

There is an open letter claiming to be from the “hacker”, where his interpretation of the contract was described:

I have carefully examined the code of The DAO and decided to participate after finding the feature where splitting is rewarded with additional ether. I have made use of this feature and have rightfully claimed 3,641,694 ether, and would like to thank the DAO for this reward. It is my understanding that the DAO code contains this feature to promote decentralization and encourage the creation of “child DAOs”.

Finally2, the interpretation of the creators and the funders of the contract, as backed by the Ethereum foundation, won over that of the so-called hacker: the transaction was rolled back. This was a controversial decision leading to a part of the network breaking off to create their own blockchain where the transaction was not rolled back.

Is correctness of code execution the final arbiter of a contract dispute, or are we to interpret the intentions behind the code over its correct execution? In the same spirit, is code more important than its execution?

2 Key Confusions Behind Smart Contracts

2.1 Self-executing programs

The claim to fame for smart contracts is that it is the only means to execute programs securely that suffer from counterparty risks. Think of a Delivery-versus-Payment scenario, such as the car sales agreement from above.

The buyer and the seller can execute their sale program on the blockchain, with the guarantee that neither would be able to take advantage of it in any way.

But this is not because of anything specific that smart contracts bring to blockchains. Rather it is the opposite — blockchains provide objective code execution infrastructures.

This is because, code is executed in blockchains only if it is approved by a majority of computing nodes that it follows the protocol. This ensures that none less than the majority of computing members own or control the execution of a code running on it. Neither the developers of our car sales contract codebase nor the parties of the contract (buyer and seller) will be able to influence the contract execution to their advantage.

In fact we can implement escrows, like the one above, using scripts in Bitcoin3 irrespective of the fact that Bitcoin does not offer an expressive computing language4 like that of Ethereum. All we need are an objective code execution infrastructure (i.e., the Bitcoin blockchain), and a programming language with the conditional operators to verify if the amount asked has been payed at the same time as the car title has been given for exchange.

Therefore, we need only a limited set of operations in blockchain-based code to guard against counterparty risks. Smart contracts are an overkill for the job at hand.

This is the source of the first confusion — smart contracts introduce self-executing programs to blockchains. The truth is the opposite.

2.2 The Inevitability of Human Intervention

The inevitability of human intervention to resolve disputes is not because there were bugs in the smart contract code. This was about5 language and reality.

Even if a smart contract code is bug free and does exactly what it is written to do, there is no way to ascertain that it is doing exactly what the stakeholders intended it to do as described in its specification.

The best we can get is specifying the software in formal terms, and then deducing the code from it. There is currently a lot of research by Ethereum developers to apply this approach. However, formal methods are difficult to specify complex business processes.

As evidenced in The DAO dispute, programmers are the mediators for smart contract disputes, just as lawyers are for legal contracts. Reddit and Twitter have become the arbitration forums for smart contracts, but there are no formalized rules and precedence on these kinds of mediation.

Bugs (or theft) are not the most important factor behind disputes, the limits of language and understanding are. This is the source of the second confusion affecting smart contract proponents — Irrespective of bugs or theft, human intervention is inevitable.

2.3 Humans over Machines

In a techno-utopian world, machines interact with each other executing code when the conditions for business are ripe without having to wait for pesky humans. This is prevalent beyond the world of blockchains, as can be seen in IoT networks as well.

Machines are predictable, humans are not.

But machines execute code on behalf of or at the command of humans. If machines could be self-sovereign to the extent that they never need any humans, there will be no kill switch6 when things go very wrong.

The “no kill switch” dilemma is faced when the human members of a blockchain have to decide whether to change the history of a blockchain to handle disputes. This turns into a highly political process since blockchains are supposed to respect the immutability of non-living machines over the changing nature of the humans operating them.

This is the source of the third confusion — over-valuing the mechanistic execution and under appreciating human creativity and change.

2.4 Law over Code

Smart contracts enthusiasts often tout the famous line by Lawrence Lessig, “Code is Law”. This is problematic.

Even contractual law is not Law7. Law becomes the law-that-is-enforced only after it is interpreted by human institutions of authority and power. These institutions provide the formalized rules to interpret legal text correctly — which other cases or contracts can be cited or can override it, criteria for applicability of the contract and so on.

In the absence of institutional intermediaries, a contract is enforceable only within the boundaries of the parties who agree to it.

When that agreement gets questioned due to a difference of individual interpretation, there is no higher authority to appeal to for smart contracts. This is because Reddit, Twitter, and the Ethereum Foundation do not equal the institutional intermediaries that legal contracts operate under.

Smart contracts are not legal contracts; at the most, they are like the corporate by-laws that are valid within the jurisdiction of the corporation.

Computer code, being deterministic, is like the laws of the universe, not the law of contracts. As Lawrence Lessig puts it in his Open Code and Open Societies:

Now I’ve made something of a career telling the world that code is law. […] I meant that originally as a metaphor. Code is not literally law; code, I argued, was like law.

Lawrence Lessig, Open Code & Open Societies

A more accurate way of putting it is that smart contracts are allegal8, in that they are outside of legality, neither legal nor illegal.

This the source of the fourth confusion — the two meanings of law (contract versus physics) are considered as one.

2.5 Summary of the key confusions

1. Self-executing programsSmart contracts introduce self-executing programs to blockchains. The truth is the opposite.Neither the developers of a smart contract codebase nor the parties of the contract are able to influence the contract execution to their advantage.Blockchains are fundamentally infrastructures to execute code objectivity, something that is leveraged by smart contracts; you don’t need a smart contract for this, bitcoin scripts can do this as well.
2. The Inevitability of Human InterventionHuman intervention only to fix bugs in smart contract codeCode written clearly can accurate reflect the contractual termsEven without bugs or thef, the intentions behind a code is interpreted differently by different people, requiring humans to clarify whether the execution is acceptable Effects: Potential gains with accepting this new applicant
3. Humans over MachineSmart contracts over-value mechanistic execution and under-appreciate human creativity and change.Remove the inconsistencies of human control so machines can run predictablyHumans will always prevail over machines as the later execute at the command of humans, and not for themselves. Predictability ≠ Perfection
4. Law over CodeCode is LawCode is blind, so is LawCode is like the codified laws of physics, not the laws of contracts

Much to the chagrin of techno-utopians, humans remain irreplaceable in our human world of business.

3 End-to-End Contracts

Smart contracts are good at capturing the digital agreements to run a piece of code, but a contract is more than that.

To reach an agreement, there’s the “meeting of minds” where parties meet each other to discuss their interpretations, as mediated by their respective lawyers.

Then post-execution of a contract, in cases of disputes, the differences in individual interpretation are discussed, as mediated by the respective lawyers in a court of law, or via arbitration, to arrive at a resolution.

Contracting is a process as follows.

Meeting of Minds → Agreement (signatures) → Execution on conditions being met → Dispute resolution if needed.

Having no human angle, both these pre- and post-execution steps are missing in smart contracts.

4 Making Contracts Smart Again

At Stratumn, we model contracts as processes with each of the four steps above as milestones in that process. Each milestone has steps leading it, where the steps have the following.

  • Who. The parties involved in, including mediators and institutions if needed.

  • What. The content of the terms and conditions being discussed, and the interpretations behind each, other contracts being referenced as a precedence, links to code that needs to be executed with conditions that are to be checked.

  • When. Timestamps of each and every step in the process.

  • Where. Ensuring that the contractual process follows the sequence as prescribed by the jurisdiction that the contracted parties apply to.

  • Why. Reference to external documents rationalizing the steps, that could be a document in legalese and a corporate by-law text if required.

We refer to the above structure as Proof of Process (PoP), which is a protocol that enables parties to trust a common process, which in this case, is the process of contracting.

Using the above model, the contract maintains a cryptographic audit trail that secures the contractual steps for all of the stakeholders.

This audit trail is shared between all of the stakeholders who are all connected to their respective blockchain nodes that are responsible for executing the agreed upon code as per the contract.

By separating the contracting process (PoP) from the execution of any code that the contractual agreement mandates, it leaves room for interpretation and dispute resolution in a legal and sound manner.

5 Conclusion

Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible since financial institutions cannot avoid mediating disputes.

Bitcoin Whitepaper, Satoshi Nakamoto

In regards to transaction reversibility, two roads emerge from here onward:

  1. Ban it, so there’s no need for mediation, but we end up with a technology that is fundamentally incompatible with the human reality of impermanence9.

  2. Allow it by mediating it. Either offchain (outside the blockchain, like Ethereum), or onchain (as part of the blockchain, like EOS and Tezos)

Without a powerful dispute resolution model for our blockchain-based processes, we will never fully realize Nakamoto’s dream.


1. Legal Language Errors

All constitutions in the world are riddled with passages that are incorrect from a language construction point of view? This is because they are ratified by legal experts without consenting any literary experts. Take for example, the one too many commas in the United States Constitution, such as the 2nd Amendment, “A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed.” — it is just wrong English. Or, the case of loosing 1 million Canadian dollars for a single comma in a contract in Canada.

2. The DAO Fork Decision

What followed next was debates and discussions outside of the Ethereum blockchain, since it lacks a built-in subjective layer for dispute resolution. It was carried out in centralized websites, such as Reddit, Twitter, Medium, followed by a final voting with carbonvote where only 4.5% of the network turned up to cast their vote.

3. Bitcoin Escrow

For examples of escrows written in Bitcoin script.

4. BTC versus Ethereum programming paradigms

In regards to choosing between programming languages that run on blockchains, Turing complete or not is besides the point. In fact if we consider the two most popular ones, Bitcoin and Ethereum, neither offer Turing complete code execution as the code always halts.

Since you pay for computations in Ethereum, the smart contract execution is bound by the economic limit which will run over in case the execution goes on forever. Bitcoin does the same by having no loops in its programming language.

In spirit of blockchains being platforms to execute code objectively (section 2.1 from the article), the deeper factor is that of ensuring predictability of code execution over its finality. This is addressed in Bitcoin, not Ethereum.

Bitcoin uses a declarative programming language for its scripts, - the programmer instructs what to do. The Bitcoin interpreter decides “how” to do it in one of the inbuilt ways, thereby making the execution predictable with no side-effects. In contrast to Ethereum Solidity language which is an Imperative language, the programmer instructs the what by specifying the “how” to do it. The “how” does add an enhanced level of expressiveness that is lacking in the imperative domain of Bitcoin scripts but it gives rise of corner cases as seen TheDAO and the Parity Hack or 2017. However, Bitcoin scripts makes for a better security in terms of knowing what the program will exactly do.

Solving the problem of Halting is necessary but not enough, solving Predictability makes its complete.

This insight is the raison d’etre behind the TxVM approach from Chain where they combine the best of both Ethereum and Bitcoin.

_A TxVM transaction is an imperative program, as in Ethereum. Running it produces a declarative log of proposed blockchain state changes. Crucially, the program executes in isolation from the blockchain state, preventing it from having unexpected side effects in other contracts. TxVM transactions can thus be verified, and their logs computed, in parallel.

5. Code is Text

Code that serves human purposes, as a social network website, is not just instructions for a computing machine, but is set in a human context. There has been a growing trend in reading computer code as if reading a piece of literature. This is inspired by the post-modernist approach to read a text as it reveals itself in its contextual and cultural milieu.

6. Kill Switch in Regular Contract Law

In regular contract law, the kill switch is enforced under force majeure measures, which “is a common clause in contracts that essentially frees both parties from liability or obligation when an extraordinary event or circumstance beyond the control of the parties, such as a war, strike, riot, crime, or an event described by the legal term act of God (hurricane, flood, earthquake, volcanic eruption, etc.), prevents one or both parties from fulfilling their obligations under the contract” [Source: Wikipedia].

7. Legal Formalism versus Legal Realism

These are opposing schools of jurisprudence. The former states that the law can be interpreted based on formal rules, thereby, making the interpretation objective and same for all parties and judges. The later claims that the social context in which the law is applied in instrumental in interpreting the law, thereby making the application of law contextually dependent. Smart contracts, seems to naively take on the formalist approach.

To bridge this gap between smart contract code and the legal text, there have been some approaches to link the two explicitly — Ricardian Contract, CommonAccord, Legalese, the Internet of Agreements, – the first of which is used in EOS blockchain, Corda DLT, OpenBazaar, and some others.

8. Allegality

Term introduced by Ethereum co-founder, Gavin Wood, — meaning decentralized applications “don’t care”; they are like forces of nature, are outside of the law, that they are neither legal or illegal.

9. The Human Reality of Impermanence

Human life progresses not in a straight line of happenings, but of a back-n-forth motion between what did happen and what should happen. What makes it even more non-linear is that the “should” depends on the who is asking that question, hence there are no single “shoulds”.

As for The DAO, what is one person’s hack, is another’s feature. But that does not mean there are no hackers, it depends on who is asking – its complicated and needs debates and arbitration to resolve for the time being. There are no permanent resolutions.
Any software code that does more than one-off transfer of value, can not avoid disputes due to the complexity of changing human relationships.

En savoir plus sur Stratumn et notre solution basée sur la blockchain ?

Notre produit