There are more than one “blockchain” and “smart contract” mental models
Thinking in terms of different mental models, while saying the same words, can be detrimental to your project.
“Blockchain” and “smart contract” are labels, which evoke different mental models for different people, depending on the different use cases they contemplate, and the different platforms they are comfortable with.
Using these labels and leaving the underlying mental models undisclosed (and consequently, undisputed), can be a huge liability in projects. It leads to people thinking they are on the same page when they are not, eventually defaulting to suboptimal groupthink equilibria.
In this blog post, I describe some mental models I often encounter in “blockchain” and “smart contract” related projects.
My message: next time, when you come across these expressions, take the effort and time of reflecting and discussing the underlying mental models. Otherwise, you risk derailing your project right at the outset.
I use the expression “mental model” in the way the Farnam Street blog uses it, following in the footsteps of investment guru Charlie Munger. The FS blog says: “Mental models are how we simplify complexity, why we consider some things more relevant than others, and how we reason.”
I add to the concept of “mental models”: some of the reasons why different mental models get the same labels are historic development, competition, marketing, sloppy thinking, false anthropomorphism, and “the fallacy of misplaced concreteness”.
Spoiler: in the following sections, I list a lot of different mental models, so that you can all consider for your specific problem to solve. For my projects, because I’m currently working mostly with enterprises and government agencies, the most useful ones are:
- Shared ledger with sub-transaction privacy, implementing the principles of contract law (not censorship-resistant, mutable in a controlled and auditable way in order to comply with GDPR, lacking “total broadcast” and lacking blocks containing unrelated transaction data).
- Smart contracts as documents expressing rights and obligations.
Because this is a long blog post, I present a table of contents to you in advance:
“Blockchain” mental models
- “Immutable ledger”, “putting something on the blockchain”, “fly trapped in amber”, etc.
- Total broadcast, “Yap money”, etc.
- Censorship resistant transfers
- Tokens and mining, CBDC
- “Not blockchain” as branding decision
- Distributed Ledger Technology
- What You See Is What I See or WYSIWIS
- Shared ledger with sub-transaction privacy, implementing the principles of contract law
- GDPR-compliant “Global Synchronization Beyond Blockchain”
“Smart contract” mental models
- “Neither smart, nor contract”
- Contracts as state transition rules in Corda
- Smart contracts are software and contract at the same time, implementing the basic principles of contract law
“Blockchain” mental models
“Immutable ledger”, “putting something on the blockchain”, “fly trapped in amber”, etc.
This one comes from Bitcoin, though the Bitcoin White Paper doesn’t contain the word “immutable”.
Nick Szabo, one of the fathers of cryptocurrencies and smart contracts, in a podcast interview with Tim Ferris, used the metaphor of “fly trapped in amber”: “Crypto currency, as the name suggests, is protected by cryptography and in particular, the modern cryptocurrencies like Bitcoin and Ethereum and so forth, their integrity is protected by cryptography; a structure called a Merkle tree that you can think of it as a fly getting trapped in amber. If you say I shot JFK and then put it through this process of the Merkle tree putting it on the blockchain, then it’s there and you’ve signed it with your private key, then you can’t later deny you said that.”
The Bitcoin data structure guarantees that two instances of the chain can be easily compared: if the two chains have equal length, the “Prev Hash” value in each block of each chain is correct, and the hash of the highest block of the two chains is equal, the contents of the two instances must be equal.
In the case of public blockchains like Bitcoin and the original version of Ethereum, this data structure, together with the mechanism of ledger updating (aka “mining”), guarantees, that (as the Bitcoin White Paper puts it) “as long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network”, the contents of the ledger cannot be modified via BAU operation. (I write “via BAU operation” because the Ethereum blockchain was actually modified by the Ethereum Foundation after the DAO Attack.)
This data structure is also used in some (but not all, we sill see exceptions later) enterprise blockchain platforms like Hyperledger Fabric or Hyperledger Sawtooth. In the case of enterprise platforms, there is no mining, no cryptocurrency, and the ledger is only immutable as long as the consortium members don’t agree to delete it, or rebuild it with different content.
This kind of (restricted) immutability is useful in some cases, and problematic in other cases. It’s useful eg if you have Bitcoin holdings, and you don’t want that somebody else spends your Bitcoin. And it’s problematic, if somebody puts PII (Personally Identifiable Information) say into the comments* field of a Bitcoin transaction, because this data disclosure breaches the “right to be forgotten” requirement of GDPR.
(*Actually, there is no “comments” field of a Bitcoin transaction. There are still ways to “put” arbitrary information “on the blockchain”. A famous example is the genesis block, where in the “coinbase” field was inserted the text of one of the headlines of The Times of London: “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”. The “coinbase” field normally cannot be used for this purpose. Instead, it is usual to use the “OP_RETURN” field of such transactions which don’t represent a spendable sum of Bitcoin.)
I saw several projects which defaulted to the mental model of “immutable ledger”. Not because this was the most useful one for the use case, but because the stakeholders had different tacit mental models, and this one proved to be the equilibrium state of the groupthink dynamics.
When this is the case, the usual suspect for solving the GDPR challenge is to avoid “putting personal data on the blockchain”, just hashes — which limits the usefulness of the solution severely, because the original data have to travel from one transaction participant to the other outside of the blockchain system.
(The GDPR challenge can be tackled in a different way under a different mental model of a “shared ledger”. The Canton “ledger interoperability protocol” by Digital Asset eg, which is labeled as “Global Synchronization Beyond Blockchain”, can prune archived contracts. You can read about this later.)
Total broadcast, “Yap money”, etc.
The Bitcoin update mechanism can be described in the following way (as a software engineer put it):
I don’t give you digital data as payment. I give the rest of the world a signed statement saying I paid you.
Many people see this as an analogy to the way the famous stone money on a tiny Micronesian island, Yap works.
Again, this mechanism is in some cases useful, and in other cases problematic. Members of an enterprise consortium don’t want to broadcast all their pairwise private transaction data to all members of the consortium.
Censorship resistant transfers
Nobody can prevent a Bitcoin owner from transferring their Bitcoin to a valid address. (“Owning” Bitcoin means being able to sign transactions with the private cryptographic key paired with the public address the Bitcoin was sent to. This doesn’t necessarily mean that the person who spends the Bitcoin is the same, as the intended recipient of the previous transaction was! Private keys can be lost or stolen, so Bitcoin and other cryptocurrency owners need to make extra efforts to prevent their private keys from being lost or stolen.)
This feature is sometimes called “censorship resistance”.
Regulators and regulated financial institutions try to exert some control over transfers to comply with KYC, AML and ATF regulations. (The acronyms stand for Know Your Customer, Anti Money Laundering, Anti Terrorist Financing.) Nonetheless, if somebody wants to operate their transactions off the grid, they can do it.
On the system side, this feature comes with a hefty price tag in terms of low throughput and computing power necessary for “mining”.
And again, this is in some cases useful, in other cases problematic. Within a consortium, censorship resistance is neither necessary, nor desirable, because consortium members must operate within a legal and contractual framework.
Tokens and mining, CBDC
For many people, the “raison d’être” of blockchain is supporting tokens. There are basically two kinds of tokens.
One of them is called in the Canton White Paper aptly “the digital equivalent of golden nuggets: a bearer token that is neither controlled nor backed by any single real-world party”. This is true for Bitcoin and Ether, and many other tokens which are used to reward “miners”, entrepreneurs who invest time and resources to validate transactions.
There are blockchains which do not provide any other functionality than providing a means for transferring value, like the Facebook Diem (originally Libra), Ripple, Stellar, or Tezos.
The other kind of token is tied to an issuer. The famous Ethereum ERC-20 token standard, which was the basis for many ICO tokens is for tokens tied to an issuer.
There is no general rule for blockchains supporting or not supporting tokens. There are blockchain platforms which have a native token which can be “mined”, and others which cannot be mined, because a set of trusted validators run the network.
Enterprise blockchain networks usually don’t have any native tokens, but some of them are entering the race for supporting Central Bank Digital Currency or CBDC. Corda eg works with the Swedish Riksbank on the e-krona proof of concept, and Digital Asset has demonstrated recently the ability of the platform to support CBDCs.
“Not blockchain” as branding decision
Sometimes a platform brands itself as “not blockchain”, although the purpose of the platform is similar to other platforms which call themselves blockchain.
This is the case with Hedera Hashgraph, which has a much faster consensus algorithm than Bitcoin. Hashgraph declared that it’s “not blockchain”, forcing a mental model of “blockchain” which is slow and complicated, identifying the general concept with a specific technical implementation, that of Bitcoin.
The Estonian company Guardtime has an interesting — and changing — relationship with the “blockchain” label.
The core technology the company was built on was called originally KSI or Keyless Signature Infrastructure. It aims at proving the integrity of large data sets without using PKI private keys, just via multistep hashing. In this video from the time “before Bitcoin was cool” Mike Gault founder and CEO talks about KSI, without mentioning the word “blockchain”.
After that, Gault wrote a famous article with the title Forget Bitcoin — What Is the Blockchain and Why Should You Care?. In the article, he outlines the concept that the technology behind Bitcoin is capable of securing the integrity of any data set. In the article, he uses the analogy of “a piano falling from the sky”, and the exact words how every bystander reports about the accident. He argues, that the technology of Bitcoin is misunderstood, and its essence is not payment, but securing information:
“The problem is that, for most people, the concept of blockchain is intrinsically tied to the digital currency bitcoin — a fairly complicated and highly controversial system. (…) What is a blockchain? Essentially, just a record, or ledger, of digital events — one that’s “distributed,” or shared among many different parties. It can only be updated by consensus of a majority of the participants in the system. And, once entered, information can never be erased. The bitcoin blockchain contains a certain and verifiable record of every single bitcoin transaction ever made.”
And goes on, outlining how Estonia at that time is already using “blockchain” and how it can use even more, essentially outlining the future focus of Guardtime: “The country of Estonia, which secures much of its banking infrastructure with a blockchain, boasts the lowest rate of credit card fraud in the euro zone. And startups like Bitreserve are enabling completely free online-money transactions, without the volatility and risk associated with bitcoin. We can think even bigger — let’s put health records, voting, ownership documents, marriage licenses and lawsuits in the blockchain. Eventually, every dataset and every digital transaction could leave a “fingerprint” there, creating an audit trail for any digital event throughout history, without compromising anyone’s personal privacy.
You can see that Gault’s interpretation is basically the same mental model as the one which Nick Szabo called “fly trapped in amber”.
From that time, KSI was rebranded to “KSI Blockchain”, and the label “blockchain” has been tied to Estonia as a country. Check out eg the PwC paper Estonia — the Digital Republic Secured by Blockchain.
Fast forward to the present.
Today, if you check out the Guardtime website, in the Technology section you cannot find the work “blockchain”. In the About Guardtime section they mention KSI without the word “blockchain”. If you search for it, you can find a page for “KSI Blockchain Timestamping”, but the company doesn’t advertise it in this way.
What happened?
It seems, for Guardtime (my guess is that for Gault personally, but I cannot prove this) the term “blockchain” became too much tied to cryptocurrencies, and they didn’t want to identify themselves to that mental model, which is very different from theirs.
On a former version of their website, you could read the following rant (again, I cannot prove this, because that version of the page isn’t available any more):
“The stupidity of what we read about blockchain in enterprise continues to astound us. The logic seems to go something like this: cryptocurrencies are cool — let’s solve problems by “putting X on the blockchain”. This makes zero sense. Taking a solution that was designed to solve one problem (cryptocurrencies) and then thinking this can be applied to other problems is equivalent to “I have a hammer, everything looks like a nail”.”
Distributed Ledger Technology
Some people say, that the technology supporting the consortium use case should be called “Distributed Ledger Technology” (DLT), rather than “blockchain”.
Some even argue, that DLT is the super-category of blockchain.
In reality, many people use DLT and “blockchain” interchangeably. Besides, both parts of the expression are misnomers.
“Distributed” is not correct, because many blockchain systems, like Bitcoin, Ethereum or Hyperledger Fabric replicate the data at every node rather than sharding or “distributing” it between several nodes. (In some other platforms, the nodes only store their users’ private data, and the system makes sure that these data fragments are consistent with each other, making up together a virtual ledger.)
“Ledger” is a misnomer, because it interferes with the use of the expression in accounting. As a footnote to the DAML (a smart contract platform I will discuss later) documentation explains it, “Calling such a complete record “ledger” is standard in the distributed ledger technology community. In accounting terminology, this record is closer to a journal than to a ledger.”
So instead of “Distributed Ledger”, we should in many cases say “Replicated Journal”. Not much help in making the terminology more clear.
What You See Is What I See or WYSIWIS
This is already pretty close to what I think is most useful in an enterprise or government setting. Another formulation is that Corda wants to “optimise entire markets” in a similar way as middleware was optimizing the inner operation of companies.
(The acronym is a playful allusion on WYSIWYG or “What You See Is What You Get", a text editor UI paradigm nowadays taken for granted, which was a while ago a big invention.)
This mental model was introduced by Corda CTO Richard Gendal Brown in several of his articles, e.g. Markets are decentralised and the software that runs them should be too, and Decentralised Centralisation: Enterprise Blockchains in the Era of Cloud.
The idea is, that a shared ledger makes the transaction parties be on the same page in terms of their mutual data and processing logic.
There are some caveats though:
If you have more than two parties involved in a transaction, the parties shouldn’t always see the same information. Eg in the case of a “delivery vs payment” use case, where one party is holding money in a bank and another party is holding security in a securities depository (so we have four parties altogether), the bank and the depository shouldn’t see the same information: the bank mustn’t know about the security leg of the transaction, and the depository mustn’t know about the cash leg of the transaction.
So the parties shouldn’t “see” the “same” information. Instead, they should be certain that every party of a transaction can access the information in a need-to-know basis, and that the different information fragments belonging to the same transaction are consistent with each other.
Additionally, the use of the verb “see” is not expressing the common processing logic, that is the fact, that the parties must know in advance, what can and cannot happen with the assets their information refers to.
I have to emphasize that what I write here, only applies to the WYSIWIS mental model. The Corda blockchain operates according to the need-to-know basis information partition requirements I outlined above.
The technical implementation of the Corda blockchain doesn’t confirm to the mental models I listed in the previous sections of this blog post. Corda doesn’t have blocks and doesn’t use total broadcast under the hood. The information only travels peer to peer between transaction parties. (In the Corda Technical White Paper they call the original version of blockchain, which consists of blocks, chained together via cryptographic hashes, and broadcast to the whole network, “Nakamoto Style Blockchain”, referring to the mysterious creator of Bitcoin.)
“Is Corda a blockchain?
Transactions on Corda are cryptographically linked or chained to the transactions it depends upon. So, by definition, Corda is a blockchain — with one key differentiator.
Corda does not periodically batch up transactions needing confirmation — into a block — and confirm them in one go. Instead, Corda confirms each transaction in real-time. With Corda, there is no need to wait for other transactions to come along or a “block interval”. Transactions are confirmed immediately. This means that your transaction is not dependent on any others, increasing both privacy and scalability.
So, Corda is both a blockchain and not a blockchain.”
Shared ledger with sub-transaction privacy, implementing the principles of contract law
This mental model is described in the documentation of the DAML smart contract platform.
The mental model is called the DAML Ledger Model, which is a universal model of handling ledger entries (called “smart contract instances”) and ledger transactions.
The ledger model is distinguished from the possible DAML ledger topologies, which describe how the physical implementations of the “virtual shared ledger” (a logical entity) can look like. (The topologies described are: fully centralized, replicated, Trusted Execution Environment, and partitioned.)
The caveat I mentioned above applies here as well: the word “ledger” is kind of a misnomer, but is so widespread that we can hardly avoid it. The entity we call “ledger” here, resembles more to a “journal” in accounting terminology, than to a “ledger” in accounting terminology.
The DAML Ledger Model is so intertwined with the DAML smart contract language, that at this point we cannot separate the “blockchain” mental model from the “smart contract” mental model, so it’s in the overlap of these two branches of my blog post.
The DAML Ledger Model guarantees integrity and privacy, which I won’t explain in full detail here.
It should be enough here, that DAML smart contract instances, which are DAML ledger entries, embody rights and obligations of ledger parties, and adhere to the principles of contract law. Most prominently, via the “propose/accept pattern”, multiparty agreements can be modelled via ledger entries.
Via the DAML Ledger Model’s privacy guarantees, need-to-know-basis visibility can be guaranteed in a sub-transaction level. (See again for this my example of a delivery versus payment use case in the previous section, where the bank mustn’t know about the security leg of a transaction, and the securities depository mustn’t know about the cash leg of the same transaction.)
GDPR-compliant “Global Synchronization Beyond Blockchain”
The Canton “ledger interoperability protocol” by Digital Asset, which is labeled as “Global Synchronization Beyond Blockchain” is a twin product of the DAML smart contract platform.
It can be used to create a “network of networks”, connecting several DAML-based “trust domains”.
The Canton White Paper highlights that the platform “allows developers to balance auditability requirements with the right to forget, making it well-suited for building GDPR-compliant systems.”
Canton makes it possible to prune the archived smart contracts (which is an essential requirement of GDPR) from an underlying persistent storage which supports deleting. At the time of writing this is only PostgreSQL.
This is possible because Canton doesn’t follow the “fly trapped in amber” mental model and technical implementation. As the list of key concepts section of the Canton documentation reveals:
- Blockchain: The Canton protocol does not use a Blockchain. Canton allows different DAML based ledgers to interoperate, independent of whether they are running on a blockchain, on enclaves or on centralised databases.
- Consensus: The Canton protocol does not use PBFT or any similar consensus algorithm. There is no proof of work or proof of stake involved. Instead, Canton uses a variant of a stakeholder based two-phase commit protocol. As such, only stakeholders of a transaction are involved in it and need to process it, providing efficiency, privacy and horizontal scalability. Canton based ledgers are resilient to malicious participants as long as there is at least a single honest participant. A domain integration itself might be using the consensus mechanism of the underlying platform, but participant nodes will not be involved in that process.
Canton, under the hood, uses vector clocks to synchronize participant nodes. See how in a presentation Daml and Canton: Privacy-aware smart contracts on interoperable ledgers by Andreas Lochbihler, summarized in a few slides.
“Smart contract” mental models
In this second part of my blog post I describe several mental models which are attached to the label “smart contract” in the minds of different people.
Again, these mental models are driven by the use cases people contemplate, and the platforms they are familiar with.
“Neither smart, nor contract”
One widespread belief is, that the things which are called “smart contracts”, are in reality “neither smart, nor contract”. I can hear this sentence in conference speeches very often.
The verdict is true for some platforms, like Ethereum and Hyperledger Fabric, and not true for other platforms, like DAML.
The term “smart contract” was introduced by Nick Szabo in the nineties, in the form of a concept language, which he never implemented in practice.
From his articles (like A Formal Language for Analyzing Contracts and others) it’s clear, that he didn’t intend to say that smart contracts are “neither smart, nor contracts”, quite the opposite. For him, smart contracts were there to implement legal contracts written in the form of computer code.
Nick Szabo’s signature example for a “contract embedded in the world” is a soda machine. The soda machine is a mechanical device implementing contractual relationships. If such contractual relations are implemented in the form of software, they are called “smart contracts”.
The reason why many people believe that smart contracts are “neither smart, nor contract”, is that the Ethereum White Paper introduced a concept which they called “smart contract”, with an unexplained hint to Nick Szabo, with a content very much different from Szabo’s original idea.
The title of the Ethereum White Paper even puts the term “smart contract” in the focus via the title “A Next-Generation Smart Contract and Decentralized Application Platform”.
The authors of the Ethereum White Paper admit, that the thing they call “smart contract”, doesn’t resemble to contracts at all. They don’t explain though, why then they gave it this name.
“Note that “contracts” in Ethereum should not be seen as something that should be “fulfilled” or “complied with”; rather, they are more like “autonomous agents” that live inside of the Ethereum execution environment, always executing a specific piece of code when “poked” by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables.” — runs in the Ethereum Accounts part of the Ethereum White Paper. (In reality, the term “autonomous agent” is also a misnomer here, because the code which they call “smart contract” is not autonomous at all: it is passively waiting that a user “pokes” it.)
The perplexity caused by the Ethereum White Paper continues in the terminology used in the documentation of Hyperledger Fabric.
In Fabric, “smart contracts” are arbitrary code, which translate calls coming from client applications into ledger update requests. The platform doesn’t even guarantee, that this code is deterministic. One can easily deploy, say, a stochastic “rock, paper, scissors” program as “smart contract” — this is indeed very far from what we would intuitively call “contracts”. (The intended remedy for this indeterminism is “endorsement policy”. I leave it to the reader to think through why this is not a real remedy.)
Maybe the authors of the docs felt the contradiction between the word and the intended content, so they sometimes say “chain code” instead of “smart contract” — not clear when is correct the one name and when the other.
Within IBM, a group of researchers is working on a project which aims at creating a platform for Formally Verified Smart Contracts with Haskell (as the title of the video puts it). The arguments supporting this experimental project explain clearly why the present state of Hyperledger Fabric “smart contracts” is not satisfactory: “This talk presents support for writing Hyperledger Fabric chaincode with Haskell, a big first step towards having fully verified and secure smart contracts. The work is evaluated by comparing contracts written in Go, Java and Node with Haskell to demonstrate how a functional programming language can help identify flaws in logic, leading to code that is both correct, secure and easier to reason with. The talk finally demonstrates how smart contracts written in Haskell can be formally verified.”
Contracts in Corda
In the documentation of Corda, they don’t use the term “smart contract”. They say simply “contract”.
In Corda, the term “contract” is closely related with the term “state”, which is what the name suggests: “In Corda, contracts are the mechanism used to impose constraints on how states can evolve.”
The Corda documentation reflects on the ambiguity of the term “smart contract” in other platforms: “Contracts in Corda are very different to the smart contracts of other distributed ledger platforms. They are not stateful objects representing the current state of the world. Instead, like a real-world contract, they simply impose rules on what kinds of transactions are allowed.”
Corda uses languages for contracts which are not deterministic, just like Hyperledger Fabric. Contracts in Corda (written in Java or Kotlin) run on the Java Virtual Machine (JVM) which is not deterministic. Unlike the developers of Hyperledger Fabric, the developers of Corda don’t accept this as a fact of life. Instead, they have created a sandbox, a deterministic subset of the JVM, called Deterministic JVM, and only allow contracts run in this sandbox.
In the “12 Future Work” section of the Corda Technical White Paper they even mention a Haskell inspired experimental Domain Specific Language, which should be formally verifiable. As of today, this DSL has not come to fruition.
Smart contracts are software and contract at the same time
I’ve already mentioned Nick Szabo’s concept smart contract language and the Daml smart contract platform.
The common approach followed by Szabo and the Daml team is that they want the opposite of what the quip “neither smart, nor contract” formulates.
Here is a slide from the video DA Tech Talk: Semantically Rich Segmented Blockchains by DAML creator James Litsios, highlighting the fact, that DAML smart contracts are programs and contracts at the same time. (The ledger concept mentioned in the video called Global Synchronization Log or GSL was deprecated since. The actual DAML Ledger Model, as I mentioned earlier, is laid down in the current version of the DAML Documentation, and the concept of “Global Synchronization Beyond Blockchain” in the Canton documentation.)
In the video, James explains why Digital Asset is using mostly purely functional languages like Haskell and Scala for smart contract and ledger development: only purely functional languages provide guarantees that a) the data is not changed in-place, but in the case of an update a new version gets created (see the concept of “immutability earlier), and b) the functions can be composed without the risk of breaking anything.
And also, why Digital Asset goes the extra mile for creating a rich tool set for developers, like the DAML Studio development environment, the DAML Sandbox in-memory ledger for prototyping, and the UI tools like the Navigator automatically generated admin UI and UI templates: the reason is that what they develop is very new and innovative, and what is new is not easy, and they want to give as much support to clients as possible to develop integrated solutions based on the DAML platform.
