feat: update last_common_header only in find_blocks_to_fetch

[keroro520]

• peer.best_known_block refers to the best-known block we know this peer has announced; peer.last_common_header refers to the last block we both stored between local and peer. This PR proposes the logic to update the two fields:

  • When we receive CompactBlock or SentHeader from peer, we update the peer.best_known_block if the arrival one has greater total_difficulty.
  • When we insert a block which is from peer, we don't update the corresponding last_common_header(remove lines CompactBlock, SendBlock).
  • We update the last_common_header only in find_blocks_to_fetch. There are 2 places,
    1. fn update_last_common_header fixes last_common_header when the peer has reorganized;
    2. Updates last_common_header when we know a better block has already stored.

• Fix bug: status == BLOCK_STORED => status.contains(BLOCK_STORED)

• Enhence last_common_ancestor.

[doitian]

Is there any benchmark to show the differences among the three different strategies?

1. Update last common immediately for all peers whenever the node receives a new block.
2. Lazy update only in fetch
3. A hybrid solution. Do some quick updates in 1 and use 2 as a fallback.

[quake]

@keroro520 CI failed, may need to rebase, please check the log

[keroro520]

Is there any benchmark to show the differences among the three different strategies?

1. Update last common immediately for all peers whenever the node receives a new block.
2. Lazy update only in fetch
3. A hybrid solution. Do some quick updates in 1 and use 2 as a fallback.

No benchmark for this change, as I don't think it is necessary to bench it.

1. In my opinion, the strategy to update last_common_header cause a very small effect on the sync-performance. It's hard to make this kind of benchmark.

2. "Update last common immediately" is prone to error. For example, when chain.process_block returns Ok(false) because the given block is already stored at before, but the original code will still update the last_common_header.

3. "Lazy update only in fetch" is more simple and easy to ensure the correctness.

[driftluo]

Differences caused by delayed update common:

1. There may be a small increase in the consumption of get_ancester
2. Unify all update points, and can unify the common point of each peer relatively quickly. If there is a stuck or a large number of orphan block updates, this is the advantage

[doitian]

benchmark

[nervos-bot-user]

Benchmark Result

• TPS: 345.21
• Samples Count: 50
• CKB Version: e99b150
• Instance Type: c5.xlarge
• Instances Count: 3
• Bench Type: 2in2out
• CKB Logger Filter: info,ckb=debug

[doitian]

Why?

[keroro520]

• https://github.com/nervosnetwork/ckb/pull/2081/files/e99b150daee3b942b6d36753a8a59fb2a7620cae#diff-402ee94ba649e0f53da25c4da84ec58dL41

• https://github.com/nervosnetwork/ckb/pull/2081/files/e99b150daee3b942b6d36753a8a59fb2a7620cae#diff-402ee94ba649e0f53da25c4da84ec58dL56

The above two code has changed/removed, peer is unnecessary for BlockProcess.
However, removing peer from BlockProcess would affect many test codes. I just change to the field name to _peer to disable the compiler noise.

[doitian]

How this change is related to the PR?

[keroro520]

This change is about reverting #1997 .

#1997 records peer-index in OrphanBlockPool so that we can update the peer-state once accepting an orphan block.
#1997 is required originally, which we update the corresponding peer's peer.last_common_header every time accepting a new block.

This PR changes the way to update peer.last_common_header. We don't need to record peer-index inside OrphanBlockPool, hence I remove it.

[keroro520]

bors r=quake,doitian

[bors]

Build succeeded:

• continuous-integration/travis-ci/push