Lux Quasar -- Post-Quantum Consensus Engine

Overview

Lux Quasar is the consensus engine for the Lux network. It is a unified, leaderless, post-quantum protocol achieving sub-second 2-round finality with triple-certificate security (BLS12-381 aggregate signatures + Pulsar lattice-based threshold signatures + ML-DSA-65 identity signatures). All three paths run in parallel via TripleSignRound1. Quasar runs every chain in the Lux primary network -- Q, C, X, P -- and any dynamically registered chain.

This is an original consensus protocol built from first principles around Photonic Selection -- not derived from earlier metastable voting schemes.

There are two code locations:

• Library (github.com/luxfi/consensus): The standalone consensus engine with protocol implementations, multi-language SDKs, and the Quasar protocol stack.
• Node integration (github.com/luxfi/node/consensus): The node-level wiring that binds Quasar to P-Chain finality events, the ZAP agentic bridge, and Pulsar coordinator lifecycle.

Quick Reference

Consensus Engines Comparison

Quasar Algorithm -- Detailed Steps

Quasar achieves triple quantum finality through parallel execution of classical and post-quantum signature paths (BLS + Pulsar + ML-DSA). The full algorithm:

Phase 0: Photonic Selection (Committee Formation)

1. Emitter selects K validators from the active set using luminance-weighted random sampling via Prism's Cut.Sample(K).
2. Luminance tracks each node's brightness (10-1000 lux). Successful votes increase brightness by 10% (cap 1000 lux). Failed votes dim by 10% (floor 10 lux). Higher lux = higher selection probability.
3. Fisher-Yates shuffle with crypto/rand ensures cryptographic uniformity in peer selection.

Phase 1: Wave Voting (Classical Confidence Building)

1. A block/vertex is proposed. Wave performs repeated sampling rounds:
   • Sample K peers via Prism Cut
   • Request votes from selected peers (transmitted as Chits on the wire)
   • Count yes/no votes
2. Threshold check: If yes votes >= alphaK (default alpha=0.69, enforced >= 0.68), register preference. If no votes >= alphaK, register rejection.
3. Confidence accumulation: Each consecutive same-preference round increments a counter. When counter >= beta (default 14 for mainnet), item is decided.
4. FPC mode (optional): Instead of fixed alpha, threshold theta is selected per-phase using a PRF over [theta_min=0.5, theta_max=0.8], making the protocol more resistant to adaptive adversaries.
5. Classical finality typically completes in 600-700ms.

Phase 2: QuasarCert Generation (Quantum Finality)

All three paths execute in parallel immediately after classical decision (via TripleSignRound1):

BLS Path (fast, classical):

1. Each validator signs the finality message (blockID + height + timestamp, 48 bytes) with their BLS12-381 key share.
2. Signature shares are aggregated into a single 96-byte aggregate signature.
3. Verification: reconstruct aggregate public key from signer bitset, verify aggregate signature.
4. Requires 2/3+ validator weight.

Pulsar Path (quantum-safe, 2-round):

1. Round 1: Each participating validator generates commitments (D matrix + MACs) using their Pulsar key share. Broadcast Round1Data to all other signers.
2. Round 2: Each validator computes partial signatures using collected Round 1 data. Broadcast Round2Data.
3. Finalize: Any validator aggregates Round 2 data into a threshold signature. Verify against the group public key.
4. Requires t-of-n threshold (typically 2/3+1).
5. Pulsar adds approximately 200-300ms for quantum finality.

ML-DSA Path (quantum-safe, identity proof):

1. Each validator signs the finality message with their ML-DSA-65 key (FIPS 204).
2. ML-DSA signatures provide per-validator post-quantum identity binding.
3. Aggregated alongside Pulsar into the PQ proof field of QuasarCert.

Block is final ONLY when all three certificates are valid:

type CertBundle struct {
    BLSAgg []byte  // 96B BLS aggregate signature
    PQCert []byte  // Aggregated Pulsar + ML-DSA proof
}

isFinal := verifyBLS(blsAgg, quorum) && verifyPQ(pqCert, quorum)

Quantum Bundle Architecture (Async PQ Anchoring)

For high-throughput scenarios, Quasar uses an async two-layer architecture:

BLS Layer:     [B1]--[B2]--[B3]--[B4]--[B5]--[B6]--[B7]--[B8]--[B9]--...
                |     500ms finality per block     |
                |_____________________________________|
                                 |
Quantum Layer:              [QB1: Merkle(B1-B6)]--------[QB2: Merkle(B7-B12)]
                                 |  3-second interval, async Pulsar signing

• BLS blocks continue at 500ms pace (unblocked).
• Every 3 seconds (QuantumCheckpointInterval), a QuantumBundle is created containing a Merkle root of ~6 BLS block hashes.
• The bundle is signed asynchronously with Pulsar threshold (0.6s online signing, 2.5s total including offline prep).
• Bundles are chained via PreviousHash for integrity.

