A gentle introduction to smart contracts
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.
An interesting piece, thanks.
In my opinion, self-executing contracts may be helpful for transactions where performance can be ascertained by a machine. An item scanned on delivery by a courier service can trigger an automatic payment. A change in the public registry can trigger payment.
But take services. In many cases you cannot have the machine measure how well the service was done. It would take a human eye, or, ear, or other sensory organ, and a brain to make an assessment of performance. At a maximum, you can set up an auto payment subject to absence of a certain trigger (say, a complaint filed with respect to performance). Then, an expiry of a time period can trigger a monthly fee charge. Thus, a self-executing contract would work on a presumption of performance, not actual performance. That is, you cannot really make a truly self-executing contract for services.
And no, force majeure clauses are not made by us lawyers for our own sake. There are simply situations where the parties agree it would be unfair to demand performance as if nothing happened (as if your factory was not destroyed by a flood). Demanding performance in spite of hardship in such a case would simply be considered unfair.
And still, there might be disagreement whether in a particular case there was indeed an excusable reason not to perform. Whether, say, the flood was due to factory’s demolitions contractor blowing the dam in the first place. And this is just one example where you cannot avoid a human third party to resolve the dispute. You can’t code for that.
Like your article Antony, but I think you can widen this to cover even more public areas of use !
As in Denmark (native living here), we have been through the process creating the perhaps most digitalized public state on earth, and I know how hard that was to get there !
So I look forward to much more transparent legal ‘Contracts’ based on BlockChain (and its future successors). Have a look on my Ideas:
http://rosenberg-it.blogspot.com/2015/11/why-blockchain-algoritm-is-versatile.html?view=flipcard
Cheers
Peter Rosenberg
Great write-up Antony! Thank you.
Why don’t you use the ‘decentralized’ instead of ‘distributed’ in the paragraph “If blockchains give us distributed trustworthy storage, then smart contracts give us distributed trustworthy calculations.”. ‘Decentralized’ is a better word, right?
This was clear and readable and useful. But the subject deserves more frankness about fundamental issues. I speak as both an attorney and a software developer, and therefore with the greatest possible interest. To the extent that code can automate mechanical transaction elements — like payments — its application is obvious. To the extent that the execution of a contract depends on human agreement that the conditions of a contract have been met, automation can add nothing and only confuses the situation — at least at any level that does not make use of AI to “adjudicate” disputes about contractual elements, which is a step far, far above (both philosophically and technologically) anything discussed here.
The practical fact is that any kind of serious contract — employment, sale of a business, real estate construction — is fundamentally providing a framework for the transaction to take place in the business context, embodying expectations of the parties in objective terms as best as possible. But expectations, and whether they have been met, are the very essence of “subjective,” not objective. In short, there is no way that one can avoid the human decision that, for example, a custom-constructed office building has met the expectations of the purchaser in terms of standards of workmanship or other elements. The purchaser has to effectively decide whether to contest the result before paying the final balance or not, and many factors beyond the nature of the physical construction will feed into this — above all, the cost and hassle of litigation. Thus contract law has always been part of the game of business, a weapon in the war to make a buck. What lawyer does not understand this?
Lawyers writing contracts are selling services that business people need. Businessmen need to memorialize expectations and to provide for contingent solutions to disagreements within the limits of the real world. When the promoters of smart contract solutions face flatly what contracts are really all about, and why attorneys expect high fees to negotiate and draft them, we may start seeing some progress.
Isn’t the best use where services are concerned, as contracts that benefit from automation between parties where a relationship of trust exists already? Pre existing trust networks corresponding to different levels of trust like Google circles could be used by individuals to monetize themselves where price of default risk is the severance of the relationship that exists prior to the agreement. The structure built into the contract could provide a structure and convenience absent in informal loans and accounts run on tic as in the case of repeated clients of independent professionals who would also benefit from the accreditation afforded by verification of past record.
I consider effective the use of smart contracts because they certainly propose a safer way of dealing with token proposals, they don’t need intermediaries to be created. I read about it for the first time in Webchain when I was researching for a website to mine and I found out that site itself is actually pretty profitable because besides offering smart contracts, their algorithm is ASIC resistant so you don’t need high-end hardware to mine in their pool.
I must say that this article provides important insights into smart contracts and blockchain technology at large. Now that there is a wide variety of potential blockchain projects that are being released, including webchain.network, we surely need these perfect reads for blockchain newbies to learn more about blockchain technology as they interact with it practically.