Are Smart Contracts Ready for Mass Adoption?

Nick Szabo, the father of the Smart Contract, used to compare smart contracts to a vending machine because of their automaticity. When you put the right amount of coins in the machine you receive your soda can no matter what. Once initial parameters have been set, Smart Contract will also execute regardless of external events or changing intention of the parties.

The definition given on Monax website is more accurate: « Script hosted on a blockchain which represents a unilateral promise to provide an execution determined based on transactions which are sent to the script. » Let’s break down this definition to better understand the different aspects of smart contracts:

–       A Smart Contract is a script…

Basically, a smart contract is a computer program in the same way as any other program. The programming language used depends on the platform or rather, on the blockchain that hosts the Smart Contract. At the moment, the most popular Smart Contracts platform is Ethereum and Solidity its most commonly used language.

–       …hosted on a blockchain…

Once the program is finalized, it is deployed (or compiled) and stored in the blockchain. An address (in hexadecimal) is then issued for this Smart Contract. This is the address where transactions will be sent to activate the contract.

It is important to remember that the blockchains developed since the creation of bitcoin can execute the code contained in Smart Contract. Blockchains are no longer simply decentralized records (as the bitcoin blockchain), they are also « Turing complete », which means that they are able to execute more complex programs (those of smart contracts for example).

– …and activated by transactions.

Without entering into too many details, the program of the Smart Contract contains one or several functions, which will be activated by transactions sent from user’s accounts. The functions are commands, or “determined execution” as per the Monax definition, which can be operated automatically or by external transactions.

These two definitions shed light on the technological aspects of smart contracts, as well as on the automatic and inexorable character of their execution, but they do not make any reference to their interactions with the real world and the practical legal consequences.

Contracts between humans as we currently know them are extremely complex in their execution. Many events unforeseeable at the time of signing of the contract cannot be incorporated in contracts. This is the reason why we have court and judges whose roles are to interpret the contract and try to deduct the initial intentions of the parties in the light of new elements.

It is impossible to code unforeseeable events in a Smart Contract at the time of the creation of the contract. But smart contracts will automatically execute the terms, independently of the intention of the parties, which leaves no place to the interpretation of a judge. That is why it is often considered that the « Code is Law », i.e the code of the contract is the only law applicable to the contract, even when this code is flawed and does not reflect the intention of the parties.

But since smart contracts are implemented in a (constantly evolving) national and international legal framework, code cannot be the only law applicable to contract organizing human relationships. For this reason, smart contract will need to become adaptable or updatable.

Let’s compare traditional contracts with Smart Contract to better understand the main differences:

As we can see from the above table, Smart Contract are improving many features of our good hold paper contracts, but two main points remain problematic for the application of these smart contracts to human daily relationships:

• The difficult readability of smart contracts.
• The impossibility to adapt the contracts to external events due to their immediate and irrevocable execution.

We will discuss these two points and describe the solutions that are currently tested to allow mass adoption of smart contracts.

HOW CAN WE MAKE SMART CONTRACTS READABLE?

Clark, Bakshi and Braine in their essay entitled « Smart Contract Templates: foundations, design landscape and Research Directions » have been the first to define Smart contracts by differentiating the technological and the legal aspects of smart contracts. In other words, they believe that the code that is executed and stored on the blockchain which they call « smart contract code », and the legal implementation of this technology, which are called « smart legal contracts », should be analyzed separately.

SMART CONTRACT CODE

The Smart Contract Code refers exclusively to the computer program that is the smart contract.

The purpose of this article is obviously not to enter into the details of the programming language. However, it seems interesting to give you an overview of what is actually a Smart Contract. If we take the example of the creation of a token on the Ethereum blockchain, the language used is solidity, which is the most commonly used language to program on this platform.

This example is an excerpt from one of the tutorials offered on the Ethereum website and corresponds to a very simplified version of the creation of a token.

As you can see, the name of the Smart contract is « MyToken » and it is constituted of two functions. The function « MyToken » (which has the same name as the contract, also called « Constructor ») is used only once during the creation of the Smart Contract to initialize the terms, i.e. for instance to determine the number of tokens that will be put into circulation and to store them in the memory space created on the blockchain.

The second function is called « Transfer » and when triggered will initiate the transfer of tokens from one user to another. These functions are activated through transactions sent by users from their external accounts. This memory space where the information of Smart Contract is stored is created by the « mapping ».

