How will upgrades to Bitcoin such as Taproot help allow increase of block sizes?

Question

Bitcoin's block size, hardcoded at 1MB, has been limited by the capabilities of its weakest full nodes. The block size limits the number of transactions on the blockchain outside of Layer 2 solutions, increasing fees. Fewer people using their own full nodes makes Bitcoin less decentralized. However, if the weakest full nodes can process larger blocks, Bitcoin can safely increase its block size without losing decentralization. How will upgrades to Bitcoin such as Taproot help allow increase of block sizes?

Belcher told CoinDesk that Schnorr signatures will also enable “batched validation” wherein a Bitcoin full node could “validate 1,000 Taproot signatures in nearly the same time it takes to validate one [ECDSA] signature.” -- How Bitcoin’s Taproot Upgrade Will Improve Technology Across Bitcoin’s Software Stack

If the above quote is true, then it will take much less CPU power to verify a block. That could potentially allow the least powerful full nodes of the network to process larger blocks, which would help Bitcoin scale without sacrificing decentralization.

If the limiting factor that prevented Bitcoin's least powerful full nodes from increasing block size was bandwidth (kilobits per second), then this upgrade won't allow Bitcoin to increase its block size.

A Bitcoin node must receive a block then verify it before retransmitting it. If it takes less CPU power to verify, it might also mean blocks can propagate through the network faster.

There might also be other upgrades that can improve block propagation time. What are they?

Satoshi Nakamoto once said:

Bitcoin can already scale much larger than that with existing hardware [..] By Moore's Law, we can expect hardware speed to be 10 times faster in 5 years and 100 times faster in 10. Even if Bitcoin grows at crazy adoption rates, I think computer speeds will stay ahead of the number of transactions.

Answer 1

Note that blocks can and have been larger than 1 MB. They are generally around 1.5 MB. Additionally, the limit is not on the size in bytes by rather a calculated parameter known as weight. The current limit is 4 million weight units. Depending on the kinds of transactions in the block, the actual block size at the limit can vary from 1 MB to 4 MB.

In general, improvements to Bitcoin are focused around efficiency, rather than just increasing the block size limit. They are focused on making it faster to verify transactions and making transactions smaller. By reducing the weight of transactions, it becomes possible to fit more transactions in the same amount of weight. This reduces the network bandwidth required as more transactions can be sent in the same amount of data.

Typically, the bottleneck in Bitcoin is not network bandwidth but rather on validating blocks and transactions. Blocks are still small enough that most internet connections can relay them in a reasonable amount of time. The bottlenecks are usually on CPU or disk I/O. However bandwidth and storage space are concerns that are being addressed.

CPU is a bottleneck because it takes time verify the scripts and signatures in each transaction. Disk I/O is a bottleneck because the blocks and UTXO set need to be read from and written to permanent storage. The most important thing in the blockchain is the UTXO set. As it grows larger, it is harder to keep it in memory (for fast access) and takes longer to search through. This can have a large effect on the time it takes to verify transactions.

The introduction of taproot gives us batch validation which can dramatically reduce the time required to verify signatures. This makes CPU less of a bottleneck. Taproot also reduces the weight of transactions, particularly multisigs and other more complex scripts. Because taproot implements MAST, only the part of the script that is actually being used needs to be revealed in the transaction. The rest remains hidden away behind hashes. This is generally more space efficient. Furthermore, with signature aggregation schemes like MuSig2, multisigs become indistinguishable from single sig outputs. This provides a dramatic transaction weight reduction as only one pubkey and signature needs to be in the transaction rather than every individual pubkey and signature involved in that multisig.

In terms of the UTXO set, taproot does not provide any changes there. It is generally harder to change the UTXO set through soft forks (other than declaring some kinds of outptus unspendable, but we don't want to do that). However changes can be made to encourage users to consolidate their UTXOs and to encourage spending UTXOs rather than creating UTXOs. Segwit did this through the introduction of the block weight limit where it made spending Segwit UTXOs cheaper.

Answer 2

In 2017, the 1-MB blocksize limit was replaced with a 4,000,000 weightunit blockweight limit when the segwit softfork became active.

The average blocksize has grown fairly consistently since then to about 1.33 MiB in average now. In the same time frame, payments per day have been growing consistently as well:

How's that happening? Growing against the limit, users across the network are incentivized to adopt best practices and use blockweight more efficiently. Today, in April 2021, only 45% of all inputs use pre-segwit output types. 42% use wrapped segwit, and about 13% use native segwit. As adoption of native segwit increases, the average blocksize will trend towards about 2.5 MiB—fitting significantly more payments into the same blockweight limit.

Taproot provides further efficiency improvements in the same vein. Signatures on Pay to Taproot (P2TR) inputs are 11% smaller since Schnorr signatures are encoded more compactly. The script tree in Taproot allows encoding multiple spending conditions in separate leafs and allows spending by only revealing the one leafscript that is used—previously, multiple conditions would be encoded in a single complex script that had to be written to the blockchain in full. Schnorr signatures have linearity which allows multiple signatures to be aggregated. This opens up the possibility to perform scriptless scripts like atomic swaps or oracle-based transactions without adding more data to transactions. Hopefully, we'll see widespread adoption of public key aggregation which allows us to encode multisignature or threshold quorums in what looks like a single public key. Meanwhile, batch validation will allow P2TR inputs to be validated slightly more efficiently.

Obviously, all of these scalability improvements are limited in their potential. For Taproot keypath-spends, just the reference to the spent UTXO makes up 62% of the input weight. So, when the potential for efficiency improvements with the current blockweight has been completely exhausted, we might want to revisit the idea of a blockweight limit increase or perhaps even implement a continuous growth function for the blockweight. Meanwhile, other layers built on top of Bitcoin are maturing slowly with e.g. Lightning Network reportedly growing exponentially among early adopters at the moment.