All data in this report was captured and analyzed by Huobi Research; please cite the source “Huobi Focal Point” for reference.
Abstract
On October 2018, Bitcoin developer Mark Friedenbach proposed a bitcoin expansion plan—Forward Blocks—to increase on-chain settlement capcity by 3,584 times without initiating a hard-fork.
Through analysis, we at Huobi Research believe that the new proposal is not without its merits: by directly increasing on-chain capacity of the loosely-coupled forward block chain, and exploiting the time-warp bug (could be simply understood as modifying timestamp) to make the original chain (compatibility chain) produce more blocks, Forward Blocks could spoof the old nodes on the original chain and lower the inter-block interval on the original chain before achieving the transition of the old nodes of the compatibility chain into the new nodes of the forward block chain. However, in practice, the possibility of widespread application is not very high, largely due to the difficulty of reaching enough consensus to even support such a “soft-fork”.
1.Background
On October 6, 2018, at the Fifth Scaling Bitcoin Conference, Bitcoin developer Mark Friedenbach proposed a “Forward Blocks” on-chain scaling soft-fork scheme [1], which has aroused extensive discussion in the community. Mark Friedenbach is not only a Bitcoin developer, but also the co-founder and research engineer at Blockstream, a blockchain technology company well-known in the industry for its key role in Bitcoin’s Lightning Network solution. Moreover, Blockstream is also one of the important advocaters of the Segwit upgrade. As such, the Forward Blocks proposal has received widespread attention.
In the white paper, Mark Friedenbach claimed that the following features can be achieved through his Forward Blocks approach:
- Provides on-chain settlement scaling of up to 3584x current limits as a soft-fork;
- Provides for an (optional) proof-of-work upgrade as a soft fork;
- Limits growth of validation costs with a flexible weight limit;
- Decreases centralization risks through the adoption of sharding; and
- Provides a framework for ledger accounting in future protocol extensions including but not limited to:
- A rebatable fee market with consensus-determined transaction clearing fee rates;
- Confidential transactions for obscuring transaction amounts;
- Mimblewimble, ring signatures, or anonymous spends for obscuring the spend graph; and
- Sidechain value-transfer mechanisms.
2.Forward Blocks’ Soft-Fork Scheme
Before diving into the specifics of Forward Blocks’ soft-fork scheme, we must first understand the difference between a hard-fork and a soft-fork. In Bitcoin, both mining and transferring are done through the client. The Bitcoin client originally developed by Nakamoto was bitcoin-qt (now called bitcoin core). In a nutshell, forking means to upgrade the Bitcoin client. Defining soft- and hard-fork is rather complicated in real-life circumstances because it involves the recognition of the new/old nodes regarding the blocks issued by the new/old nodes, as well as the ratio of the computing power between the new and old nodes. For the convience of our readers, this paper has thus simplified the definition of hard-fork and soft-fork.
According to the bitcoin.org, a hard-fork means that, upon upgrade, the old node cannot accept the block sent by the new node. On the contrary, soft-fork means that the old node can still accept the block sent by the new node after the upgrade. The node that upgraded the client is the new node, and vice versa. For example, Bitcoin Cash (BCH) is a hard-fork from Bitcoin (BTC) because it modifies the transaction data structure of Bitcoin. As a result, a BCH node cannot accept the blocks issued by a BTC node, and a BTC node cannot accept the blocks issued by a BCH node, while both accept the block before the hard-fork. On the other hand, Segwit is a soft-fork. Although Segwit also modifies the transaction data structure (unlock script field), there is a way for the old node to still accept the block sent by the new node. Therefore, in the Bitcoin blockchain, regardless of whether your client (node) has upgraded the version of Segwit, it can accept the block sent by both nodes.
However, it’s important to note that, hard-fork does not always end up with two separate blockchains. If the whole network can reach an agreement and upgrade the client together, there will only be one blockchain after the hard-fork, and the nodes refusing to upgrade will be left out of the network. For example, Ethereum has repeatedly implemented upgrades with hard-forks, such as upgrading Homestead and Metropolis, and only one blockchain remained after the hard-forks. Similarly, BCH has also undergone several “upgrades” through hard-forks.
However, in a distributed network, it is very difficult to achieve consensus; the birth of bifurcations such as BCH and ETH is a result of split among community. However, because Ethereum and the BCH community have a strong leadership (plus Ethereum has a clear upgrade plan) so it is easier for the two community to reach a consensus to upgrade through hard-forks. Compared to the Ethereum community and the BCH community, Bitcoin community treated upgrades very cautiously: until now, most of Bitcoin’s upgrades were achieved through soft-forks. When Satoshi was still active in the Bitcoin community back in 2010, the Bitcoin community reached on a consensus to initiate a hard-fork—a rollback in that sense—to jump back to the point in the blockchain before a “value overflow incident” has occurred.
For these reasons, Forward Blocks’ scaling scheme emphasized on its soft-fork nature. At the same time, since the soft-forks requires backwards-compatibility—meaning that the old nodes should still be able to accept the block sent by the new nodes—new nodes often use “spoofing” methods to deceive the old nodes into aceepting their blocks. Forward Blocks also adopted this idea, which we will discuss in detail later.
In the design of Forward Blocks, after certain nodes upgrade the Forward Blocks client, a loosely-coupled chain consists of both compatibility chain (the original bitcoin chain) and forward block chain (supported by the upgraded nodes) will be created. The original proof-of-work model will also be slightly modified, but it is still based on double-SHA256.
The new nodes mining on the forward block chain will submit the blocks to both blockchains, so that the old nodes could still record the transactions. In order not to be accepted by the old nodes, the new nodes’ coinbase rewards will also be sent from the UTXO of the compatibility chain. Furthermore, a difficulty transition plan is designed to encourage the old nodes to voluntarily upgrade to the new Forward Blocks version.
Read Full Report Here: 【Huobi Focal Point 13】Increasing block Size by 3584 Times through Soft Fork Analysis of Bitcoin Forward Blocks
