Documentation

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.

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

Lift preferCandidate to AnchoredFragment

See discussion for compareAnchoredCandidates .