Thursday, February 15, 2018

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.


David. said...

Tim Bray's tweetstorm starts:

"1/ Suffering from disorientation and cognitive dissonance around blockchain and Bitcoin. It’s time to stop the craziness. "

Read the whole thing.

David. said...

Stephen Williamson of the St. Louis Fed asks Is Bitcoin a Waste of Resources?:

"Potentially, Bitcoin could be useful if it is widely used as a means of payment or as a safe-haven asset. But, given its properties, it is an inefficient and poorly designed means of payment and probably cannot survive as a safe haven asset. Bitcoin could encourage crime, which is a further social cost, but fortunately it may not serve criminals well either."

David Gerard said...

I'll cop to having used "tamper-proofed" as an elision of "tamper-evident" :-)

David. said...

One thing blockchains were good for was "pump & dump" schemes such as Long Island Ice Tea's but alas the party is over:

"I’ve never seen a sector skyrocket and totally collapse this fast – in four months – as these newfangled “blockchain stocks.” Now they’re surrounded by debris and revelations of scams."

Wolf Richter surveys the wreckage in detail.

David. said...

Finding The Greedy, Prodigal, and Suicidal Contracts at Scale by Ivica Nikolic, et al reports on a study of nearly 1M "smart contracts" on the Ethereum blockchain using MAIAN, an automated tool that found 34,200 had one of three types of vulnerability.

"For 3,759 contracts we tried to concretely validate, MAIAN has found over 3,686 confirmed vulnerabilities with 89% true positive rate."

"Smart contracts" are software. Software has bugs. Immutable software has bugs that cannot be fixed.

David. said...

What do you get when you combine a DAO with an ICO? Its a DAICO! Lawyer Preston Byrne takes down the concept:

"There are, of course, problems with this approach. The first is that tokenholders are generally passive rather than active investors: the original DAO could pass resolutions with a simple majority drawn from quorum of 20% (meaning as little as 10% +1 of the investors could bind the remaining 90%). No resolution ever passed because none of the tokenholders actually cared enough about what the DAO was doing in order to participate. Their primary motivation was to sit on their hands and wait for their investment to pay off.


Second, ... the SEC literally wrote a report about the original DAO scheme, likened it to a security, and cited as authority for this proposition not one but TWO cases relating to an infamous 1970s pyramid scheme that landed its promoter in federal prison for nearly a decade."

Johan van der Knijff said...

Meanwhile the JPEG committee is jumping on the blockchain bandwagon as well (the announcement doesn't mention what specific problem they're hoping to solve with it).

David. said...

Sam D'Amico's Blockchain Technology, Decentralization, and Magical Thinking is a great summary of the many gaps between hype and reality. Here's a snippet:

"A major factor is that magical thinking is masking certain economic realities that are hard to overcome. Distributed and decentralized services aren’t merely a feature in themselves, and censorship resistance of a particular technology says nothing about the censorship resistance of the peripheral technologies needed to support it (for Bitcoin, that would be exchanges, wallet apps, etc). Another issue is that distributed and decentralized services do not necessarily map to existing networks and likewise, do not push network investment in the ways that are best optimized for their adoption. An example here is why Bittorrent-style distribution didn’t win out versus hosting content on cloud storage instances — the performance guarantees and base economics of services such as Amazon S3, plus the poor location of the server nodes in the BitTorrent case, push towards this conclusion."

David. said...

The EU's "General Data Protection law, ... says people must be able to demand that their personal data is rectified or deleted under many circumstances. A blockchain is essentially a growing, shared record of past activity that's distributed across many computers, and the whole point is that this chain of transactions (or other fragments of information) is in practice unchangeable – this is what ensures the reliability of the information stored in the blockchain." writes David Meyer at Medium:

"For blockchain projects that involve the storage of personal data, these two facts do not mix well. And with sanctions for flouting the GDPR including fines of up to €20 million or 4 percent of global revenues, many businesses may find the ultra-buzzy blockchain trend a lot less palatable than they first thought."

David. said...

David Gerard's slides are an excellent overview of three points:

1. The blockchain data structure, which is a simple application of Merkle trees (published 1979).

2. The failure of Bitcoin and other cryptocurrencies.

3. The "blockchain for business" bype-fest.