Blockchain Technology and Smart Contracts set to revolutionise the Legal Sector – Part Two

Article by Matthew Pennington of Tonic Works.

In the second part of “Blockchain Technology and Smart Contracts set to revolutionise the Legal Sector” we look at Smart Contracts, and what they currently can and cannot do.

“Smart Contracts” are currently getting a great deal of media attention. It is worth pointing out straight away that they are neither smart, nor are they really contracts – but the name has now stuck. Whilst they are Turing Complete^[1], they are still just, at the end of the day scripts – chunks of computer code.

Smart contracts have the potential to change the way legal contracts are written and executed. In order to produce a smart contract, the terms have to be distilled into an unambiguous rule set so that the obligations, benefits, and penalties will be crystal clear to both parties. Knowing that any contractual breach will be enforced automatically provides greater security for the parties and means they won’t have to resort to spending time and money enforcing a breach through the courts.

Casey Kuhlman, CEO at Monax (a platform for building blockchain-based applications for businesses) eloquently summed up the current media frenzy around smart contracts when he said^[2]:

“Folks are both fascinated and confused by … what is, fundamentally, a super fascinating idea. The idea that we can have processes and procedures, with rules we agree to, running, automatically, on our behalf. This is a powerful idea. For many the power of the idea leads them off to neverland!”

Gideon Greenspan, the CEO of Coin Sciences Ltd (the company developing the open source blockchain platform MultiChain) is also quick to bring us back to reality in his article Beware the impossible smart contract^[3]:

“It’s not that people lack ideas of what they want smart contracts to do. Rather, it’s that so many of these ideas are simply impossible. You see, when smart people hear the term ‘smart contracts’, their imaginations tend to run wild. They conjure up dreams of autonomous intelligent software, going off into the world, taking its data along for the ride.

Unfortunately the reality of smart contracts is far more mundane than all that:

A smart contract is a piece of code which is stored on an blockchain, triggered by blockchain transactions, and which reads and writes data in that blockchain’s database.

That’s it. Really. A smart contract is just a fancy name for code which runs on a blockchain, and interacts with that blockchain’s state.”

Ethereum

One of the most popular smart contract implementations is Ethereum^[4] which allows contracts to be written in Solidity^[5] – a bespoke programming language.

An Ethereum smart contract is stored on the blockchain and triggered by blockchain transactions. When triggered the contract may then read and/or write data or send a response back to the whomever triggered it or it may even trigger another contract to be created.

As an example: say we have a smart contract that maintains a database of the credit available for customers with gift vouchers for a popular high street brand. The smart contract may be written to perform the following steps:

• If a customer requests to pay using their gift voucher
• Check that the customer has sufficient credit to make the purchase
• If so, release the payment amount on behalf of the customer
• Check the payment was successful
• If so, deduct the payment amount from the customer’s credit balance

Smart contracts are designed to eliminate the need for enforcement or dispute resolution because the clauses of a given contract are enshrined in code which is automatically executed without the need for third party enforcement or intervention.

By creating a contract in this fashion, you accept that:

1. Once the code is written it cannot be altered.
2. The code is publicly visible allowing anyone to review it
3. Due to the distributed nature of the blockchain each copy will have to run the same code

This caused major problems for Ethereum last year, when an “unchecked-send”^[6] bug in relatively simple smart contract (similar to the example above) led to the theft of Ethereum’s cryptocurrency “Ether” which at the time was equivalent to $50 USD. This led to a “hard fork” of the Ethereum blockchain setting a dangerous precedent.

The “hard fork” was a decision taken – with the support of the majority of the Ethereum community – to return the stolen funds. This sounds great but in practice Ethereum demonstrated that the core promise of smart contracts – the elimination of the mediator – could not delivered, as they themselves stepped in to enforce the spirit of the smart contract rather than accepting the outcome of the smart contract execution.

This erodes trust in the one of the core benefits smart contracts on Ethereum are supposed to provide – no need for a mediator. If you were party to a traditional paper legal contract and wanted to get out of it, you might hire a lawyer to look for a loophole. With the code written to create smart contracts available for public scrutiny, could you hire a programmer to look for a programmatic loophole in the same way? If you found one and used it, upsetting the other party, would you then have to resort to more traditional mediation or would Ethereum step in again to rule in the spirit of the contract? Either way, the need for a mediator has not been removed.

As any programmer will tell you, writing code that is bug free is impossible. The idea of writing your code once and never being able to change it would have most developers waking up in a cold sweat!

Gideon Greenspan of Multichain^[7] states that:

