The Joy of Minimalism in Smart Contract Design

We all know blockchains and smart contracts provide unmatched assurances about unstoppable logic and immutable data. As attractive as that sounds, it’s best to use it as sparingly as possible. A well-crafted, minimalist contract only addresses concerns that cannot be addressed any other way.

“If a concern can possibly be addressed outside of a smart contract, then that’s what we should do.”

That may seem strange coming from someone who specializes in helping others maximize utility of smart contracts and blockchains. It’s not a contradiction. Blockchains and smart contracts are an extraordinary solution. It’s best to reserve it for extraordinary problems. Use it to create trust and resolve uncertainty — nothing routine.

For example, if you merely want to award points, countless examples existed long before blockchain. On the other hand, if you want to prove that those points are always and will always be awarded by a disclosed formula, then you may need to make the formula an observable fact on the blockchain. That would be solving for trust in the meaning of the scores.

This interpretation implies a narrow scope of concerns a smart contract should address. Contracts;

• define the essential, enduring facts about the application,
• provide the authoritative record of the facts that all participants can refer to in order to know they have the correct information, and
• provide evidence of application integrity via immutable processes that prevent corruption in any form.

With those concerns attended to, it’s usually a good idea to make the complete state conveniently discoverable and completely auditable. Beyond these core concerns are details that can be attended to by clients.

Consider the idea of sorting the data in the contract or finding a way to search it and filter it efficiently. It might be very useful, perhaps even critical to the overall solution. Even so, high importance doesn’t imply that the implementation belongs at the smart contract level.

Given that:

• the data in the contract is completely discoverable,
• state changes emit events in real time (they should), and
• clients can inspect the state, listen to events, or both,

software clients can employ a range of strategies to discover the facts they need in any given moment. Minimalist contract design provides the toolbox for constructing an appropriate client-side implementation without attempting to do the software client’s job. Indeed, the author would argue that client-side convenience shouldn’t influence contract design.

Whether it’s a browser app or a massive cluster of caching servers, the contract’s posture toward the outside world is the same.

• The state is completely discoverable.
• State changes are (should be) broadcast by event emitters.
• Any off-chain caching strategy is acceptable but the contract’s version of the facts is always authoritative.
• Any off-chain query solution is acceptable.
• Any service that purports to perform these services can (and should) provide clients with all the necessary details clients would need to check the blockchain for themselves, if they want to.

Knowing that a wide range of valid concerns will be attended to by off-chain processes greatly reduces the scope of functions that need to be coded inside a contract. A minimalist contract addresses only concerns that can’t be addressed any other way.

Minimalism leads to clarity about exactly what the contract needs to prove and the minimum logic and data required to construct the proof. Minimalism is the first defense against defects that might have non-trivial consequences. The ideal is something so simple that there are obviously no defects.

“Obviously no defects” is easier said than done, which is why an Audit and a Bug Bounty is an absolute must before any piece of software should be entrusted with significant value.

When you’re going for perfection, simple is better.