Smart contracts and immutability: a misunderstanding?

TL;DR — in the context of a state machine replication system, so-called “smart contracts” are user-defined components of the transition function. The idea that they must be immutable does not make much sense.

State machines

State history

In many systems, however, keeping track of the history of transactions and of the successive states is desirable or even mandatory. In most areas of industry, trade, commerce and finance, we need to keep track of transactions for some time. For accounting and banking records, that time period may be mandated by law.

If possible that history should also be tamper-proof — today we tend to say: immutable. Block-chains have proven incredibly useful for doing just that. By linking together data structures with cryptographic hash functions, any tampering can be made visible. With proof-of-work, tampering can be made nigh impossible, but that is another story.

Transition function mutability

The first state machine replication system that was open to the public and allowed anyone to freely add their own transition function components of reasonable complexity is the Ethereum network — the first“smart contract platform”. This platform has one fundamental problem: once a smart contract is deployed, there is no built-in mechanism to modify it.

The immutability problem

In a contract, a term is usually specified and termination clauses are often included. The possibility of later disagreements is generally acknowledged by specifying a governing law or by agreeing to submit to arbitration. Apart of that, in real life, contracts are sometimes renegotiated when conditions change. This applies to all contracts, commercial and personal, formal and informal.

In software development, there are situations where software, once deployed, cannot easily be modified. This is the case for embedded system software. In general however, deploying software without having the possibility to modify it later is simply reckless.

So why make smart contracts immutable?

In reality, smart contracts are simply custom transition functions and there is no particular reason they should be immutable. In fact, there are often good reasons to plan for future upgrades and/or migrations. The downside of this is that it adds complexity to the code, thus creating a new source of potential bugs. What we really need are smart contract platforms that acknowledge this issue and provide built-in mechanisms for smart contract upgrades.

Disclaimer: the majority of Ethereum smart contracts I have written do not include mechanisms for a future upgrade or migration!