Can Bitcoin Cash Scale On Chain?
For years there were a number of us who pushed back against the narrative of the Core developers and their allies that Bitcoin Cannot Scale™. Or at least that if you tried to scale on chain you would create centralization. At least since 2015 such dissenting opinions have not been allowed in /r/bitcoin or any other of their communications channels. People like myself have given up trying to get our opinions across since 1) they will just delete my comments anyway and 2) I will be subjected to a Two Minutes of Hate by a mob of groupthinkers. But now that Bitcoin Cash has forked the blockchain and is positioning itself to actually scale on chain, these same people, plus a group of newbies victimized by censorship, are now shouting from the rooftops that BCASH CAN’T SCALE™!! It’s IMPOSSIBLE! But is it really? Centralization The primary reason scaling is said to be “impossible” goes something like this. If you increase the number of transactions the network processes then you will increase the cost of running a Bitcoin node. People will have to spend money on more expensive hardware and fewer people will do this resulting in centralization of the network. There is a second concern about block propagation that I will address below but for now I want to address the above argument. Is it true that if we increase transaction volume it will require more expensive hardware to run a node? Yes, but only beyond a certain point. The reason for this is that nearly every computer running today has excess resources. Some, like the laptop I’m typing this on, have A LOT of excess resources. Now I tend to be of the opinion that targeting a minimum system requirement such that end users can run a full node from home is probably overly conservative (the level of decentralization could probably be maintained even if only businesses ran nodes), but nonetheless it’s good to be conservative. So for the purpose of this article I will assume we want to keep it feasible to run a full node from home. Ask yourself how much centralization could there possibly be in the Bitcoin Cash network if, like the Bitcoin network, it remains feasible to run a full node on a home computer?
But I Heard 1MB is Already Too Large
Rather than relying on gut intuition let’s do some actual science. Shall we? Peter Rizun and Andrew Stone from Bitcoin Unlimited have undertaken a research initiative to determine the maximum feasible blocksize. For the purpose of this research they are using computers with similar specs to what people have at home and what most of the Western world have access to ― quad-core CPUs with 16GB of memory and a 30 Mbps internet connection.
Here’s a video of them presenting their research at Stanford.
https://www.youtube.com/watch?v=5SJm2ep3X_M So what are the preliminary results? Well basically they hit a bottleneck at a blocksize of about 22MB (my estimation). But it turns out that the cause of the bottleneck was not due to hardware. Nor was it the internet speed. The bottleneck turned out to be the Bitcoin Core software itself. Despite all the praise lavished on the Core developers, the Core software could best be described as horrifically unoptimized. For those who are less tech savvy it means that the software is not taking full advantage of the resources available to it. Andrew Stone identified the bottleneck as mempool acceptance and proceeded to optimize the code to admit transactions into the mempool in parallel. With just this one optimization they were able to increase the blocksize up over 100MB before hitting another bottleneck. This second bottleneck was due to block propagation which I will discuss below but I just want to pause here for a second. We’re already at 100MB. That’s three times PayPal scale. Running on a typical home computer. With internet speeds typical of home networks. The research is still ongoing. They still have to repeat the experiment with larger UTXO set sizes which may degrade performance some, but again there are still huge software optimizations still out there that have yet to be implemented which may balance out. But Isn’t Home Internet Bandwidth the Bottleneck?
No. Let’s take a look at the bandwidth usage of a Bitcoin node. You can find some stats here. The combined upload and download bandwidth for that Bitcoin node is about 8.8 Mbps. If I compare that to my home internet with speeds of about 100 Mbps I can see I’ve got a fair amount of excess bandwidth. But let’s dig into that 8.8 Mbps number a bit more. It turns out that about 97.5% of the bandwidth being used is unrelated to processing transactions and blocks. Instead all of that bandwidth is being used to upload blocks to nodes that are bootstrapping or coming back from an absence. Another opportunity for some massive optimization. I will talk about how we can optimize that in the next section but for now I just want to point out that if you run your node in “pruned” mode, you will not upload the chain to other peers and will reduce your bandwidth usage to just 220 kBps. If we multiply 220 kBps by 100 to get a rough estimate of our bandwidth usage at 100MB blocks we get 22 Mbps. Plenty to run a blockchain with 100MB blocks and still stream Netflix on multiple TVs at the same time. I am aware that some, though certainly not all, ISPs have monthly data caps. But people with those ISP would just have to suck it up and upgrade to an unlimited plan if they want to run a home node. And I suspect in a few years all plans will be unlimited. But Wont Blockchain Storage Be Astronomical? If we have 100MB blocks we’re looking at about 5.2 TB of data storage per year. While that high(ish) and would probably take a dedicated device to store that amount, we can mostly eliminate the storage requirement through optimization. To run a fully validating node you don’t technically need to store the historical blockchain. All you need to validate new transactions and blocks is the UTXO set ― a database of unspent bitcoins. This is what the “pruned” mode I mentioned above does. It deletes the historical blockchain and just uses its copy of the UTXO set to validate new transactions. The only issue with pruned mode is if everyone uses it then we can’t bootstrap new nodes. Currently the only mechanism available to bootstrap new nodes is to have them connect to a peer and download the full blockchain from genesis. This not only requires that some nodes bite the bullet and store the full chain on disk, but it makes bootstrapping a dreadfully slow process AND it’s the cause of that excessive amount of bandwidth we saw above. We can do better. The idea behind UTXO commitments have been around a long time and have never really been implemented. There are a couple different ways to use them to bootstrap new nodes. Each have different tradeoffs and I won’t get into them here, but the bottom line is that we should be able to get to the point where to bootstrap a new node we only need to serve them the UTXO set and not the entire historical chain. This removes the need for all but archival nodes to store the historical blockchain and will pretty dramatically reduce the bandwidth used to bootstrap new nodes.
So we’ve arrived at a point where it seems entirely feasible to process at least 100MB blocks on a laptop that we could find at Best Buy. Is there any other reason why larger blocks might cause centralization? It turns out there is. It’s somewhat unintuitive but larger blocks actually provide a small competitive advantage to larger miners creating an incentive for people to only mine in the largest pool which risks mining centralization. The reason for this is larger blocks take longer to propagate to other miners and increase the amount of time a miner has to mine on top of his own block before everyone else. Occasionally a miner will mine a second block before the first one has propagated. Larger miners simply have more opportunities do to this. We do know of some advanced blockchain designs that would eliminate or reduce the problem. For example, Emin Gün Sirer’s Bitcoin-NG protocol completely eliminates this problem. Professor Brian Levine’s Bobtail protocol dramatically reduces (though I don’t believe eliminates) the effect. But without radical consensus changes we can still pretty dramatically reduce this effect through simple block compression. Currently Core’s compact block protocol can compress a block down to as little as 2% of its original size. That means a 100MB block would only take about 2MB of data to transmit around the network. The smaller size means it not only uses less bandwidth but it minimizes the amount of time miners have to mine on top of their own blocks. But we can do a lot better than this. Professor Levine’s Graphene protocol based on invertible bloom lookup tables is able to compress a block down to a tenth of the size of Core’s compact block. That means a 100MB block would transmit with only 200kB of data. But we might even been able to compress it even further than that. There is some preliminary work being done by Bitcoin Cash developers on weak blocks. This is a technique that would pre-transmit the vast majority of the transactions in a block so that when the actual block is mined it only needs to include the diff between it and the weak blockchain. If we combined weak blocks with a 10 second interval with Graphene, the final 100MB block would transmit using only 3.3kB of data (the rest was pre-transmitted).** That’s the amount of data the Bitcoin network was transmitting per block way back in 2012. So to sum up, unless you thought Bitcoin had unacceptable mining centralization in 2012, 100MB blocks should not a concern.
**I should mention here that deadalnix believes I’m wrong on the magnitude of the weak blocks savings but he has yet to fully convince me ¯\_(ツ)_/¯
But You Can’t Scale On Chain Forever. Layer 2 Is Still Needed! So we can scale to at least 100MB blocks on a home laptop but what happens once we exhaust that capacity? Won’t we have to give up and admit we failed and accept the inevitability of layer 2? Maybe. But maybe not. I’ve made it this far by only talking about what is possible today. I still haven’t mentioned Moore’s Law ― the observation that CPU speeds double approximately every two years. People have heralded the end of Moore’s law for a while but it’s still chugging along. For bandwidth we have Neilsen’s Law in which bandwidth grows by about 50% per year. Assuming CPU speeds and bandwidth continue to increase, Bitcoin Cash will be able to continue adding transaction volume without creating new centralization pressure. The only real risk is if growth in transaction demand outstrips Moore’s Law (which seems likely). Then yes, we may eventually hit an actual (non-Core developer imposed) bottleneck. But we can predict we won’t hit that bottleneck at least for a while. If we assume transaction volume will double every year for the foreseeable future (which may or may not be a reasonable estimate), the following chart shows when we will actually hit that bottleneck assuming different resource growth rates.
Even if we take a conservative estimate of only 20% resource growth per year, we still don’t hit any actual bottlenecks until 2029 and by then a home laptop will be able to process Gigabyte blocks, which is essentially VISA scale.
OK, OK But in 2029 You’re Going To Need Layer 2! Greg Maxwell Is Right! We really can’t predict what the state of the art for blockchain technology will look like next year, let alone over a decade from now. Innovation in this field is coming fast and furious. Ethereum is already experimenting with sharding, which for me holds great promise for delivering unlimited on chain scaling. A decade from now I would be surprised if every new blockchain being brought to market isn’t using sharding to scale. Beyond sharding, zk-snarks seem to have tons of potential. Imagine syncing and fully validating a blockchain from genesis in less than a second by downloading just 32 bytes. Mind blowing. Zk-snarks can’t efficiently do this today, and may never be able to do so, but given the amount of research pouring in and the pace of innovation, it doesn’t seem unreasonable to think that this might be possible in 10 years.
In the end the way you scale any software is to push it to the limits, identify bottlenecks, optimize, then wash/rinse/repeat. That’s the Bitcoin Cash scaling plan in a nutshell.
Conclusion People have been claiming that Bitcoin Can’t Scale™ for years despite pretty strong evidence to the contrary. In my opinion the success of this narrative owes itself to rampant censorship, outright deleting of dissenting opinions, a tightly controlled narrative and social manipulation. Typically when the facts speak for themselves you do not need to engage in this type of dishonesty. Sadly the Bitcoin community has shown little capacity for independent critical thinking and has bought right into this narrative.
In this article I have shown that Bitcoin Cash can indeed scale to pretty large blocksizes all the while running on home computers and without sacrificing decentralization. The groupthinkers shouting BCASH CAN’T SCALE from the rooftops are wrong and Bitcoin Cash developers are committed to proving this to be the case.
30 of 30 reviewers say it's worth paying for
0 of 30 reviewers say it's not worth paying for