As I mentioned in my previous post, Blockchain is a design pattern that describes a system or network of nodes in which the ledger (i.e. a common temper-proof ledger that contains all the transactions) is maintained on multiple nodes, and there is a consensus (among the nodes) on which nodes have correct copy of the ledger (so that the system can recover even if some of the nodes are compromised). Each participating node has a piece of code that receives the transaction request, validates the request (i.e. checks the transaction pre-requisites), and executes the transaction (i.e. update the underlying asset state). Typically, this piece of code/program is called a “Smart Contract”. Depending on the underlying Blockchain implementation, this code can be written in different languages. For example, Ethereum supports Solidity, and Hyperledger currently supports Go (or GoLang).
But as Stark points out, the term “Smart Contract” is also used to represent a legal contract that can be expressed and executed in software. He distinguishes the two as – “smart contract code” and “smart legal contract”. Clack, Bakshi, and Braine combines the two aspects, and provides a more complete definition of “Smart Contract” –
“A smart contract is an agreement whose execution is both automatable and enforceable. Automatable by computer, although some parts may require human input and control. Enforceable by either legal enforcement of rights and obligations or tamper-proof execution.”
Smart Contract code have some unique characteristics.
- Deterministic: Since a Smart Contract code is executed on multiple distributed nodes simultaneously, it needs to be deterministic i.e. given an input, all nodes should produce the same output. That implies the Smart Contract code should not have any randomness; it should be independent of time (within a small time window because the code might get executed a slightly different time in each of the nodes); and we should be able to execute the code multiple times.
- Immutable: Smart Contract code is immutable meaning that once deployed it cannot be changed. This of course is beneficial from the trust perspective but it also raises some challenges (e.g. how to fix a code bug) and implies that Smart Contract code requires additional due diligence/governance.
- Verifiable: Once deployed, Smart Contract code gets a unique address. Before using the Smart Contract, interested parties can view or verify the code.
The Idea of Smart Contracts came from Nick Szabo who said “Many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher.” In reality, it is hard to fully embed the entire contractual clause in the software – for technical and legal reasons. Let’s look at the technical reason in the context of a simple financial contract – “if the stock price goes above X then the stock should be sold”. There are two problems in embedding this clause into a Smart Contract code – first, it is time dependent (assuming the external call to get the stock price is made from within the Smart Contract which is a no-no for some people); and second, it cannot be executed multiple times (unless Stock Exchange is part of Blockchain). From a legal point of view, a contract typically contains terms and conditions (to protect the parties from damages) that cannot be converted into executed code, e.g. an indemnity clause.
Different Blockchain implementations are trying to address these problems in different ways. For example, to address the technical limitations, Ripple relies on “Smart Oracles” (or Codius) to implement the business logic which essentially moves the business logic out of Blockchain and puts it into the application layer (that can be attested by a third party). To address the legal issue, Eris/Monax uses Dual Integration which ties the Smart Contract code to the legal document and vice-a-versa. R3/Corda, on the other hand uses Smart Contract Templates which captures a Smart Contract as Ricardian Contract triple of “prose, parameters and code”.
Conclusion: Smart Contract is a powerful concept that allows the Blockchain design pattern to be applied to complex situations. But Smart Contract has some limitations which need to be kept in mind when thinking of Blockchain use cases. In addition, given its impact, Smart Contracts require extra due diligence/governance.
For more on blockchain, join our upcoming webinar:
