The Network Behind the Specification

This editorial is an interpretation, and it is the second half of one. Our earlier reading sorted the 2020 Network of Momentum whitepaper into three bins and stopped there, closing with the line “it describes no implementation.” That was the honest limit of a paper-only reading. It is also the easier half. A specification that is never measured against a running network is a document, not a standard.

So this version keeps the extraction and adds the measurement. Every mechanism the paper requires now carries a second badge recording what the shipped Alphanet does about it, and every one of those verdicts names a path in go-zenon that a reader can check. The reading is ours; the paper and the code are the record.

About this document

Why measure at all

A protocol implemented before it is independently specified can make its first implementation authoritative by accident. Undocumented behavior hardens into de facto rules, and the line between what the protocol requires, what a given implementation chose as policy, and what is mere implementation detail goes blurry.

Extraction is the first defense: fix the specification, so a codebase can be measured against the paper rather than the paper retrofitted to a codebase. But extraction alone leaves the second failure mode untouched. If nobody performs the comparison, a specification and an implementation can drift apart indefinitely while both remain in good standing — the paper describing a network that does not exist, the network running rules nobody wrote down. The measurement is what keeps the two honest about each other.

What follows finds that drift is wide. Read one way that is an indictment. Read another, and most of it is substitution rather than shortfall: the network kept the paper’s jobs and changed the machinery doing them, usually for something simpler. Both readings are available below. The distinction that matters is which clauses were substituted, which were left standing empty, and which were quietly answered by an implementation that got there first.

Bin one

Guaranteed outcomes

The paper states its guarantees as six theorems, proved in its appendix. It calls these the conformance surface: an implementation that fails any of them is not running the protocol, whatever else it does.

All but one of them are quantified over a supermajority of honest consensus nodes, ζ = 2N/3 + 1. That quantity does not exist in the shipped network. The second badge on each card below therefore records something narrower than pass or fail — whether the guarantee, as stated, is delivered by the mechanism the paper names for it.

System-wide posture

• Under the CAP constraint, the protocol chooses partition tolerance and eventual consistency over availability: a query may need retries before it returns the current state, but the state it returns converges for everyone.
• The hard operating condition: honest consensus nodes must number at least twice the malicious nodes plus one. The paper names this the vital condition for the network to function.

Bin two

Required mechanisms

The dual ledger

The paper requires two ledgers with distinct roles. Consensus data and transaction data never share a structure.

• Block-lattice stores settled transactions. Every account is its own chain, updated independently; send and receive are separate transactions that pair across chains.
• Meta-DAG carries the consensus record: the finishing-PoW transactions, epoch markers, and message history from which ordering is derived.
• Only full nodes hold both ledgers; light participants hold the transaction ledger or a pruned view of it.

Node roles

• Sentries observe. They hold the transaction ledger or a pruned version and monitor traffic for specific accounts.
• Sentinels relay and protect. They build PoW links on user transactions and answer queries, without voting.
• Pillars order. They run the consensus algorithm and hold both ledgers. Roles are acquired by locking stake.

PoW links: spam and sybil defense at the edge

Before a transaction reaches consensus, sentinels must chain proof of work onto it:

• A user disseminates a transaction to a logarithmic number of sentinels, which defends against eclipse attacks.
• Each sentinel adds a small PoW computation plus its signature, then relays to another random sentinel. One signature per key pair per transaction.
• A minimum of three hops is required; relaying continues until accumulated weight clears a difficulty-set threshold, then the transaction goes to a pseudorandomly chosen pillar.
• The accumulated link weight also serves consensus: it is the first criterion for choosing between two conflicting transactions in a double spend.

Consensus: epochs and virtual voting

Consensus is leaderless. No vote messages exist on the wire; each pillar derives the same ordering from the message history it has received.

• Time divides into epochs. During each epoch, every pillar computes a proof of work at adjustable difficulty while collecting transactions from sentinels.
• A pillar that finishes broadcasts a finishing-PoW transaction carrying everything it knows. A pillar advances to the next epoch after hearing finishing PoWs from a stake-weighted supermajority: ζ = 2N/3 + 1.
• A pillar that hears ζ before finishing its own PoW must abandon it, broadcast its transactions, and advance. This keeps epochs synchronized and rewards only competitive work.
• Once a pillar holds a supermajority view of an epoch’s transactions, it orders them by deterministic rules: PoW link weight, then arrival timestamp, then transaction hash. Identical inputs produce identical orderings at every honest node, which is the whole vote.
• Confirmation takes no fewer than three epochs from submission to settled order.
• If epochs stall without conclusion, honest pillars vote randomly in a shared coin round, which drives the probability of consensus to one against an attacker controlling the network.

