What are people talking about when they talk about smart contracts?
In the context of blockchains and cryptocurrencies, smart contracts are:
– pre-written logic (computer code),
– stored and replicated on a distributed storage platform (eg a blockchain),
– executed/run by a network of computers (usually the same ones running the blockchain),
– and can result in ledger updates (cryptocurrency payments, etc).
… In other words, they are little programs that execute “if this happens then do that”, run and verified by many computers to ensure trustworthiness.
If blockchains give us distributed trustworthy storage, then smart contracts give us distributed trustworthy calculations.
Smart contracts are one of the functionalities that sets Ethereum apart from other blockchains.
I’ve found three helpful ways to bring them to life:
- Bank accounts with embedded instructions
- Replacing legal-ese with computer code
- An actual smart contract example
1. Bank accounts with embedded instructions
There are some elements of bank accounts that behave like smart contracts.
My bank account has a balance. Every month, I have an automated payment that deducts a fixed amount and sends it to my landlady. If there isn’t enough money in my bank account, the payment fails, I get fined, and another workflow is triggered.
There are instructions I have set up which are associated with the account.
This is similar to what a smart contract can do, except that a smart contract running on a blockchain is run by many parties rather than being controlled by a single one.
2. Replacing legal-ese with computer code
A smart contract is some code which automates the “if this happens then do that” part of traditional contracts. Computer code behaves in expected ways and doesn’t have the linguistic nuances of human languages. Code is better, as there are less potential points of contention. The code is replicated on many computers: distributed/decentralised on a blockchain (more on that later) and run by those computers, who come to an agreement on the results of the code execution.
The idea is that you can have a normal paper contract with all the “whereas” clauses that lawyers enjoy, and then a clause that points to a smart contract on a blockchain, saying “this is what we both agree to run and we will abide by the results of the code.”.
3. An actual smart contract example
Here is the code for a basic smart contract that is written for use on the Ethereum blockchain:
An example smart contract on Ethereum. Source: https://www.ethereum.org/token
Ethereum.org explains what it does:
It is a contract that generates 10 thousand tokens to the creator of the contract, and then allows anyone with enough balance to send it to others. These tokens are the minimum tradeable unit and cannot be subdivided, but for the final users could be presented as a 100 units subdividable by 100 subunits, so owning a single token would represent having 0.01% of the total.
How is this different to automated banking payments?
Control
My bank is the ultimate guardian of my bank account. It has complete control, and can arbitrarily add money to my account (haha) or subtract it (funnily enough, this does happen, and I need to argue to get it back).
In a correctly set-up blockchain ecosystem, there should be no single source of control. The distributed layout with consensus mechanisms mean that multiple parties are constantly checking and re-checking and updates to the ledgers, and anything that doesn’t conform to pre-agreed rules is rejected by other participants.
Code
With the bank account, there is some logic creating transactions on a monthly basis. That code sits on one computer and is executed by one party (the bank). There are internal controls and reconciliations, but there is no external validation.
With smart contracts running on a blockchain, the logic is run in parallel on all the participating computers, and the results are compared by all participants. Participants only change their own version of the ledger if they agree the results. No one can cheat a blockchain, in theory.
Transparency
For all participants in a blockchain ecosystem to run the same code, each verifying the other, the logic of the smart contract must be visible to all. This means anyone can look into a smart contract, and if you like the logic, you can use it. If you don’t, you don’t. There will be smart contracts for general usage, and also very specific smart contracts. The transparency is both a pro and a con. It’s useful to all stakeholders of the contract to agree on what happens; on the other hand it’s not just the stakeholders that can see what happens – it’s everyone on the network. Privacy in blockchains is a contentious issue. There are solutions to the privacy-vs-validation tension being discussed, some using zero-knowledge proofs; which will be the subject of another post.
Flexibility
The logic that I can run within my bank account is limited to recurring payments, and maybe some other basic things – I haven’t investigated fully. I can’t, for example, automate a payment from my salary account to my savings account every day it is sunny, then have it all sent back when there is a storm (the ‘saving up for a rainy day’ smart contract).
A so-called “Turing complete” smart contract can do anything that a normal computer can do, though the blockchain version will run much more slowly and be more expensive to run than on a regular computer (depending on the set-up of the blockchain), because ultimately you need to pay for all computers on the network to run the code in parallel.
Why are smart contracts useful?
As discussed in my post about blockchains, shared ledgers can be useful when you have multiple parties, who may not trust each other fully, each comparing their version of events with each other.
For example when two banks do a complex derivative trade with each other that doesn’t go through a clearing house, it is called an “Over The Counter” or OTC trade. These are agreements between the two banks, without third party validation. These trades are usually bets – i.e. variations of “if this happens before the end of the year then you pay me, else I pay you”.
Both parties have a copy of the original trade documents (the terms and conditions of the trade), and they both have a view on the external dependencies of the trade. They should both therefore agree on the outcome of the trade i.e. who wins the bet. However this is not always the case.
A mismatch or “break” can occur, where parties don’t agree on the outcome of the trade, due to a number of things:
- A mutual misunderstanding of the initial trade terms
- Confusion due to multiple copies of the original trade terms (usually there is back-and-forth on the wording of the documents, with in-house lawyers on both sides trying to protect their interests)
- Or a disagreement with what actually happened in the external dependencies
With a smart contract, there is only one set of trade terms, written in computer code, which is much less fluffy than legalese, and agreed upon up-front. The external dependencies (price of oil, share price of Apple, etc) can be fed in via a mutually agreed feed. The contract will live on a blockchain, and run when an event happens or when the bet expires.
The bet payout can be stored in the smart contract itself: the contract is “primed” by both parties funding the account with their maximum loss, and then the payout occurs at the event. This is potentially cleaner than the existing process, however there remain privacy issues with other blockchain participants having read-access to this contract and being able to see the terms of a bet between two of their competitors. Also a lot of trades in financial services are currently done on credit and margined or collateralised; the necessity to pre-fund the total payout with the full value of the potential payout, in the currency/asset of the payout would not be attractive.
Current smart contract offerings
The existing blockchains have varying degrees of being able to run smart contracts. Below is a selection.
Bitcoin’s platform is great for processing bitcoin transactions, but otherwise has very limited compute ability. Within the scripts of bitcoin transactions you have a very limited ability to implement rich logic. An example of what is possible in bitcoin is logic requiring multiple signatories to sign a transaction before a payment is made, like needing two signatories in a cheque. However major changes would need to be made to both the mining functions and the mining incentivisation schemes to enable smart contracts proper on Bitcoin’s blockchain. See a gentle introduction to bitcoin for more.
Sidechains, i.e. blockchains connected to Bitcoin’s main blockchain could enable smart contract functionality: by having different blockchains running in parallel to Bitcoin, with an ability to jump value between Bitcoin’s main chain and the side chains, side chains could be used to execute logic.
NXT is an public blockchain platform which includes a selection of smart contracts that are currently live. However it is not Turing-complete, meaning that you can’t code up anything you want, you have to use the existing templates.
Ethereum is a public blockchain platform which is currently the most advanced smart contract enabled blockchain. With a “Turing complete” coding system, theoretically you can put any logic into an Ethereum smart contract, and it will be run by the whole network. There are mechanisms in place to prevent abuse, and you need to pay for compute power, by passing in “ETH” tokens, which act as payment for the miners who run your code. See a gentle introduction to Ethereum for more.
Question marks
Decentralisation is expensive. The more computers that run code, the more expensive things get for the end uses. The decentralisation doesn’t come for free. If you’re using a system that has 10,000 of computers running your code, somehow those compute costs need to be paid: the computer operators aren’t doing this for free.
In a public network, the users necessarily end up paying to run all the machines on the network. Having every computer (“node”) in a system store data (eg a blockchain) and then run the smart contract code embedded in it is a lot more expensive than having one or two participants run the code. Currently, nodes have to compute everything even if they aren’t attempting to mine the block, because the only way to validate a block is to run the code yourself and compare your answers to the mined block.
So surely it’s good enough to have the code written on a blockchain, so that parties can see for sure what the smart contract they are committing to looks like, then the code can be run privately, perhaps by the very parties to the transaction? This would save on compute costs. The code could be regarded by the miners and nodes as regular text, as opposed to instructions which need to be executed.
As an industry we need to be able to articulate why a decentralised system of data storage and compute is worth the cost. A more efficient and cheaper alternative would be for one organisation to centrally act as the storage and compute platform, where users / participants could log in, upload their smart contracts, have the counterparty sign these off, and then both parties would rely on the result. Of course you lose the guarantees of decentralisation (immutability and I’m not sure what else).
The future of smart contracts
There’s also another secret which the industry isn’t talking about: People like optionality. In many contracts, clauses are written into things on purpose to create a channel for arbitration. For example in a flat rental agreement, wear-and-tear from tenants is acceptable, but major damage needs to be repaired. How does code define these things? Force majeure is present in many contracts to allow for wiggle-room for the parties involved. In a smart contract environment, how does one party call that without abusing it or referring to a human arbitrator. So many grey areas, so many things to figure out…
I have no doubt that in the end, shared ledgers will have a role to play in removing the need for trust among multi-party agreements. Smart contracts make sense for all parties by reducing operational risk, and can be thought of as automated trustworthy workflow between parties without a central specific co-ordinator. However there are a number of hurdles to adoption, as with blockchains in general.
What’s the approach? Forward-thinking law firms should future-proof by tooling up and building in-house capabilities for coding smart contracts. Students with legal aspirations should learn dual skills of law and computer programming. Those who can bridge that gap between law and computer science will be highly sought after in the near future.
With thanks to Marcus Swanepoel for comments and ideas.