ouroboros-consensus- Consensus layer for the Ouroboros blockchain protocol
Safe Haskell None
Language Haskell2010



Utility functions on anchored fragments

Intended for qualified import > import qualified Ouroboros.Consensus.Util.AnchoredFragment as AF



compareAnchoredFragments :: forall blk. ( BlockSupportsProtocol blk, HasCallStack ) => BlockConfig blk -> AnchoredFragment ( Header blk) -> AnchoredFragment ( Header blk) -> Ordering Source #

Lift compareChains to AnchoredFragment

PRECONDITION: Either both fragments are non-empty or they intersect.

For a detailed discussion of this precondition, and a justification for the definition of this function, please refer to the Consensus Report.

Usage note: the primary user of this function is the chain database. It establishes the precondition in two different ways:

  • When comparing a candidate fragment to our current chain, the fragment is guaranteed (by the chain sync client) to intersect with our chain (indeed, within at most k blocks from our tp, although the exact distance does not matter for compareAnchoredCandidates ).
  • It will only compare candidate fragments that it has previously verified are preferable to our current chain. Since these fragments intersect with our current chain, they must by transitivity also intersect each other.

compareHeadBlockNo :: HasHeader b => AnchoredFragment b -> AnchoredFragment b -> Ordering Source #

Compare the headBlockNo , which is a measure of the length of the chain, of two anchored fragments.

A fragment with a head is always "greater" than one without. When both fragments have no head (i.e. are empty), they are EQ .

Note that an EBB can share its BlockNo with another regular block. If such an EBB is the head of one fragment and the regular block with the same BlockNo is the head of the other fragment, then this function will say they are EQ , while in fact one fragment should be preferred over the other.

This is not a big deal as we won't be seeing new EBBs, so they will not be the head of a fragment very often anyway, only when catching up. As soon as a new block/header is added to the fragment, the right decision will be made again ( GT or LT ).

forksAtMostKBlocks Source #


:: HasHeader b
=> Word64

How many blocks can it fork?

-> AnchoredFragment b

Our chain.

-> AnchoredFragment b

Their chain

-> Bool

Indicates whether their chain forks at most the specified number of blocks.

preferAnchoredCandidate Source #


:: forall blk. ( BlockSupportsProtocol blk, HasCallStack )
=> BlockConfig blk
-> AnchoredFragment ( Header blk)

Our chain

-> AnchoredFragment ( Header blk)


-> Bool

Lift preferCandidate to AnchoredFragment

See discussion for compareAnchoredCandidates .