The seed the schedule turns on

Half of each tick’s producer slots are drawn at random, which makes the source of that randomness a protocol-critical parameter. The paper does not specify one, because it has no producer schedule to seed. The 2018 lightpaper does: it calls for VRF-based, bias-resistant committee selection.

Stake and incentives the protocol depends on

• Voting weight is stake, not node count, which is the sybil defense: spawning nodes buys no consensus power.
• Stake can be delegated to pillars; staking, delegating, and unlocking are processed at epoch boundaries, and consensus nodes face an unstaking waiting period.
• Pillars are rewarded for competitive epoch PoW; sentinels consume transaction fees to fund PoW links and may charge for ledger queries.
• Fees double as denial-of-service defense: flooding sentinels costs the attacker resources that flow into the network.

Bin three

Left to implementation

The paper marks each of these as an example, a parameter, or deferred work. They are where implementation policy lives, and no implementation’s choice here becomes protocol by shipping first.

• Epoch duration. One minute appears only as an example. The requirement is that adjustable difficulty keeps epochs within stable time bounds; the target itself is a parameter. OPEN
• The difficulty algorithm. A self-balancing scheme switching between ASIC-friendly and ASIC-resistant hashing is described as under investigation, with detailed specification deferred. OPEN
• Penalties for byzantine pillars. Slashing-style punishment is stated as under consideration, not specified. OPEN
• PoW pooling. Pillars may outsource epoch PoW to pools. This is a market arrangement the protocol permits, not a protocol component. OPEN
• Broadcast strategy. Full pillar-to-pillar broadcast is the baseline; round-based gossip with lower message complexity is flagged as future research. OPEN
• zApps. The unikernel application layer is explicitly out of scope, deferred to a yellow paper. Nothing any implementation does with contracts or applications today is specified behavior. OPEN
• Query fees. Sentinels can charge for state queries; pricing and structure are unspecified. OPEN

Not in any paper

Who may change the rules

The whitepaper has no governance section. It describes a protocol whose parameters are set by difficulty algorithms and whose participants are disciplined by stake, and it never contemplates an operator. The shipped network has one, and this is the part of the gap least visible from the paper, because the paper gives no clause to compare against.

Summary

The measurement

Reading note

Where the spec needs a ruling

The whitepaper mixes normative and illustrative language without marking which is which. The three-hop minimum appears once as a named constant. The one-minute epoch is introduced with “for example.” The ordering rules are given as “such as.” A conformance-grade specification has to rule on each of these.

This summary makes the calls as follows: the hop minimum and the ordering rule set are requirements, because the theorems lean on them; epoch length is a parameter, because the paper says so directly. Anyone extracting a formal spec from the paper should expect to defend rulings like these clause by clause.

That note was written before the measurement, and the measurement changes what it is for. The rulings above are no longer preventative. The implementation has already answered most of these questions by shipping, and some of its answers — the ordering rule, the election seed, the authority to change the rules — are now the de facto protocol, unwritten.

Read together, the paper and the network describe two different systems that share a vocabulary. The block-lattice, stake-weighted power, and the double-spend tiebreak came through intact. Virtual voting, the meta-DAG, PoW links, sentries and unikernels did not arrive, and the guarantees that rested on them are not the guarantees the network now offers. Plasma carries the paper’s admission mechanism forward under a new name; the second coin is the network’s own idea. Sentinels hold a slot for work that was reassigned.

None of that is settled by this page. Where an implementation and a paper disagree, the question of which one is wrong is a decision somebody has to make, and writing the specification is how it gets made rather than defaulted. That is the whole of the NOM’s argument, and six years of drift is the argument’s best evidence.

Sources · Network of Momentum, leaderless BFT dual ledger architecture, DRAFT v0.1, 31 March 2020, The Zenon Team — for every clause in the three bins. go-zenon at v0.0.8-alphanet, commit 667a69d, read 15-Aug-26 — for every conformance verdict. This page supersedes The Specification Behind the Whitepaper, which reads the paper alone.