Epoch-Based Key Rotation

• Epoch duration: 10 minutes minimum (MinEpochDuration), 1 hour maximum (MaxEpochDuration).
• Pulsar keys rotate when the validator set changes, rate-limited to at most 1 rotation per 10 minutes.
• Historical epochs are retained (default 6) for cross-epoch signature verification.
• BLS and Pulsar validator sets are kept synchronized.
• EpochManager handles key generation, rotation, and pruning.

Grouped Threshold Signing (10,000+ Validators)

For large validator sets, GroupedEpochManager splits validators into groups (default size 3):

1. Validators are assigned to groups via deterministic Fisher-Yates shuffle using epoch seed (VRF-based).
2. Each group generates its own Pulsar keys (2-of-3 threshold within group).
3. Groups sign in parallel -- constant signing time regardless of total validator count.
4. 2/3 of groups must produce valid signatures for consensus (GroupQuorum).
5. Signing time: ~243ms per group (n=3), independent of total validator count.

Finality Guarantees

All three proofs (BLS, Pulsar, ML-DSA) are REQUIRED for Q-Chain validators in triple mode. IsTripleMode() returns true when all three are configured. The Verify method enforces strict triple-proof validation.

Validator Selection and Identity

Photonic Selection

Validators are selected via Photon's luminance-weighted sampling:

Performance-based weighting: successful consensus participation increases brightness, failed/absent rounds decrease it.

Key Hierarchy

The same rt.key registered on Q-Chain is reused by all chains -- no extra onboarding.

W3C DID Identity (ZAP Bridge)

ZAP provides decentralized identity for validators via W3C DIDs:

DIDs generate full W3C DID Documents with verification methods, authentication, and ZAP agent service endpoints.

Post-Quantum Cryptography

Pulsar Threshold Signatures

• Basis: Ring-LWE (Ring Learning With Errors)
• Protocol: Native 2-round threshold signing
• Library: github.com/luxfi/corona v0.2.0
• Round 1: Generate D matrix + MACs, broadcast commitments
• Round 2: Compute partial signatures using collected Round 1 data
• Finalize: Aggregate partial signatures into threshold signature
• Verification: coronaThreshold.Verify(groupKey, message, signature)
• NTT acceleration: GPU-accelerated Number Theoretic Transform (optional, via ntt_c.go)

Verkle Witness Optimization

Quasar includes a Verkle witness system for hyper-efficient state verification:

• Uses github.com/luxfi/crypto/ipa/banderwagon for Verkle tree commitments
• IPA (Inner Product Argument) opening proofs for O(log n) verification
• When PQ finality is assumed, skip heavy BLS re-verification -- just verify Verkle commitment
• Compressed witnesses under 200 bytes for network transmission
• Batch verification for parallel witness checking

Supported PQ Signature Types

Configuration Parameters

Consensus Parameters (config.Parameters)

Alpha enforced >= 0.68 (69% BFT threshold). Validation rejects lower values.

Quasar-Specific Config

Chain Integration

Sub-Protocol Architecture

consensus/
  protocol/
    photon/         Emitter + Luminance (committee selection)
    wave/           Threshold voting engine + FPC
      fpc/          Fast Probabilistic Consensus (dynamic thresholds)
    prism/          Peer sampling (Cut interface) + DAG proposal
    ray/            Linear consensus driver (Source/Sink pattern)
    nova/           Linear chain consensus (wraps Ray)
    flare/          Certificate generation for DAG
    horizon/        Frontier management
    focus/          Confidence tracking
    nebula/         State sync protocol
    field/          Nebula field operations
    quasar/         Post-quantum finality engine
      quasar.go     Signer (BLS+Pulsar+ML-DSA triple threshold)
      core.go       Quasar core (multi-chain block aggregator)
      engine.go     Engine interface implementation
      epoch.go      Epoch-based Pulsar key management
      quantum_block.go  Async quantum bundle production
      grouped_threshold.go  Grouped signing for 10K+ validators
      bls.go        DAG event horizon with BLS commitments
      witness.go    Verkle witness for hyper-efficient verification
      types.go      Block, QuasarCert, Engine interface
      config.go     QThreshold, QuasarTimeout
      metrics.go    Prometheus metrics
  engine/
    chain/          Linear blockchain engine
    dag/            DAG consensus engine
    pq/             Post-quantum engine variant
  core/
    dag/            DAG data structures (flare, horizon)
    choices/        Decision types
  types/            Block, Vote, Certificate, Config
  config/           Parameters, presets (Mainnet, Testnet, Local, XChain)
  pkg/wire/         Wire protocol (candidate, credentials, sequencer)

node/consensus/
  acceptor.go       Acceptor callback interface
  engine/chain/     Vote message types (wire: Chits)
  quasar/           Node-level Quasar integration
    quasar.go       Binds P-Chain + Q-Chain into triple finality
    types.go        Signature interfaces, CoronaCoordinator
  zap/              ZAP agentic consensus bridge
    bridge.go       Query/Response/Vote consensus
    types.go        QueryState, FinalityProof, StakeRegistry
    did.go          W3C DID implementation (did:lux, did:key, did:web)

