Do You Need A Blockchain?

David Gerard's Do you need a Blockchain? Probably less than Wüst and Gervais think you do reviews an interesting paper, Do you need a Blockchain? by Karl Wüst and Arthur Gervais of ETH Zurich. Their abstract says:

In this article we critically analyze whether a blockchain is indeed the appropriate technical solution for a particular application scenario. We differentiate between permissionless (e.g., Bitcoin/Ethereum) and permissioned (e.g. Hyperledger/Corda) blockchains and contrast their properties to those of a centrally managed database.

Gerard is, for him, pretty enthusiastic about the paper:

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.

Below the fold, I look at both the paper and Gerard's review.

In Blockchain: Hype or Hope? (paywalled until June '18) Radia Perlman asks what exactly you get in return for the decentralization provided by the enormous resource cost of blockchain technologies? Her answer is:

a ledger agreed upon by consensus of thousands of anonymous entities, none of which can be held responsible or be shut down by some malevolent government ... [but] most applications would not require or even want this property.

Wüst and Gervais look more closely into the question of what applications might want this, or the weaker "permissioned blockchain" variants, and summarize their answer in this flowchart.

They explain their terminology thus:

we denote as writer any entity which writes state to the database. In a blockchain this would correspond to a participant that is involved in the consensus protocol and helps growing the blockchain. As such, a writer is able to accumulate transactions within a block and append this block to the blockchain. ... We denote a reader as any entity which is not extending the blockchain, but participating in either the transaction creation process, simply reading and analysing or auditing the blockchain.

Thus the only case in which you need a "permissionless blockchain", i.e. the kind of blockchain that cryptocurrencies use, is when:

• There are multiple writers, and:
• There is no TTP (Trusted Third Party), and:
• There are unknown writers.

In the light of this flowchart, they examine three suggested blockchain applications, supply chain management, interbank and intercurrency payments, and Distributed Autonomous Organizations.

For Supply Chain Management they discover that trust is essential to the system's function, which renders a blockchain, permissioned or not, pointless:

Supply chain management has the inherent problem of the interface between the digital and the physical world. A human, or some machine under the control of a single writer, typically is required to register that a certain good has arrived in a warehouse, and if for example its quality is appropriate. If there is no trust in the operation of these employees, then the whole supply chain is technically compromised as any data can be supplied by a malicious writer. If, on the other hand, all writers are trusted, a blockchain is not needed as a regular database with shared write access can be used instead.

There are many suggestions and indeed experiments in using blockchains for interbank payments. Since the downsides of allowing random anonymous people to act as banks are obvious, they write:

This means that all writers of the system are known and we can use a permissioned blockchain.

Ripple is an attempt to set up a permissioned blockchain for interbank payments. It implements its own cryptocurrency, XRP, but also uses "fiat" currencies:

Similar to the traditional correspondent banking system, a payment may require multiple hops if no trust relationship exists between the two banks that are parties in the transaction. Contrary to the traditional system, the payment is atomic, i.e., either all of the intermediate payments go through or none of them. In the traditional system, if something goes wrong for an intermediate payment, previous payments have to be reversed and sometimes manual intervention is required.

The reversibility of payments is a feature not a bug in the current system. As the response of cryptocurrencies to several recent heists reveals, the assumption that nothing can possibly go wrong that requires reversal is not true in the real world. Further, they point out that:

XRP is the only currency on the Ripple ledger for which transactions do not entail counterparty risk. Other currencies are “issued” by gateways that need to be trusted to settle the owed debts outside of the distributed ledger if a party chooses to withdraw a deposit. This means, for example, that not all USD have the same issuer and they are not backed by the central bank, i.e., an on-chain US Dollar is not a real US Dollar and, de facto, every issuer creates a new parallel currency. Because of this gateway system, Ripple does not remove the trust relationships required in the correspondent banking system but simply shifts them to other parties, the gateways.

As we see in the case of Bitcoin, which in practice requires trusting exchanges, and the case of Tether, which appears to be acting as an alternate issuer of "USD" that are not backed by the Federal Reserve, this is a risk no sane bank would run.

As regards DAOs, it is true as the authors write that it requires a permissionless blockchain. But they don't point out that the DAOs have been tried and it turned out that, like all software, they had bugs which made irreversibility a bad idea.

So, despite their enthusiasm for blockchains, the concrete examples the authors analyze agree with David Gerard when he writes:

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.

Gerard's example of "append-only transaction ledgers with cryptographic tamper-proofing" is git. He quotes Naup1ius on Reddit /r/buttcoin analyzing this case against Karl Wüst and Arthur Gervais's flowchart:

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.

On the Reddit thread PM_ME_URANUS corrects Naup1ius and Gerard:

So, I'm replying to a 2 day old comment, but since it's linked to /u/dgerard 's article I thought that it's important to comment.

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

This is not correct. Those are readers who are then writing in their own private copy. You can clone a repository that some other user created, but you might not have the authority to push the code back^[1]. This is why a pull request is needed. It is then the decision of the original author to pull the code of the other user and merge it into their own. So, in this case the original author acts like a central authority.

Are all writers known? No. As mentioned, anyone can create a pull request or work on some branch somewhere.

Again, this is not correct. They are known and we call them maintainers.
[1]: Check out the git book on contributing to a project, especially the part on request-pull

Clearly, source code control is not an application in which allowing untrusted writers is appropriate. The recent example of allowing untrusted writers to modify popular JavaScript should convince you of that.

Wüst and Gervais cite Gideon Greenspan's Avoiding the pointless blockchain project, a less formal but equally restrictive set of criteria for identifying appropriate applications for blockchains. It's also worth reading.

I have one more nit to pick with Gerard. He approves of "append-only transaction ledgers with cryptographic tamper-proofing". But the cryptography in blockchains and git does not make them tamper-proof. It makes them tamper-evident, in that if you modify the ledger the hashes no longer match, and anyone can verify that they have been modified. After all, the blockchain is just a string of bits, and bits can be written.

What makes them in practice tamper-proof, or rather tamper-resistant, is Lots Of Copies Keep Stuff Safe. It is because there are Lots Of Copies that, if you find that your copy of the blockchain has been modified, it is highly likely  you can find an unmodified one somewhere else. If there were only a few copies, an attacker might be able to modify them all. It would be evident that he had done so, but it would not be possible to recover.