Files
rfc-index/nomos/raw/fork-choice.md
2026-01-01 20:00:09 -05:00

6.8 KiB
Raw Blame History

title, name, status, tags, editor, contributors
title name status tags editor contributors
NOMOS-FORK-CHOICE Nomos Fork Choice raw nomos
Jimmy Debe <jimmy@status.im>

Abstract

This document describes the consensus mechanism of fork choice rule, followed by nodes in the Cryptarchia protocol. Cryptarchia implements two fork choice rules, one during node bootstrapping and the second fork choice once a node is connected to the network.

Background/Motivation

In blockchain networks, the consensus process may encounter multiple competing branches(forks) of the blockchain state. A Nomos node maintains a local copy of the blockchain state and connects to a set of peers to download new blocks.

During bootstrapping, Cryptarchia v1 implements Ouroboros Genesis and Ouroboros Praos for the fork choice mechanism. These translate to two fork choice rules, bootstrap rule and online rule. This approach is meant to help nodes defend against malicious peers feeding false chains to download. This calls for a more expensive fork choice rule that can differentiate between malicious long-range attacks and the honest chain.

The Long Range Attack

The protocol has time window for a node, who is the lottery leader winner, to complete a new block. Nodes with more stake have a higher probability of being selected thorigh the lottery. The lottery difficulty is determined by protocol parameters and the node's stake. The leadership lottery difficulty will adjust dynamically based on the total stake is participating in consensus. The scenario, which NOMOS-FORK-CHOICE solves, is when an adversary forks the chain and generates a very sparse branch where he is the only winner for an epoch. This fork would be very sparse since the attacker does not control a large amount of stake initially.

Each epoch, the lottery difficulty is adjusted based on participation in the previous epoch to maintain a target block rate. When this happens on the adversarys chain, the lottery difficulty will plummet and he will be able to produce a chain that has similar growth rate to the main chain. The advantage is that his chain is more efficient. Unlike the honest chain, which needs to deal with unintentional forks caused by network delays, the adversarys branch has no wasted blocks.

With this advantage, the adversary can eventually make up for that sparse initial period and extend his fork until its longer than the honest chain. He can then convince bootstrapping nodes to join his fork where he has had a monopoly on block rewards.

Genesis Fork Choice Rule Mitigation

When the honest branch and the adversary branch are in the period immediately following the fork, the honest chain is dense and the adversarys fork will be quite sparse. If an honest node had seen the adversarys fork in that period, it would not have followed this fork since the honest chain would be longer, so selecting the fork using the longest chain rule is fine for a short range fork.

If an honest node sees the adversarys fork after hes completed the attack, the longest chain rule is no longer enough to protect them. Instead, the node can look at the density of both chains in that short period after they diverge and select the chain with the higher density of blocks.

Praos Fork Choice Rule Mitigation

Under two assumptions:

  1. A node has successfully bootstrapped and found the honest chain.
  2. Nodes see honest blocks reasonably quickly.

Nodes will remain on the honest chain if they reject forks that diverge further back than k blocks, without further inspection. In order for an adversary to succeed, they would need to build a $k$-deep chain faster then the time it takes the honest nodes to grow the honest chain by k blocks. The adversary must build this chain live, alongside the honest chain. They cannot build this chain after-the-fact, since online nodes will be rejecting any fork that diverges before their $k$-deep block.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in 2119.

Definitions

  • k : safety parameter, i.e. the depth at which a block is considered immutable
  • s_{gen} : sufficient time measured in slots to measure the density of block production with enough statistical significance.

In practice, s_{gen} = \frac{k}{4f}, where f is the active slot coefficient from the leader lottery, see Theorem 2 of Badertscher et al., 2018 “Ouroborus Genesis”)

Bootstrap Fork Choice Rule

During bootstrapping, the Ouroboros Genesis fork choice rule (maxvalid-bg)


def bootstrap_fork_choice(c_local, forks, k, s_gen):
    c_max = c_local
    for c_fork in forks:
        depth_max, depth_fork = common_prefix_depth(c_max, c_fork):
        if depth_max <= k:
            # the fork depth is less than our safety parameter `k`. It's safe
            # to use longest chain to decide the fork choice.
            if depth_max < depth_fork
                # strict inequality to ensure to choose first-seen chain as the tie break
                c_max = c_fork
        else:
            # here the fork depth is larger than our safety parameter `k`.
            # It's unsafe to use longest chain here, instead check the density
            # of blocks immediately after the divergence.
            if density(c_max, depth_max, s_gen) < density(c_fork, depth_fork, s_gen):
	                # The denser chain immediately after the divergence wins.
                c_max = c_fork

Online Fork Choice Rule

When bootstrap-rule is complete, a node SHOULD switch to the online-rule, see CRYPTARCHIA-V1-BOOTSTRAPPING-SYNCHRONIZATION for more infomation on bootstrapping. With the online-rule flag, the node SHOULD now reject any forks that diverge further back than k blocks.

def online_fork_choice(c_local, forks, k):
    c_max = c_local
    for c_fork in forks:
        depth_max, depth_fork = common_prefix_depth(c_max, c_fork):
        if depth_max <= k:
            # the fork depth is less than our safety parameter `k`. It's safe
            # to use longest chain to decide the fork choice.
            if depth_max < depth_fork
                # strict inequality to ensure to choose first-seen chain as our tie break
                c_max = c_fork
        else:
            # The fork depth is larger than our safety parameter `k`.
            # Ignore this fork.
            continue

Copyright and related rights waived via CC0.

Reference