Continuation of dc31d5b (quantumvm consumer-side leak after consensus
repo migration) — the rename was incomplete; this pass closes it.
Identifier renames in chains/{quantumvm,thresholdvm,dexvm}:
- NTTForwardRingtail / NTTInverseRingtail / BatchNTTForwardRingtail
→ NTTForward/Inverse/BatchNTTForwardCorona (Quasar GPU dispatch)
- LaneRingtail (CertLane enum)
→ LaneCorona
- ProtocolRingtail (Protocol enum)
→ ProtocolCorona (string value already "corona")
- All Ringtail-prefixed local identifiers in quantumvm/{quasar,
quasar_witness,block,vm,vm_test,signer,stamper,service}.go,
thresholdvm/{client,protocols,rpc,types/{ceremony,share},
runtime/m_chain_adapter,cert/lane_test,protocol_executor_test}.go,
dexvm/factory.go
Directory + file rename:
thresholdvm/protocol/ringtail_general/ringtail.go
→ thresholdvm/protocol/corona_general/corona.go
package ringtail_general → package corona_general
evm/main.go: replace single `precompile/ringtail` blank-import with
the canonical LP-4200 unified PQCrypto block (mlkem 0x012201,
mldsa 0x012202, slhdsa 0x012203, pulsar 0x012204, p3q 0x012205,
corona 0x012206) + xwing.
External test that imports threshold's renamed wrapper:
thresholdvm/protocol_executor_test.go now imports
"github.com/luxfi/threshold/protocols/corona" (was protocols/ringtail).
Resolves via the workspace `./threshold` entry pointing at the
local renamed wrapper; downstream chains/go.mod still pins
luxfi/threshold v1.5.5 and will tidy clean once threshold cuts the
next tag.
Build: go build ./... PASS (only harmless duplicate-rpath warnings
from the cevm cgo link).
Tests:
thresholdvm + subpackages PASS
quantumvm PASS
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
Ringtail 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)
- Ringtail threshold (Module-LWE, 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
RingtailKeySize int // Size of Ringtail 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
RingtailEnabled bool // Enable Ringtail 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.generateRingtailKey: Generate a new Ringtail 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 legacyGenerateRingtailKeyRPC name). Used for individual round attestations and the Z-witness rollup input. - Ringtail threshold share: per-validator share of the combined
Ringtail key, produced by the Q-Chain DKG ceremony (rooted in
qchain_ceremony_root). Lives inluxfi/threshold/protocols/ringtail.
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.