“…Compared to regular centralized computer systems, Ethereum is a much more tricky environment to code for safely. … smart contracts are software whose bugs are visible, cannot be fixed, and directly control real people’s money. This, rather obviously, is a highly toxic mix.

All of the issues with Ethereum apply equally to permissioned [private] blockchains, which still rely on immutable smart contracts – although in this case the immutability is guaranteed by a group of identified parties rather than anonymous miners. If you want to claim that private blockchains allow buggy smart contracts to be more easily rewound, replaced or ignored, then what you’re really saying is that smart contracts serve no purpose in these blockchains at all. Put simply, if something is not meant to be immutable, it shouldn’t be stored in a blockchain. Instead, stick to good old fashioned legal documents and centralized application logic, using the chain for: (a) immutably storing the data on which that logic depends, and (b) representing the final consensual outcome of applying it.”

Agrello

The smart contract startup Agrello^[8] proposes an interesting solution for ensuring that the coded smart contract meets the terms of any agreement.

Agrello provides a graphical interface along with templates, documents and wizards that allow users from a non legal background to formalise an agreement. The agreement is then translated into code and stored on the blockchain. In parallel a legal binding document written in natural language is also created and the parties digitally sign it.

This novel approach of providing a traditional written agreement whilst also leveraging the benefits of automatic execution of contractual obligations brings the best of both worlds to smart contracts.

The template documents themselves are created by Agrello’s community of lawyers and paralegals, who are paid in Agrello’s own cryptocurrency Delta, with earnings related to how popular the templates they contribute are.

Blockstack

Ryan Shea, co-founder of Blockstack^[9]  proposes a Simple Contracts^[10] model as a better way to handle coded contracts:

“The spirit of smart contracts must be able to overrule the code. Contract spirit is the equivalent of a defined set of parties making judgement calls. From this, we should adopt the following principles when writing blockchain contracts:

1. Make the contract code as simple as possible. Complexity is the enemy of security.
2. Allow the contract code to be upgraded by a majority of the parties involved. Static code is the enemy of security.

The simplest way to follow these principles is to have as little logic in our blockchain contracts as possible and do more complex operations off of the blockchain.

• Encode minimal logic on the blockchain. Only define the parties involved in the agreement and allow them to jointly hold assets and authorize transfers based on judgment.
• Create a code agreement that all parties run off of the chain. Create a communication channel where the parties can sign messages to vote and upgrade and distribute the code agreement as needed.
• Have the parties run code off of the chain. Parties may submit transfer requests and pass them around to the other parties. If a majority of parties run the code and get output that expresses approval of the transaction, then they jointly sign off on the transaction and it goes through.”

The “defined set of parties making judgement calls” could be the parties to the agreement who so long as they are both happy can proceed without a third party. Where both parties are not in agreement, a mediation process using a third party could be written into the code in the same way standard legal contracts may contain a statement that defines who is able to cast a deciding vote or arbitrate a dispute.

Whilst it can be argued that running the code “off the chain” makes sense when considering an alternative to Ethereum smart contracts, you have to place the code somewhere in order for it to run. If the code itself is held centrally in one location, the codebase itself could then potentially be modified surreptitiously for nefarious purposes, meaning when the code is run the outcome is no longer the anticipated behaviour and not in the interest of either party to the contract.

Summary

Smart contracts have the potential to change the way legal contracts are written and executed. Whilst there are many advantages to the auto-execution of the terms of an agreement using smart contracts, it seems more likely that we will see a mixed model developing that makes the most of this new technology, whilst also making provision for effective mediation when differences of opinion arise.

To this end, law firms with expertise in blockchain and smart contracts who are also able to offer smart contract mediation services will be well placed to benefit from the smart contract revolution.

^[1] Turing completeness https://en.wikipedia.org/wiki/Turing_completeness

^[2] WTF Are Smart Contracts Anyway? https://monax.io/2015/09/15/smart-contracts-intro/

^[3] Beware the impossible smart contract http://www.multichain.com/blog/2016/04/beware-impossible-smart-contract/

^[4] Ethereum https://www.ethereum.org/

^[5] Solidity https://solidity.readthedocs.io/en/develop/

^[6] Scanning Live Ethereum Contracts for the “Unchecked-Send” Bug http://hackingdistributed.com/2016/06/16/scanning-live-ethereum-contracts-for-bugs/

^[7] Smart contracts and the DAO implosion http://www.multichain.com/blog/2016/06/smart-contracts-the-dao-implosion/

^[8] https://www.agrello.org/

^[9] Blockstack https://blockstack.org/

^[10] Simple Contracts https://blog.blockstack.org/simple-contracts-are-better-contracts-what-we-can-learn-from-the-dao-6293214bad3a