Not unlike religion or politics at the dinner table, never mention block size to a bunch of bitcoiners.
Yet, there’s some sense to smaller blocks. With less data in each block, checking the transactions in it would become easier. Since the transactions would be verified by more parties, the block, as a whole, would be more trustworthy.
From a philosophical perspective, moreover, smaller blocks are aligned with Bitcoin’s decentralization ethos: the more active participants verify the transactions, the higher is the network’s resilience.
Who doesn’t want a more decentralized and resilient Bitcoin blockchain? Read on for the specifics of smaller-sized blocks on the Bitcoin blockchain!
The champion for small blocks Luke Dashjr gives bitcoiners between August 1st and December 31st 2019 to vote on small blocks. If the majority of the nodes agree, a soft fork in favor of smaller blocks will occur.
“This patch would enforce a very simple soft fork, reducing Bitcoin block sizes to ~300kB”, the Bitcoin Core developer explained on Twitter. At less than one third of the 1MB limit, these small — or lighter — blocks would facilitate block validation, while curbing the overall weight of the BTC blockchain.
Right time to go small?
Interestingly, it’s not the first time the concept was flaunted by the Bitcoin Core developer. Back in January 2017, Luke Dashjr had proposed a BIP (“Bitcoin Improvement Proposal”) requesting the block size to be decreased down to 300kB. At the time, though, his motion had been shrugged off. Two set of circumstances are helping smaller blocks to gain traction this time around.
The number of active nodes on the Bitcoin network has been decreasing.
Short reminder: two types of nodes allow users to connect to the blockchain.
-Fully validating nodes (aka full nodes), verify each transaction in new blocks. Unfortunately, these nodes are costly and difficult to run.
-SPV nodes (for “Simple Payment Verification” aka lightweight nodes) are easier to operate. But, the latter have two limits: they latch onto full ones to access the blockchain and they accept the blocks’ transactions without verifying them.
In the past year alone, none other than Luke Dashjr had warned the number of full nodes dropped from 100k to 60k. This kind of dip is concerning since the fewer full nodes there are, the higher is the risk of network corruption. In fact, if the number of full nodes keeps on dipping, lightweight nodes might one day have to resort to centralized services to connect to the Bitcoin blockchain.
As explained by Blockstream’s strategy chief Samson Mow in a Hard Fork article, the stake in block size is that of network decentralization: with prohibitively heavy full nodes, the network would eventually crystallize into poles around data centers.
Far from denying the losses entailed by smaller blocks, Bitcoin developers agree that the adoption of the second layer solution will offset them.
The timing of the proposal might even have played a role in convincing some. Internet entrepreneur dubbed “Bitcoin Oracle”, Vinny Lingham, who used to be rather neutral in the block size debate, has now sided with Dashjr.
Aside from those, like Roger Ver, who wholeheartedly reject small blocks, crypto experts agree that Luke Dashjr is technically correct. But, they don’t think switching to smaller blocks is as cut and dry.
The dip in the number of full nodes, for one, might be addressed without resorting to smaller blocks. The fraud proofs patch, for instance, means to bridge the gap between lightweight and full nodes. If a full node detects an anomaly in a block to be validated, it would emit a ‘fraud proof’ as a warning for the rest of the network to orphan the block.
It is worth noting that, while addressing the overall security risk, fraud proofs do not shore up lightweight nodes’ security to that of full nodes.
Blocked by consensus
Rather than technical, the issue with the BTC block size is human. Being a public chain, Bitcoin requires the consensus of the majority of its participants to upgrade.
Unfortunately, many Bitcoiners are reluctant to change. Just like the question marks clouding the Y2K in the late 90s, the unknown unknowns of a structural change deter from any upgrade at all. Nobody wants another BitcoinCash.
In a 300kb nutshell, limiting the size of the blocks will simplify the verification process. The more people can contribute to validating blocks, the more reliable, resilient and decentralized the network becomes.
Regardless of block size, network resilience hinges on the authenticity of every single transaction. On-chain congestion would be a short term trade-off for small blocks to ensure the sustainability of the network and store of value.
As the debate runs on, consensus will remain the bigger roadblock to any implementation. The tech is there, the theory makes sense, the application, though, remains elusive.
Swaying mindsets is much harder than patching a piece of code.