Three common misconceptions about smart contracts

Olivier Rikken is a principal at Amsterdam-based consultancy Axveco and a thought leader on blockchain and business process management.

In this article, Rikken points out three common misconceptions about smart contract technology.

Smart contracts are one of the most promising ideas in the development of blockchain.

Cryptography expert Nick Szabo first mentioned the concept in his 1994 paper "Smart Contracts", which Szabo described as "a computer transaction protocol that executes the terms of a contract." Today, the rise of the Ethereum blockchain has promoted the development and deployment of the concept of smart contracts.

However, this has also led to a lot of misunderstanding about the concept of smart contracts. (For those who are not familiar with smart contracts, this article provides a good introduction).

Before we get into the topic, I want to say that I believe the possibilities and number of applications of smart contracts are huge, and it can be a real game changer in all walks of life. But I noticed that many people in the industry don’t know much about smart contracts, what are they, how do they work, and what can they be used for?

Here are the three most common questions I encounter:

1. “Smart contracts are just code, not contracts”

Some people often quote the phrase “Smart contracts are neither smart, they are not contracts, they are just dumb code”.

In many cases, this may be true, such as when you are creating a decentralized application that does not involve the transfer of value. However, in other cases, smart contracts can have more properties than traditional contracts.

When we look at a regular contract, the semantics of the contract is made up of two main elements:

1. Operational semantics, which is an operational interpretation of a contract. It describes the interpretation of the precise actions agreed upon and taken by the parties. This can usually be programmed as a smart contract.

2. Denotational semantics, the non-operational legal interpretation of the entire contract, including but not limited to any references to other documents, jurisdictions, etc. This gives the contract an interpretation that allows lawyers to understand it. This element is not included in smart contracts in most cases, although references can be made by adding comments in the code.

Why do people create contracts in the first place? Mainly because they don’t fully trust the other party to enforce the agreement (despite a verbal agreement) or to provide proof to third parties that the transfer of goods is legal.

Keeping in mind the operational elements of contract semantics, if a smart contract is the result of an agreement between two or more parties, and it has been "signed" by all parties, it can be considered the operational semantics of a traditional contract (albeit written in an unfamiliar language).

Conflicts are handled in much the same way as for all traditional contracts, such as through the courts, mediation, etc.

The main difference is that in many cases the transfer of value is the result of automated contract execution having already occurred.

2. “Smart contracts can operate completely autonomously”

This is the second common misunderstanding about smart contracts.

People often have the perception that a smart contract can actively scan its environment and perform corresponding changes, that is, a smart contract can actively query an external database and change its state based on the query results.

The essence of blockchain is driven by transactions, and the same is true for smart contracts, so smart contracts are also passive.

The code of a smart contract is only executed when a transaction is called or a message is sent to it. The execution of a smart contract can be triggered by sending a transaction from an external account (owned by a natural person or company) or by another smart contract (this other smart contract is triggered by a transaction or its own message) sending a message to this smart contract.

Furthermore, the information provided by smart contracts during execution is quite limited.

As mentioned in the Ethereum paper, “This execution needs to be completely deterministic, with the only context being the block location on the blockchain and all available data”, and further, “It is not only sandboxed, but actually completely isolated, meaning that code running in the EVM cannot access the network, file system, or other processes. There are even limits on access between smart contracts.”

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

Of course, there are also smart contracts that can call other smart contracts (such as reading the balance of other smart contracts). Many experts do not recommend re-entrancy as a last resort.

Furthermore, smart contracts can only do basic calculations such as addition, subtraction, and division. They cannot perform big data analysis.

Therefore, when it comes to designing smart contracts, you have to know that at this time, they are passive, they can only do some basic calculations, and have only limited interactive possibilities. The examples described here are mainly based on Ethereum smart contracts, which leads to the last common cognitive error.

3. “This smart contract”

There is no such thing as THE smart contract.

Just as people often misinterpret the term “blockchain” when it does not refer to a specific blockchain (such as Bitcoin, Ethereum, Hyperledger, etc.), the same mistake is often made with smart contracts.

Most blockchains are simply not suitable for developing smart contracts, and if they do, it is only done in a very limited form or through sidechain solutions.

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