Note that even if solidity (derived from Javascript) is by far the language most used for programming Smart Contracts on Ethereum, it is also possible to encode in other languages such as Snake (derived from Python), LLL or XML.

SMART LEGAL CONTRACTS

The expression « smart legal contracts » refers to the legal environment in which evolves the Smart Contract and therefore is directly linked to the concept of Ricardian contract developed by Ian Grigg. The idea behind a Ricardian contract is to combine a traditional contract with a software to easily manage both the execution and the interpretation stages (1). By extension, the concept of Smart Legal Contract refers above all to Smart Contract Templates which objective are the same as Ricardian contracts, but also includes the automatic execution of Smart contracts (2).

(1) Ricardian Contracts

Ian Crigg defines a Ricardian contract as « a single document which is a) a contract offered by any issuer to a beneficiary, (b) for a title of value held by the beneficiary and managed by the issuer, c) easy to read by a person (such as a paper contract), (d) readable by a program (such as a database), (e) digitally executed, F) incorporating cryptographic key and information on a server, and g) linked to a single secured identifier ».

In short, this is a standard contract on a PDF document written in English, but some of the terms of this contract (the name of the parties, the address, the prices for instance) are variables that are changeable and directly linked to a database through a cryptographic process. You surely came across these contracts even without knowing it.

Ricardian Contracts present several interests:

1 – An automatic extraction and storage of data from the contract: As shown in the diagram below, the document and the data are extracted and submitted to a cryptographic hash (such as SHA-1) from which the information are organized and stored. The principle of the hash used in the framework of the Ricardian contracts is the same than the one used in the Proof of Work process and therefore the terms concluded in the contract cannot be changed without completely change the hash is initially obtained.

2 – Security: Ricardian contracts include the cryptographic signature of the issuer of the document. This signature is incorporated in the hash and therefore cannot be amended without producing a different hash.

3 – Negotiable by humans: you do not have to understand the cryptographic part behind the contract to use the contract. It can be negotiated by lawyer and your clients. Since its execution is not automatic, it is not a Smart Contract, the parties can also re-negotiate the contract and adapt it to new events.

OPENBAZAAR

OpenBazaar is a decentralized and open source e-commerce website. The difference between OpenBazaar and the traditional e-commerce platforms that we are currently using (Amazon, E-Bay, Leboncoin…), is that Openbazaar does not fit between a buyer and a seller by taking a commission on each transaction. Instead of visiting a Web site, you will download and install a software (the Openbazaar protocol) that grants you access to a network of peers who have the same objective as you, buy or sell. Trades and payments are completed directly between members of the network without going through an e-commerce platform for the implementation or a credit card company/PayPal for the payment. As for most decentralized applications, you do not have to disclose your personal information.

We are mentioning OpenBazaar here because they are using Ricardian Contracts to connect the members of the network.

By downloading the software, the OpenBazaar protocol, you will be able to create an ad describing the property that you want to sell and propose a price, as you would on any traditional e-commerce website. This ad is then sent on the network so that each member can access it by a simple keyword search. If two members agree on a price, the software creates a Ricardian Contract including the cryptographic signature of the two parties and sends it to a third party member of the network, the moderator, whose mission will be to check the contract and create a multisig bitcoin account.

The difference with Smart contracts is that this contract does not apply automatically, the parties are free not to buy or sell. Its execution always depends on the willingness of the parties who sign it (Cryptographically) and of the moderator of the relationship, which leads us to the last concept: Smart Contract Template.

(2) Smart Contract Template

The concept of Smart Contracts template is described in the second part of the paper written by Clark, Bakshi and Braine, in these terms: « Smart Contract templates are based on the triple architecture of Grigg’s Ricardian Contract which are the text, the settings and the Code. In this architecture, key operational settings (…) are collected from the legal text and transferred the code of the Smart contract which provides an automated execution. »

According to the same report, five conditions must be met for a Smart Contract template to exist:

