What about Initial Block Download (IBD)?

Many people, once they hear about Bitcoin's big block scaling strategy, become concerned about the need to run nodes and preserve its decentralisation. If the blockchain size grows continually (& potentially exponentially), won't it become potentially impossible to synchronise new nodes (to replace or augment the existing set) - thus eventually centralising the system? This particular concern - the time & difficulty required to synchronise a new node from other existing nodes already running on the network - is called Initial Block Download (IBD).

Of course, nodes are important for decentralisation, although bigger blocks do not need to reduce the amount of nodes. Initial block download is something the BCH community must keep in mind, but fortunately it is not as simple as "bigger blocks = terrible or infeasible IBD". There are a variety of technologies & mitigating factors which allow for a bigger blocksize without sacrificing the feasibility of IBD.

UTXO Commitments

The primary technology for improving IBD is called "UTXO Commitments". By embedding a hash of the UTXO set at a given blockheight inside the coinbase of a block, miners can vouch with their proof of work for a specific set of UTXOs that were unspent at that block. This proof accumulates over time, as with security of transactions, confirmation by confirmation. In this way, new nodes could spin up from "checkpoints" in the blockchain and perform background validation of the past data while already live & serving the network.

Old model (without UTXO Commitments): New nodes download hundreds of GBs or TBs of blockchain data & beginning at block 0 work forward to the present day to check validity of the history of transactions, building a current UTXO set along the way. Slow to start & becomes harder and harder to catch up to current transactions as throughput scales.
New model (with UTXO Commitments): New nodes can start at block X (close to the current tip), grab a much smaller (As of mid 2025, sub 20 GB) UTXO set download from any trusted or untrusted source, verify that it is correct with the Proof-of-work secured hash inside the matching block & begin processing transactions as part of the network immediately. Not only is it faster to spin up new nodes, but retroactive validation time becomes much less problematic (since it can happen in the background while the node is already operating). Trustlessness is preserved by having the UTXO set hash embedded into the PoW secured blockchain.

UTXO Commitment concepts have been discussed since the early 2010s, but interest and development died down because of the Blocksize War. The small block side limited their blocks' throughput thus removing any incentive to investigate scalability improving technology (at great cost). The big block side lost the branding and had more immediate problems. Nevertheless, UTXO Commitments has remained in the minds of the BCH community, and as of mid-2025 is being actively researched and discussed. It is hoped that more effort will be focussed on this area to build proof-of-concepts or non-consensus versions leading to a protocol level upgrade once the best version is established.

Software improvements

The BCH community has been able to massively speed up UTXO set management (among other things) by improving the node software, for instance with the UTXO-Z initiative. As with UTXO commitments, this is an ongoing effort in both research & implementation which multiplies with the improvements offered by UTXO Commitments, better hardware, better node pruning etc.

This can be particularly confusing for BTC adopters, as the hijacked status of the Bitcoin Core development team or the surrounding propaganda has taught them (incorrectly) that they have world-leading experts producing world-leading software which is duly optimised as well as can be. None of that is true. Superior node development teams & implementations is just one of the many things BCH already has that BTC wants.

Hardware improvements & Pruned Nodes

As with every part of the big block scaling startegy, hardware improvements and pruned nodes do a lot to mitigate the impact of increasing blockchain traffic on initial block download.