Transaction volume on the BSV blockchain approximately doubled for a few days last week – due to “multi source stamina testing” on the BSV blockchain mainnet by the Metastreme team for 5 days beginning September 28. This large increase in transaction volume is an opportunity to analyse the network and evaluate its performance under the increased load.
Timeline
The number of transactions being propagated across the network started to increase at approximately 04:001 on the 29th of September. The rate of transactions increased to around 20 transactions per second (tps) and has remained fairly constant since then, for at least 56 hours.
This is clearly visible in the chart below which shows the rate of increase of the number of transactions in the “mempool” of one of the nChain nodes.
This analysis focuses on the period from 2020-09-29 04:00 to 2020-10-01 12:00 with reference to earlier periods for comparison purposes.
Blockchain Performance
The first area to examine is the blockchain itself.
Figure 2 shows the number of transactions per second averaged per day. The increase in transaction volume is clearly visible for the 29th and 30th of September.
The two graphs in Figure 3 show similar increases in the total number of transactions per day and the average block size per day.
Figure 4 shows blocks plotted against their size and the number of transactions, for all blocks in the time frame of interest. The chart shows many small blocks, with a significant number of blocks in the 10 to 30 MB range and one or two much larger blocks. It also shows a direct correlation between the size of the block and the number of transactions. There are two blocks significantly below the norm, these blocks may contain larger data transactions. The largest block was 58.4 MB with 199k transactions.
Software Performance
At nChain we manage a number of systems of various configurations and we monitor the performance of these systems. We reviewed the performance of these systems and the results are similar for all of them. The charts below are representative and have been taken from one of the smallest systems, a virtual machine with 4GB RAM and 2 virtual CPU. The charts cover about seven days, from the morning of the 25th to the morning of the 2nd of October, and are related to the performance of the node software.
Figure 5 shows the number of open connections to peers, which we see remained constant over the period of interest.
Figure 6 shows a chart of the mempool, which is the pool of transactions that the software has received. You can see a repeating pattern where the software receives transactions and these are then removed when a block is mined.
Figure 7 shows a more detailed view of the mempool, covering the period from 1st of October to the morning of the 2nd. The green line shows the size of the mempool in bytes, while the orange line shows the number of transactions. The lines are highly correlated as expected. In the early morning of the 1st of October the mempool grows to over 52 Megabytes and 194,000 transactions, and then a single block confirms all of the transactions and they are removed from the mempool. That was the block at height 654926.
System Performance
nChain manages a number of BSV systems of different configurations and monitors the performance of these systems.
Figure 8 shows the overall CPU usage for the system. We can clearly see the increase in CPU use due to the increased number of transactions but CPU use is still very low.
The BSV blockchain is intended to scale and the Node implementation has been heavily optimized to enhance scalability. A critical strategy has been to parallelize its functions, so that the processing load is evenly spread across processors.
Figure 9 shows the processor usage for each processor. It shows an even distribution of load across the processors of the machine. Although this system only had two processors, other machines with more cores showed a similarly even distribution of load across processors.
Figure 10 shows the same chart for a system with six processors which further demonstrates the load distribution across processors. Note that there were approximately 100 peer connections for this system, which accounts for the increased total processor usage compared to the smaller system.
Figure 11 shows an expected increase in memory use due to the larger number of transactions but the increase is modest and well within the capabilities of the system.
Despite the doubling in transaction volume, this small system is still easily capable of keeping up with the blockchain.
Conclusion
The doubling of transaction volume had no adverse impact on the BSV blockchain. The blockchain, network, and systems scaled to cope with demand, easily absorbing the additional transactions. The capability to support large blocks enables spikes in transaction volume to be quickly absorbed, delivering consistent confirmation times.
The work in parallelizing the processing across multiple processors has been successful, with the load being equally spread across processors. As transaction volume increases, more powerful servers can be deployed as required.