Add far future blocks to the ChainSync client test #526
Labels
enhancement
New feature or request
Comments
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 5, 2024
…waitReply` (#1186) This PR enables the ChainSync client to disconnect from peers who send *historical `MsgRollBackward` and `MsgAwaitReply` messages*, ie rollbacks that no honest caught-up peer would send as the corresponding blocks are already immutable for them, and `MsgAwaitReply`s that would indicate a chain whose tip is way behind the wall-clock. This is relevant for the ChainSync Jumping (CSJ) optimization (part of Ouroboros Genesis): CSJ handles `MsgAwaitReply` and rollbacks to before a point that a peer previously acknowledged by "disengaging" that peer, ie running full ChainSync with them. This is the right thing to do when we are almost caught-up; however, during syncing the historical chain, this causes extra network load (albeit symmetrical) and CPU load. We define a `MsgRollBackward`/`MsgAwaitReply` to be *historical* if the Genesis State Machine has not yet concluded that we are caught up and the wall-clock time of the slot of the oldest rewound header (if any) or the previous tip of the candidate fragment, respectively, is older than a configuration value, the *historicity cutoff*. In this PR, we set it to the duration of one mainnet stability window plus one hour as extra margin (so `36 h + 1 h = 37 h`). Future work might include getting this duration out of the HFC. We also modify the existing ChainSync client test to test for false positives; false negatives can be tested by manually modifying the code (such as subtracting a constant from `historicityCutoff`, or introducing bugs in the actual implementation); we defer a standalone test for false negatives (similar to #526). The PR is intended to be reviewed commit by commit.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context: #525 (comment)
We're currently merging a PR that adds near-future blocks. A reasonable next increment would add far-future blocks. But that's a little more delicate since such a block truncates each execution of the test.
The text was updated successfully, but these errors were encountered: