Compact block: Good news for Bitcoin full node users

Compact block relay, or BIP152 (Bitcoin Improvement Proposal), is a solution that reduces the amount of bandwidth required for p2p network nodes to broadcast blocks.

summary

When full nodes already share many of the same mempool contents, it is possible to reduce the amount of bandwidth required to broadcast new blocks to full nodes using simple techniques. The sending node sends a compact block "summary content" to the receiving node. These summaries contain the following information:

1. 80-byte header of the new block;

2. Shortened transaction identifiers (txids) to prevent denial of service attacks;

3. Some complete transactions predicted by the sending node but not available to the receiving peer;

The receiving node will try to reconstruct the entire block using the received information and the transactions in its memory pool. If it is still missing some transactions, it will request the broadcasting node.

The advantage of this approach is that transaction data only needs to be sent under optimal circumstances (when they are in the initial broadcast), which significantly reduces the total bandwidth.

Additionally, the dense block relay proposal provides a second mode of operation (called high-bandwidth mode) in which the receiving node directly requests some of its peers to send new blocks without first obtaining permission, which may increase bandwidth (because two peers may send the same block at the same time), but it further reduces the time it takes for blocks to propagate.

The following figure shows the two operation modes of the current node sending blocks and dense block relay.

In the traditional relay method, a block (grey bar) is verified by node A, and then node A will send an inv message to node B to request permission to send this block. Node B replies to the block request ( getdata ), and then node A sends the block.

In the high-bandwidth relay, node B uses sendcmpt(1) (send compact block) to tell node A that it wants to receive blocks as soon as possible. When a new block arrives, node A performs some basic validation (such as validating the block header), and then automatically sends the block header, shortened transaction identifiers (txids), and predicted missing transactions (described above) to node B. Node B attempts to reconstruct the block and requests any transactions that are still missing ( getblocktxn ) that were sent by node A ( blocktxn ). In this context, both nodes complete full block validation before adding the block to their respective copies of the blockchain, maintaining the same full node security as before.

In low-bandwidth relaying, node B uses sendcmpt（0） to tell node A that it wants to minimize bandwidth usage. When a new block arrives, node A fully validates it (so it doesn't relay any invalid blocks). It then asks node B if it wants the block (inv), so that if node B has already received the block from another peer, it can avoid downloading it again. If node B doesn't want the block, it requests compact mode ( getdata(CMPCT) ), where node A sends the block header, shortened transaction identifiers (txids), and predicted missing transactions. Node B attempts to reconstruct the block, requesting the transactions that are still missing, and node A sends them. Node B then fully validates the block.

How to consider the factors of fast relay network?

The Fast Relay Network (FRN) consists of two parts:

1. The set of nodes currently in the fast relay network.

2. Fast Block Relay Protocol (FBRP).

The nodes currently in the Fast Relay Network (FRN) are carefully selected. The failure of these nodes will result in a waste of mining power and lead to further centralization of mining. Currently, most of the mining power is connected to this network.

Recently, some miners have been testing the deployment of a UDP and forward error correction (FEC) protocol called RN-NextGeneration . Protocol layer improvements using dense blocks will narrow the performance gap between node networks and general P2P networks. The increased robustness of P2P networks and the speed of block broadcasting will play a role in the future development of the network.

Can this thing scale Bitcoin?

The purpose of compact blocks is to reduce bandwidth peaks for nodes and improve user network experience. However, a large part of the pressure currently concentrated in Bitcoin mining lies in the delay of block broadcasting, as described in the video below. The main purpose of compact block version 1 is not to solve the problem of scaling Bitcoin.

https://www.youtube.com/watch?v=Y6kibPzbrIc

Who benefits from compact blocks?

Full node users who want to relay transactions but have limited network bandwidth . If you just want to save as much bandwidth as possible while still being able to relay blocks to peers, blocksonly mode is now enabled in Bitcoin Core v0.12. In blocksonly mode, the node only accepts transactions that are included in the block, so it will not accept additional transactions.

Reducing the block broadcast time of the p2p network can create a healthier network.

What is the timeline for coding, testing, reviewing, and deploying compact blocks?

The first version of compact blocks has been proposed in BIP152 and has a working implementation that is actively being tested by the developer community.

BIP152: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki

Reference implementation: https://github.com/TheBlueMatt/bitcoin/tree/udp

Can it adapt to faster p2p relays?

The dense block scheme can have other improvements, which involves RN-NG and two aspects:

1. First, use UDP transmission to replace TCP block information transmission.

2. Second, use forward error correction (FEC) codes to drop packets and predict lost transaction data.

Is this a new idea?

The idea of ​​using bloom filters to improve block broadcasting has been proposed for several years, and Pieter Wuille (sipa) tried this approach in 2013.