Python's Counter and a Quorum Reducer —
Tallying Divergent Chain Views
and the Majority-Head Decision

A tally is a small thing. It is also the whole of agreement: count who holds what, and read where the weight fell.

Section I§I — Frame

The Ops lesson leaves off at an algorithm and a name: the quorum-of-heads. Poll a set of nodes, read each one's head at a reference height, and decide whether they agree. Written as English it sounds like judgment. Written as Python it is a tally and a threshold, and the whole thing fits in a screen of code with no async machinery and no clever tricks. The right tool is the one most people reach past on the way to something fancier.

Petrov states the quorum condition in Database Internals (Part II, p. 307): a decision holds when a majority of participants agree, weighted by their vote. That sentence is the specification. The rest of this lesson is one faithful implementation of it, built on collections.Counter, and then guarded against the two ways a naive tally lies about agreement.

Section II§II — Language Idiom

collections.Counter is a dict subclass built for exactly this shape of problem. You feed it hashable keys and it holds counts. Its most_common(n) method returns the keys ranked by count, highest first, which is precisely the majority read a quorum needs. Two facts about it decide how the reducer is written.

First, Counter counts occurrences, but consensus is weighted by voting power, not by node count. Three tiny nodes must not outvote one large validator. So the reducer does not feed nodes into a Counter one apiece. It accumulates weight per head, which Counter supports directly through addition and the update method with explicit amounts. A Counter is a mapping from key to a number, and the number can be stake, not a headcount.

Second, most_common breaks ties by insertion order, which is not a property to trust when correctness is at stake. A real fork can produce two heads with equal weight, and equal weight is the most dangerous case, not a rounding footnote. The reducer therefore never reads only the top entry. It reads the top two, compares their weights, and treats a near-tie as its own verdict rather than silently declaring the first-inserted head the winner.

Section III§III — Code Worked Example

Model each node's report as a small immutable record: which node, the weight it carries, and the block hash it holds at the reference height. A frozen dataclass makes the report hashable-adjacent and clear at the call site.

from collections import Counter
from dataclasses import dataclass
from enum import Enum


@dataclass(frozen=True)
class NodeReport:
    node_id: str
    weight: int
    head_hash: str


class Verdict(Enum):
    UNANIMOUS = "unanimous"
    MINORITY_LAG = "minority_lag"
    SPLIT_HEADS = "split_heads"
    NO_QUORUM = "no_quorum" 

The reducer accumulates weight per head into a Counter, then reads the top two entries. The threshold is expressed as a fraction of total polled weight. A head that holds at least the quorum fraction is the single agreed head; anything less means the weight is too scattered to call.

def reduce_quorum(reports, quorum=0.67, lag_tolerance=0.10):
    tally = Counter()
    for r in reports:
        tally.update({r.head_hash: r.weight})

    total = sum(tally.values())
    if total == 0:
        return Verdict.NO_QUORUM, None

    ranked = tally.most_common(2)
    top_hash, top_weight = ranked[0]
    second_weight = ranked[1][1] if len(ranked) > 1 else 0

    top_share = top_weight / total
    second_share = second_weight / total

    if top_share >= quorum and second_share <= lag_tolerance:
        return Verdict.UNANIMOUS, top_hash
    if top_share >= quorum and second_share > lag_tolerance:
        return Verdict.SPLIT_HEADS, top_hash
    if top_share < quorum and second_share <= lag_tolerance:
        return Verdict.MINORITY_LAG, top_hash
    return Verdict.SPLIT_HEADS, top_hash

Read the four branches as a truth table over two questions: does one head clear the quorum, and does the runner-up carry real weight. A dominant head with a trivial runner-up is unanimity, a healthy chain. A dominant head with a runner-up that carries meaningful weight is a split, because that runner-up is a second history with stake behind it. A head short of quorum but with a trivial runner-up is ordinary lag, one or two nodes trailing on the same history. Anything else is a split by default, because the safe failure mode of a fork detector is to over-report, never to under-report.

The lag_tolerance is the parameter that separates behind from elsewhere, the exact distinction the Ops lesson named. A node one block back at the reference height contributes almost nothing to the second head's share, so it lands under tolerance and reads as lag. A node on a genuinely different history contributes its full weight to a competing hash, so it clears tolerance and reads as a split. One number encodes the whole judgment, and it is tunable per network.

Guarding the tie

Give the reducer a real fork and watch it refuse to guess:

reports = [
    NodeReport("sentry-a", 30, "0xA"),
    NodeReport("sentry-b", 25, "0xA"),
    NodeReport("public-1", 20, "0xB"),
    NodeReport("public-2", 25, "0xB"),
]
print(reduce_quorum(reports))
# (<Verdict.SPLIT_HEADS: 'split_heads'>, '0xA')

Head 0xA holds 55 of 100 weight, 0xB holds 45. Neither clears a two-thirds quorum, and the runner-up is far above lag tolerance. The reducer returns SPLIT_HEADS and names 0xA as the majority head so the operator learns which head leads even in the split. A headcount reducer would have reported a two-two tie and told the operator nothing. The weighted tally reports a 55/45 fork and points at the leader.

Section IV§IV — Connection to Today's Ops Lesson

This function is the quorum-of-heads from today's δ-Chain lesson, made executable. The Ops lesson described three shapes coming out of the reducer: unanimous, minority lag, split heads. Those are three of this Verdict enum's four members, and the fourth, NO_QUORUM, is the honest answer when polling itself failed and there is nothing to reduce. The halt-decision signal the Ops lesson fires is a downstream consumer of this return value: on SPLIT_HEADS, page a human; on MINORITY_LAG, open a ticket; on UNANIMOUS, emit the green heartbeat and sleep. The operational policy lives in the Ops lesson. The verdict that policy branches on is computed here.

Section V§V — Prior-Lesson Reach

The 2026-05-30 validator-telemetry lesson built the async RPC polling that produces these NodeReport records. That lesson owns the collection; this one owns the reduction, and keeping them apart is deliberate. Collection is I/O-bound and asynchronous; reduction is pure and synchronous and trivial to test. The 2026-06-30 enum-and-state-machine lesson established the pattern of returning a typed verdict rather than a bare boolean, and this reducer follows it: a Verdict enum carries more meaning than a True/False and forces the caller to branch on every real case. A pure function returning a typed verdict is the easiest thing in a monitoring stack to unit-test, and a fork detector is the last place you want an untested edge.

Section VI§VI — Closing

Reach for Counter before reaching for anything larger. Weight the tally by stake, never by headcount. Read the top two entries, not the top one, and let the margin between them carry the fork verdict. Keep the reducer pure so the tests are trivial and the collection layer stays where it belongs. The whole of consensus reconciliation, at the operator's vantage, is one honest count and one threshold read against it.

Write the reducer, then write the test that hands it a fifty-fifty split. If it names a winner without flagging the split, it has lied to you in the one case that matters. Fix it there, on your desk, before the network does it for you.