bsc: add new block fetching mechanism;#3040
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR implements a new block fetching mechanism for the BSC protocol to support fast retrieval of newly generated blocks and improve validator consensus efficiency. Key changes include adding two new messages (GetBlocksByRange and BlocksByRange) in the BSC protocol, updating the peer and dispatcher logic to support these messages, and integrating a quick block fetching feature into the block fetcher along with corresponding configuration and tests.
Reviewed Changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| eth/protocols/bsc/protocol.go | Added new protocol version, message constants, and packet types |
| eth/protocols/bsc/peer.go | Introduced dispatcher and a new RequestBlocksByRange method |
| eth/protocols/bsc/handler.go | Added handlers for GetBlocksByRange and BlocksByRange messages |
| eth/protocols/bsc/dispatcher.go | Implemented dispatcher logic for request/response messaging |
| eth/handler.go | Integrated quick block fetching callback into block fetcher initialization |
| eth/fetcher/block_fetcher.go | Introduced quick block fetching channel and scheduling logic |
| eth/ethconfig/* and eth/backend.go | Updated configuration and backend wiring to enable quick block fetching |
| eth/fetcher/block_fetcher_test.go | Added tests covering multiple peers and the quick block fetching feature |
galaio
force-pushed
the
new-block-fetching
branch
2 times, most recently
from
cd7d144 to
d25d1e1
Compare
zzzckck
left a comment
zzzckck
left a comment
There was a problem hiding this comment.
seems like this PR does not change the current eth block fetch logic, right?
with EnableQuickBlockFetching enabled, the eth blcok fetch would still work?
Yes, after enabling EnableQuickBlockFetching, BlocksByRange will usually fetch the block first. If it times out or fails, the previous fetchHeader and fetchBody will still work. |
There was a problem hiding this comment.
Pull Request Overview
This PR implements a new block fetching mechanism that accelerates the retrieval of freshly generated blocks to improve validator consensus efficiency. Key changes include:
- Adding a new configuration flag (EnableQuickBlockFetching) in node/config.go.
- Extending the BSC protocol (in protocol.go, peer.go, handler.go) with new messages (GetBlocksByRangeMsg and BlocksByRangeMsg) and corresponding dispatcher and handler logic.
- Integrating the quick block fetching mechanism into the block fetcher (and related tests) to support fast block imports.
Reviewed Changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| node/config.go | Added the EnableQuickBlockFetching flag to control the quick block fetching mechanism. |
| eth/protocols/bsc/protocol.go | Introduced Bsc2 protocol version and new messages for block range fetching. |
| eth/protocols/bsc/peer.go | Implemented RequestBlocksByRange method using the dispatcher. |
| eth/protocols/bsc/handler.go | Added handlers for GetBlocksByRange and BlocksByRange messages. |
| eth/handler.go | Integrated quick block fetching with an inline fetchRangeBlocks function and its usage. |
| eth/fetcher/block_fetcher.go | Extended the block fetcher with a quick fetching channel and logic to handle range calls. |
| eth/fetcher/block_fetcher_test.go | Added tests for the new quick block fetching feature. |
| eth/downloader/downloader.go | Minor logging updates for chain synchronization. |
| eth/backend.go | Passed the EnableQuickBlockFetching flag to the handler for proper integration. |
| if req.StartBlockHash != (common.Hash{}) { | ||
| block = backend.Chain().GetBlockByHash(req.StartBlockHash) | ||
| } else { | ||
| block = backend.Chain().GetBlockByNumber(req.StartBlockHeight) | ||
| } | ||
|
|
||
| if block == nil { | ||
| return fmt.Errorf("msg %v, cannot get start block: %v, %v", GetBlocksByRangeMsg, req.StartBlockHeight, req.StartBlockHash) | ||
| } | ||
| blocks = append(blocks, NewBlockData(block)) | ||
| for i := uint64(1); i < req.Count; i++ { | ||
| block = backend.Chain().GetBlockByHash(block.ParentHash()) | ||
| if block == nil { | ||
| break | ||
| } | ||
| blocks = append(blocks, NewBlockData(block)) | ||
| } |
There was a problem hiding this comment.
wait so StartBlockHeight it's from but it's means we going backwards as you putting there parents right ? so let say from is 1000 then I will get like 1000, 999, 998 .. not 1000, 1001 as I would be expecting
There was a problem hiding this comment.
Yeah, it is the reverse block order fetching.
There was a problem hiding this comment.
Was it stated like this in BEP ? Because I don't remember
There was a problem hiding this comment.
block_fetcher: add some UTs; block_fetcher: add some UTs; bsc: fix some failed UTs; bsc: fix some failed UTs; bsc: fix some failed UTs; bsc: fix some failed UTs; bsc: fix some failed UTs; bsc: fix some comments;
chore: fix some comments;
galaio
force-pushed
the
new-block-fetching
branch
from
d9988f8 to
d516dc3
Compare
4 participants
Description
This PR will implement bnb-chain/BEPs#564.
It supports fast fetching of newly generated blocks, avoids validators and full nodes from lagging behind in the subsecond block interval, and especially improves the validator consensus efficiency, which can produce the next block or send vote faster.
Example
If you want to use new block fetching mechanism, you need modify the config:
Changes
Notable changes: