Adds four Go files to chains/quantumvm so the Q-Chain VM can call into
the lux-private/gpu-kernels plugin's batched ML-DSA verify, ML-DSA sign,
and SLH-DSA verify slots without a build-time pkg-config dependency:
* backend.go cross-build types: Backend enum, GPUBackend
interface, MLDSAMode + MLDSA65* size constants,
SLHDSAVariant enum + per-variant pk/sig widths
(FIPS 204 / FIPS 205), ErrGPUNotAvailable,
AutoBackend(). Build-tag-free so vm.go can
reference the surface regardless of CGO_ENABLED.
* quantumvm_gpu.go cgo dlopen probe at init() in order
(cgo) cuda -> hip -> metal -> vulkan -> webgpu,
resolving lux_gpu_backend_init and verifying
the ABI v14 cookies (abi_version + vtbl_size)
plus the load-bearing op_mldsa_verify_batch
slot before opening a LuxBackendContext. Three
vtbl-slot wrappers dispatch through C
trampolines into op_mldsa_verify_batch,
op_mldsa_sign_batch, and the SHAKE-128f /
SHAKE-192f variants of op_slhdsa_verify_batch.
* quantumvm_gpu_nocgo.go symmetric noGPUBackend stub returning
ErrGPUNotAvailable on every method so the
package surface is identical under !cgo.
* quantumvm_gpu_test.go round-trip test: dlopens the configured
plugin (LUX_GPU_PLUGIN_DIR override or default
loader path), generates an ML-DSA-65 keypair +
signs a 64-byte digest via circl, then submits
the triple through MLDSAVerifyBatch and asserts
results[0] == true. Cleanly SKIPs when no
plugin loaded or when the backend returns
NOT_SUPPORTED for op_mldsa_verify_batch (e.g.
plugins built without LUX_GPU_LINK_CRYPTO).
The probe is header-only: cgo CFLAGS points at
${SRCDIR}/../../../lux-private/gpu-kernels/include for the v14 vtbl
layout, but the .dylib / .so is dlopen'd at runtime - no pkg-config,
no static link, no luxcpp/install dependency. Existing quantumvm
vm.go, quantum/signer.go, and quantumvm/quasar.go are untouched;
consumers opt in explicitly when ready. Both 'go build ./quantumvm/...'
and 'CGO_ENABLED=1 go build ./quantumvm/...' are green.
Test output with LUX_GPU_PLUGIN_DIR pointing at a freshly-built
libluxgpu_backend_vulkan.dylib:
--- PASS: TestAutoBackend_Probes (0.00s) [backend=vulkan]
--- PASS: TestMLDSAVerifyBatch_RoundTrip (5.56s) [backend=vulkan,
op_mldsa_verify_batch honest verify -> true]
--- PASS: TestMLDSAVerifyBatch_LengthMismatch (0.00s)
--- PASS: TestMLDSAVerifyBatch_NonMLDSA65Skips (0.00s)
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.