Completes the "one and only one way" wire migration: every VM in this repo now
serializes blocks and txs through luxfi/zap struct-is-wire at fixed field
offsets — no encoding/json, no hand-rolled big-endian, no cursor codec.
- aivm: Block + AIVertex + nested CIntent native-encoded. Fixes a latent
data-loss bug — AIVertex had unexported fields, so encoding/json silently
marshalled it as {}; the native encoder round-trips every field.
- keyvm: Transaction (signing preimage = SigningBytes(), excludes Auth/Sig;
full wire = signing || sig object, so the signed bytes stay a genuine prefix
and authenticate() re-derives a byte-identical preimage) + Block.
- quantumvm: Block + BaseTransaction. Block wire is the quantum-signature
preimage (deterministic fixed offsets, ordered tx list).
- dexvm: block envelope (txs were already ZAP). Preserves UnixNano timestamps,
deterministic tx order, and content-addressed carried fills.
Hardening from the adversarial crypto review (must-holds all verified: no
keyvm signature malleability/replay, no aivm CIntent id-forgery/escrow tamper,
no dexvm ordering/fill tamper, all parsers fail closed):
- keyvm (M1): make the wire strictly canonical. zap follows the root offset
and ignores unreferenced padding inside a message's declared size, so a twin
buffer could decode to identical fields with a different hash (id-malleability).
ParseTransaction now binds the id to the re-serialized (canonical) form and
rejects any non-canonical input at the door — exactly one byte-string
authenticates per logical tx. Regression test: the padded twin is rejected.
- quantumvm (M2): derive block + tx ids as sha256(Bytes()), matching the other
three VMs. The prior ids.ToID(parent||height) over 40 bytes (and ids.ToID over
the >=32-byte tx wire) silently yielded ids.Empty for every block/tx,
collapsing the block store and tx pool to a single slot. The block id is no
longer stored in the wire, so the invariant id == sha256(Bytes()) holds
unconditionally. Regression tests: ids are non-Empty and collision-distinct.
Not in scope (tracked separately, fail-closed today): aivm RewardPerOperator is
escrowed but not bound by ComputeIntentID — a pre-existing design gap that needs
a coordinated A-side + C-side intent-id preimage bump before any non-fail-closed
CCommitVerifier ships.
Builds + tests green under the canonical CGO=0 -mod=readonly recipe; go.mod/go.sum
are the go mod tidy canonical set (indirect deps resolved forward, all within
major). Cryptographer verdict: SAFE TO PUBLISH.
Co-authored-by: Hanzo Dev <dev@hanzo.ai>
Q-chain Virtual Machine (QVM)
The Q-chain Virtual Machine (QVM) hosts the Q lane of Lux's parallel-witness
finality model (LP-020 Quasar). When the operator-selected witness set
includes WitnessQ (policies PolicyPQ or PolicyQuantum), Q-Chain runs a
Corona 2-round threshold ceremony per consensus round and emits the
resulting threshold signature as the round's Q-witness. Q-Chain is one of
three parallel finality producers (P, Q, Z); adding it does not change
finality latency, only parallel verification cost.
The VM also provides per-validator ML-DSA-65 (FIPS 204) identity signatures and a quantum stamp for individual transactions.
Features
Q-witness production (Quasar parallel-witness finality)
- Corona threshold (Module-LWE, the two-round Corona construction,
eprint 2024/1113): 2-round threshold
signing per consensus round, t = ⌊2n/3⌋ + 1 of n validators, combined
public key rooted in
qchain_ceremony_root. - Per-validator ML-DSA-65 (FIPS 204): identity signatures over round digests, used by the Z lane (chains/zkvm) to produce the Groth16 rollup.
- Quantum stamp: time-windowed transaction-level binding.
Performance Optimization
- Parallel Transaction Processing: Process multiple transactions concurrently
- Configurable Batch Sizes: Optimize throughput based on network conditions
- Worker Pool Architecture: Efficient resource utilization with pooled workers
Configuration
The QVM can be configured through the config.Config structure:
type Config struct {
TxFee uint64 // Base transaction fee
CreateAssetTxFee uint64 // Asset creation fee
QuantumVerificationFee uint64 // Fee for quantum signature verification
MaxParallelTxs int // Maximum parallel transactions
QuantumAlgorithmVersion uint32 // Quantum algorithm version
CoronaKeySize int // Size of Corona keys in bytes
QuantumStampEnabled bool // Enable quantum stamp validation
QuantumStampWindow time.Duration // Validity window for quantum stamps
ParallelBatchSize int // Batch size for parallel processing
QuantumSigCacheSize int // Cache size for quantum signatures
CoronaEnabled bool // Enable Corona key support
MinQuantumConfirmations uint32 // Minimum confirmations for quantum stamps
}
Architecture
Core Components
- VM (
vm.go): Main virtual machine implementation - Factory (
factory.go): VM factory for creating QVM instances - Config (
config/config.go): Configuration management - Quantum Signer (
quantum/signer.go): Quantum signature implementation
Transaction Flow
- Transactions are submitted to the transaction pool
- Worker threads process transactions in parallel batches
- Quantum signatures are verified using the quantum signer
- Valid transactions are included in blocks
- Blocks are signed with quantum stamps
RPC API
The QVM exposes the following RPC endpoints:
qvm.getBlock: Retrieve a block by IDqvm.generateCoronaKey: Generate a new Corona key pairqvm.verifyQuantumSignature: Verify a quantum signatureqvm.getPendingTransactions: Get pending transactionsqvm.getHealth: Get VM health statusqvm.getConfig: Get current configuration
Security Features
Quantum Signatures
The QVM uses ML-DSA (FIPS 204, NIST module-lattice DSA) for per-validator quantum-resistant signatures:
- ML-DSA-44/65/87 supported (NIST Level 2/3/5)
- Quantum stamp: time-windowed binding of message + nonce + timestamp, prevents stamp replay
- GPU batch verification via
accel.DilithiumVerifyBatch(accel.Available(), threshold 64+ signatures)
Validator key material
Two distinct categories live on Q-Chain validators:
- Per-validator ML-DSA-65 identity key:
MLDSAValidatorKeyinquantum/signer.go(kept exposed via the legacyGenerateCoronaKeyRPC name). Used for individual round attestations and the Z-witness rollup input. - Corona threshold share: per-validator share of the combined
Corona key, produced by the Q-Chain DKG ceremony (rooted in
qchain_ceremony_root). Lives inluxfi/threshold/protocols/corona.
Parallel Processing Safety
- Thread-safe transaction pool with mutex protection
- Isolated worker threads for transaction processing
- Atomic operations for state updates
Usage
Creating a QVM Instance
factory := &qvm.Factory{
Config: config.DefaultConfig(),
}
vm, err := factory.New(logger)
if err != nil {
return err
}
Initializing the VM
err := vm.Initialize(
ctx,
chainRuntime,
db,
genesisBytes,
upgradeBytes,
configBytes,
toEngine,
fxs,
appSender,
)
Building Blocks
block, err := vm.BuildBlock(ctx)
if err != nil {
return err
}
Testing
The QVM includes comprehensive error handling and logging for production use:
- Error recovery for parallel processing failures
- Detailed logging at all levels (Info, Debug, Error)
- Health check monitoring
- Metrics collection
Future Enhancements
Planned improvements include:
- Additional quantum-resistant algorithms (SPHINCS+, Dilithium, Falcon)
- Enhanced parallel processing with GPU acceleration
- Cross-chain quantum signature verification
- Advanced caching strategies for improved performance
License
Copyright (C) 2019-2025, Lux Industries Inc All rights reserved. See the file LICENSE for licensing terms.