3 Smart Contract Misconceptions

Olivier Rikken is manager, public speaker and thought leader on digital disruption, blockchain and business process management at Axveco, a boutique consultancy firm headquartered in Amsterdam. 

In this CoinDesk opinion article, Rikken outlines three common mistakes newcomers make when seeking to leverage blockchain-based smart contract technology.

One of the most promising developments in blockchain is the idea of smart contracts.

First detailed by cryptographer Nick Szabo in his 1994 paper "Smart Contracts", Szabo describes the concept as "a computerized transaction protocol that executes the terms of a contract". Today, the rise of the ethereum blockchain facilitates the easy development and deployment of this concept in a public environment.

Yet, this has led to a cloud of confusion around smart contracts. (For those less familiar with smart contracts, this article provides a nice introduction).

But before we dive in, I'd like to state that I believe the number of possibility and use cases for smart contracts are huge and can create real game changers across various industries. However, working with various companies on possibilities, I noticed that many are still struggling to understand what smart contracts really are, how they work and what they can do.

Here are the three issues that I encounter most:

A common phrase that is often quoted is "smart contracts are neither smart nor contracts, they are just dumb code".

In various cases, this might be true, like when you are creating a decentralized application that does not involve the transfer of value. However, in other cases, smart contracts can have more characteristics of conventional contracts.

When we look at conventional contracts, the semantics of a contract consist of two main elements namely:

Why are people setting up contracts in the first place? Mostly because they don’t fully trust each other for the execution of an agreement (despite any verbal agreement) or as proof for third parties that a transfer of goods was legitimate.

Taking this and the operational element of contract semantics in mind, if a smart contract is the result of an agreement between two or more parties and "signed" by all parties (by actively transacting to the smart contract), it could thus be seen as constituting the operational semantics of a traditional contract, although written in an unfamiliar language.

Handling conflict could pretty much follow the same route as with all traditional contracts, ie via courts, mediation etc.

The main difference will be that in a lot of cases, the transfer of value as a result of automated contract execution has already has taken place.

This brings us to the second misconception

One of the most common mistakes is that people have the perception that a smart contract can actively scan its environment and execute in response to changes accordingly, ie a smart contract proactively queries an external database and changes its own state based on the outcome of the query.

Blockchain, in its essence, is transaction driven. This is also the case for smart contracts and thus smart contracts are reactive.

The code of a smart contract is only executed when called upon by a transaction or message that is sent to the smart contract. This can either be done from an external account (owned by a natural person or a company) sending a transaction or another smart contract sending a message to the smart contract (this other smart contract being triggered by a transaction or message itself).

In addition, the information available to a smart contract during execution is quite limited.

As stated in the ethereum documentation, "This execution needs to be completely deterministic, its only context is the position of the block on the blockchain and all data available". Further, "it is not only sandboxed but actually completely isolated, which means that code running inside the EVM has no access to network, filesystem or other processes. Smart contracts even have limited access to other smart contracts".

The available data is the data sent to the contract in the transaction or message plus the data in the storage (state) and memory of the contract.

While a smart contract can call other smart contracts, (eg read balances of other smart contracts) re-entrancy is not recommended by various experts as they state it should only be used as a last resort.

Additionally, smart contracts can only do basic calculations like adding, subtracting and dividing. They are not capable of performing big data analytics.

So, when it comes to designing processes that involve smart contracts, know that, at this time, they are reactive, have limited information to work with, can only do basic calculations and have limited interaction possibilities. The examples as described here are primarily based on ethereum's smart contracts, which brings me to the last point.

There is no such thing as THE smart contract.

As people often make the mistake to talk about THE blockchain, instead of referring to a specific blockchain (eg bitcoin, ethereum, hyperledger, etc), the same mistake is often made for smart contracts.

Most blockchains have no smart contract capabilities at all, or if they do, it's only in very limited form or via pegged sidechain solutions.

The features that a smart contract can possess differ per blockchain.

So, when it comes to designing solutions that need smart contracts, there is no such thing as THE smart contract. In order to create a smart contract that meets your requirements, be very careful and precise when deciding which blockchain to use.

Red pencil image via Shutterstock