Progress pill
Bitcoin Gouvernance

Scaling

Bitcoin Development Philosophy

Scaling

  • History of Scaling
  • Scaling approaches
  • Conclusion about Scaling
In this chapter, we explore how Bitcoin does and does not scale. We start by looking at how people have reasoned about scaling in the past. Then, the bulk of this chapter explains various approaches to scaling Bitcoin, specifically vertical, horizontal, inward, and layered scaling. Each description is followed by considerations over whether the approach interferes with Bitcoin's value proposition.
In the Bitcoin space, different people ascribe different definitions to the word "scale". Some conceive it as the increase of the blockchain transaction capacity, others believe it equals to using the blockchain more efficiently, and others see it as the development of systems on top of Bitcoin.
In the context of Bitcoin, and for this book's purposes, we define scaling as increasing Bitcoin's usage capacity without compromising its censorship resistance. This definition encompasses several kinds of changes, for example:
  • Making transaction inputs use fewer bytes
  • Improving signature verification performance
  • Making the peer-to-peer network use less bandwidth
  • Transaction batching
  • Layered architecture
We'll soon dive into different approaches to scaling, but let's start with a brief overview of Bitcoin's history within the context of scaling.

History of Scaling

Scaling has been a focal point of discussion since the genesis of Bitcoin. The very first sentence of the very first email in response to Satoshi's announcement of the Bitcoin whitepaper on the Cryptography mailing list was indeed about scaling:
Satoshi Nakamoto wrote: "I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party. The paper is available at http://www.bitcoin.org/bitcoin.pdf" We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size.
The conversation in itself might not be very interesting nor accurate, but it shows that scaling has been a concern from the very beginning.
Discussions over scaling reached their peak interest around 2015-2017, when there were many different ideas circulating about whether and how to increase the maximum block size limit. That was a rather uninteresting discussion about changing a parameter in the source code, a change that didn't fundamentally solve anything but pushed the problem of scaling further into the future, building technical debt.
In 2015, a conference called Scaling Bitcoin was held in Montreal, with a follow-up conference six months later in Hong Kong and thereafter in a number of other locations around the world. The focus was precisely on how to address scaling. Many Bitcoin developers and other enthusiasts gathered at these conferences to discuss various scaling issues and proposals. Most of these discussions didn't revolve around block size increases but on more long-term solutions.
After the Hong Kong conference in December 2015, Gregory Maxwell summarized his view on many of the issues that had been debated, starting off with some general scaling philosophy:
With the available technology, there are fundamental trade-offs between scale and decentralization. If the system is too costly people will be forced to trust third parties rather than independently enforcing the system's rules. If the Bitcoin blockchain’s resource usage, relative to the available technology, is too great, Bitcoin loses its competitive advantages compared to legacy systems because validation will be too costly (pricing out many users), forcing trust back into the system. If capacity is too low and our methods of transacting too inefficient, access to the chain for dispute resolution will be too costly, again pushing trust back into the system.
He speaks about the trade-off between throughput and decentralization. If you allow for bigger blocks, you will push some people off the network because they won't have the resources to validate the blocks anymore. But on the other hand, if access to block space becomes more expensive, fewer people will be able to afford using it as a dispute resolution mechanism. In both cases, users are pushed towards trusted services.
He continues by summarizing the many approaches to scaling presented at the conference. Among them are more computationally efficient signature verifications, segregated witness including a block size limit change, a more space-efficient block propagation mechanism, and building protocols on top of Bitcoin in layers. Many of these approaches have since been implemented.

Scaling approaches

As hinted above, scaling Bitcoin doesn't necessarily have to be about increasing the block size limit or other limits. We now go through some general approaches to scaling, some of which don't suffer from the throughput-decentralization trade-off mentioned in the previous section.

Vertical scaling

Vertical scaling is the process of increasing the computing resources of the machines processing data. In the context of Bitcoin, these latter would be the full nodes, namely the machines that validate the blockchain on behalf of their users.
The most commonly discussed technique for vertical scaling in Bitcoin is the increase in the block size limit. This would require some full nodes to upgrade their hardware to keep up with the increasing computational demands. The downside is that it happens at the cost of centralization.
Besides the negative effects on full node decentralization, vertical scaling might also negatively impact Bitcoin's mining decentralization and security in less obvious ways. Let's have a look at how miners "should" operate. Say a miner mines a block at height 7 and publishes that block on the Bitcoin network. It will take some time for this block to reach broad acceptance, which is mainly due to two factors:
  • Transfer of the block between peers takes time due to bandwidth limitations.
  • Validation of the block takes time.
