Smart contracts: Too blurry to be true?

The herding mentality in finance is a recurring theme. We have seen it take place both during the dot-com boom and the mortgage crisis. Recently, it is fintech startups and the solutions that they develop which have attracted interest. Smart Contracts (SC) are a recent example of a solution that’s beginning to turn heads. One often hears SC associated with Blockchain, another big fintech buzzword.

Smart Contracts (SC) serve as a programmable layer that sits on top of a Blockchain. There are various ways to characterise the way SCs work, such as:

  • An agreement between two parties whereby the terms are converted into a software program that will be executed by the SC layer.
  • A workflow whose state keeps changing in time and through external event inputs.
  • A state machine that keeps track of events.

Blockchain is a software that has a data-store capability and runs on several computer nodes. Yet Blockchain is fairly restrictive in its programmability to execute different scenarios. SCs, meanwhile, can run on the same nodes but with a rich and flexible programming language. When SCs are running, they may be linked to external data sources for inputs.

Here are the mechanics of using a SC: Two parties codify their agreed terms in a language supported by the SC software. The parties would then sign it with their respective private keys, which proves their acceptance of contract terms. The signed code is then published to nodes running the SC software. The running program may require inputs from signed/validated external sources – known as Oracles – to determine the output results. The SC output – or terms of the contract when executed – may be met externally through other means or it may be an internal Blockchain transaction.

For example, let’s assume Bob and Alice agree to a 12-month contract where on the last day of each month, Bob will pay Alice $1,000 if the NASDAQ index is between 4000 and 5000. Otherwise Alice will pay Bob $600. At the end of each month, the SC decides whether Bob or Alice pays based on the contract’s logic. The resulting monthly cash transaction can be completed through a traditional payment channel, or the SC can automatically initiate this through the Blockchain wallet.

As simple as this sounds, the ecosystem of SCs and Blockchain nodes are quite intricate and leave behind a few thoughts and questions, including:

  • In the current model, contracts go through a legal review whereby a lawyer vets the process. Yet when it’s in the form of code how can it be reviewed? Do we need a legal opinion?
  • To automatically process financial transactions as part of an SC output, there needs to be an element of trust when it comes to giving the SC access to the Blockchain node and its private key. What is the relationship between the SC and the Blockchain node/wallet?
  • In the Bitcoin world, one or more nodes (mining) solve a problem (executes code) and all the other nodes just validate the results. In the SC model, many nodes will be executing similar instructions at the same time. Is this actually required?
  • The mechanism proposed to prevent an errant SC code from going haywire is to pre-fund SC execution and deduct small amounts in the fund as a charge for code execution. This seems like a crude mechanism to prevent errant code.

Smart Contracts contain attributes that build its strong case for the future of computing. But for now, it remains unclear just how the individual steps tie everything up. This could be because of a lack of understanding or because it’s a sophisticated concept that will mature in time. In other words, all answers may not be available right away. If ease of use and simplicity are one’s core requirements, then SCs in their current form will not be your cup of tea. For all we know Smart Contracts are the embodiment of Einstein’s classic quote – “We shall require a substantially new manner of thinking if mankind is to survive.”


The article was originally published  in the Financial IT on May 05, 2016 and is re-posted here by permission.