Background
On May 21st 2019 the Bitcoin SV Scaling Test Network (STN) saw its maximum mined block size record broken eight times in rapid succession. In the latest release of Bitcoin SV Node (0.2.0) one of the standout changes was lifting the hard cap block size limit from 128MB to 10GB. The reason for setting the cap so far in excess of mainnet is the stated intention of STN, which is to push the limits of Bitcoin SV software to breaking point so we can identify those breaking points well in advance. The STN capacity is always intended to be several months ahead of mainnet.
Test plan
The SV node team had been hard at work on scaling improvements to the node, which is a requirement if we are to safely provide a 2GB cap in July on mainnet. As such the team called on the STN to show us how those improvements have affected capacity. The stress test set out with a modest goal of increasing the softcap to 200MB, then, if all went well, continue increasing by 200MB increments until we reached 1GB or until a natural limit in the software was encountered. A mixture of small payment transaction and big data transactions was used in varying proportions as the goal was not simply test and gather data on transaction throughput but to observe the effect on bitcoind and other services of large data transactions pushing block sizes to extremes. It is already known to us that transaction counts are more of a constraint than pure block size but due to the previous limits (128mb) it has been impossible to test raw block size capacity.
One of the first challenges when talking about scaling Bitcoin to 1GB is mining itself. The old GetBlockTemplace mechanism doesn’t scale well at all. This is where a new mining api comes into play. Put simply, it allows miners to mine without sending every transaction over the RPC connection between Node and miner. 0.2.0 was our first official release with this API and the result was a complete decoupling of mining pool load from block size.
Results
With that problem solved and multiple other improvements to the node software, 200MB was reached comfortably as expected. So the team began incrementing the cap in successive cycles. The end result was better than hoped for, after seeing how robustly 0.2.0 handled 1GB the decision was taken to push past the initial target. The test ended with a 1.424GB block containing 359,793 transactions. At this point some degradation of services like block explorers was observed. The Bitcoin SV nodes handled things ok and probably could have been pushed further but the Stresstest team and the nChain team both needed some sleep.
The following table shows some of the more notable blocks from the test period:
As can be seen, consecutive big blocks were common any not posing any real issue at all.
We did observe degradation of some services, in particular the block explorers had a little trouble in the beginning when blocks started breaking the 400MB barrier. However, with a little communication and some sharing of IP’s they all managed to get caught up and from what we saw, all were operational throughout the process after this.
Some real world effects of the Great firewall of China were also noted. A user participating in the STN had their node fall behind the chain, this was due to bandwidth restrictions with their service as a result, we have begun looking at ways to improve our connectivity in China for the STN (We already do this for mainnet).
We now have a mountain of data to comb through and analyse, looking for more ways to improve, more ways to be reliable, more ways to ensure that when mainnet reaches these levels it is boring. So boring you don’t notice. Boring means its reliable, boring means it can be built on. Boring is good.
The Bitcoin SV team would like thank Esthon Medeiros from the Satoshi Shotgun team who has worked tirelessly to ensure we can blast just about any size and combination of block or transaction volume as required into the p2p network, on demand.
