The Specification Behind the Whitepaper
Superseded by The Network Behind the Specification, which keeps this extraction and measures each clause against the shipped Alphanet. This page reads the paper alone and is kept as the record of that framing.
This editorial is an interpretation. The NOM above proposes that Network protocols be specified independently of any codebase, so that the specification — not whichever implementation shipped first — defines the protocol. What follows applies that principle to the founding document: an executive summary of the 2020 Network of Momentum whitepaper, read as a specification. It separates what any conformant implementation must deliver from the choices any particular implementation happens to make. The reading is ours; the note and the paper are the record.
ZENOAbout these notes — three bins meet a real spec
The Zeno spec (v1.6.0) specifies off-chain WASM execution on Zenon, and it was written the way the NOM above prescribes: specification first, normative, independent of any codebase. Zeno and Phase 1 are not synonyms: Zeno is the specification, laid out across a three-phase roadmap; Phase 1 — a single bonded executor, attestation only — is the one phase currently active, with every later capability specified but reserved. The spec carries its own three-way schema, and the mapping to this article’s bins is direct: OUTCOMES corresponds to the guarantees its trust model lists as executor-independent; ARCHITECTURE to its Normative clauses (RFC 2119 MUST / SHOULD / MAY); OPEN to its Informative commentary, Deferred items, reserved values, and pre-mainnet parameters. White notes like this one appear wherever Zeno makes a decision on something the whitepaper left open, diverges from it, or extends it.
About this document
Why read the whitepaper this way
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. The defense is to fix the specification first: state the outcomes the protocol guarantees and the mechanisms it requires, so that any codebase can be measured against the paper instead of the paper being retrofitted to a codebase.
This summary sorts the 2020 whitepaper into three bins:
- Guaranteed outcomes. Properties the paper states as theorems. Any network calling itself Network of Momentum must exhibit these, however it is built.
- Required mechanisms. The architecture the paper specifies to produce those outcomes: the dual ledger, virtual voting, PoW links, epochs, node roles.
- Left open. Parameters, examples, and deferred work the paper itself marks as configurable or unfinished. An implementation’s choices here bind nobody, including future implementations.
Bin one
Guaranteed outcomes
The paper states its guarantees as six theorems, proved in its appendix. These are the conformance surface: an implementation that fails any of them is not running the protocol, whatever else it does.
A transaction submitted to any honest node reaches all honest nodes, absent an active denial of service.
No double spend settles while an honest supermajority of consensus nodes holds.
Once one honest node concludes on a transaction, every honest node reaches the same conclusion.
The network agrees on a total ordering of transactions as long as byzantine participants stay under one third.
Transaction processing time grows sublinearly as the number of consensus nodes grows.
A confirmed transaction remains confirmed forever, regardless of later byzantine action.
ZENOWhat Phase 1 claims — and refuses to claim
The six theorems hold at the consensus layer the Zeno spec builds on; it consumes the momentum chain as given and does not restate them. For its own execution layer it is deliberately narrower: Phase 1 is “bonded attestation, not trustless execution,” and the spec requires that limit to be communicated “without qualification or obfuscation.” Its executor-independent guarantees are a shorter list — aggregate conservation per (domain, asset), domain isolation, canonical input order, batch contiguity and finality windows — while per-account correctness rests on a bonded executor until fraud proofs (Phase 2) and validity proofs (Phase 3) restore machine-checked correctness. It is the same bin discipline applied honestly: the trust model splits “guaranteed on-chain” from “established by the profile, not free.”
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.
ZENOA third structure joins the two
The Zeno spec leaves both ledgers untouched — defining L1 consensus mechanics is one of its explicit non-goals — and adds a third structure beside them: per-domain execution state in an off-chain Sparse Merkle Tree. L1 stores only roots and bounded commitment metadata; it must not store bulk execution state and must never execute contract code. Commitments anchor through the chain’s existing state-change hash, so there is no momentum-format change at all — the whole layer arrives as one spork-gated embedded contract. That takes the paper’s separation principle one step further: consensus data and transaction data never share a structure, and execution state never enters consensus at all. The spec compresses this into its own invariant: “Consensus orders. Executors compute. Settlement anchors.”
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.
ZENOA fourth role: the bonded executor
To the paper’s three roles the Zeno spec adds a fourth: the bonded executor, which computes state transitions off-chain and holds no sequencing authority — it must not reorder, skip, censor, or privately insert inputs. Pillars still order and never execute. The other roles keep recognizable jobs: sentinels serve execution-data bundles over libp2p, content-addressed and best-effort, and browser watchers reproduce results independently — the sentry posture, aimed at execution. The bond itself follows the sentinel registration pattern exactly: two legs, a QSR deposit and a ZNN amount, and the executor is active only while registered and fully bonded.
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.
ZENOPlasma took the PoW link's job
The sentinel relay chain never shipped as drawn. On the network as built, admission cost is plasma — proof of work or fused QSR per account-block — and the Zeno spec builds on that instead: its inputs are ordinary account-blocks, “data + plasma only,” and a full 16 KiB input costs more plasma than PoW alone can supply, so it requires fused QSR — “feeless-but-rate-limited exactly like all L1 traffic.” The spec also splits what the paper’s single weight mechanism combined: L1 plasma pays for admission and is governed entirely by L1 rules, while L2 execution gas is a separate ledger metered off-chain, and the two must not be conflated — L1 cannot meter WASM without running it, which the spec forbids.
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.
ZENOThe ordering rule that actually shipped
The paper’s ordering rules are introduced with “such as” — link weight, then timestamp, then hash. The chain as built orders differently: momentum height ascending, then within a momentum the ascending lexicographic order of address ‖ height ‖ hash, an order already committed inside the momentum hash. The Zeno spec pins exactly that as canonical — verifiable from L1 with no new derivation — and forbids every alternative, “by account-block hash alone, fee, plasma, input type, or originator.” This is the reading note’s scenario arriving on schedule: an illustrative clause got its ruling from the implementation, and the spec’s job was to write the ruling down and freeze it. The confirmation discipline carries over too: the executor may consume inputs only from confirmed momenta, so an L1 reorganization can never reorder its stream.
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.
ZENOSlashing arrives — at the execution layer first
The paper leaves penalties for byzantine consensus nodes under consideration. The Zeno spec decides the question for its own layer: the executor’s bond must be slashable on a successful fraud proof, and it is sized against the worst case the configuration allows — at least the hard ceiling of the per-batch withdrawal cap — so an administrator raising limits can never silently under-collateralize it. Honestly binned, though: no slashing logic exists in Phase 1. Until fraud proofs land, a misbehaving or unresponsive executor is replaced by administrator action, and the bond returns only after every batch it submitted has finalized.
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
ZENOHow the Zeno spec spends its own open bin
zApps are the open item the Zeno spec answers. The application layer arrives not as unikernels but as WASM execution domains — off consensus, deterministic, settled through an embedded contract — the yellow-paper slot filled with a different shape than the paper sketched. Its own open bin is kept with the discipline this article argues for: pre-mainnet parameters (withdrawal delay, bond amounts, caps) are listed rather than implied; Phase 2 work (fraud proofs, slashing, DA enforcement, multi-executor sets) and Phase 3 work (validity proofs) are enumerated as explicitly out of scope; and unresolved designs are marked OPEN DESIGN and gated — the minted-asset reconciliation item must be resolved before any asset bridge can register. Reserved values are not conventions waiting to harden: the core rejects them until a release activates them, so nothing becomes protocol by shipping first.
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.
ZENOThe ruling problem, solved by convention
The Zeno spec adopts exactly the discipline this summary finds missing in the whitepaper. Every clause is marked: RFC 2119 keywords separate binding requirements from prose, Informative text is labeled and carries no force, Deferred items are recorded so they are not foreclosed by accident. Where the NOM says consensus-critical requirements should be machine-checkable, the spec ships normative machine-readable artifacts — state-tree test vectors, a gas table, conformance suites — that bind exact bytes and costs. Version handling is “unknown == reject.” Nobody defends rulings clause by clause after the fact; the clauses arrive pre-ruled.
Read this way, the specification is compact: six theorems, the mechanisms that discharge them, and one operating condition on honest stake. Everything else is a knob. That compactness is the point of doing the extraction before any implementation gets to define the protocol by default.
Source · Network of Momentum, leaderless BFT dual ledger architecture, DRAFT v0.1, 31 March 2020, The Zenon Team. This page summarizes the paper’s own claims and proofs. It describes no implementation.