Smart contracts are computer protocols that facilitate, verify, or enforce the negotiation or performance of a contract, or that make a contractual clause unnecessary.

As an aside, I have to admit a certain bias against technology terms prefixed by “Smart”, “Simple”, “Open” etc. They are usually a sign that the technology is compensating for something…!

Unfortunately Smart Contracts currently don’t appear to buck this trend.

First, let’s take a look at what they do, and how they work.

A Smart Contract is triggered by an API call (aka a Transaction). When invoked the Smart Contract runs and may update local or global state.

The Smart Contract is expressed as procedural code (Go on Hyperledger, Solidity for Ethereum) that runs on the distributed nodes of the blockchain network.

The Smart Contracts can read and write to the global state for the network (think key/value stores).

If all participants to the transaction agree (consensus) then the transaction is appended to the distributed ledger and the update to the global state is saved.

Hyperledger and Ethereum differ in the details of 3 & 4 as Ethereum has a more Object-Oriented approach, keeping the data and the Smart Contract within a unified data structure, while Hyperledger is more functional/procedural, keeping the code and state separate.

Ethereum Solidity code runs within the Ethereum Virtual Machine which computes a cost (“gas”) to execute code (and avoid the halting problem), and rewards nodes in the network for running computations.

Hyperledger Go code runs in a Docker image across a permissioned/trusted set of peers – typically within an enterprise, or across a known business network.

Fundamentally both Solidity code and Hyperledger’s Go code expose a set of methods that can be called by clients to process transactions.

The net is that Smart Contracts today are hunks of potentially re-entrant procedural code that can mutate local and global state when invoked from remote (potentially malicious) clients. The threading and transaction model is complex, due to the distributed nature of the system, and there not being a central coordinator.

What could possibly go wrong! 🙂

What we need is:

Much higher level primitives that are computationally safe and can be statically and dynamically analyzed. Think state machines, or Event-Condition-Action rules with a very restricted instruction set.

Better support in the language for declarative data validation, identity management and permission checking to remove the need for boring and error prone boilerplate.

A clearer mapping to concepts coming from contract law (or read this, for dummies), such as a clear mechanism to deal with mistakes (bugs!), damages, remedies, termination etc. In short, we need much more focus on the contract requirements of business networks.

There’s huge promise in the core capabilities of blockchains: business networks, consensus, shared ledger, privacy and confidentiality but the current incarnations of “Smart Contracts” needs serious evolution and refinement.