The general answer to “do you need a blockchain?” is “no.” As I detail in chapter 11 of the book, append-only transaction ledgers with cryptographic tamper-proofing are good and deserve wider use — but the “distributed” bit is largely superfluous.

You’ll basically never need a so-called “permissioned blockchain.” If you have a trusted third party, you don’t need any sort of blockchain — and in real-world use cases, you’ll almost always have a trusted third party, or central administrator of some sort.

When Satoshi Nakamoto created Bitcoin, he took the append-only ledger — a robust construct that had been around for decades — and bolted on a torturously convoluted and stupidly wasteful consensus mechanism, to determine who got to write the next block, in order to avoid having any central control whatsoever.

This solved a problem only the economically delusional thought they had, and even then it only solved it temporarily — Bitcoin had recentralised by 2014. It was an extremely clever and interesting hack — but that’s not the same as being useful for any other purpose.

Most business usage that thinks it needs a blockchain just wants the append-only ledger. And we’ve had those for decades.

The best-known example is probably Git from 2005, four years before Bitcoin. This is a program by Linus Torvalds, the creator of Linux — it’s his second big hit. He needed something to store the Linux computer code in, that would let you readily look through the full history of the code, back to the beginning.

Git has cryptographic tamper-proofing, as part of how it ensures the data is consistent — if a single bit changes, all the hashes change. Software developers routinely copy entire full-history Git repositories around. Git is append-only ledgers on steroids.

As I note in the book, your actual problem is usually cleaning up your data and its formats. If you really want an append-only ledger, you may just need Git, or a simplified version of Git. Some actually-useful “blockchain” products can reasonably be described as a simplified Git.

But the question “do I need a blockchain?” needs addressing in detail. Karl Wüst and Arthur Gervais from the ETH Zürich Department of Computer Science have written a paper on the subject: Do you need a Blockchain?

This paper is worth your time. They explain the jargon at length, and discuss many commonly-advocated blockchain use cases — it’s a useful survey of the area — even as the authors are huge Bitcoin and blockchain advocates, and somewhat more optimistic for applying blockchains than is really warranted.

The main takeaway from the paper is this flowchart:

To put that chart into text form:

Do you need to store state? (data on where you are right now in your process)

Are there multiple writers?

Can you use an always online Trusted Third Party? (a central authority)

If either of the first two are “no,” or the third is “yes,” you don’t need a blockchain.

Are all writers known?

If not, you may need a public Bitcoin-style blockchain.

Are all writers trusted?

If yes, you don’t need a blockchain.

Is public verifiability required?

If yes, you may need a public permissioned blockchain. If no, you may need a private permissioned blockchain.

This is mostly good and plausible. But Wüst and Gervais are a bit overenthusiastic about blockchains and their applicability.

Naup1ius on Reddit /r/buttcoin takes us through the use case I mentioned at the top: what does Linus Torvalds want to store his computer code in, to share it with his collaborators around the world?

Let’s run through the use case “Version Control for the Linux Kernel Source Code”: • Do you need to store state? Um, yeah.

• Are there multiple writers? Um, yeah, anyone can create a pull request or work on some branch somewhere.

• Can you use an always online TTP? No, source code version control should not require coders to be constantly connected to something.

• Are all writers known? No. As mentioned, anyone can create a pull request or work on some branch somewhere. Therefore, according to the flowchart, not only does “Version Control for the Linux Kernel Source Code” require a Blockchain, but a Permissionless Blockchain at that. Now, I guess they could say that “writer” in this case should really only be applied to Linus’s blessed branch on his blessed machine, to which indeed only he and/or people subordinate to him have write privileges. But that isn’t obvious, and confusion on this point is part of why people think there’s a lot more use cases for blockchains than there are.

Wüst and Gervais don’t address non-blockchain uses of append-only ledgers at all — and not addressing Git, and similar highly successful uses for append-only ledgers, is a glaring omission in the paper.

The authors also include this table of the difference between a Bitcoin-style “permissionless” blockchain, a “permissioned blockchain” and an ordinary database:

Permissionless Blockchain Permissioned Blockchain Central Database Throughput Low High Very High Latency Slow Medium Fast Number of readers High High High Number of writers High Low High Number of untrusted writers High Low 0 Consensus mechanism Mainly PoW, some PoS BFT protocols (e.g. PBFT) None Centrally managed No Yes Yes

(The “consensus mechanism” is how you choose who writes the next block. “PoW” is proof of work, the incredibly wasteful method used by Bitcoin. “PoS” is proof of stake, a mechanism used by some insignificant cryptocurrencies, and which Ethereum is trying to switch to but haven’t got working properly yet. “BFT” and “PBFT” are various consensus mechanisms that, in practice, are variants on “taking turns,” because all writers to a permissioned blockchain are authorised, by definition.)

The append-only ledger with cryptographic tamper-proofing is good — it’s an obviously useful format for data that needs to be verifiable by others as not having been tampered with.

The only use case that needs the full Bitcoin-style consensus mechanism is a cryptocurrency.

Outside of that use case, you’re going to have a central authority, however you slice it — and the only reason anyone posits using a “blockchain” for this job is either cryptocurrency advocacy or buzzword compatibility.

The World Food Programme system, that uses a private Ethereum instance for just a single user, is a good example of a “permissioned” blockchain that offers no advantage over a central database — even if anyone else ever joins the system, the World Food Programme still have ultimate control. So there’s no reason a similar programme should follow its example and deliberately adopt an inefficient system.

Just use a database. You can write a log to an append-only ledger you distribute if you like, but you don’t need to be using that as your database.