If the first generation of Blockchain platforms was defined by the transaction-based distributed ledgers such as Bitcoin, the next generation is clearly defined by the advent of Smart Contracts.
Smart Contracts are logic written in computer code (in languages such as Solidity, Go, Python, Java) that define how and when an agreement will be enforced. The smart contract is deployed on the Blockchain. Any interaction with a smart contract is recorded as a transaction on the Blockchain.
The term was coined over 20 years ago by the computer scientist, Nick Szabo. His intention was to design an electronic commerce protocol which would facilitate business transactions between strangers on the internet without the need for trusted intermediaries.
The Bitcoin Blockchain fulfils the need for which it was created – facilitating payments. But it does not directly support Smart Contracts. It has made a conscious decision to only support about 250 opcodes. It omits the use of Turing-complete languages for its programming.
Sensing the interest of the industries, many Blockchain platforms leveraging the benefits of smart contracts have come up. Some of the more popular ones are listed below.
Ethereum, Lisk, HyperLedger Fabric, R3:Corda
How do Smart Contracts work?
It’s a three-step process – Deployment, State Change, Querying.
Let’s use the example of a Blockchain-based simplistic Voting System to explain the workings of a smart contract. A Voting System would have three main entities – the Poll, the Voter and the Auditor. These entities would work under given business rules – for example, a poll must maintain the count of votes cast under each option; the voter must be valid and must cast only a single vote on a given poll; the auditor must have access to the audit trail of the poll.
The first step in setting up the Voting System is the creation of the entities – Poll, Voter and the Auditor.
The poll is “created” in the form of a smart contract made up of two aspects – its state and its behavior. The behavior is an implementation of the business rules that need to be enforced. The act of creating the poll is the act of deploying the smart contract. Taking into account implementation on the Ethereum platform (the most popular of the lot), a smart contract can be equated to a “class” in an object-oriented system. Deploying a contract is like instantiating an object instance of the class such that it transforms to a tangible entity (object) from a conceptual entity (class). At the time of deployment, a contract is assigned a unique public key on the Blockchain. This key acts as the handle for accessing the smart contract instance.
The Voter and Auditors are valid accounts on the Blockchain with unique Public keys of their own. The access rights of these accounts (yet another business rule), can be built into the poll smart contract (or in a separate smart contract that may act as a Voting Manager).
Once the poll, voter and auditor have been set up, the second step is casting a vote on the poll.
“Casting a vote on a poll” is akin to changing the state of the deployed smart contract. This can be done via a call to a publically exposed method (say, castVote()) on the poll smart contract. Think of this as a public method on a class. The method records the vote by changing the state of the poll, i.e. its vote count per option. In addition, it executes the business rules, e.g. a voter must cast his vote only once on a given poll.
Each such interaction with the smart contract is recorded as a”transaction” on the distributed ledger of the Blockchain. In the usual way, multiple such transactions are bunched together in a Merkle tree and stored in a block on the Blockchain. The validation of the transactions and the blocks is achieved through the distributed consensus protocol of the Blockchain platform.
Now that the vote has been cast, the last (optional) step is auditing the system.
The list of incoming votes is a transparent, real-time and public audit trail that helps an auditor verify voter’s intent. In Ethereum, incoming votes are exposed as “events” that can be tracked real-time as they happen. If an auditor wants to verify the counted votes against what has been recorded on the Blockchain, he may query the smart contract for the poll to get the total count of votes that have been recorded. Note that querying a smart contract is not recorded on the Blockchain as a transaction.
The use of smart contracts running on distributed ledgers has given a tremendous boost to Blockchain Technology resulting in its version 2.0 – “The network of computers”.
Enterprises see its potential in cutting reconciliation cost, risk and the red tape prevalent in the workflows today. They look forward to replacing the trust-deficit between counterparties with the deterministic nature of a computer code, thus reducing/removing intermediaries. New and efficient collaborative business ecosystems can be created through the use of smart contracts. Before the smart contract-based Blockchain were introduced, such agreements between collaborating parties could not be auto-executed/enforced since they maintained separate databases.
Many different industries such as Finance, Entertainment, Insurance and Public Sector have been attracted to the potential of Blockchain smart contracts. Given the current pace of PoC and prototype development, we believe that smart contracts will find a near-term adoption in production environments of enterprises.
Benefits of Smart Contracts
To understand the benefits of smart contracts, let’s take an example of how contracts are enforced today – a sales deed executed between a home buyer and seller is presented in the form of a document (digital or paper). Enforcement of the sales deed and validation of its conditions can either be done manually or replicated in the form of a computer code. There are multiple flaws in this system. The document is open to forging or destruction. The replicated codebase may or may not correctly and exhaustively represent the terms of the sales deed. Enforcement of the contract can be impacted by human error or malicious intent. Enforcement of the contract may require the help of third parties such as Law or Property firms.
In contrast, once a sales deed in the form of a smart contract is agreed and written on the Blockchain, it becomes non-fungible. It can be made to automatically execute and enforce the terms agreed by the buyer and seller, thus increasing accuracy, reducing time and cost, and risk of manipulation. This overcomes the flaws of the current systems and opens up avenues for disintermediation. In a real implementation the sales deed would be represented in a hybrid manner – a digital/hard copy and a self-enforcing smart contract on the Blockchain.
In the example of the Voting System on a Blockchain, the benefits are not limited to privacy, transparency, public verifiability and corruption-resistance. It also includes a huge cost benefit. In our tests, on an average, it costs only 0.00077 Ether or $0.0077 (assuming $10 to an Ether) to cast a single vote on a smart contract-based system. In terms of reduction of time taken to implement the overall process, since the counting of votes is real-time, the ballot reconciliation is immediate.
Challenges faced by Smart Contracts
Just as any other system, smart contracts may need to be upgraded in functionality. The challenge is that since the smart contracts are immutable, upgrade or re-versioning is not possible. Until such time as appropriate systems evolve, this issue can be mitigated by designing modularized encapsulated smart contracts such that the ones that store state do not need to undergo changes.
Automated triggering and execution of smart contracts may require data to be pulled in from off the chain. For example, a smart contract may need to know the current sentiment of a product as seen on Twitter. Currently accessing off-chain data is done through services called as “oracles”. Since these are services owned by central entities, it may lead to manipulation. Decentralization of oracles is necessary before we can see their widespread use.
On a Blockchain, codebase of a smart contract is visible to all entities on the network. Privacy of smart contracts is yet to be solved.
Current real-time systems have very low latencies. Given the nature of distributed consensus protocols such as Proof of Work, the latency of a smart contract execution (i.e. recording of a transaction) may not be acceptable to most systems. This issue can be resolved by switching to permissioned chains and choosing appropriate consensus algorithms.
Scalability is an open concern with the Blockchain platforms. This challenge is lesser in permissioned chains since the network usage and bandwidth can be monitored and controlled.
For most complex systems, it may be required to interoperate between different chains. This aspect has not been tried and tested completely. That said, there are some initial samples in place. One example is the BTCRelay that allows Bitcoin owners to interact with Ethereum smart contracts.