A Common Mistake: 3 Typical Misconceptions About Smart Contracts

The rise of the Ethereum blockchain facilitates the easy development and deployment of smart contracts in a public environment. This led to a hype around smart contracts and a new awareness of the potential possibilities. For those less familiar with smart contracts, this is a nice introduction article.

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 smart contract implementation possibilities, I noticed that there are currently multiple misconceptions around what smart contracts really are, how they work and what they are (currently) capable of. Here are three of the most common misconceptions that I encounter:

    “Smart contracts are just code, not contracts”

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, e.g. when you are creating a game DApp 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 2 main elements namely:

A. The operational semantics, which is the operational interpretation of a contract. It describes the consideration of the precise actions as agreed and to be taken by the involved parties.1 This is typically what can be programmed into a smart contract

B. The denotational semantics, the non-operational legal interpretation of the entire contract, including, but not limited to, any references to other documents, jurisdiction etc. This is the interpretation that would be given to the contract as a lawyer would read it. This element is in most cases not included in smart contract, although references could be added to smart contracts as comments in the code

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 (as described under a), if a smart contract is the result of an agreement between 2 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 (e.g. Solidity).

Handling conflict could pretty much follow the same route as with all traditional contracts, i.e. via courts, mediation etc. The main difference will be that in a lot of cases, transfer of the value as result of automated execution of the contract already has taken place. The latter brings us also to the second misconception.

     "Smart contracts can operate fully autonomously"

In a lot of use case designs, I observe mistakes with regards to how smart contracts work, act and react. One of the most common mistakes is that people have the perception that a smart contract can actively scan the environment and execute in response to changes accordingly, i.e. 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” and “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 smart contract. Whilst a smart contract can call other smart contracts, (e.g. read balances of other smart contracts) re-entrancy is not recommended by various experts and as they state should only be used as a last resort. Additionally, smart contracts can only do basic calculations like +, -, *, / and % and is e.g. 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.

   "THE smart contract"

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 (e.g. Bitcoin, Ethereum, Hyperledger, etc) the same mistake is often made for smart contracts. Most blockchains have no smart contract capabilities at all or 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, again 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 which blockchain to use. Look at things like tokens (that bear an economic value or not), Turing completeness, privacy, desired consensus mechanism etc.

The three described misconceptions are the most common misconceptions that I encounter and there are more that are not addressed in this article. But despite these misconceptions, blockchain and smart contracts, to my point of view, are true game changers in various industries. They will contribute hugely to process improvements, disintermediation and new business and industry models, even with today’s misconceptions and (technical) limitations.

Olivier Rikken is a blockchain & smart contract expert, keynote speaker from Amsterdam and been highly active in training, consulting and implementations in the field of blockchain for several years.

                                                                                                   Photo: An Ache in Every Stake/Columbia Pictures