While block 7 is being propagated through the network, many miners are still mining on top of block 6 because they haven't received and validated block 7 yet. During this time, if any of these miners finds a new block at height 7, there will be two competing blocks at that height. There can only be one block at height 7 (or any other height), which means one of the two candidates must become stale.
In short, stale blocks happen because it takes time for each block to propagate, and the longer propagation takes, the higher the probability of stale blocks.
Suppose that the block size limit is lifted and that the average block size increases substantially. Blocks would then propagate slower across the network due to bandwidth limitations and verification time. An increase in propagation time will also increase the chances of stale blocks.
Miners don't like to have their blocks staled because they'll lose their block reward, so they will do whatever they can to avoid this scenario. The measures they can take include:
  • Postponing the validation of an incoming block, also known as validationless mining. Miners can just check the block header's proof-of-work and mine on top of it, while in the meantime they download the full block and validate it.
  • Connecting to a mining pool with greater bandwidth and connectivity.
Validationless mining further undermines full node decentralization, as the miner resorts to trusting incoming blocks, at least temporarily. It also hurts security to some degree because a portion of the network's computing power is potentially building on an invalid blockchain, instead of building on the strongest and valid chain.
The second bullet point has a negative effect on miner decentralization, because usually the pools with the best network connectivity and bandwidth are also the largest, causing miners to gravitate towards a few big pools.

Horizontal scaling

Horizontal scaling refers to techniques that divide the workload across multiple machines. While this is a prevalent scaling approach among popular websites and databases, it's not easily done in Bitcoin.
Many people refer to this Bitcoin scaling approach as sharding. Basically, it consists in letting each full node verify just a portion of the blockchain. Peter Todd has put a lot of thought into the concept of sharding. He wrote a blog post explaining sharding in general terms, and also presenting his own idea called treechains. The article is a difficult read, but Todd makes some points that are quite digestible:
In sharded systems the “full node defense” doesn’t work, at least directly. The whole point is that not everyone has all the data, so you have to decide what happens when it’s not available.
Then he presents various ideas on how to tackle sharding, or horizontal scaling. Towards the end of the post he concludes:
There’s a big problem though: holy !@#$ is the above complex compared to Bitcoin! Even the “kiddy” version of sharding - my linearization scheme rather than zk-SNARKS - is probably one or two orders of magnitude more complex than using the Bitcoin protocol is right now, yet right now a huge % of the companies in this space seem to have thrown their hands up and used centralized API providers instead. Actually implementing the above and getting it into the hands of end-users won’t be easy. On the other hand, decentralization isn’t cheap: using PayPal is one or two orders of magnitude simpler than the Bitcoin protocol.
The conclusion he makes is that sharding might be technically possible, but it would come at the cost of tremendous complexity. Given that many users already find Bitcoin too complex and prefer to use centralized services instead, it's going to be hard to convince them to use something even more complex.

Inward scaling

