ouroboros-consensus-0.18.0.0: Consensus layer for the Ouroboros blockchain protocol
Safe HaskellSafe-Inferred
LanguageHaskell2010

Ouroboros.Consensus.Util.AnchoredFragment

Description

Utility functions on anchored fragments

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

Synopsis

Documentation

compareAnchoredFragments ∷ ∀ blk. (BlockSupportsProtocol blk, HasCallStack) ⇒ BlockConfig blk → AnchoredFragment (Header blk) → AnchoredFragment (Header blk) → Ordering Source #

Compare two (potentially empty!) AnchoredFragments.

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 when sorting fragments that are preferred over our selection. It establishes the precondition in the following way: 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.

compareHeadBlockNoHasHeader 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).

crossHasHeader block ⇒ AnchoredFragment block → AnchoredFragment block → Maybe (Point block, AnchoredFragment block) Source #

If the two fragments c1 and c2 intersect, return the intersection point and join the prefix of c1 before the intersection with the suffix of c2 after the intersection. The resulting fragment has the same anchor as c1 and the same head as c2.

forksAtMostKBlocks Source #

Arguments

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 #

Arguments

∷ ∀ blk. (BlockSupportsProtocol blk, HasCallStack) 
BlockConfig blk 
AnchoredFragment (Header blk)

Our chain

AnchoredFragment (Header blk)

Candidate

Bool 

Lift preferCandidate to AnchoredFragment

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

Usage note: the primary user of this function is the chain database. It establishes the precondition when comparing a candidate fragment to our current chain in the following way: The fragment is guaranteed (by the chain sync client) to intersect with our chain (indeed, within at most k blocks from our tip, although the exact distance does not matter for compareAnchoredFragments).

stripCommonPrefix ∷ ∀ f blk. (Functor f, Foldable f, HasHeader blk) ⇒ Anchor blk → f (AnchoredFragment blk) → (AnchoredFragment blk, f (AnchoredFragment blk)) Source #

Strip the common prefix of multiple fragments.

PRECONDITION: all fragments have the given anchor as their anchor.