We order between chains as follows:

1. By chain length, with longer chains always preferred.
2. If the tip of each chain was issued by the same agent and they have the same slot number, prefer the chain whose tip has the highest ocert issue number.
3. By a VRF value from the chain tip, with lower values preferred. See pTieBreakVRFValue for which one is used.

IMPORTANT: This is not a complete picture of the Praos chain order, do also consult the documentation of ChainOrder.

IMPORTANT: This is not a SimpleChainOrder; rather, there are PraosChainSelectViews a, b such that a < b, but not $ preferCandidate cfg a b, namely for cfg = RestrictedVRFTiebreaker.

Rules

Concretely, we have preferCandidate cfg ours cand based on the following lexicographical criteria:

1. Chain length, with longer chains always preferred.

2. If the tip of each chain was issued by the same agent and had the same slot number, then we prefer the candidate if it has a higher ocert issue number.

   Note that this condition is equivalent to the VRFs being identical, as the VRF is a deterministic function of the issuer VRF key, the slot and the epoch nonce, and VRFs are collision-resistant.

3. Depending on the VRFTiebreakerFlavor:

   • If UnrestrictedVRFTiebreaker: Compare via a VRF value from the chain tip, with lower values preferred. See pTieBreakVRFValue for which one is used.
   • If RestrictedVRFTiebreaker maxDist: Only do the VRF comparison (as in the previous step) if the slot numbers differ by at most maxDist.

Non-transitivity of RestrictedVRFTiebreaker

When using cfg = RestrictedVRFTiebreaker maxDist, the chain order is not transitive. As an example, suppose maxDist = 5 and consider three PraosChainSelectViews with the same chain length and pairwise different issuers and, as well as

Then we have preferCandidate cfg a b and preferCandidate b c, but not preferCandidate a c (despite a < c).

Rationale for the rules

1. The abstract Consensus layer requires that we first compare based on chain length (see Chain extension precedence in ChainOrder).

2. Consider the scenario where the hot key of a block issuer was compromised, and the attacker is now minting blocks using that identity. The actual block issuer can use their cold key to issue a new hot key with a higher opcert issue number and set up a new pool. Due to this tiebreaker rule, the blocks minted by that pool will take precedence (allowing the actual block issuer to decide on eg the block contents and the predecessor) over blocks with the same block and slot number minted by the attacker, and they will end up on the honest chain quickly, which means that the adversary can't extend any chain containing such a block as it would violate the monotonicity requirement on opcert issue numbers.

   See "3.7 Block Validity and Operational Key Certificates" in "Design Specification for Delegation and Incentives in Cardano" by Kant et al for more context.

3. The main motivation to do VRF comparisons is to avoid the "Frankfurt problem":

   With only the first two rules for the chain order, almost all blocks with equal block number are equally preferrable. Consider two block issuers minting blocks in very nearby slots. As we never change our selection from one chain to an equally preferrable one, the first block to arrive at another pool is the one to be adopted, and will be extended the next time the pool is elected if no blocks with a higher block number arrive in the meantime. We observed that this effectively incentivizes block producers to concentrate geographically (historically, in Frankfurt) in order to minimize their diffusion times. This works against the goal of geographic decentralisation.

   Also, with the VRF tiebreaker, a block with a somewhat lower propagation speed has a random chance to be selected instead of the one that arrived first by pools before the next block is forged.

   See VRFTiebreakerFlavor for more context on the exact conditions under which the VRF comparison takes place.