1. A method to create and edit legal documents, including the legal text and parameters specific to each legal situation. These methods already exist and go from simple Word or PDF documents to software more developed such as contract Express (developed by Thomson Reuters).
2. A standard format for the storage, access and the transmission of the legal documents. This condition intends to allow the transfer of contracts between counterparties in a format that is acceptable to all, such as JSON, XML or Markdown.
3. Protocols to execute Smart contracts (with or without signature).
4. Methods for linking the Smart legal contracts (the legal text) to the Smart Contract Code (the computer language of the Smart Contract), to create a contract that can fit the legal environment in which it is created. A solution could like the one used by Ricardian Contracts, i.e. achieve a cryptographic hash of the Smart legal contract that would be stored in the Smart Contract Code.
5. Methods to make Smart Contracts accessible and in a form acceptable by the laws of the jurisdictions in which they apply. This is exactly the challenges that are currently trying to raise CommonAccord, Common Language for Augmented Contract Knowledge (Clack) or Legalese.

R3 CORDA FABRIC

All these elements seem to have been gathered by the R3 Corda « fabric » which intends to use Smart Contract Template to connect banks and considerably speed-up transactions processes.

During a presentation organized by Barclays, Lee Brain, one of the main creators of Smart Contract Template, was describing R3 Corda « fabric » with these words:

« They provide an elegant way to connect the text within legal agreements to the corresponding business logic. I emphasize to you that legal documentation processes can be lengthy, cumbersome and manual. Smart Contract Templates could simplify all of that and, because they are templates designed for reuse, they could drive the industry’s adoption of standards that are legally enforceable »(…) »This has huge potential to enable banks to mutualize costs across the industry by using common components – the potential for a paradigm shift in a field where there are billions of pages of legal agreements. »

R3’s idea is to build a closed network of banks relying on one or several blockchains that would store all the transactions, but also the legal contracts.

The ultimate goal would be to remove from the transactions circuits all the back/middle offices, depositaries, CSD and CCPs which have become extremely cumbersome following the enactment of the financial regulations (MIFID, EMIR, BASEL…) decided by the G20 after the 2008 crisis.

These Smart Contract Templates work because the contracts they replace are highly standardized and also because all the legal terms have been pre-negotiated at the network level. This kind of set-up is only possible when the parties are able to discuss the other terms upstream.

For this reason, Smart Contract Templates are well suited for consortium blockchains, which are closed blockchains where all participants are known and selected. So Corda is the platform where all the members of the R3 Consortium are able to exchange Smart Contracts to conclude transactions. But all the legal terms of the ISDA Master Agreement (contract negotiated by bank to trade financial derivatives that banks want to replace by Smart Contracts Templates) they used to negotiate bilaterally, have been pre-agreed at industry level.

CAN WE REALLY MAKE SMART CONTRACTS MORE FLEXIBLE?

Beyond the implementation of Smart Contract Templates, using closed blockchains present several advantages. It gives its members the possibility to tailor access to the contracts on the blockchain and even update them when needed. Such features would not be possible for Smart Contracts stored on a public/open blockchain, even if some solutions exist.

The problematic is indeed different for Smart Contracts that are hosted on public ledgers such as Ethereum, because it is impossible to amend the terms of a contract that has been deployed, i.e compiled by the Ethereum Virtual Machine.

The only way to introduce some flexibility in such Smart Contract is to separate the data form the logic of the contract either by creating a different contracts for each of them or by using libraries for outsourcing the logic. But either option can be complicated to implement and would not be sufficient to cover all legal specificity of complex legal contracts or solve the confidentiality issue of contracts freely accessible on the blockchain.

CommonAccord

This is why initiatives such as “CommonAccord” try to find alternative solutions to simplify the use of smart contracts. If we summarize the terms of one of its inventors, James Hazard, « CommonAccord can be described as a community of legal documents, a kind of a civil code 3.0, on GitHub and compatible with the systems of decentralized transactions based on a blockchain ».

More precisely, « CommonAccord is a programming language oriented object which supports the creation of a comprehensive system of legal texts which are codified. The aim of CommonAccord is to render the documents so flexible that a significant part of the text disappears, leaving only to the parties the negotiation of specific points and a very clear relationship. These relationships can at any time be translated into a legal document to perform audits or to sign it. »

The ambition of CommonAccord is therefore to create standardized legal texts recognized by all and stored in databases freely accessible, like Github for the software or Incoterms for commercial transactions. It would open a world where lawyer and everyone, would draft a contract (and smart contracts) by assembling pre-written text, like programmers currently do with code. Lawyers should all start learning a programming language because the “Uberization” of their profession is coming fast.

CONCLUSION:

Smart Contracts are already a reality but only for very standardized industry specific contracts exchanged within a closed network. We are far from mainstream adoption and application of these contracts in our day to day lives, but things are moving fast and we should get ready for this inevitable revolution.