Files
chains/quantumvm
zeekay 813e45e234 quantumvm: wire GPU plugin substrate via ABI v14 vtbl dlopen+dlsym
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)
2026-06-05 14:59:54 -07:00
..

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

  1. VM (vm.go): Main virtual machine implementation
  2. Factory (factory.go): VM factory for creating QVM instances
  3. Config (config/config.go): Configuration management
  4. Quantum Signer (quantum/signer.go): Quantum signature implementation

Transaction Flow

  1. Transactions are submitted to the transaction pool
  2. Worker threads process transactions in parallel batches
  3. Quantum signatures are verified using the quantum signer
  4. Valid transactions are included in blocks
  5. Blocks are signed with quantum stamps

RPC API

The QVM exposes the following RPC endpoints:

  • qvm.getBlock: Retrieve a block by ID
  • qvm.generateRingtailKey: Generate a new Ringtail key pair
  • qvm.verifyQuantumSignature: Verify a quantum signature
  • qvm.getPendingTransactions: Get pending transactions
  • qvm.getHealth: Get VM health status
  • qvm.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: MLDSAValidatorKey in quantum/signer.go (kept exposed via the legacy GenerateRingtailKey RPC 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 in luxfi/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.