Blockchain Myth 4: “Public blockchains are too slow for [insert use case]”
This is the fourth post in a six part series about prevailing myths in blockchain implementations. The previous myths are:
“Public blockchains are too slow” sounds a lot like what skeptics said in the mid 90s about the state of the internet.
At the time, the argument was that most communication that the internet should be good for was synchronous, like telephone conversations, sales interactions, and watching TV shows, while the real internet seemed to have been designed to route data in ways that aren’t tuned to immediacy, like email, downloading a sound clip prior to listening to it, or viewing a website that might take 20s to load.
“For a while the internet seemed only good for making online CVs and brochures. How boring!”
Although access to having an internet presence was very easy, the possibilities of such a limited medium seemed underwhelming. A sign of this apparent lack of potential was that everyone could, and many did, have a home page that no one visited. Small businesses made web pages to showcase their offering, but mostly these were just like Yellow Pages listings, yet harder to find. People were trying to make the internet do what they were doing using other more mature technology. For a while the internet seemed only good for making online CVs and brochures. How boring!
Of course, there were a few businesses that seemed to be making millions on the internet, like eBay, but these seemed very niche and it was far from obvious how the internet would change the brick and mortar world that we experienced every day. eBay was only about making a better classifieds listing, and for a while it looked like that was the only way for an internet business to make money. No one believed that anyone would buy shoes online without trying them on or that internet media could someday swing elections. The internet experience seemed just too limited in scope and too detached from the real world to make a real impact.
For example Robert Metcalfe, a recognized internet pioneer, predicted in 1995 that “the Internet will soon go spectacularly supernova and in 1996 catastrophically collapse,” listing speed as one of the insurmountable bottlenecks. Incidentally, another bottleneck he identified was the lack of digital money. He made the same mistake that we all make. He thought that the internet would first replace the mature technologies we already used, like telephones and television.
It turned out that even though the early internet was too slow or jittery for what we thought it should do, it was in those slow beginnings that the great internet use cases were born and proven, despite or maybe even because of these limitations. It is actually thanks to limitations specifically that we can better see great solutions, because they succeed in spite of the limitations that weigh them down.
There is a brief allusion to this limitation paradox in Myth 3 about Netflix and Amazon succeeding despite not being able to stream movies or deliver electronic books to their customers. But Netflix did not wait for cloud scaling and video streaming technology to arrive, because that was not how it created value.
The answer at that time was, as it is now, that high bandwidth use cases are almost certainly not the ones that should be explored first, and they are not the transformative ones anyway.
Amazon decided to sell paper books through an online ordering process,
Netflix allowed online ordering of snail-mailed DVDs,
etc.
Similarly, with blockchain there is no reason to rush for 20k transaction use cases. This is especially true, since we already have 20k transaction per second throughputs on legacy infrastructure. Blockchains do not solve old problems in the ways that we expect, they solve problems in completely new ways that will take a little while to grow on us. In fact, even the internet hasn’t yet caught up to the immense bandwidth of legacy “data transmission” technology and lore has it that Google FedEx what they can’t transmit.
If we find ourselves waiting for the technology to catch up with our expectations, is it possible that the train is leaving the station and we are not on board?
Perhaps we might achieve the speeds we seek if we take a page from the Netflix playbook and try to put as little data on the chain as possible, or none at all?
For instance, if we stick to using the blockchain for data validation using hashes, we can omit placing any data whatsoever on the blockchain itself. Hashes can be easily aggregated using Merkle Trees to drastically reduce the amount of on-chain space required for hash storage. Drastic might be an understatement. A Merkle Tree reduces any number of hashes to a single Merkle Root hash that needs to be registered on chain. The tradeoff is a little more data to pass around with the information that needs to be verified, and the internet is very good at letting us pass vast amounts of data around peer-to-peer. And so, if we want to register 1 million documents on a public chain, we only need one small on-chain transaction to do it, while keeping all transaction details off-chain.
If we look around, there are already projects that are implementing this approach as a layer on top of public blockchains. Some notable ones include Toda, Celer, and Elixxir (it is likely that there are others that I have not come across). All these projects make extensive use of merkle trees to compress proofs into manageable size for on-chain transactions, and at the same time let the user keep all details of transactions in private channels or in private containers, which in addition to providing privacy, also allow for parallel processing (i.e. speed).
What of fast blockchains then? While blockchains will get faster with time, they will always be limited by the eons it takes for signals to travel across the globe and patchy network reliability. A good introduction to why this is so is captured in the PACELC Theorem, which explains how to tackle the challenges of having a single source of truth in distributed systems. It is important to note that blockchains do not bring any novel solutions to the limitations resulting from this theorem.
To get just a glimpse of how storage and data analytics will work in the decentralized, private, and fast blockchain enabled internet, check out Stanford’s Prio.
—
NOTE: In my articles I refer to existing projects that I find noteworthy for a particular purpose. Under no circumstances should this be construed as evidence of my having done substantial due diligence on these projects beyond skimming their whitepaper, and these references should not be construed as endorsement of these projects or investment advice.
Accreditation: The material for Blockchain Myths (of which this post is a part) was initially developed at ConsenSys with the fantastic feedback and help of many individuals, including: Tee Ganbold, Zunaira Arshad, Micah Dameron, Chris Leishman, Van Sedita, John Wolpert, Jeff Gillis, Jérôme de Tychey, Ray Valdes, Igor Lilic, Joseph Khalife, and other great people roaming cryptoland.
