The road to on-chain scaling: the impact of Xthin on block transfer speed

Part 4: Xthin communication requires fewer bytes

Written by Andrew Clifford, Peter R. Rizun, @sickpig, Andrew Stone, and Peter Tschipper. Special thanks to Jihan Wu of AntPool for providing block resources, and to @cypherdoc and other generous donors for allowing us to pay for nodes in mainland China.

Note to readers: If you missed Part 3, you can read about the impact of China’s GFW on block transfer speeds here.

In this section, we compare the number of bytes required to transmit an extremely thin block (Xthin) with the number of bytes required to transmit a standard block.

Figure 1: Using Xthin transfer technology, the number of bytes required is only 1/24 of the original. The result is simple: on average, it only takes 42kB to transfer a 1MB thin block, so the bandwidth required for block transfer is only 1/24 of the original bandwidth (1000kB/42kB).

The rest of this section takes a closer look at the relevant data. First, thin blocks can significantly reduce the number of bytes required, and the presence of GFC does not significantly change the average compression amount.

Statistics and ANOVA

The following table shows the mean, median, and 95th percentile of the number of bytes transferred per bin. The uncompressed size of all blocks is between 900kB and 1MB, and the average size of the uncompressed block in each bin is 0.99MB.

Statistics on the number of kilobytes required to transfer a block

Using Xthin blocks saves bandwidth significantly (41.3kB and 42.6kB vs. 0.99MB), and GFC seems to have a small effect as well. Thin blocks transmitted over the regular P2P network use 3% fewer bytes than Xthin blocks transmitted over GFC. To see if this is statistically significant, we run another 2×2 full factorial ANOVA, this time analyzing the bandwidth data.

The p-value for the effect of Xthin is very significant (p=3 x 10^-8796), but the p-value for the effect of GFC is not high (p=0.4). Therefore, we can discard the null hypothesis about the effect of Xthin (Xthin does reduce bandwidth requirements); however, we cannot directly deny the effect of GFC (there is not enough data to determine whether GFC affects the average compression amount).

There is no significant statistical difference between bin2 and bin4 in terms of compression, so this section will combine all the Xthin data (i.e. bin2 and bin4) for analysis.

Bloom filter and Xthin histogram

Below is a flattened histogram of the number of bytes required to transmit a very thin block (Xthin), and histograms of its two local components: very thin blocks (Xthin) (including missing transactions) and bloom filters. Note that the horizontal axis of the figure below is presented on a logarithmic scale, this is to capture the full domain of the data.

Chart 2: Bloom filter size, Xthin block size (including missing transactions), and total size (Bloom filter + Xthin block). Including bin2 and bin4; N=6685.

Box and Whisker Plot

The box and whisker plot reveals occasional outliers that require much more than 42kB to transfer. In all cases, this is due to "fat" very thin blocks (Xthin), not to the bloom filter being too large.

Figure 3: Box and whisker plot of Bloom filter size, ultra-thin block size (including missing transactions), and total size (Bloom filter + ultra-thin blocks).

How big of an impact do Bloom filters have?

The purpose of the Bloom filter is to let the transmitting node know the contents of the receiving node's storage pool. This allows the transmitting node to use short hashes when sending transactions known to the receiving node, and to send transactions unknown to the receiving node in full. As shown in Part 2, this allows block transmission to take only 1.5 round trips in 98.5% of cases.

(https://medium.com/@peter_r/towards-massive-on-chain-scaling-block-propagation-results-with-xthin-a0f1e3c23919#.2cu90karu)

So one should study the frequency of occurrences where the mempool is homogeneous enough that the bloom filter has no effect (i.e. the receiving node already knows all transactions in the block except the coinbase TX (which is always sent as part of the thin block).

The following figure will answer this question. In more than half of the cases (53%), the receiving node already knows all the transactions in the block; the entire block is transmitted as a transaction hash, and the Bloom filter has no effect. In 17% of the cases, the receiving node is missing one transaction, in 9% of the cases, the receiving node is missing 2 transactions, and so on as shown in the probability density function below. In total, a Bloom filter is needed to prevent the second round trip in 47% of the cases (all cases except the green ones).

Chart 4: Frequency of thin blocks sent by transmitting nodes containing complete transaction information 0, 1, 2, ….10 (coinbase TX is always sent and is not counted).

Part 5: The Path to Massive On-Chain Scaling

This section will summarize our analysis of the experimental data. Our next and final section of this 5-section series will provide suggestions on how to better use this technique (note that it has already been deployed and successfully run on Bitcoin Unlimited 0.12 ) and take a peek inside the Bitcoin Unlimited Laboratory.

(http://www.bitcoinunlimited.info/download)