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 finality. Finality is sealed by a typed compact-certificate envelope (ConsensusCert) that binds one or more cryptographic evidence legs — Beam (BLS12-381 classical aggregate), Pulsar (Module-LWE / FIPS-204 ML-DSA threshold), Corona (Ring-LWE / Ringtail threshold), and P3Q (rollup fallback) — to one canonical, domain-separated finality message under one P-Chain-pinned key-era. Quasar runs every chain in the Lux primary network -- C, X, P -- and any dynamically registered chain. See the Quasar reference for the envelope, suites, and postures.

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 reaches a leaderless decision through photonic committee selection and Wave voting, then seals it with the compact-certificate envelope (Beam ∧ Pulsar ∧ Corona under STRICT_QUASAR). 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: Compact-Certificate Finality

After the classical decision, finality is sealed by a ConsensusCert envelope. Policy declares the required cryptographic legs; certificate bytes carry the per-leg evidence; every leg proves the same weighted-quorum predicate over the same domain-separated finality message M. The chain stores one compact typed evidence per lane, never N raw per-validator signatures:

The operator selects a finality posture per chain. Each posture pins required leg kinds (committed into the cert's required-legs root) and permitted modes (in the policy allow-table):

// A block is final iff every leg REQUIRED BY POLICY verifies over the same M.
// Required legs come from policy ONLY, never from the certificate bytes.
err := quasar.VerifyConsensusCert(cert, policy, validators, M)
isFinal := err == nil

Threshold legs (Pulsar, Corona) are O(1) in committee size — one group signature under one KeyEra group key regardless of validator count. A classical-only certificate is rejected under any posture that requires a PQ leg.

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

Under the STRICT_QUASAR posture, the Beam, Pulsar, and Corona legs are all REQUIRED and verified over one canonical message M. Required legs come from policy only; the VerifyConsensusCert envelope rejects a certificate that is missing any required leg, or that offers classical evidence in place of a required PQ leg.

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

Two PQ threshold kernels — Pulsar (M-LWE) and Corona (R-LWE)

Quasar's post-quantum strength rests on two independent lattice families, each emitting one O(1) group signature. They are independent libraries with no import line between them; Quasar consumes them as parallel kernels.

Pulsar (TALUS) — github.com/luxfi/pulsar v1.2.0

• Basis: Module-LWE (ML-DSA-65, FIPS 204)
• Output: threshold signature byte-identical to a single-party FIPS-204 ML-DSA signature — verifies under an unmodified ML-DSA verifier
• Construction: dealerless Shamir nonce DKG + distributed w1 (CEF) + real CSCP secure-comparison (the W-LEAK is closed — no node forms w0/w in clear)
• Keygen profiles: Pulsar-MPC (honest-majority N ≥ 2T−1) / Pulsar-TEE
• Verification: pulsarwire.VerifyBytes

Corona (Ringtail) — github.com/luxfi/corona v0.8.0

• Basis: Ring-LWE (Ringtail; BKLMTT, ePrint 2024/1113)
• Dealerless: native Pedersen DKG over R_q + proactive resharing — carries the permissionless-public PQ guarantee (not FIPS)
• Verification: coronaThreshold.Verify(groupKey, message, signature)

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     Compact-cert envelope (Beam+Pulsar+Corona+P3Q legs)
      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 signer-set eras into compact-cert 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 PQ 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