[WIP] Annotate headers with time #1288
Conversation
Introduce a new `HeaderWithTime` data type which associates the relative slot time the header was received by the chain sync client mini-protocol.
...oros-consensus-diffusion/src/ouroboros-consensus-diffusion/Ouroboros/Consensus/NodeKernel.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus-diffusion/test/consensus-test/Test/Consensus/PeerSimulator/Run.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/Genesis/Governor.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/Genesis/Governor.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/Genesis/Governor.hs
Outdated
Show resolved
Hide resolved
...ensus/src/ouroboros-consensus/Ouroboros/Consensus/MiniProtocol/BlockFetch/ClientInterface.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HeaderValidation.hs
Outdated
Show resolved
Hide resolved
...boros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/MiniProtocol/ChainSync/Client.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/test/consensus-test/Test/Consensus/MiniProtocol/BlockFetch/Client.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus/test/consensus-test/Test/Consensus/MiniProtocol/ChainSync/Client.hs
Outdated
Show resolved
Hide resolved
From ``` BlockFetchConsensusInterface (ConnectionId addrNTN) (Header blk) blk m ``` to ``` BlockFetchConsensusInterface (ConnectionId addrNTN) (HeaderWithTime blk) blk m ``` The next commits will start implementing the `undefined` in the code.
This is semantically identical (as the LoE fragment is anchored in a recent immutable tip), but it is nice to use a more familiar function, and it is also potentially useful for a planned change.
... from `AnchoredFragment (Header blk)` to `AnchoredFragment (HeaderWithTime blk)`.
... which contains an `AddBogusTime` type class, which allows to add bogus times to headers. This type class and its instances are meant to be used in test code.
dnadales
force-pushed
the
dnadales/annotate-headers-with-time
branch
from
b76d77c
to
2b11f09
Compare
... from `AnchoredFragment (Header TestBlock))` to `AnchoredFragment (HeaderWithTime TestBlock))`.
... from `AnchoredFragment (Header TestBlock))` to `AnchoredFragment (HeaderWithTime TestBlock))`.
... in the density disconnect tests.
... to `AnchoredFragment (HeaderWithTime blk)`.
| Projecting a header | ||
| -------------------------------------------------------------------------------} | ||
|
|
||
| -- REVIEW: we could consider placing this somewhere else. |
There was a problem hiding this comment.
What about Ouroboros.Consensus.Block.Abstract? This module defines GetHeader which contains getHeader :: blk -> Header blk which is quite similar to projectHeader.
One could even move getHeader to ProjectHeader and remove projectHeader like this:
class (HasHeader blk, HasHeader a) => ProjectHeader a blk | a -> blk where
getHeader :: a -> Header blk
class (HasHeader (Header blk), ProjectHeader blk blk) => GetHeader blk where
...(This will probably require small changes in various places, so could also be done separately.)
There was a problem hiding this comment.
Yeah, that'd make sense. If the change is a sensible generalization of Consensus, it could be merged before this PR.
There was a problem hiding this comment.
The preferred way to move this forward would be to rename GetHeader to something like BlockSupportsHeader, and rename ProjectHeader to GetHeader. The method getHeader will have to be removed from what is now the GetHeader class. (thus ending in the new GetHeader class).
| -> Ordering | ||
| compareCandidateChains = compareAnchoredFragments bcfg | ||
|
|
||
| headerForgeUTCTime = slotForgeTime . headerRealPoint . unFromConsensus | ||
| headerForgeUTCTime = slotForgeTime . headerRealPoint . hwtHeader . unFromConsensus |
There was a problem hiding this comment.
Add a comment here that this is the place to adapt once IntersectMBO/ouroboros-network#5009 is integrated into Consensus?
There was a problem hiding this comment.
The blockForgeUTCTime definition you mean?
There was a problem hiding this comment.
Both blockForgeUTCTime and headerForgeUTCTime. The former will just be gone, and the latter can stop relying on slotForgeTime (which can be removed) and instead be replaced with projecting out the time from HeaderWithTime. (Technically, that can already happen now, but it would be a bit weird as blockForgeUTCTime still has to use slotForgeTime.)
There was a problem hiding this comment.
TODO: change the implementation of headerForgeUTCTime to use the HeaderWithTime annotation, and add the comment Alex mentioned above blockForgeUTCTime.
| AnchoredFragment (Header blk) | ||
| -> HeaderStateHistory blk | ||
| -> AnchoredFragment (HeaderWithTime blk) | ||
| withTime fragment history = undefined fragment history |
There was a problem hiding this comment.
Reifying this undefined as a review comment
| -> AnchoredFragment (t blk) | ||
| -> AnchoredFragment (t blk) |
There was a problem hiding this comment.
The payloads could also be different, right?
There was a problem hiding this comment.
Good one. I think so, let me try.
| -- REVIEW: I even wonder if this instance should be defined here and | ||
| -- at all: there might be use cases in which the 'TestBlock's are used | ||
| -- in tests that depend on the header having a meaningful time | ||
| -- associated with them. |
There was a problem hiding this comment.
Hmm, one idea: All tests where you are currently adding bogus times are using non-HFC blocks. For these, time translation is very easy as there just is a constant slot length, so this wouldn't even be a "bogus" time!
attachSlotTime ::
NoHardForks blk
=> TopLevelConfig blk
-> Header blk
-> HeaderWithTime blk
attachSlotTime cfg hdr = HeaderWithTime {
hwtHeader = hdr
, hwtSlotRelativeTime =
runIdentity $ epochInfoSlotToRelativeTime ei (blockSlot hdr)
}
where
ei = noHardForksEpochInfo cfgThe important thing here is that we can get a single EraParams from the TopLevelConfig. NoHardForks provides that via getEraParams, but it has SingleEraBlock as a superclass constraint, which our TestBlocks don't implement (they could, but it requires implementing lots of "boring" stuff so nobody has done that yet). To sidestep that, we could move getEraParams to a separate class that doesn't demand SingleEraBlock instead.
There was a problem hiding this comment.
An alternative is to extract the logic of noHardForksEpochInfo and use it in attachSlotTime directly. For this, we need to rely on a function that extracts the era-params from a top-level config (which is always true for our tests).
... and place it in a new class called `HasEraParams`.
... in favour of `attachSlotTimeToFragment` and `attahcSlotTime`, respectively. These functions rely on the `HasEraParams` type class which allows us to extract the `EpochInfo` needed for time conversions. For those tests for which we do not have a top level configuration available, we rely on `singleNodeTestConfig`.
This class generalizes this function in the sense that it can extract headers of any values that support this operation, not only blocks. Required by #1301
Introduce a new
HeaderWithTimedata type, which associates the relative slot time the chain sync client mini-protocol received the header.