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.
Your subscriptions keep this site going. Sign up today!
I have a hunch that most of these problems could be sorted out by having a highly specialized and trusted 3rd party, not for profit, system agnostic transaction broker that could seal deals and store the details on any transaction/contract for any given system. All the ledgers could exist on different networks and protocols but use a standard interface with the transaction broker which is the ultimate reference point to verify the integrity of any transaction history. The BTC ledger is already 150GB on doing a mere 200,000 txs a day. There just isn’t the CPU power or disk space for all these competing blockchain systems to co-exist and maintain the 51% global CPU security demands or scale to the 400 billion transactions per year they global finance requires every year which is 109,589,042 transactions per day which is already 5400 days of BTC transactions at the current rates.
I think in the general case the answer is “don’t try to use a blockchain” and instead assume that a system for human purposes will have a trusted human actor or organisation somewhere in it already 😉 and if it doesn’t, it’ll evolve toward having one, because it’s just so ridiculously more efficient. e.g., the bitcoin system, in which “level 2” has actually evolved to be the individual exchanges.
Such an ideal trusted third party is highly unrealistic. Not that this means that a blockchain is the answer, but I can’t imagine an entity such as you describe.
“Can you use an always online TTP? No, source code version control should not require coders to be constantly connected to something.”
This is where you go wrong. The coders don’t need to be constantly connected, they only need to be connected to the TTP when they make pull requests. However GIT needs a TTP in its current form.
Git relies on the repository being available to make pull and push requests. Git relies on the repository provider to not act malicious. A project run on GIT could be disrupted if i.e. the creator goes offline or sends every writer a different version of the project.
The reason why GIT doesn’t need a blockchain, is that it would be silly to assume that the people who administer the project would try to disrupt their own project. If you would actually want to do a 100% temper coding project, then you would need more than just GIT.
This is a human doing the bureaucratic job a blockchain proponent proposes to automate.
Ultimately, all mechanisms without a completely decentralised consensus mechanism come down to who is allowed to write to a database. If the database is maintained as a tamperproofed append-only ledger, we’re talking about variants on git.
A key issue, as I see it, is that double-spend prevention and tamper evidence are no longer present in multi-writer cryptographic systems when they are allowed to come to rest for a period of time. Because then there is an opportunity for a bad actor to replace a chunk of the chain with a valid string of blocks. (At least, in “longest block wins” systems.) What would happen to a blockchain Git repository if there were a gap in block production because of lack of activity? To counter this, empty blocks have to be continuously produced, with all the associated waste.
> What would happen to a blockchain Git repository if there were a gap in block production because of lack of activity?
It’s not clear to me how that makes sense as a question about actual git repositories or how they are used.
I’d perhaps add “Do you need to solve the double spending problem” to the graph.
What “Blockchain” inspires is a new design pattern using shared datasets.
Use cases like Supply Chain Management would likely just require git, or something like it. If any participant deviates from the canonical branch, it could be investigated “offchain” what happened and why they did so.