The full chains build hit a go.sum SECURITY ERROR — luxfi/[email protected] was
re-tagged (recorded hash no longer matched served bits), blocking everything that
pulls the consensus-adjacent module tree. Fixed PROPERLY, NO bypass
(GONOSUMCHECK/GOSUMDB=off never used):
- staking v1.5.0 → v1.5.1 (clean tag), records the real hash
- consensus v1.25.21 → v1.25.29 (was drifted behind; CROSS-REPO-VERSION-PIN), pulls
crypto v1.19.26
- added luxfi/dex v1.5.20 require + recorded the transitive sums (shopspring/decimal
et al) the evm/precompile dex wiring needs
Consensus path now builds + tests clean: schain + schain/cmd/plugin exit 0, full
./schain/... suite green. (Remaining full-tree ./... failure is the luxfi/evm+dex
CGO native link needing luxcpp prebuilt Metal/secp256k1 libs — a heavyweight-VM
native-build concern, NOT consensus and NOT in the schain path.)
quantumvm/vm.go: remove GetEngine() so the chain manager routes Q-Chain through
the linear consensuschain cert path (the same deterministic 2/3-stake BFT
certificate finality as C/D/P), not the undriven DAG engine. quantumvm already
implements the full chain.ChainVM/BlockBuilder surface; dropping GetEngine is the
whole change. Adds the _ chain.ChainVM + _ consensuschain.BlockBuilder asserts.
dexvm/factory.go: correct the stale 'Quasar consensus' comment — dexvm finalizes
via the linear cert path (Photon->Wave->Focus + 2/3-stake cert), same as C-Chain.
The Stage-1 allocate gate was owner-gated in LOGIC (pinning.IsOwner over the
block's threaded proposer) but UNENFORCEABLE by a verifying node: a Lux block
carries no verifiable proposer, and resolving one (GetValidatorSet) can be a
network call, so the gate could not run inside the pure, local block apply. The
chain was therefore unsafe for >1 validator.
Make ownership self-attested and cryptographically verifiable:
- AllocateTx gains Signer/SignerScheme/SignerPubKey/Sig + Epoch/Nonce/Fingerprint.
Sig is an ML-DSA signature (FIPS 204, the SAME scheme the validator NodeID
derives from) over the SP 800-185-framed bytes Range|Count|Epoch|Nonce|
Fingerprint. The owning proposer signs at BuildBlock with its staking key.
- Verify (applyAllocate) is pure + local: recompute owner = pinning.Owner(R,
V@epoch); require Signer == owner; re-derive the NodeID from the carried public
key (ids.DeriveMLDSA — the NodeID is a SHAKE256-384 commitment to the key) and
require it to equal Signer; ML-DSA-verify the signature. Any failure rejects the
whole block (fail closed).
- Validator-set locality: GetValidatorOutput carries no ML-DSA key, so Verify
binds the key via the NodeID commitment instead of a set lookup, and uses the
EpochFingerprint carried in the tx (recomputed from the local snapshot) as the
DESIGN 6.4 guard — the network call (set resolution) happens in BuildBlock,
never in Verify.
A non-owner's forged allocate is unverifiable by construction: it cannot sign as
the owner (no key), and claiming the owner's NodeID with a foreign key fails the
re-derivation. This is the property that replaces raft's serialized writer.
Tests (real ML-DSA keys, production NodeID derivation, no bypass): owner-signed
accepted + contiguous/monotonic; non-owner-with-VALID-key rejected; forged sig
rejected; foreign-key-for-owner-NodeID rejected; tampered tx rejected; epoch and
fingerprint mismatch rejected; verifier accepts owner-signed block regardless of
relay; state-root/manifest tests stay green. Full schain suite green under -race.
Replaces raft's serialization role for volume/fileId allocation with
owner-gated VM state riding native Lux consensus. The HRW owner of a range
is the only emitter of allocate mutations, enforced at block Verify — no
leader election.
- txs: AllocateTx{Range,Count} mirrors PutManifestTx codec (type byte + JSON);
Verify rejects empty range / zero count. Owner gate is block-level, not in
the tx (a tx cannot see the block's validator set).
- state: per-range counter alloc/<range> (GetAlloc/SetAlloc), folded into the
SHAKE256 state Root() alongside manifests via rootPrefixes; domain bumped to
SCHAIN_STATE_ROOT_V2 so the root covers allocator divergence.
- vm: applyAllocate increments alloc/<range> by Count, reserving [base,base+Count)
— pure function of committed state, deterministic, version-layer only, no I/O.
Owner gate: pinning.IsOwner(range, proposer, members) in ProcessBlock; a
non-owner (or no-validator-set) allocate fails the whole block. ProcessBlock
now Aborts staged state first so read-modify-write applies over COMMITTED
state (idempotent across BuildBlock+Verify re-application).
- BlockContext{Members,Proposer,Epoch} threads the validator set + proposer as
explicit deterministic inputs (no network I/O in Verify). BlockContextBuilder
is the seam to the real consensus runtime (master-cutover stage); empty
context = M0/no-allocate path, AllocateTx fails closed.
Tests (green, no go.sum bypass):
- owner allocates: contiguous + monotonic across blocks ([0,8) then [8,13)).
- non-owner rejected: proposer-side (BuildBlock) and verifier-side (Verify) →
errNonOwnerAllocate; counter untouched; nothing leaks to durable base.
- empty validator set: fails closed (errNoValidatorSet).
- parallel distinct ranges: independent owners allocate independently.
- same range: serializes through its one owner.
- state root covers alloc: counter change moves Root(); Verify rejects a
tampered claimed root (errStateRootMismatch).
git add -A in the v1.4.1 commit swept in a 12.6MB local Mach-O build artifact.
Remove it from the tree and ignore it so binaries never land in the release again.
CRYPTO (Red/cryptographer HIGH): manifest state root was a hand-rolled
len||k||len||v SHA-256 fold (length-extendable, no domain sep). Now SHAKE256 +
SP 800-185 leftEncode framing + 'SCHAIN_STATE_ROOT_V1' domain, mirroring the
validator NodeID scheme (ids/node_id_scheme.go) — not length-extendable,
domain-separated, PQ-strength. Full schain suite green (determinism +
change-sensitivity + Verify-rejects-tampered-root), NO sum bypass.
DEPS (integrity, NOT bypassed): luxfi/[email protected] had been re-tagged (go.sum
recorded an immutable-tag hash that no longer matched the served bits). Fixed
PROPERLY by moving to the clean v0.8.11 and recording the real hashes; added the
private hanzos3 org to GOPRIVATE (it was missing) so luxfi/zapdb's hanzos3/go-sdk
dep resolves via git+go.sum, not the public sumdb. go.sum is now correct, not skipped.
CI: registered schain in .github/images.json (build matrix); added the canonical
schain/cmd/plugin/main.go (ZAP-native vm/rpc.Serve, no build tag — the path the
release workflow builds), removing M0's grpc-tagged rpcchainvm plugin. Plugin
builds clean via ./schain/cmd/plugin.
Pure weighted-rendezvous (HRW) owner assignment over the P-Chain validator set
(schain/pinning): Owner/IsOwner/EpochFingerprint — single-writer-per-range as a
function of (range, validatorSet@pChainHeight), no leader election, parallel across
ranges, same-object double-write impossible. 9 tests green; nothing wired yet (safe).
DESIGN_pinned_writer.md: the spec to replace the s3 master's raft (the last gRPC
server). v1 on linear ChainVM (already leaderless). TWO HARD blockers gate cutover:
(1) off-chain blob durability must be ordered before the on-chain manifest commit;
(2) validator-set lookup in Verify must be a pure local read (determinism). Staged:
AllocateTx → shadow mode (after blockers) → kill raft.
PART A — manifest STATE ROOT (the >1-validator prerequisite M0 omitted):
- state.Root() hashes the committed manifest keyspace deterministically via the
zapdb prefix iterator NewIteratorWithStartAndPrefix(nil, prefixManifest),
folding each entry length-prefixed in lexicographic key order. Mirrors
dexvm/state/state.go:395 StateHash, narrowed to the one keyspace.
- VM.computeStateRoot folds blockHash+height with state.Root() (dexvm/vm.go:1260);
ProcessBlock stamps BlockResult.StateRoot (dexvm/vm.go:584).
- The root travels in the block HEADER (new 32B field after parentID; block id
commits to it). Block.Verify recomputes it and REJECTS a mismatch
(errStateRootMismatch) + Aborts staged writes — the safety gate dexvm computed
but never compared.
- Tests: determinism across write order, change-sensitivity (object set / etag /
size / fileIds), Verify-rejects-tampered-root.
PART B — S3 OBJECT path, on-chain-metadata / off-chain-blob split, end to end
(schain/object/):
- Store.PutObject streams the blob to a Volume (OFF chain) -> fid, then commits
only PutManifest{bucket,object,[fid],size,etag} to the VM through a real block
(ON chain). GetObject reads the manifest back and reconstructs from the volume.
- object.Volume is the seam; MemVolume satisfies it for M1 with a fid shape
mirroring hanzo/s3 needle.FileId and etag = base64(md5(blob)) (= ContentMd5).
- M2 PLUG POINT (object/volume.go): swap MemVolume for a github.com/hanzoai/s3
s3/operation.SubmitFiles adapter; nothing in the VM or object.Store changes.
- Test proves blob bytes appear in NO accepted block, the block stays
manifest-small, the manifest IS on chain, and GET byte-reconstructs.
luxfi packages only; zapdb-native; no protobuf in state; SDKROOT needed on macOS.
Fork dexvm's commit discipline into a new storage VM (VMID 'schain'): dual-DB
(durable zapdb base + per-block versiondb), pure-deterministic ProcessBlock, ONE
CommitBatch at Accept (mirrors dexvm/vm.go:1194, block.go:159). M0 op: PutManifest
{bucket,object,fileIds,size,etag} staged in the version layer, durable only after
Accept; GetManifest reads committed state. Proves the on-chain-metadata / off-chain-
blob architecture for an embedded decentralized S3 'S-chain'.
schain_test.go (real on-disk zapdb.New): manifest absent in base DB before Accept,
present after — versiondb→CommitBatch proven end-to-end; +Reject-aborts-staged and
tx-codec round-trip. go vet + -race clean.
M1 notes (in-code): add a manifest STATE ROOT before multi-validator consensus
(dexvm computeStateRoot pattern); keep any future cross-chain blob-ref leg separate
from the manifest commit; add genesis/config. Next: wire the S3 Sig-V4 gateway
(PUT→needle off-chain + PutManifest on-chain; GET→manifest+needle stream).
forbiddenChainTokens + IsForbiddenChainRef named the off-network white-label
universe by string to reject it. That negative gate is redundant: the
positive gate (ChainVerifier) already admits only real on-chain Lux assets,
so an off-network universe can never pass regardless. Removed the brand list
and the func; kept the genuinely-distinct guards (mock/synthetic liquidity,
ASCII-ticker-as-id). AssertNoForbiddenAssetRefs keeps its signature for the
gate's call shape. No brand strings remain; builds clean.
VM.Initialize now runs enforceRealAssetsOnly before marking initialized:
fail-closed over the consensus-supplied network identity (never operator-
spoofable). Refuses synthetic flags on a value net, value activation with no
legal consensus mode, a wrong-net/Liquidity manifest, value with no real
assets, bad allowed-kinds. Config gains the real-assets fields (manifest
path + SHA-256 pin, synthetic flags, consensus mode, caps/halt). Renames
HONEST_VALIDATOR_LAUNCH -> HONEST_VALIDATOR_LABELED across the registry
(value qualified by what it IS — labeled CFT parity — not when it runs).
Adds cmd/dex-assets-validate (CI proves every manifest entry real against
the target net RPC) + the validate-asset-manifests workflow. dexvm tests +
registry gate tests green.
Mirror the canonical cross-home golden KAT: registry.DeriveAssetID must reproduce
the EXACT 32-byte AssetID bytes that luxfi/dex pkg/dexcore.DeriveAssetID asserts
(AssetIDGoldenVectors). Fixed (networkID=2, source chain all-0x11, {ERC20, EVM_NATIVE,
UTXO}) → expected id vectors, byte-identical to the dexcore side. This locks the
resolve↔register equivalence the 0x9999 value path depends on: a registered AssetID
(here) and a swap-derived AssetID (dexcore, via the precompile resolver) name the SAME
asset by the SAME id. A drift in either home's preimage discipline now fails CI in BOTH
suites — a real consensus-identity divergence caught in test, never in prod.
Verified: CGO_ENABLED=0 go test ./dexvm/registry -run GoldenKAT green; the same three
vectors pass in dex/pkg/dexcore.
Make the per-network asset manifests (mainnet/testnet/devnet) available to a node
binary with no filesystem dependency, so the EVM plugin can build the 0x9999
value-path AssetResolver from the CI-approved, content-hashed asset set compiled
into the binary. Selection is by EVM chainID (96369/96368/96370). Localnet (1337),
whose C-Chain id is environment-specific, gets a runtime-rooted native-only manifest
(LocalnetNativeManifest) synthesised from the node's live cChainID — never a constant.
- embedded.go: //go:embed the three manifests; EmbeddedManifestFor(evmChainID) +
LocalnetNativeManifest(networkID, cChainID).
- manifest.go: split decodeManifestBytes out of loadManifestBytes so the embed path
and the disk path share one decoder (shape-validate + content-hash + unknown-field
rejection identical for both).
The keeper/venue model is abandoned. The D-Chain (dexvm) trades via its own
consensus-driven state transition (matcher-at-Verify), not via an off-chain
keeper polling dex.getSettlement to drive 0x9999. Revert the three v1.3.16
commits' additions to the v1.3.15 working state:
- vm.go: remove GetSettlement + the proceeds-coordinate record
- chainvm.go: remove the SubmitTx RPC seam additions
- api/service.go: remove dex.submitTx + dex.getSettlement handlers
- state/state.go: remove PutSettlement/GetSettlement settlement index
- api/submit_test.go, state/settlement_test.go: remove keeper-RPC tests
Deps are unchanged from v1.3.15 (go.mod/go.sum identical). bridgevm + dexvm
build clean and all tests pass.
consensus v1.25.18 quasar.go/epoch.go call corona/threshold.Round1 single-value,
but corona's Round1 now returns (Round1Data, error) -> the quantumvm plugin (and
any consensus consumer) fails to compile. v1.25.19 has the Round1 fix. All 11 VM
plugins build clean.
Exposes the two RPCs the off-chain dexkeeper drives the 0x9999 two-phase atomic
DEX seam with:
- dex.submitTx: mempool entry so the keeper can inject ImportTx (consume the
C->D atomic object) + the settling RelayOrderTx (clob_submit, CollateralRef-bound)
- dex.getSettlement(collateralRef): returns the D->C proceeds object's
(outputID, amount) recorded deterministically in settleFromFills, the Phase-B input
State.Put/GetSettlement write through versiondb (commit-atomic, consensus-safe).
RelayOrderTx.Verify permits an unsigned relay (authority binds to the escrow owner,
not From). dexvm/api + dexvm/state tests pass.
settleFromFills now records the proceeds D->C object's (outputID, amount) under the
collateral ref (the C->D intentID) via state.PutSettlement, written into the versiondb
so it commits atomically with the block. outputID = deriveUTXOID(settlementExportTx.ID(),
0) — the SAME key executeExport puts into shared memory — and the amount is the realized
proceeds; both are pure functions of consensus-agreed inputs (blockHash+txIndex seed the
export identity), so every validator writes the identical record and the StateRoot stays
consensus-safe. The record is purely informational (moves no value; never consulted by
the deterministic settle/consume path).
dex.getSettlement(collateralRef) reads it back (VM.GetSettlement -> state.GetSettlement)
so the off-chain keeper, after submitting the ImportTx + settling RelayOrderTx and the
proposer settles, learns the D->C object's outputID + amount and builds the C-side Phase-B
ImportSettlement (DS01 outputID|amount|intentID) that consumes the object and emits DEXFill.
This closes the keeper's export-discovery gap.
Tests: 3 state round-trip/isolation/escrow-coexistence + 3 RPC pending/found/bad-ref, all
pass (CGO_ENABLED=0; local cgo accel toolchain is broken — CI builds linux/amd64).
The dexvm is a stateless atomic ZAP proxy whose ImportTx/RelayOrderTx/ExportTx
are deterministic block inputs, drawn from the proposer's pending pool. That pool
(ChainVM.SubmitTx -> pendingTxs + engine notify) was unreachable from outside the
process: CreateHandlers exposed only Ping/Status/Relay, so an off-chain keeper had
no way to inject the ImportTx that consumes the C->D atomic object the C-side
0x9999 SubmitSwapIntent writes, nor the settling RelayOrderTx. The full two-phase
seam therefore could not land a DEXFill.
This adds a dex.submitTx JSON-RPC method (api.Service.SubmitTx) that forwards
wire-encoded tx bytes to an api.TxSubmitter and returns the canonical
ids.Checksum256 tx id. The submitter is wired ONLY on the node path
(ChainVM.CreateHandlers builds the service with the ChainVM as submitter); the
inner VM's read-only CreateHandlers (standalone/test) reports ErrSubmitUnavailable.
Bootstrap-gated; admission/fee gate stays in ChainVM.SubmitTx. 6 unit tests cover
unavailable/not-bootstrapped/bad-hex/empty/success(verbatim+TxID)/submitter-error.
The swap-seam HIGH fix (c242e01) extended encodeExportedOutput to 69 bytes
(rail|owner|asset|amount|spent), where the trailing spent witness carries the matched
INPUT amount on a D->C swap proceeds leg so the C-side ImportSettlement can enforce the
taker's recorded slippage limit. That widening MUST be byte-identical with the precompile's
exportedOutputSize9999 or D would export an object C cannot decode (every swap settlement
reverts ErrNativeSettleMalformed, no taker is ever credited).
native_seam_parity_test pins the lockstep on the D side: a hardcoded golden vector
(reproduced byte-for-byte by precompile/dex/native_seam_parity_test) + a round-trip that
proves the spent witness survives + a wrong-width rejection. If either repo's layout drifts,
one of the twin parity tests fails BEFORE the bytes reach consensus. Closes the dangling
'native_seam_parity_test pins it' reference in atomic.go.
HIGH (inert attestation gate): FillAttestationPubKey was read by settleCarried but
NEVER written — parseConfig copied only 10 enumerated fields and parseGenesis carried
only DexZapEndpoint+TrustedChains. So in prod the pubkey was nil, verifyFillAttestation
returned nil, trustCarried was always true, and the fabricated-fills guard could never
engage: a malicious/MITM proposer could settle fabricated fills and drain a cross-taker's
seam reserve via the proceeds leg. Fix: add FillAttestationPubKey (hex) to the Genesis
struct + parseGenesis, assigned into vm.Config. It is GENESIS-pinned only — deliberately
absent from parseConfig — because it is consensus-affecting (gates trustCarried ->
escrow-consume + export legs -> computeStateRoot); a per-node value would fork the
StateRoot. A wrong-width key is a FATAL genesis error (fail-closed). FillAttestationSeed
stays json:"-" (KMS-only, never in a genesis/config blob).
MEDIUM (consensus comment): config.go now states the stronger invariant — the pubkey is
STRICTER than DexZapEndpoint (which is node-local transport, not recomputed in the
deterministic settle path) and MUST be a single genesis-pinned constant.
MEDIUM (taker-authenticated MEV floor): the proceeds export object now carries the matched
input (AtomicOutput.Spent; shared-memory object 61->69 bytes, both repos in lockstep) so
the C-side ImportSettlement can enforce the taker's OWN recorded slippage limit
(proceeds >= spent*worstRate) independently of the keeper's relay-supplied priceLimit. A
keeper that zeroes the relay limit to sandwich the taker still produces a proceeds object
C will refuse; understating spent loosens the floor but inflates refund, which the
per-taker principal cap + seam-reserve conservation independently bound.
Tests (redteam, CGO_ENABLED=0 pure Go): redteam_genesis_attestation_test drives a REAL
genesis blob through Initialize->parseGenesis (NOT a direct Config write) and proves the
pubkey reaches Config, a fabricated/unattested block becomes a full refund by virtue of
genesis alone, a wrong-width genesis key fails Initialize closed, and the runtime config
blob cannot set the consensus-affecting pubkey. native_seam canary pins the joint 69-byte
object wire (incl. spent) across both repos. Full dexvm redteam + unit suites green.
HIGH-1 (THE happy-path break, swapsWork=NO): settleFromFills exported the taker's
PROCEEDS leg under assetFromRef(ref,leg)=SHA256(ref||leg), a synthetic routing handle.
The C-side ImportSettlement requires recAsset==assetID(currency_out) (the injective id
that also keys seamReserve[assetOut]); a SHA256 handle never matched, so the proceeds
credit ALWAYS reverted (ErrNativeSettleAsset) and the taker never received their swap
output. FIX: settleFromFills exports the proceeds leg under the REAL output-asset id
carried with the settling relay (RelayOrderTx.AssetOut, signature-bound, keeper-asserted
and C-bound => a wrong value is taker-liveness-only, never theft/mint). Removed the dead
assetFromRef SHA256 helper. Kept the prior pass's owner-bind + one-time-consume +
per-intent binding intact.
MEDIUM (bounded sandwich/MEV): settleFromFills now enforces a worst-acceptable CLOB
price carried from the relay (RelayOrderTx.PriceLimit/LimitIsUpper, derived from the V4
SqrtPriceLimitX96): a fill worse than the limit is refused (BUY ceiling, SELL floor;
0=no limit), leaving the escrow reclaimable.
MEDIUM (single-proposer fabricated fills): populate+verify the reserved carried-fills
attestation. The venue signs blake3(domain||blockHash||entries) with Ed25519; every
validator verifies it before settling (verifyFillAttestation), gated behind
Config.FillAttestationPubKey (default-on once set; fail-secure full-refund when a block's
fills are unattested/forged). Config note: the pubkey MUST be identical across validators
(consensus-affecting, same class as DexZapEndpoint).
Tests (CGO_ENABLED=0, default + redteam): TestRED_SwapProceeds_* (unit + e2e happy-path
credit under the real output asset), TestRED_SwapSlippageLimit_*, TestRED_FillAttestation_*
(verify/forge/fabricated-refund/off-by-default). Full dexvm suite green.
Extends fix/swap-rail-escrow-owner-bind (27f4c35). Within chains v1.3.15.
* dexvm: bind swap-settle authority+payout to authenticated escrow owner (CRITICAL escrow-theft fix)
The swap rail delegated per-taker refund-liveness + relay authority to the
unauthenticated RelayOrderTx sender with NO C-side owner binding, letting any
fee-paying tx name a victim's collateral ref and settle the locked collateral to
the attacker out of the shared seam reserve (cross-depositor theft).
Fix (load-bearing, derives authority from the already-authenticated cross-chain
object owner — the platformvm import/export model):
- state/state.go: escrow value is now owner(20)|asset(32)|amount(8); the owner
leads. PutEscrow/GetEscrow carry it.
- atomic.go executeImport: persist the AUTHENTICATED importedOwner (read back from
the consumed C->D shared-memory object) into the escrow.
- vm.go settleFromFills: a settle is authorized ONLY by the escrow's recorded
owner (errSettleUnauthorized otherwise), and BOTH proceeds+refund legs export to
that owner, never to the relay tx sender.
- txs/tx.go: RelayOrderTx.Verify now does present-gated secp256k1 authentication of
From (Sign/SigningBytes/verifyFrom), wiring the dangling ErrInvalidSignature.
From bears NO authority (authority is the escrow owner), so an unsigned relay is
admissible and cannot escalate; a present-but-invalid signature is rejected.
Regression: redteam_escrow_owner_test.go proves the attacker is credited 0 even
with a valid own-key signature (defense in depth: escrow-owner bind holds
independent of the signature). Fixed a pre-existing off-by-one in
TestRED_FractionalFill (export asset offset). All dexvm tests pass (default +
-tags redteam, CGO_ENABLED=0 pure-Go).
Gated on red re-verify; NOT promoted to testnet/mainnet.
* aivm: A-Chain quorum-settlement engine (provider stake/slash, beacon selection, commit-reveal, settlement, receipt export, import committed C intent). LP-5300. NOTE: branched on swap-rail base; rebase to main on merge.
---------
Co-authored-by: zeekay <[email protected]>
The D side of the precompile/dex H1 rail-binding. The shared-memory object wire
goes 60->61 bytes: rail(1)|owner(20)|asset(32)|amount(8), byte-identical to the
precompile's exportedOutputSize9999. The rail tag is the lane the value travels
(RailSwap=0 default / RailLP=1) and round-trips through the atomic core unchanged.
- txs.AtomicOutput gains Rail; ImportTx/ExportTx.Verify enforce one-rail-per-leg
(structural half, mirroring the asset bind).
- encode/decodeExportedOutput carry the rail byte (decode now returns rail too).
- executeImport binds the credited outputs' rail to the consumed UTXO's RECORDED
rail (authoritative half; errImportMixedRails), so an import cannot re-lane
value — a swap object onto the LP lane or vice-versa.
- executeWithdraw (the LP collect/withdraw export) stamps RailLP; the fill/refund
settlement exports (settleFromFills) stay RailSwap (zero default).
New: TestNativeRail_ImportRejectsRailMismatch (both directions) +
TestNativeRail_ImportAcceptsMatchingRail (positive control). Wire-parity canary
TestNativeSeam_WireMatchesPrecompile asserts byte-identity on BOTH rails. LP-seam
round-trip + conservation/redteam offset helpers updated to the 61-byte wire.
CGO_ENABLED=0 GOWORK=off go test ./dexvm/... green.
Prove the D side of the LP rail (precompile/dex 0x9999 modifyLiquidity /
collectPosition) consumes/produces the EXACT atomic wire WITHOUT any new D-side
primitive: a position-commit object (DL01) is byte-identical to any value object,
so the C->D commit leg == executeDeposit (atomic import -> CLOB ledger credit; the
position's collateral + fee accrual lives in the CLOB, funded by the consumed
object) and the D->C collect leg == executeWithdraw (debit realized balance ->
atomic export). Three tests: commit-funds-position (+ replay reject),
collect-exports-principal+fees, full round-trip conserves.
Prove the dexvm import/export wire is byte-identical to the precompile's atomic
object (TestNativeSeam_WireMatchesPrecompile), that a C->D object the precompile
PUT imports cleanly on D, that a D->C export the dexvm writes decodes as the
precompile's settlement object, and the full C->D->C round trip. Locks the
cross-chain seam compatibility the 0x9999 money path depends on.
Bump to the clean-go.sum builds of evm/precompile and regenerate chains' go.sum
from a clean module cache (v1.3.12's consensus/geth hashes were poisoned by a
tampered local cache, breaking clean-CI plugin builds). No chains code change.
go mod verify clean; build + bridgevm + dexvm tests green.
origin/main had drifted to a docs-only commit that did not include the
bridgevm BLS threshold-scheme registration (v1.3.11, 7761e80) — without it the
v1.30.16 bridge regression recurs. Merge keeps both.
bridgevm runs as a standalone rpcchainvm plugin; mpc.go called
threshold.GetScheme(SchemeBLS) but never imported crypto/threshold/bls,
whose init() registers it. The full node binary pulled it in via
platformvm, but the v1.30.16 plugin build didn't -> B-Chain failed VM
init ('threshold: scheme not registered'). Blank-import to self-register.
The Z-Chain is DEFINITIVELY strict-PQ (shielded settlement on the canonical
Lux strict-PQ profile), but the switches were inert: the default ZConfig
omitted StrictPQ (->false) and RegisterZKPrecompiles had ZERO callers.
Task 1 — drive BOTH switches from the single ZConfig.StrictPQ field:
- Default ZConfig now pins StrictPQ=true + ProofSystem='stark' (the only
system accepted under strict-PQ). A genesis with no explicit ZConfig
yields a strict-PQ chain; a permissive deployment MUST set StrictPQ=false
explicitly.
- VM.Initialize now calls precompiles.RegisterZKPrecompiles(reg, config.
StrictPQ) — same bit. On strict-PQ the classical Groth16 (0x80) / PLONK
(0x81) verifiers are NOT registered (fail-closed by absence); only
STARK/FRI (0x82) + the fail-closed stubs exist. Added VM.ZKPrecompiles()
/ VM.StrictPQ() accessors.
LOW (Red) — TestStrictPQ_RealBN254VKLoadErrors drove a test-local mirror
(reapplyStrictPQVKGuard), not the production loadVerifyingKeys. Added a
config path (ZConfig.VerifyingKeys) to supply real keys in-memory; the test
now drives the REAL NewProofVerifier->loadVerifyingKeys and asserts the
strict-PQ real-bn254-VK guard fires there. Deleted the mirror.
Tests (a)(c): default Z-Chain is strict-PQ + registers strictPQ=true;
classical 0x80/0x81 absent, 0x82 present; a groth16 shielded proof is
REFUSED before reaching bn254; explicit StrictPQ=false flips both switches
in lockstep (profile-driven, not hardcoded); real-VK guard via the
production loader; non-strict chain still accepts a real bn254 VK.
H1 — shielded-tx ProofVerifier was classical-only (groth16/plonk) and
fail-closed only via all-zero dummy VKs; real bn254 VKs would re-enable a
CRQC-forgeable shield/unshield mint/steal path. Add ZConfig.StrictPQ and a
single gate refuseClassicalUnderStrictPQ(proofType) called at the top of
VerifyTransactionProof AND per-tx in the GPU batch path (which verifies
groth16 inline, bypassing VerifyTransactionProof). Under strict-PQ only
"stark" is accepted — wired to precompile/starkfri (cSHAKE256/Goldilocks
FRI, fail-closed until the prover binds), public inputs bound to the tx's
nullifiers+commitments. loadVerifyingKeys now ERRORS on a non-dummy bn254
VK under strict-PQ (explicit fail-closed, not implicit dummy-keys). The
remaining prover work (p3q_prove C ABI + shielded/ML-DSA AIR) is tracked
as a code comment; shielded value is effectively disabled on strict-PQ
chains until it lands — the correct no-classical-fallback posture.
H2 — Groth16/PLONK precompiles (0x80/0x81) were registered unconditionally
and Run([]byte) has no AccessibleState to call RefuseUnderStrictPQ.
RegisterZKPrecompiles(registry, strictPQ) now omits Groth16/PLONK on
strict-PQ chains (registering STARK 0x82 + fail-closed Halo2/Nova stubs
only) so 0x80/0x81 fail closed by absence; non-strict chains keep them as
an optional building block (kept, not deleted). CrossChainZKVerifier gains
StrictPQ that refuses routing Groth16/PLONK while still routing STARK.
H4 — verifyPLONK computed a self-cancelling pairing, discarded the result,
ignored public inputs, and returned valid for ANY >=544-byte blob (total
bypass). Now fails closed (errPLONKVerifierIncomplete) after structural
parsing — NEVER universal-accepts.
Groth16/bn254/PLONK remain present-but-gated; STARK/FRI (P3Q) is the only
accepted proof path on strict-PQ chains.
Tests: strict-PQ refuses groth16/plonk/bulletproofs (direct + GPU-batch);
real-VK-load errors; STARK fails-closed unbound and accepts bound with
nullifier+commitment-bound public inputs; non-strict path unchanged;
strict registry omits classical + keeps STARK; cross-chain strict refuses
classical; PLONK never universal-accepts. H-02 regression updated to the
new wired-STARK fail-closed behavior.
Make the Z-Chain MLDSA-rollup verification path post-quantum. The
rollup aggregates per-validator ML-DSA-65 sigs over the round digest;
the proof was classical Groth16/bn254 (pairing-based, quantum-breakable)
and is now a strict-PQ STARK/FRI proof (P3Q: Plonky3 fork, cSHAKE256
Merkle over Goldilocks, FRI; no KZG, no pairings, no trusted setup).
VERIFIER (the clean half, done):
- precompiles/zk_verifiers.go: STARKVerifier stub -> delegates to
precompile/starkfri.Verify. Parses [proof_len][proof][pub_len][pub];
proof must carry the 'P3Q1' magic. FAILS CLOSED (errVerifierUnavailable,
never resultValid) when no FRI binding is registered (CGO_ENABLED=0 /
no -tags starkfri_p3q) — no forgery oracle. The classical
Groth16Verifier/PLONKVerifier are KEPT intact at their own addresses.
- precompiles/crosschain.go: route VerifierTypeSTARK to STARKVerifierAddr
(was errNotImplemented).
- tests: STARK now proven to delegate to starkfri (accept->0x01,
reject->0x00, bad-magic rejected before callback, unbound fails closed)
and to route cross-chain; Groth16/PLONK tests unchanged.
PROVER (the honest remaining step, FLAGGED — NOT faked):
- zwitness.go: MLDSAGroth16 -> MLDSAStark rename; doc now states the
proof is STARK/FRI. Body stays ErrZWitnessNotImplemented: ~/work/lux/p3q
exposes a Rust prover but NO p3q_prove C ABI, and has NO MLDSA-rollup
AIR. Emitting fake proof bytes on the finality path would be a forgery
oracle, so the prover binding is left as the outstanding step.
go build ./zkvm/... + go test ./zkvm/precompiles/ green (CGO_ENABLED=0,
GOWORK=off). Real cgo-tagged starkfri binding (-tags starkfri_p3q)
compiles + KAT passes against the in-tree p3q staticlib.
executeImport reads the consumed UTXO owner|asset|amount from shared memory and binds the credit to it (rejects declared!=actual; native-aliasing closed); two-pass validate-then-consume so a rejected import mutates nothing. Withdraw-rail consume-once on fillRef.
Decomplect obtain-fills (proposer, BuildBlock, once network-wide) from settle-from-carried-
fills (deterministic, Accept). No validator relays at Verify/Accept -> block output is a pure
fn of (height, carried ts, tx bytes, carried fills) -> byte-identical StateRoot. NEW
carried_fills.go wire section (block + vertex) with a RESERVED fill-signature field for the
future trustless path (no 2nd wire bump). #7 computeStateRoot completed (commits state+atomic).
TestRED_PerValidatorRelay_SplitsConsensus PASS (0 cross-validator relay); redteam 21/0 (37/0);
conservation/determinism green; race-clean. NETWORK-UPGRADE-GATED wire-format change.
orderbook/perpetuals/lending/mev dirs + backend.go deleted; vm.go 2230->830 lines.
NEW atomic.go (shared-memory import/export at Block.Accept) + relay.go (rpc.ZAPDial,
frame byte-identical to zapwire, no luxfi/dex dep). State holds only nonce:/receipt:/
consumed: -- no order/pool/position keys. txs reduced to import/export/relay. NEW
conservation_test.go::TestEndToEndAtomicValueConservation. Verified -tags dchain build+tests
green -race; grep matchAllOrders|tryMatch|crossOrders empty.
zeekay
zooqueen