Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not even propagate future headers #525

Merged
merged 4 commits into from Nov 30, 2023
Merged

Conversation

nfrisby
Copy link
Contributor

@nfrisby nfrisby commented Nov 28, 2023

@njd42 and I came up with this idea a couple weeks ago, during a chat about the vagaries of NTP/clocks/etc.

See the commit message of the 'consensus: do not even propagate future headers' commit.

The main concrete benefits:

  • It's a step towards Chronos and that helps simplify/ground our story around future blocks.
  • A network-load optimization of sorts: if someone with a horribly out of sync clock sends a block 60 seconds early, the direct neighbors won't even propagate it.

@nfrisby nfrisby added the enhancement New feature or request label Nov 28, 2023
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE TypeApplications #-}

module Ouroboros.Consensus.MiniProtocol.ChainSync.Client.InFutureCheck (
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@njd42 Please confirm this logic matches what you and I chatted about a few weeks ago. Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@njd42 It's being merged now, but I'd still appreciate your thoughts on this module. Thanks.

@nfrisby
Copy link
Contributor Author

nfrisby commented Nov 28, 2023

FYI, the PR is draft because I've so far only propagated the ChainSync client interface change to its test. I'll tackle the rest tomorrow.

Edit: No longer Draft.

Copy link
Member

@amesgen amesgen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, mostly minor comments and a few suggestions. Will review again after the chores (formatting, compilation failures, changelog entries, etc.).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to other reviewers: The diff here is much smaller when using sth like difftastic.

@nfrisby
Copy link
Contributor Author

nfrisby commented Nov 29, 2023

Just FYI, I just now rebased onto origin/main---there were no conflicts.

@nfrisby
Copy link
Contributor Author

nfrisby commented Nov 29, 2023

CI is green 👍

@nfrisby nfrisby marked this pull request as ready for review November 29, 2023 20:56
@nfrisby nfrisby requested a review from a team as a code owner November 29, 2023 20:56
Copy link
Member

@amesgen amesgen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (after squashing), only very minor comments left

@nfrisby
Copy link
Contributor Author

nfrisby commented Nov 30, 2023

FYI: I based a second time to sign the commits.

Main change: remove the LogicalClock, since it's quite a bit of indirection
with no real gain. Also, remove -XRecordWildCards.
This an aggressively-simple interpretation of the easy part of Ouroboros
Chronos in the presence of The Header-Body Split. (The hard part is the
_synchronization beacons_---which need to be propagated promptly, and will be
implemented much later.)

Other less-aggressive interpretations would propagate future headers/blocks but
set them aside. But this seems much simpler and within an RTT or two, assuming
eg the NTP clients are well-configured.
@nfrisby nfrisby added this pull request to the merge queue Nov 30, 2023
Merged via the queue into main with commit 3a1fde0 Nov 30, 2023
12 of 14 checks passed
@nfrisby nfrisby deleted the nfrisby/ChainSync-future branch November 30, 2023 23:32
now <- systemTimeCurrent systemTime
let ageNow = now `diffRelTime` onset
syntheticDelay = negate ageNow
threadDelay $ nominalDelay syntheticDelay -- TODO leap seconds?
Copy link
Contributor

@njd42 njd42 Dec 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we can resolve the leap second argument now. Worst case is a 0.9s jump (see https://en.wikipedia.org/wiki/DUT1). So the two extrema are:

  • local clock adjustment is +ve by 0.9s : the delay here would be (up to) 0.9s 'too much' - this is not an operational issue, delays of that magnitude occur during usual operation
  • local clock adjustment is -ve by 0.9s: this could be perceived by other nodes as a (minor) future arrival and therefore delayed there by a small amounr.

The handling of leap seconds is (and will likely forever be) a bit of mess (see https://en.wikipedia.org/wiki/Leap_second#Issues_created_by_insertion_(or_removal)_of_leap_seconds).

As we only ever take the slotToWallClock time direction we would be safe as this is always (to UTC) unambiguously defined. The mapping in the other direction is (around leap seconds) ambiguous depending on the operating system's handling of leap seconds.

Copy link
Contributor

@njd42 njd42 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It all looks good to me - I've added some comments as to why I believe that you have already effectively dealt with the leap second issue (as best as can be done)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Block forge should check for pending future blocks in ChainDB
3 participants