mirror of
https://github.com/luxfi/chains.git
synced 2026-09-24 00:26:00 +00:00
zeekay
6220024728
Nine chains each write their own Accept, and five of them write it with individual Puts that return early. A later write failing leaves the earlier ones on disk and the chain already believing the block was accepted: state is half-applied and there is no path back. The discipline two chains already have becomes the only one there is. A block declares what it Writes and what it Publishes; the store stages the writes through a versiondb, commits them in ONE batch with the block, its height entry and the tip pointer, and on any failure rolls the view back and rebuilds the caches from committed state. Nothing the block claimed survives and the tip does not move. Publish runs after the commit, so there is no window in which the chain has advanced past state that is not on disk. Beside it: the blocks in flight, under the store's one lock, pruned at or below the accepted height because the engine may abandon a block without ever deciding it; the pool, whose claim set is derived from its queue so a claim cannot outlive the entry that made it; the fee a chain declares, which admits nothing until it is declared; and the factory, whose VM holds nothing until Initialize. Seven mutations of the store and three of the pool each fail at least one test.
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.