Ideas for Improving HeaderSync Speed

[eval-exec]

Feature Request

Currently, a node starting from scratch sends a GetHeaders request (containing locator_hashes and hash_stop) to a full node, which responds with 2000 headers from the latest common ancestor determined by locator_hashes.

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

The current CKB header sync process is slow because it requests headers from only one peer at a time, and each peer responds with a maximum of 2000 headers per request. I propose two ideas to improve the efficiency of this process:

Idea 1: Request Headers from Multiple Peers

With the recent PR (#4742) that incorporates multiple hardcoded assume valid targets, we can leverage this to dispatch GetHeaders requests to multiple peers, thereby speeding up the header sync phase.

For example, if we hardcode 10 assume valid targets: [1,000,000 → 2,000,000 → 3,000,000 → ... → 9,000,000 → 10,000,000], we can distribute requests as follows:

• Send a request to peer_0 with 1,000,000 as locator_hashes
• Send a request to peer_1 with 2,000,000 as locator_hashes
• Send a request to peer_2 with 3,000,000 as locator_hashes
• ...

This approach allows the node to accumulate non-consecutive headers, which can then be incrementally verified. As the number of peers increases, the speed of the HeaderSync phase should improve correspondingly.

Idea 2: Request More than 2000 Headers at Once

The current limit of 2000 headers per request is not a heavy bandwidth burden for a CKB peer. By allowing a node to request more than 2000 headers in one go, we can enhance synchronization efficiency.

This can be achieved by trickly using the hash_stop: Byte32 field in the GetHeaders request. Currently, hash_stop is underutilized. A node wishing to receive multiple messages at once (e.g., 5 messages totaling 5 × 2000 headers) could encode 5:u8 into the hash_stop: Byte32 field, ensuring unused bits are set to 0.

When the full node processes a GetHeaders request with an encoded hash_stop, it would parse the u8 data to determine N and respond with N messages containing a total of N × 2000 headers.

This proposal maintains backward compatibility with older versions of nodes, as it does not require changes to existing protocols.