The road to on-chain expansion: Xthin can now safely support 20MB blocks

Part 5: Massive on-chain scaling with support for blocks up to 20MB from day one

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.

In this section, we will summarize this 5-part series and discuss why we believe that Xthin can now support 60tps (transactions per second) and 20MB blocks on the chain. This will greatly alleviate the current severe network congestion (3tps limit) and provide breathing space for the maturity of off-chain expansion solutions. Finally, we take a peek at Bitcoin Unlimited's next plan.

60 transactions per second, 20MB blocks

“Ultra-thin blocks make efficient block relay a reality.”

What an exciting series of posts! In Section 1, we described how ultra-thin blocks solve a long-standing inefficiency in Bitcoin Core: transactions are always received twice by each node, once when the user first broadcasts the transaction, and again when the node later downloads the block containing that transaction. This inefficiency results in slow block transmissions and consumes a lot of bandwidth. By collating statistics from over 9,000 blocks transmitted from real Bitcoin networks, we show that ultra-thin blocks are faster (Section 2), less susceptible to GFW (Section 3), and smaller than standard blocks (Section 4). (We even took a detour last week to debunk an alleged attack vector.) Ultra-thin blocks can make efficient block relay a reality.

Chart 1: Based on data from over 9,000 blocks transmitted on the real Bitcoin network, ultra-thin blocks are faster, less affected by the GFW, and smaller than standard blocks.

These properties of ultra-thin blocks address the bottleneck problem of on-chain scalability. The pure data-driven research we know of on these issues comes from: Cornell’s scalability position paper and Jonathan Toomim’s “Block Size Olympics” research paper.

Cornell Position Paper

(http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf)

Cornell believes that the transmission of blocks and nodes is the main bottleneck. They believe that with the existing block size, some nodes will not be able to download blocks within the 10-minute target block time, and will fall further and further behind. Based on real measurements of block transmission on the Bitcoin network, they calculated that with an average block size of 4.1MB, 10% of the nodes in the entire network will not be able to keep up, and with an average block size of 37MB, half of the nodes in the entire network will fall behind. They recommend that the block size should not exceed 4MB.

“The problem of transferring blocks and nodes is the bottleneck. Ultra-thin blocks can solve it.”

Jonathan Toomim Block Size Olympics

