The closure property of smart contract systems - take 2

In an earlier post, I’d written that blockchain apps must be closed systems. Since the specific sense in which I’d used the words “closed” and “system” didn’t quite manage to get through to readers, I’d like to explain them a bit in this post.

First off, let me get the easier word “system” out of the way -

System: An app on a blockchain is expressed as a collection of “smart contracts”, with each contract transaction recorded on the blockchain. These contracts are therefore a “system” of interacting parts with information flowing between them. The participants of this information flow include users identified within the blockchain using an address, as well as other contracts also identified within the blockchain using contract addresses.

Now for the contentious word -

Closed: The word “closed” is the harder part, since it threw off many readers in a tangential direction. It does not mean “regulated”, “private”, “secluded”, “by membership only”, “encrypted” or any such sense. It refers to the mathematical notion of closed operations on sets. In this context, the truth of any claim statement made on the blockchain must be validatable using information from the blockchain itself.

The notion of “closed operations” is that the operations make use of one or more items from a set and produce a result that also belongs to the same set. In such cases, the set is said to be “closed under the operation”.

The reason this applies to blockchain contracts is that the transactions that happen with contracts need to make use of information whose truth claim can be validated purely using information already available within the blockchain, or using a mathematical proof as with cryptographic signatures.

Let me take the “NYT” example given in the earlier post and elaborate it a bit. Consider the following series of events -

  1. NYT (or a random magazine) writes an article about Brian and says something scandalous about him.

  2. Arthur (some random person) takes note of this article by NYT and wants to record on the blockchain that NYT said such and such a thing about Brian.

  3. Arthur uses a data storage kind of contract and places a reference to the article on the blockchain, say, a https URI to the article and perhaps an extract from it. Maybe he writes his own contract for doing such a thing.

  4. Brian is livid about the article and complains to NYT with proof that their claim is false and threatens to trash their reputation if they don’t retract the statement or so much a breathed a word about it later.

  5. NYT modifies its article to remove the scandalous statement.

  6. Time passes and Charlie notices the record on the blockchain. Since he thinks that the blockchain is infallible, he immediately publishes an article about the scandal and quotes NYT.

  7. NYT claims that Arthur had inserted that information on the blockchain and that they didn’t have anything to do with it. NYT also asks for proof from Arthur that it did say what Arthur claimed it said. Furthermore it accuses Arthur to try to setup to hurt NYT’s reputation.

  8. Final state - DEADLOCK. Arthur (assuming benign actor) knows about the scandalous statement but has no evidence presented. NYT is bound by contract with Brian to not mention it. Charlie is confused as he can neither trust Arthur nor NYT. This situation can only be resolved in court.

If information that goes onto the block chain can be contended in this manner, there would be absolutely nothing gained by placing it on the blockchain in the first place since the final resort would have to be a subpoena from a court. We’re therefore back to square one!

This deadlock can be resolved if Arthur, when recording the NYT statement about Brian also included a practically incorruptible proof that NYT did say what he claimed it to say. Charlie can then verify the proof independently without talking to NYT or to Arthur and so quickly check the trustworthiness of the record.

There are two important aspects to highlight in this situation -

  1. Information from an external source is being injected into the blockchain. In this case, it was a claim that NYT wrote something about Brian.

  2. Without a proof that the claim being made by the injected information is indeed valid, the fact that the information is present on the blockchain does not give it special powers of truth. This is because when Arthur included the information, he could’ve said anything whatsoever and we wouldn’t know whether NYT actually said that, but changed it later, or whether Arthur is being malicious in trying to destroy NYT’s reputation.

The deadlock therefore results independent of whether Arthur is being truthful or malicious. The only way to break it is for Arthur to also include proof that the claim being made is indeed valid. In the real world, this might be done by getting one or more “notary public figures” to attest to the truth of Arthur’s statement expressed and signed in physical form. The more who sign, the more trustworthy the claim can be taken to be. A “smart oracle” such as PageSigner is the digital counterpart of obtaining such a signature that can then be placed on the blockchain.1 While PageSigner is one possible solution, it would also suffice to produce references to artifacts that have been digitally signed by enough independent witnesses that collusion would be a very remote probability.

Side note: This discussion is independent of whether we use IPFS to store the information elsewhere and place the hash on the blockchain or directly place the article contents on the blockchain.2 The fact that a hash collision can occur for two different contents has negligible probability for a vetted cryptographic hash, we can treat the IPFS hash as an “immutable pointer” to the content that was hashed. Placing an IPFS hash on the blockchain would therefore be equivalent to placing the full content on the blockchain from a trust perspective. So even if the content is on IPFS, its validity would still be questionable since anyone can create an IPFS hash with any content.


When designing a smart contract system for an application domain, all interactions that involve injection of information from external sources must be converted into a process that can be validated within the blockchain at a later date. A useful rule of thumb is that if you want such an injection of external information, you will have to setup incentives (ex: payment) for participants to provide you incorruptible attestations of its validity.

This may or may not take on literally such a payment mechanism depending on the domain. For example, with a lottery system (solidity source code), ticket buyers provide random numbers that participate in the system. Though the ticket buyers are not being paid to provide random numbers, they stand to get paid if they win, so there is certainly an incentive to not game the system.3

Notes for folks starting off on blockchain tech

Designing smart contracts is not to be taken lightly. Do not treat the blockchain as a regular database into which any information stored gets magically imbued with glowing timeless validity. It is your contracts that give it that trait. In other words, the blockchain does not solve the trust problem. It only shifts the trust problem from that of the players maintaining the ledger to the contracts that populate the ledger. It has absolutely nothing to say about the correctness or warrantability of those contracts themselves.

Think about all properties your “system of contracts” must meet up front first and decide how you will test for those properties before writing up a contract.

Pay close attention to the interaction properties of existing physical systems that solve the problem that you’re trying to move to the blockchain. They can provide valuable clues about how to solve it, even if not very cost effectively in the beginning. They can point out what properties cannot be dispensed with. Cost optimizations can come later.

All contract code is public. So reuse known well designed contracts such as OpenZeppelin for sub-problems in your domain to reduce chances of errors creeping in. Note that even the OpenZeppelin team did an independent audit of their contract code.

Get the code audited by multiple reviewers for possible errors before deploying to production. Treat your production code as you might imagine NASA would treat their rocketry or spacecraft code. Depending on what you’re doing, a lot of money and reputations might be at stake.

Solidity code can look like regular OOP code. This doesn’t mean that it is a regular OOP language. So understand the EVM (or whichever) from ground up first so you can correctly interpret what a contract is doing more often than not.

  1., for example, can act as a “trust line” for getting your data referenced on the blockchain.

  2. Except for the difference in cost between the two, that is. [return]
  3. In the linked lottery code, there seems to be an ever so slight advantage to the last participant that isn’t necessarily obvious.

Srikumar Subramanian avatar
About Srikumar Subramanian, "Sri"