While horizontal and vertical scaling have historically worked out well in centralized systems like databases and web servers, they don't seem to be suitable for a decentralized network like Bitcoin due to their centralizing effects.
An approach that gets far too little appreciation is what we can call inward scaling, which translates into "do more with less". It refers to the ongoing work constantly done by many developers to optimize the algorithms already in place, so that we can do more within the existing limits of the system.
The improvements that have been achieved through inward scaling are impressive, to say the least. To give you a general idea of the improvements over the years, Jameson Lopp has run benchmark tests on blockchain synchronization, comparing many different versions of Bitcoin Core going back to version 0.8.
In the graph above, you can see the initial block download performance of various versions of Bitcoin Core. On the Y-axis is the block height synced and on the X-axis is the time it took to sync to that height
The different lines represent different versions of Bitcoin Core. The leftmost line is the latest, i.e. version 0.22, which was released in September 2021 and took 396 minutes to fully sync. The rightmost one is version 0.8 from November 2013, which took 3452 minutes. All of this - roughly 10x - improvement is due to inward scaling.
The improvements could be categorized as either saving space (RAM, disk, bandwidth, etc.) or saving computational power. Both categories contribute to the improvements in the diagram above.
A good example of computational improvement can be found in the libsecp256k1 library, which, among other things, implements the cryptographic primitives needed to make and verify digital signatures. Pieter Wuille is one of the contributors to this library, and he wrote a Twitter thread showcasing the performance improvements achieved through various pull requests.
In the graph above, you can see the performance of signature verification over time, with significant pull requests marked on the timeline.
The graph shows the trend for two different 64-bit CPU types, namely ARM and x86. The difference in performance is due to the more specialized instructions available on x86 compared to the ARM architecture, which has fewer and more generic instructions. However, the general trend is the same for both architectures. Note that the Y-axis is logarithmic, which makes the improvements look less impressive than they actually are.
There are also several good examples of space-saving improvements that contributed to performance enhancement. In a Medium blog post about Taproot's contribution to saving space, user Murch compares how much block space a 2-of-3 threshold signature would require, using Taproot in various ways as well as not using it at all.
A 2-of-3 multisig using native Segwit would require a total of 104.5+43 vB = 147.5 vB, whereas the most space-conservative use of Taproot would require only 57.5+43 vB = 100.5 vB in the standard use case. At worst and in rare cases, like when a standard signer is not available for some reason, Taproot would use 107.5+43 vB = 150.5 vB. You don't have to understand all the details, but this should give you an idea of how developers think about saving space - every little byte counts.
Apart from inward scaling in Bitcoin software, there are some ways in which users can contribute to inward scaling, too. They can make their transactions more intelligently to save on transaction fees while simultaneously decreasing their footprints on full node requirements. Two commonly used techniques toward such goal are called transaction batching and output consolidation.
The idea with transaction batching is to combine multiple payments into one single transaction, instead of making one transaction per payment. This can save you a lot of fees, and at the same time reduce the block space load.
Transaction batching combines multiple payments into a single transaction to save on fees.
Output consolidation refers to taking advantage of periods of low demand for block space to combine multiple outputs into a single output. This can reduce your fee cost later, when you'll need to make a payment while the demand for block space is high.
Output consolidation: Melt your coins into one big coin when fees are low to save fees later.
It may not be obvious how output consolidation contributes to inward scaling. After all, the total amount of blockchain data is even slightly increased with this method. Nonetheless, the UTXO set, i.e. the database that keeps track of who owns which coins, shrinks because you spend more UTXOs than you create. This alleviates the burden for full nodes to maintain their UTXO sets.
Unfortunately, however, these two techniques of UTXO management could be bad for your own or your payees`' privacy. In the batching case, each payee will know that all the batched outputs are from you to other payees (except possibly the change). In the UTXO consolidation case, you will reveal that the outputs you consolidate belong to the same wallet. So you may have to make a trade-off between cost efficiency and privacy.

Layered scaling

The most impactful approach to scaling is probably layering. The general idea behind layering is that a protocol can settle payments between users without adding transactions to the blockchain.
A layered protocol begins with two or more people agreeing on a start transaction that's put on the blockchain, as illustrated in the below figure.
How this start transaction is created varies between protocols, but a common theme is that the participants create an unsigned start transaction and a number of pre-signed punishment transactions, that spend the output of the start transaction in various ways. Subsequently, the start transaction is fully signed and published to the blockchain, and the punishment transactions can be fully signed and published to punish a misbehaving party. This incentivizes the participants to keep their promises so that the protocol can work in a trustless way.
Once the start transaction is on the blockchain, the protocol can do what it's supposed to do. For instance, it could do super fast payments between participants, implement some privacy-enhancing techniques, or do more advanced scripting that would not be supported by the Bitcoin blockchain.
We won't detail how specific protocols work, but as you can see in the previous figure, the blockchain is rarely used during the protocol's life cycle. All the juicy action happens off-chain. We've seen how this can be a win for privacy if done right, but it can also be an advantage for scalability.
In a Reddit post titled "A trip to the moon requires a rocket with multiple stages or otherwise the rocket equation will eat your lunch... packing everyone in clown-car style into a trebuchet and hoping for success is right out.", Gregory Maxwell explains why layering is our best shot at getting Bitcoin to scale by orders of magnitudes.
He starts by emphasizing the fallacy in viewing Visa or Mastercard as Bitcoin's main competitors and highlighting how increasing the maximum block size is a bad approach to meet said competition. Then he talks about how to make some real difference by using layers:
So-- Does that mean that Bitcoin can't be a big winner as a payments technology? No. But to reach the kind of capacity required to serve the payments needs of the world we must work more intelligently. From its very beginning Bitcoin was design to incorporate layers in secure ways through its smart contracting capability (What, do you think that was just put there so people could wax-philosophic about meaningless "DAOs"?). In effect we will use the Bitcoin system as a highly accessible and perfectly trustworthy robotic judge and conduct most of our business outside of the court room-- but transact in such a way that if something goes wrong we have all the evidence and established agreements so we can be confident that the robotic court will make it right. (Geek sidebar: If this seems impossible, go read this old post on transaction cut-through) This is possible precisely because of the core properties of Bitcoin. A censorable or reversible base system is not very suitable to build powerful upper layer transaction processing on top of... and if the underlying asset isn't sound, there is little point in transacting with it at all.
The analogy with the judge is quite illustrative of how layering works: this judge must be incorruptible and never change her mind, otherwise the layers above Bitcoin's base layer will not work reliably.
He continues by making a point about centralized services. There's usually no problem with trusting a central server with trivial amounts of Bitcoin to get things done: that's also layered scaling.
Many years have passed since Maxwell wrote the piece above, and his words still stand correct. The success of the Lightning Network proves that layering is indeed a way forward to increase the utility of Bitcoin.

Conclusion about Scaling

We've discussed various ways through which one might want to scale Bitcoin, increase Bitcoin's usage capacity. Scaling has been a concern in Bitcoin since its very early days.
We know today that Bitcoin doesn't scale well vertically ("buy bigger hardware") or horizontally ("verify only parts of the data"), but rather inward ("do more with less") and in layers ("build protocols on top of Bitcoin").
Quiz
Quiz1/5
What was the primary criticism raised in the very first email response to Satoshi Nakamoto's announcement of the Bitcoin whitepaper on the Cryptography mailing list?