fix: unknown list should get header from headermap and db

[driftluo]

What problem does this PR solve?

Thanks to @eval-exec for pointing out these problems

ref: #3668

unknown list bug

unknown_list is the key to enabling multi-node parallel download in ibd phase. Its implementation is the get locator algorithm:

ckb/sync/src/types/mod.rs

Lines 2032 to 2035 in 1ce2b34

	if index != 0 {
	locator.push(self.shared.consensus().genesis_hash());
	}
	break;

Note this line in the algorithm, all results are added to the genesis hash again at the end

If insert_peer_unknown_header_list can find the corresponding value at the beginning of a new connection, this node can be used as one of the download sources:

ckb/sync/src/types/mod.rs

Lines 1875 to 1889 in 1ce2b34

	pub fn insert_peer_unknown_header_list(&self, pi: PeerIndex, header_list: Vec<Byte32>) {
	// update peer's unknown_header_list only once
	if self.peers.unknown_header_list_is_empty(pi) {
	// header list is an ordered list, sorted from highest to lowest,
	// so here you discard and exit early
	for hash in header_list {
	if let Some(header) = self.header_map.get(&hash) {
	self.peers.may_set_best_known_header(pi, header);
	break;
	} else {
	self.peers.insert_unknown_header_hash(pi, hash)
	}
	}
	}
	}

Otherwise, try_update_best_known_with_unknown_header_list will get stuck in a dead loop on the genesis hash and the node will not be able to become a download source again in the connected state:

ckb/sync/src/types/mod.rs

Lines 1891 to 1903 in 1ce2b34

	pub fn try_update_best_known_with_unknown_header_list(&self, pi: PeerIndex) {
	// header list is an ordered list, sorted from highest to lowest,
	// when header hash unknown, break loop is ok
	while let Some(hash) = self.peers().take_unknown_last(pi) {
	if let Some(header) = self.header_map.get(&hash) {
	self.peers.may_set_best_known_header(pi, header);
	} else {
	self.peers.insert_unknown_header_hash(pi, hash);
	break;
	}
	}
	}
	}

Finally, the try_update_best_known_with_unknown_header_list function is removed and get_header_view is used instead of just looking from the headermap.

Because if the block is inserted into the DB and the header map is cleaned up, the unknown list may get stuck in this situation where the hash cannot be found, resulting in reduce the download of the source.

eviction bug

In the ibd process, a node can only request headers data from one peer at a time. For headers, multiple data sources will result in duplicate downloads.

When synchronization starts, the headers_sync_controller of the node will be initialized to the normal state:

ckb/sync/src/synchronizer/mod.rs

Lines 370 to 380 in 1ce2b34

	if let Some(ref mut controller) = state.headers_sync_controller {
	let better_tip_ts = better_tip_header.timestamp();
	if let Some(is_timeout) = controller.is_timeout(better_tip_ts, now) {
	if is_timeout {
	eviction.push(*peer);
	continue;
	}
	} else {
	active_chain.send_getheaders_to_peer(nc, *peer, &better_tip_header);
	}
	}

eviction's remaining judgments will likely result in simultaneous requests for headers to multiple data sources, which is unnecessary in the ibd phase and should be disabled

Check List

Tests

• Unit test
• Integration test

Release note

Title Only: Include only the PR title in the release note.

[eval-exec]

LGTM.

[driftluo]

bors r+

[bors]

Build succeeded:

• ci_benchmarks_ubuntu
• ci_cargo_deny_ubuntu
• ci_integration_tests_ubuntu
• ci_linters_ubuntu
• ci_quick_checks_ubuntu
• ci_unit_tests_ubuntu
• ci_wasm_build_ubuntu