Key Dependencies (from go.mod)

Performance Benchmarks (Apple M1 Max)

Consensus Operations

Pulsar Signing Performance

Network Finality

Multi-Language SDKs

100% test parity across all 4 implementations. 15 comprehensive test categories.

ZAP Agentic Consensus

ZAP (Zero-copy Agent Protocol) provides consensus for AI agent operations:

Protocol Flow

1. SubmitQuery: Agent submits a query with content and DID identity.
2. SubmitResponse: Other agents provide responses with DIDs.
3. Vote: Validators vote for responses (one vote per validator, enforced by DID).
4. Consensus check: When total votes >= MinVotes and a response has >= ConsensusThreshold fraction, the query is finalized.
5. Finality proof: Signed with Quasar dual signatures (BLS + Pulsar).

ZAP Bridge Config

Stake Registry

ZAP includes a StakeRegistry interface for stake-weighted voting:

• GetStake(did) / SetStake(did, amount) / TotalStake()
• HasSufficientStake(did, minimum) / StakeWeight(did) (fraction of total)

Security Model

Adversary Model

Consensus Transport

Consensus messages are transported via ZAP (github.com/luxfi/zap), the zero-copy binary protocol. ZAP provides 17x faster serialization than JSON-RPC with zero heap allocations on the parse path.

Node-to-node connections use PQ-TLS 1.3 for transport encryption:

• ML-KEM-768 + X25519 hybrid key exchange (Go 1.26 default via crypto/tls)
• ML-DSA-65 post-quantum message authentication
• Forward secrecy via ephemeral keys
• Replay protection via session IDs
• Zero-copy semantics are preserved under TLS -- the TLS layer operates on the same buffer without additional allocations

Account-Level PQ Options

EVM (C-Chain)

• Lamport-XMSS multisig contracts
• Gas: ~300K for VERIFY_LAMPORT
• EIP-4337 Account Abstraction wrapper available

X-Chain

• LatticeOutput type with PQ public key
• Spend verifies single Pulsar signature (~1.8KB)
• CLI: lux-wallet generate --pq

Usage Examples

Library: Single-Import API

// Create chain with default config
chain := consensus.NewChain(consensus.DefaultConfig())
if err := chain.Start(ctx); err != nil {
    return err
}
defer chain.Stop()

// Add a block
block := consensus.NewBlock(id, parentID, 1, payload)
if err := chain.Add(ctx, block); err != nil {
    return err
}

Library: Quasar Engine

cfg := quasar.Config{QThreshold: 3, QuasarTimeout: 30}
engine, err := quasar.NewEngine(cfg)
if err != nil {
    return err
}
engine.Start(ctx)

// Submit blocks
engine.Submit(block)

// Listen for finalized blocks
for block := range engine.Finalized() {
    log.Printf("Finalized: height=%d cert=%v", block.Height, block.Cert.Verify(validators))
}

Node: Quasar with Triple Finality

q, err := quasar.NewQuasar(logger, threshold, quorumNum, quorumDen)
q.ConnectPChain(pChainProvider)
q.ConnectQuantumFallback(quantumSigner)
q.InitializeCorona(validatorNodeIDs)
q.Start(ctx)

// Listen for dual finality events
for finality := range q.Subscribe() {
    log.Printf("Dual finality: block=%s BLS=%dms RT=%dms",
        finality.BlockID, finality.BLSLatency.Milliseconds(), finality.CoronaLatency.Milliseconds())
}

Node: ZAP Bridge

bridge := zap.NewBridge(logger, zap.DefaultBridgeConfig())
bridge.Initialize(coronaCoordinator)
bridge.RegisterValidator(nodeID, zap.DIDFromNodeID(nodeID))
bridge.SubmitQuery(ctx, queryID, content, submitterNodeID)
bridge.SubmitResponse(ctx, queryID, responseID, responseContent, responderNodeID)
bridge.Vote(ctx, queryID, responseID, voterNodeID)

result, _ := bridge.GetResult(queryID)

Testing

# All tests
go test ./...

# With coverage
go test -cover ./...

# Benchmarks
go test -bench=. ./...

# Quasar-specific tests
go test ./protocol/quasar/...

# ZAP bridge tests
go test ./consensus/zap/...

Troubleshooting

Related Skills

• lux/lux-node.md -- Node that imports and runs Quasar
• lux/lux-p2p.md -- Networking layer for vote/chit propagation
• lux/lux-crypto.md -- BLS12-381, threshold signatures, IPA/banderwagon
• lux/lux-corona.md -- Ring-LWE post-quantum threshold signatures
• lux/lux-lattice.md -- Lattice cryptography (v7)
• lux/lux-sdk.md -- SDK for querying consensus state
• lux/lux-warp.md -- Cross-chain messaging