(https://toom.im/blocktime)

Prior to the Cornell paper, Jonathan Toomim had led a study called "Block Size Olympics" in which he concluded that the current network can safely support 4MB blocks. Toomim measured block transfer time data for hundreds of test networks, with sizes up to 10MB, and a total of 20 different nodes, 3 of which were located in mainland China inside the GFC. As with the Cornell paper, Toomim's reasoning for the 4MB limit was the inefficiency of block and node transfers - especially with those nodes isolated by the GFC.

Ultra-thin blocks can solve bottlenecks

The problem of block and node transmission is the bottleneck, and ultra-thin blocks can solve it. If 4MB blocks are safe under standard block transmission, then if ultra-thin blocks are widely used, the security standard can far exceed 4MB.

Figure 2: Both the Cornell position paper and Toomim's "Block Size Olympics" study suggest that blocks should be no larger than 4MB (12 transactions per second). The bottleneck in both studies is the transmission of blocks to nodes. Ultra-thin blocks can solve this problem, and in our opinion, if used with Xval, a safe block limit of 20MB (60 transactions per second) can be achieved. This level of on-chain expansion can provide sufficient breathing space for the maturity of off-chain expansion solutions.

Ultra-thin blocks increase the speed of block transmission to nodes by 5.6 times (normal P2P), and 9.7 times through GFC. It can also reduce the bandwidth requirements for block transmission by 24 times. Simply proportionally, the new block limit is 22MB in the 5.6x case, 39MB in the 9.7x case, and 96MB in the 24x case. (The Cornell paper suggests that the transaction-confirmation and disk-I/O bottlenecks are much larger than 4MB, so we expect the bottleneck to be mainly bandwidth-related.)

“We have been able to safely configure our nodes to accept blocks up to 20MB in size.”

Bitcoin Unlimited rejects the idea that there needs to be a protocol-enforced block size limit. Instead, it provides tools to facilitate the embryonic form of an "effective limit" mechanism, where each node operator can adjust their own maximum block limit settings based on the information they have at hand. With the advancement of thin blocks and other Bitcoin Unlimited advances (including Xval), and the information we gain from these experiments, we can already safely set our nodes to accept blocks up to 20MB.

Everyone loves the skinny block

Six months ago, efficient block-node relay was just a concept. The debate at the time was whether it was a good idea or not.

Thanks to a lot of hard work from Peter Tschipper, @sickpig, and Andrew Stone, efficient block relaying has become a reality. Developers from all over, including Classic, Core, and XT, not only agree that this is a good idea, they also want to implement it (or something very similar) in their respective implementations.

The developer community is currently debating the details.

Figure 3: With minimal code changes, developers can add and remove features from thin blocks to meet the needs of their customers.

For example, some developers want to even out bytes by removing Bloom filters (at the expense of longer transmission times and more round trips for data), while some developers want to add salting to hashes as an additional security measure (at the expense of additional CPU cycles and code complexity).

"Let the free market debate the details."

One of Bitcoin Unlimited's central principles is that the network should evolve based on the code that people freely choose to run. With that in mind, we believe that all thin block features that users demand and developers are interested in should be implemented. Let the free market debate the details.

A peek inside the Bitcoin Unlimited lab

Below are 4 projects that are currently underway. Anyone is welcome to join Bitcoin Unlimited and contribute to these ideas (or bring your own)!

Optimistic Mining

Refers to mining by block header after PoW is verified but before the entire block is downloaded for verification. Miners who do this have a slight profit advantage over other miners. This technology can also destroy all "attacks" that rely on slowing down the block speed of miners' competitors. Thomas Zander coined the term Optimistic Mining based on the headers-first technique proposed by Gavin Andresen.

eXpedited Block Relay

Fast block relay

eXpedited Block Relay is about developing "delay-aware" miner nodes and relay nodes. Unlike Bitcoin inv/getdata methods such as ultra-thin blocks, a Bitcoin Unlimited node sends thin blocks to nodes served by eXpedited without asking them in advance whether they are willing to receive them. This can result in as few as 0.5 round trips for block transmission data, at the cost of greater bandwidth consumption.

“Long Tail” Block Propagation Times

“Long tail” block transfer time

During our empirical study of block transmission, we found that a small number of blocks take irregularly long times to transmit. The causes of this problem can be varied, including connectivity issues with the global network, GFC tracking, software bugs, etc. In many physical engineering disciplines, it is standard practice to bring the results of empirical research into the design and create an iterative design process. Although the Bitcoin client is just a computer program, Bitcoin as a whole is a complex system built on the Internet of physical fiber and copper cables connecting data centers and homes around the world. We believe that an empirical and redesign cycle can effectively optimize the Bitcoin system. We have begun our iterative redesign by investigating these "long tail" block transmission times.

Subchains

Subchains (www.bitcoinunlimited.info/resources/subchains.pdf)

The subchain is a weak block application that reduces the risk of orphan blocks and enhances zero-confirmation security. The subchain can work with the ultra-thin block to promote on-chain expansion to 100MB or even larger.

“Everyone is welcome to join Bitcoin Unlimited”

end

Finally, we would like to thank our readers and the entire Bitcoin community. It is your expectation that this great experiment will change the world that drives all of this forward.

Donate

To advance Bitcoin Unlimited's on-chain scaling projects, please consider donating to help us maintain our VPS network, including our nodes in Shanghai and Shenzhen. Donators who donate 1 BTC or more will be credited in future articles.

The Bitcoin Unlimited donation address is 3AtbpAikJ6C11ZCHiYbEKcSjyoVjzfxYwU, which is a 2/3 multi-signature address, and the signing keys are held by Andrew Clifford, Andrew Stone, and Peter Rizun. (Translator's note, please double-check with the original text.)