Every adopter asked whether its block still extended the tip, released
that reading, and only then asked the store for the lock. The tip moves
in between and the commit lands anyway, writing the height index and the
tip pointer for a block on an abandoned branch -- which every peer
bootstrapping from that index is then served as canonical. The lock is
not reentrant, so the check cannot come from the caller and be held
across the commit: it comes from the store or it is not held at all.
Parent joins Height on the Block interface because a place in the
sequence takes both, and height alone is the reading that lets an old
accepted block pass. Two concurrent accepts fall to the same move, not
just the Verify-to-Accept window: the tip a block is judged against is
now read inside the critical section that commits it, so the second is
refused rather than serialised behind a reading taken before the first
landed. The store also exempts nothing, where identityvm exempted height
zero -- and its Verify skips every parent check at height zero, so a peer
could hand a live chain a second genesis carrying records of its choosing
and send the tip and the height back to the start.
mpcvm keeps its root comparison, which answers a different question --
whether applying this block reaches the root the network agreed on -- and
stays true of a node whose state moved for any reason. That a moved tip
also showed up there is a consequence of that chain refusing empty
blocks, not what the comparison is for.
Seed records the tip in that same commit, because seeding is what makes
a chain no longer fresh. Recording none left Open, for which a missing
tip is a fresh chain, reporting a seeded node fresh on every boot and
asking for the allocation again: a duplicate its own state refuses, and
a node that cannot restart until it produces a block it cannot produce.
PLONK's verification equation was never written: verifyPLONKPairing
refused every proof unconditionally, and above it sat some 200 lines
decoding the proof and the key — exact sizes, subgroup checks, points at
infinity — whose result that refusal discarded. The refusal is the whole
of what the path does, so it is now the whole of what it says.
The aggregate block proof went the same way. VerifyBlockProof re-verified
the very transactions Verify had verified one line above, so it could
only ever agree with them; nothing built a block carrying one; and the
field stood on the wire and in the block id where a reader would take an
aggregate guarantee to be.
Two more second implementations: Verify type-asserted its parent to
*Block after GetBlock had already refused anything that is not one, and
Shutdown asked whether its logger was disabled before logging, which is
what a logger decides.
Coverage 95.5% -> 99.1%. What is left cannot be reached: four bn254.Pair
error returns on one-element slices, two IsInSubGroup refusals on a curve
whose G1 cofactor is 1 and whose Unmarshal already checks G2, and three
boot gates — a store opened through a versiondb view, and fee.Validate on
the floor chain.Floor returns.
Coverage 76.7% -> 95.5%, and three more things the tests found on the way.
A chain that seeds its genesis allocation and has not yet accepted a
block reports itself fresh on every boot, because the store records a tip
when it accepts a block and seeding is not accepting one. Answering that
with a second allocation ends in "UTXO already exists" — a node that
cannot restart until it produces a block. Whether the allocation has been
applied is now asked of the state: Finalize is the last thing it does, so
a committed root that is no longer the empty one is the allocation saying
so.
Three Marshal methods returned an error they never produced, so every
caller wrote an unreachable branch for it — Block.Bytes answered nil in
its one, which is a block with no encoding.
spendTx built every fixture with the same all-zero commitment, so two
different spends created the same output and the set refused the second.
An output commitment now follows what the transaction spends.
The proof tests construct a key and a proof that SATISFY the pairing
equation, so the arithmetic reaches a verified verdict rather than only
refusals — and then show that the same proof bytes on a transaction
spending different notes do not reach it.
The proof cache was keyed on tx.ID as read off the wire, plus the proof
type, the proof and its public inputs — all four the sender's to choose.
Copy an accepted transaction's four onto a transaction spending entirely
different notes and the key matched; the hit returned nil from the cache,
ahead of verifyPublicInputs, which is the only thing tying those inputs to
what the transaction spends. Shielded value, backed by a proof that
attests to nothing about it.
The id is no longer on the wire. parseTransaction derives it, the cache is
keyed on ComputeID(), and a block's id folds in ComputeID() rather than
whatever id arrived — which also ends the block and vertex id malleability
that one flipped byte bought.
Every block and vertex id, and the first public input of every proof, now
open with sha256(ChainID ‖ NetworkID). It is not on the wire, so a block
from another chain has no parent here and its proofs do not verify, rather
than passing a check someone can forget to write.
Also on the consensus surface:
Verify required height == parent+1 and nothing more, so a block whose
parent was a long-accepted ancestor verified, and accepting it rewound
the tip and left the height index naming an orphan to every peer that
bootstraps from it. Verify now requires the parent to be the tip or a
block above it, and Accept re-checks against the tip, which moves
between the two.
Vertex.Verify checked its transactions and nothing else — no parent, no
height — so a vertex naming no parent at height 1<<40 verified, and
accepting it set the store's height to 1<<40 and left the chain unable
to propose again. Its decoder also ignored trailing bytes, so one
logical vertex had unboundedly many encodings under one id, each of
which the store writes to disk.
BuildBlock skipped the ValidateBasic that Verify runs, so a transaction
with an out-of-range Type — read straight off the wire — was assembled
into every block and refused by every node including the proposer, and
nothing evicted it. admit is now that one predicate, assembly drops what
it cannot build, and a transaction names an expiry so a bounded pool
drains.
BuildBlock stamped an unclamped time.Now(), which is below a parent
legally up to maxClockSkew ahead — a block its own Verify refuses.
ParseBlock never tracked what it parsed and SetPreference discarded it,
so a follower could verify the first block of a run and not the second.
A genesis naming no timestamp was stamped with the wall clock, hashed
into the genesis id: one genesis file, a different chain per node and
per restart.
VerifyBlockProof took a GPU path on accel.Available() — a second, inline
copy of the Groth16 checks that consulted neither the cache nor the
dummy-key refusal — so whether a block was accepted turned on whether
the node had an accelerator.
Reads that failed were reported as absence: the spent set answered "not
spent" for a set it could not read, which is the whole double-spend gate;
the state root answered "empty" at boot AND on rollback, where it also
returned nil; the UTXO store answered "not found". Each now reports the
failure.
Deleted, none of it reachable: a node-side wallet holding plaintext
spending keys behind an HTTP endpoint, with a loadAddresses that returned
nil so the keys were unusable anyway; note construction and the package's
only panic; an FHE processor whose verifier tested len(proof) >= 128 and
whose "encryption" wrote the plaintext into the first eight bytes; a
zwitness carrying a TODO; a 256-level sparse Merkle tree that computed no
root and wrote its cache under a read lock; six endpoints answering "Not
implemented"; a Signature field nothing verified; and eight config knobs
nothing read. The endpoints that remain answer at the path the node mounts
them on, rather than behind a mux that dispatches on a path it never sees.
Coverage 58.9% -> 76.7% on a denominator 539 statements smaller.
Accept marked the block accepted and moved lastAccepted before writing
anything, then issued a Put per nullifier and per output, each returning early.
A failure partway left some notes spent and some outputs created under a tip
the chain had already advanced.
Worse, the spent-nullifier cache advanced as it went, and MarkNullifierSpent
refuses a nullifier it already holds — so the block that failed could never be
applied again. The chain was stuck at that height holding notes it believed
spent with no block recording the spend.
Everything a block writes — nullifiers, outputs, the state root — now stages
through the store's view and commits in one batch with the block and the tip.
On failure the view is rolled back and the three caches are rebuilt from what
committed, so the block can simply be applied again. The DAG vertex had the
same defect and goes through the same store.
That is why the store's Block is not the engine's block interface: a vertex has
several parents and no timestamp, so it cannot satisfy it, and it changes state
exactly the same way. The store is generic in what a chain tracks, so Propose,
Open and Block hand back the chain's own type and no caller asserts.
Also here: genesis is seeded through Seed, which commits on its own, because a
staged allocation would ride on whichever block landed first and vanish from a
chain that never accepted one. StateTree.Finalize records the root before
holding it, rather than after.
Restoring the original Accept fails the atomicity test; removing the cache
rebuild fails it on the line that says the cache must agree with the database.
verifyTransaction checks each nullifier against nullifierDB, which only holds
nullifiers spent in ACCEPTED state; a block's own nullifiers are marked spent in
Accept, after Verify. So two transactions in one block sharing a nullifier both
passed — neither was spent yet — and one shielded note funded two spends, each
creating outputs. Supply inflation, which is the exact event the nullifier set
exists to prevent. A single transaction listing the same nullifier twice got
through the same way: the mempool consults its conflict map before inserting the
transaction's own nullifiers, so [n, n] passes admission too.
Proven: Vertex.Verify on a vertex whose two txs share a nullifier returned nil.
BuildVertex already refuses to batch conflicting txs (usedNullifiers), so the
invariant was intended — it just was not enforced on anything that arrived over
the wire, and BuildBlock never had it at all.
Block.Verify and Vertex.Verify now require every nullifier in the block to be
distinct, checked before proof verification because it is the cheaper gate.
Also bounds the vertex decoder's counts by the bytes actually present.
parentCount and txCount are attacker-controlled uint32 read straight into
make(); the length checks came after the allocation. A 16-byte vertex claiming
2^32-1 parents requested 128 GiB, and a 20-byte one claiming 2^24 txs measurably
allocated 671 MB before returning its error — remote unrecoverable
out-of-memory from a payload smaller than a UDP header.
Tests: TestBlockVerifyRejectsDuplicateNullifier,
TestBlockVerifyRejectsNullifierRepeatedInOneTx,
TestVertexVerifyRejectsDuplicateNullifier,
TestDeserializeVertexBoundsParentCount, TestDeserializeVertexBoundsTxCount.
Co-authored-by: Hanzo Dev <[email protected]>
VMs now live in ONE place: chains/<name>/ owns the full implementation.
Previously split across node/vms/<name>/ (impl) + chains/<name>/main.go
(plugin wrapper). Now consolidated.
New layout:
chains/<name>vm/*.go — package <name>vm (VM code)
chains/<name>vm/cmd/plugin/main.go — package main (plugin binary)
chains/<name>vm/go.mod — module github.com/luxfi/chains/<name>vm
Moved 11 VMs: aivm, bridgevm, dexvm, graphvm, identityvm, keyvm,
oraclevm, quantumvm, relayvm, thresholdvm, zkvm.
External callers now import github.com/luxfi/chains/<name> directly.
zeekay
