BulkSync BlockFetch implementation for Genesis #4919
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facundominguez
commented
Jul 29, 2024
ouroboros-network/src/Ouroboros/Network/BlockFetch/Decision/BulkSync.hs
Outdated
Show resolved
Hide resolved
facundominguez
force-pushed
the
genesis/bulksync
branch
from
f45bf35 to
5e4515e
Compare
amesgen
reviewed
Jul 29, 2024
ouroboros-network/src/Ouroboros/Network/BlockFetch/ClientState.hs
Outdated
Show resolved
Hide resolved
ouroboros-network/src/Ouroboros/Network/BlockFetch/Decision/BulkSync.hs
Outdated
Show resolved
Hide resolved
facundominguez
changed the title
facundominguez
commented
Jul 30, 2024
ouroboros-network/src/Ouroboros/Network/BlockFetch/Decision/BulkSync.hs
Outdated
Show resolved
Hide resolved
amesgen
reviewed
Aug 1, 2024
ouroboros-network/src/Ouroboros/Network/BlockFetch/Decision/BulkSync.hs
Outdated
Show resolved
Hide resolved
nbacquey
force-pushed
the
genesis/bulksync
branch
from
b171be1 to
0ef2f19
Compare
facundominguez
force-pushed
the
genesis/bulksync
branch
from
2a163ab to
440def5
Compare
nbacquey
force-pushed
the
genesis/bulksync
branch
from
440def5 to
abf35e0
Compare
amesgen
force-pushed
the
genesis/bulksync
branch
from
abf35e0 to
ebf401b
Compare
facundominguez
force-pushed
the
genesis/bulksync
branch
from
f16a4d6 to
0d08166
Compare
|
I force-pushed a rehashing of the changes that preserves the old BulkSync mode, which the network team suggested in the last review call. |
coot
reviewed
Sep 12, 2024
There was a problem hiding this comment.
Thank you @facundominguez for the PR. My main concern is using FetchMode while LedgerStateJudgement might be more suitable for the Genesis block-fetch client. I wonder what you guys think about it.
ouroboros-network-api/src/Ouroboros/Network/BlockFetch/ConsensusInterface.hs
Outdated
Show resolved
Hide resolved
|
|
||
| -- Trim the fragments to the peer's candidate, keeping only blocks that | ||
| -- they may actually serve. | ||
| trimmedFragments <- trimFragmentsToCandidate thePeerCandidate (snd fragments) |
There was a problem hiding this comment.
Haven't we picked a peer which can serve these blocks in selectThePeer?
There was a problem hiding this comment.
Not necessarily all of them, selectThePeer just makes sure that the peer can serve at least one (the first block not already downloaded) from the previously chosen candidate.
ouroboros-network-api/src/Ouroboros/Network/BlockFetch/ConsensusInterface.hs
Outdated
Show resolved
Hide resolved
ouroboros-network/sim-tests-lib/Test/Ouroboros/Network/Diffusion/Node.hs
Outdated
Show resolved
Hide resolved
ouroboros-network/sim-tests-lib/Test/Ouroboros/Network/BlockFetch.hs
Outdated
Show resolved
Hide resolved
ouroboros-network/sim-tests-lib/Test/Ouroboros/Network/BlockFetch.hs
Outdated
Show resolved
Hide resolved
amesgen
force-pushed
the
genesis/bulksync
branch
2 times, most recently
from
5441dc8 to
f217de0
Compare
amesgen
force-pushed
the
genesis/bulksync
branch
2 times, most recently
from
6ee715d to
aa18587
Compare
coot
requested changes
Dec 3, 2024
ouroboros-network/src/Ouroboros/Network/BlockFetch/Decision/Genesis.hs
Outdated
Show resolved
Hide resolved
ouroboros-network/src/Ouroboros/Network/BlockFetch/Decision/Genesis.hs
Outdated
Show resolved
Hide resolved
ouroboros-network/src/Ouroboros/Network/BlockFetch/Decision/Genesis.hs
Outdated
Show resolved
Hide resolved
ouroboros-network/src/Ouroboros/Network/BlockFetch/Decision/Genesis.hs
Outdated
Show resolved
Hide resolved
ouroboros-network/src/Ouroboros/Network/BlockFetch/Decision/Genesis.hs
Outdated
Show resolved
Hide resolved
ouroboros-network-api/src/Ouroboros/Network/BlockFetch/ConsensusInterface.hs
Outdated
Show resolved
Hide resolved
amesgen
force-pushed
the
genesis/bulksync
branch
from
aa18587 to
9922133
Compare
amesgen
force-pushed
the
genesis/bulksync
branch
from
9922133 to
7a1adf0
Compare
The new logic aims to guarantee progress of synchronization via genesis. See the comments in ouroboros-network/src/Ouroboros/Network/BlockFetch/Decision/Genesis.hs Co-authored-by: Nicolas BACQUEY <[email protected]> Co-authored-by: Nicolas “Niols” Jeannerod <[email protected]>
1. `FetchMode` -> `PraosFetchMode` 2. `GenesisFetchMode` -> `FetchMode`
amesgen
force-pushed
the
genesis/bulksync
branch
from
7a1adf0 to
278a932
Compare
github-merge-queue bot
pushed a commit
to IntersectMBO/ouroboros-consensus
that referenced
this pull request
Jan 8, 2025
Integrates a new implementation of the BulkSync mode, where blocks are downloaded from alternative peers as soon as the node has no more blocks to validate while there are longstanding requests in flight. This PR depends on the new implementation of the BulkSync mode (IntersectMBO/ouroboros-network#4919). `cabal.project` is made to point to a back-port of the BulkSync implementation on `ouroboros-network-0.16.1.1`. ### CSJ Changes CSJ is involved because the new BulkSync mode requires to change the dynamo if it is also serving blocks, and it is not sending them promptly enough. The dynamo choice has an influence in the blocks that are chosen to be downloaded by BlockFetch. For this sake, b93c379 gives the ability to order the ChainSync clients, so the dynamo role can be rotated among them whenever BlockFetch requests it. b1c0bf8 provides the implementation of the rotation operation. ### BlockFetch tests c4bfa37 allows to specify in tests in which order to start the peers, which has an effect on what peer is chosen as initial dynamo. c594c09 in turn adds a new BlockFetch test to show that syncing isn't slowed down by peers that don't send blocks. ### Integration of BlockFetch changes The collection of ChainSync client handles now needs to be passed between BlockFetch and ChainSync so dynamo rotations can be requested by BlockFetch. The parameter `bfcMaxConcurrencyBulkSync` has been removed since blocks are not coordinated to be downloaded concurrently. These changes are in 6926278. ### ChainSel changes Now BlockFetch requires the ability to detect if ChainSel has run out of blocks to validate. This motivates 73187ba, which implements a mechanism to measure if ChainSel is waiting for more blocks (starves), and determines for how long. The above change is not sufficient to measure starvation. The queue to send blocks for validation used to allow only for one block to sit in the queue. This would interfere with the ability to measure starvation since BlockFetch would block waiting for the queue to become empty, and the queue would quickly become empty after taking just 1 block. For download delays to be amortized, a larger queue capacity was needed. This is the reason why a fix similar to IntersectMBO/ouroboros-network#2721 is part of 0d3fc28. ### Miscellaneous fixes #### CSJ jump size adjustment When syncing from mainnet, we discovered that CSJ wouldn't sync the blocks from the Byron era. This was because the jump size was set to the length of the genesis window of the Shelley era, which is much larger than Byron's. When the jump size is larger than the genesis window, the dynamo will block on the forecast horizon before offering a jump that allows the chain selection to advance. In this case, CSJ and chain selection will deadlock. For this reason we set the default jump size to the size of Byron's genesis window in 028883a. This didn't show an impact on syncing time in our measures. Future work (as part of deploying Genesis) might involve allowing the jump size to vary between different eras. #### GDD rate limit GDD evaluation showed an overhead of 10% if run after every header arrives via ChainSync. Therefore, in b7fa122 we limited how often it could run, so multiple header arrivals could be handled by a single GDD evaluation. #### Candidate fragment comparison in the ChainSync client We stumbled upon a test case where the candidate fragments of the dynamo and an objector were no longer than the current selection (both peers were adversarial). This was problematic because BlockFetch would refuse to download blocks from these candidates, and ChainSync in turn would wait for the selection to advance in order to download more headers. The fix in e27a73c is to have the ChainSync client disconnect a peer which is about to block on the forecast horizon if its candidate isn't better than the selection. #### Candidate fragment truncations At the moment, it is possible for a candidate fragment to be truncated by CSJ when a jumper jumps to a point that is not younger than the tip of its current candidate fragment. We encountered tests where the jump point could be so old that it would fall behind the immutable tip, and GDD would ignore the peer when computing the Limit on Eagerness. This in turn would cause the selection to advance into potentially adversarial chains. The fix in dc5f6f7 is to have GDD never drop candidates. When the candidate does not intersect the current selection, the LoE is not advanced. This is a situation guaranteed to be unblocked by the ChainSync client since it will either disconnect the peer or bring the candidate to intersect with the current selection.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request implements a BlockFetch logic to use when synchronizing peers with Genesis.
BlockFetch needs to penalize peers that are slow enough to delay syncing in order to fend from attacks targeting the synchronizing nodes.
The penalization consists in switching the serving peer when blocks are in flight long enough that the syncing node is idle while waiting for more blocks to validate.
Switching peers, in turn, requires organizing peers in a queue, where blocks are retrieved from the first peer in the queue that can serve them, and any time a peer is penalized, it is moved to the end of the queue.
Most of the implementation is in the first commit where the implementation of BulkSync mode is replaced. Probably the best file to approach the implementation is
ouroboros-network/src/Ouroboros/Network/BlockFetch/Decision/BulkSync.hs. There are supporting commits to split large modules into smaller ones, and to update the tests related to the BulkSync mode.