LP-4099: Q-Chain – Root PQC with Quasar Consensus Protocol Family

Abstract

This LP introduces Q-Chain and the Quasar consensus protocol family, Lux Network's quantum-secure blockchain that serves as the platform management chain in Lux 2.0, replacing P-Chain from Lux 1.0. Q-Chain achieves both fast classical consensus and post-quantum finality via an integrated hybrid consensus framework. Beyond quantum security, Q-Chain manages validator coordination, staking operations, chain creation, and network governance. It supports linear and DAG-based transaction processing through multiple consensus engines, and provides dual-certificate finality combining BLS-based classical finalization and Ringtail-based quantum-resistant threshold signatures. The protocol achieves sub-second finality while maintaining security against both classical and quantum adversaries.

Motivation

Blockchain networks face an impending quantum threat that could undermine current cryptographic foundations:

Quantum Computing Threat: Shor's algorithm can break elliptic curve cryptography, threatening all current blockchain signatures
Performance Requirements: Post-quantum cryptography must not sacrifice the sub-second finality users expect
Transition Complexity: Networks need smooth migration paths from classical to quantum-safe cryptography
Unified Framework: Multiple consensus variants (linear chains, DAGs) need consistent quantum protection

Q-Chain addresses these challenges by providing a modular, high-performance consensus stack with built-in quantum resistance.

Post-Quantum Chains (PQC) – General

A Post-Quantum Chain (PQC) is any chain in the Lux ecosystem that:

Runs the Lux PQ consensus (post-quantum BFT),
Has a validator set backed by stake in LUX or a chain whose security_token ultimately resolves to LUX,
Can accept checkpoint transactions from downstream chains,
Can emit checkpoints to an upstream PQC (often Q-Chain).

Properties

High-security: PQC consensus uses post-quantum signatures (e.g. lattice/hash-based), with crypto-agility to allow future upgrades.
Configurable throughput: A PQC can be low-throughput (like Q-Chain) or medium-throughput (e.g. a regional PQC) depending on its role.
Recursive: A PQC itself may be a "parent" to:
- classical LSCs / L2s that use its stateRoot as their finality anchor,
- or even to other PQCs (if you want multi-layer PQ trees).

Requirements

In RFC language:

A PQC MUST:

Run LuxPQConsensus (parametrized PBFT-like protocol with PQ signatures).
Accept Checkpoint(tx) messages from authorized child chains.
Produce Checkpoint(tx) messages to its parent PQC or to Q-Chain.

A PQC MAY:

Run application logic (EVM/WASM/etc.).
Maintain its own QSF-like fee market for its children, denominated in its own security_token, as long as it ultimately settles to LUX when checkpointing to Q-Chain.

Q-Chain – Root PQC

Q-Chain is the distinguished root Post-Quantum Chain of the Lux ecosystem. It is a high-security, low-throughput PQC that:

Is validated by LUX-staked validators registered on P-Chain,
Stores checkpoints from all chains and from other PQCs,
Implements the global Quantum Security Fee (QSF) fee market in LUX on a per-byte basis,
Acts as the canonical root of finality from which all other PQCs and Liquidity-Secured Chains derive their long-term safety.

Checkpoint Inclusion Mechanism

The checkpoint inclusion mechanism is cryptographically sound and builds on Lux's post-quantum consensus and signing infrastructure:

1. Merkle Mountain Ranges (MMR) for Efficient Proofs

Each child chain (LSC, L2, or PQC) maintains a Merkle Mountain Range of its block headers:

type ChainMMR struct {
    peaks       []Hash          // Current MMR peaks
    height      uint64         // Current height
    chainID     ChainID        // Source chain identifier
    lastCheckpoint uint64       // Last checkpointed height
}

func (mmr *ChainMMR) AddBlock(header BlockHeader) {
    // Add block to MMR, update peaks
    mmr.peaks = mmr.updatePeaks(header.Hash())
    mmr.height++
}

func (mmr *ChainMMR) GenerateProof(targetHeight uint64) *MMRProof {
    // Generate inclusion proof for specific height
    return generateMMRProof(mmr.peaks, targetHeight)
}

2. Post-Quantum Signed Checkpoints

Checkpoints are signed using the existing Lux PQ consensus infrastructure:

type Checkpoint struct {
    ChainID        ChainID        // Source chain ID
    StartHeight    uint64         // First block in this checkpoint
    EndHeight      uint64         // Last block in this checkpoint
    StartRoot      Hash           // MMR root at StartHeight-1
    EndRoot        Hash           // MMR root at EndHeight
    BlockCount     uint64         // Number of blocks included
    StateRoot      Hash           // Final state root
    Proof         *MMRProof      // MMR inclusion proof
    QSFFee        uint64         // Quantum Security Fee paid
    ValidatorSet   ValidatorSetID // Validator set ID
}

type SignedCheckpoint struct {
    Checkpoint     Checkpoint
    BLSsig         []byte         // Classical BLS aggregate signature
    RingtailSig    []byte         // Post-quantum threshold signature
    SignerBitmap   []byte         // Bitmap of signing validators
}

3. Dual-Signature Verification

Q-Chain validates checkpoints using both classical and post-quantum signatures:

func (q *QuasarConsensus) VerifyCheckpoint(signed *SignedCheckpoint) bool {
    // 1. Verify MMR proof structure
    if !verifyMMRProof(signed.Checkpoint.Proof, signed.Checkpoint.StartRoot, 
                      signed.Checkpoint.EndRoot, signed.Checkpoint.BlockCount) {
        return false
    }
    
    // 2. Verify classical BLS signature
    if !q.blsAgg.Verify(signed.Checkpoint.Hash(), signed.BLSsig) {
        return false
    }
    
    // 3. Verify post-quantum Ringtail signature
    if !q.ringtail.Verify(signed.Checkpoint.Hash(), signed.RingtailSig) {
        return false
    }
    
    // 4. Verify validator set matches current epoch
    currentSet := q.getCurrentValidatorSet()
    if !currentSet.Matches(signed.ValidatorSet) {
        return false
    }
    
    // 5. Verify QSF fee payment
    if !q.verifyQSFPayment(signed.Checkpoint.QSFFee, signed.Checkpoint.BlockCount) {
        return false
    }
    
    return true
}

4. Verkle Tree Integration for State Proofs

For chains that need state verification (not just block inclusion):

type StateProof struct {
    StateRoot     Hash           // Root of state trie
    Key           []byte         // Key being proven
    Value         []byte         // Value at key
    Proof         []byte         // Verkle proof
    BlockHeight   uint64         // Block height for this state
}

func (q *QuasarConsensus) VerifyStateProof(proof *StateProof, checkpoint *Checkpoint) bool {
    // Verify state proof against checkpoint's state root
    return q.verkleTree.Verify(proof.StateRoot, proof.Key, proof.Value, proof.Proof)
}

5. Checkpoint Processing Flow

1. Child chain produces blocks and updates its MMR
2. At checkpoint interval (e.g., every 100 blocks):
   - Generate MMR proof from last checkpoint to current height
   - Create Checkpoint struct with metadata
   - Sign with dual BLS+Ringtail signatures
3. Submit SignedCheckpoint to Q-Chain (or parent PQC)
4. Q-Chain validates:
   - Cryptographic proofs (MMR + signatures)
   - Validator set authorization
   - QSF fee payment
5. If valid, Q-Chain includes checkpoint in next block
6. Q-Chain updates its global state with new chain head

6. Security Properties

Post-Quantum Security: All signatures use Lux's dual BLS+Ringtail scheme
Efficient Proofs: MMR provides O(log n) proofs for arbitrary block ranges
State Verifiability: Optional Verkle proofs for state transitions
Economic Security: QSF fees paid in LUX provide Sybil resistance
Validator Accountability: Signer bitmaps enable slashing for misbehavior
Crypto-Agility: Signature schemes can be upgraded via governance

7. Performance Characteristics

Proof Size: ~1-2 KB per checkpoint (MMR + signatures)
Verification Time: ~5-10ms on modern hardware
Checkpoint Frequency: Configurable per chain (e.g., every 10-1000 blocks)
Throughput: Q-Chain can process 1000+ checkpoints/second
Storage: MMR peaks allow pruning of old block data

This mechanism ensures that Q-Chain can securely and efficiently include proofs of other networks' blocks while maintaining the full post-quantum security guarantees of the Lux consensus protocol.

The Quasar Consensus Stack

Quasar is Lux Network's completely rewritten consensus protocol family, designed from scratch with quantum security, verkle trees, witness support, and FPC (Fast Path Consensus) similar to Sui:

1. Photon – Sampling-Based Consensus

The foundation layer using network sampling for agreement:

type PhotonConsensus struct {
    // Binary consensus on a single bit
    Preference    bool
    Confidence    int
    K             int    // Sample size
    Alpha         int    // Quorum threshold
    Beta          int    // Confidence threshold
}

func (p *PhotonConsensus) Query(validators []Validator) bool {
    sample := randomSample(validators, p.K)
    votes := queryPreference(sample)
    
    if votes >= p.Alpha {
        p.Confidence++
        if p.Confidence >= p.Beta {
            return true // Finalized
        }
    } else {
        p.Confidence = 0
    }
    return false
}

2. Wave – Thresholding Consensus

Fast finality through adaptive thresholding:

type WaveConsensus struct {
    Preferences  map[ID]int    // Choice -> confidence
    K, Alpha     int
    Beta         int
}

func (w *WaveConsensus) Query(validators []Validator, choices []ID) ID {
    sample := randomSample(validators, w.K)
    votes := queryPreferences(sample, choices)
    
    for choice, count := range votes {
        if count >= w.Alpha {
            w.Preferences[choice]++
            if w.Preferences[choice] >= w.Beta {
                return choice // Finalized
            }
        }
    }
    return nil
}

3. Nova – DAG Finalizer

Finalizes transactions in DAG structures:

type NovaConsensus struct {
    dag         *DAG
    conflicts   map[ID][]ID
    finalizer   *VerkleTree  // Verkle tree for efficient proofs
}

func (n *NovaConsensus) FinalizeVertex(v Vertex) bool {
    // Use verkle proofs for efficient validation
    proof := n.finalizer.GenerateWitness(v)
    
    if n.validateWithWitness(v, proof) {
        n.dag.Finalize(v)
        return true
    }
    return false
}

4. Nebula – DAG Consensus

Full DAG consensus with parallel processing:

type NebulaEngine struct {
    dag         *DAG
    verkle      *VerkleTree
    witness     *WitnessCache
}

func (n *NebulaEngine) ProcessTransaction(tx Transaction) {
    // Fast path with witness validation
    witness := n.witness.Get(tx.ID)
    
    if n.verkle.ValidateWithWitness(tx, witness) {
        n.dag.AddVertex(tx)
        n.broadcast(tx)
    }
}

5. Prism – Voting-Based Consensus

Direct voting mechanism for governance:

type PrismEngine struct {
    proposals   map[ID]*Proposal
    votes       map[ID]map[NodeID]Vote
    threshold   float64  // e.g., 0.75 for 75% approval
}

func (p *PrismEngine) ProcessVote(vote Vote) {
    p.votes[vote.ProposalID][vote.NodeID] = vote
    
    if p.calculateSupport(vote.ProposalID) >= p.threshold {
        p.executeProposal(vote.ProposalID)
    }
}

6. Quasar – Quantum-Secure Overlay

The pinnacle layer adding dual-certificate finality:

type QuasarConsensus struct {
    engine      ConsensusEngine  // Beam or Nova
    blsAgg      *BLSAggregator
    ringtail    *RingtailThreshold
    timeout     time.Duration
}

type DualCertificate struct {
    BLSCert     []byte  // Classical BLS aggregate
    RingtailCert []byte  // Post-quantum threshold sig
}

func (q *QuasarConsensus) Finalize(block Block) (*DualCertificate, error) {
    // Parallel certificate collection
    ch1 := make(chan []byte)
    ch2 := make(chan []byte)
    
    go q.collectBLS(block, ch1)
    go q.collectRingtail(block, ch2)
    
    select {
    case <-time.After(q.timeout):
        return nil, ErrTimeout
    case blsCert := <-ch1:
        rtCert := <-ch2
        return &DualCertificate{blsCert, rtCert}, nil
    }
}

Platform Management Capabilities

As the successor to P-Chain in Lux 2.0, Q-Chain handles all platform management responsibilities with quantum-secure guarantees:

Validator Management

type ValidatorTx struct {
    NodeID          string
    StakeAmount     uint64
    StartTime       time.Time
    EndTime         time.Time
    DelegationFee   uint32
    RewardAddress   Address
    ProofOfStake    DualSignature  // BLS + Ringtail
}

Staking Operations

Minimum Stake: 2,000 LUX
Delegation: Support for delegated staking with customizable fees
Rewards: Automatic distribution with quantum-secure signatures
Slashing: Quantum-resistant penalty mechanisms

chain Creation and Management

type CreateChainTx struct {
    Owners          []Address
    Threshold       uint32
    ControlKeys     []PublicKey
    chainAuth      DualCertificate
    VMType          string  // "EVM", "WASM", "Custom"
}

Governance Functions

Proposal Submission: Quantum-signed governance proposals
Voting: Weighted by stake with dual-certificate validation
Parameter Updates: Network-wide configuration changes
Chain Registration: New chain deployment and management

Core Innovation: Dual-Certificate Finality

The Dual-Certificate Mechanism

Q-Chain requires two cryptographic certificates for block finality:

BLS Aggregated Signature (Classical)
- BLS12-381 curve with 128-bit classical security
- Aggregatable signatures for efficiency
- Compatible with existing infrastructure
Ringtail Threshold Signature (Post-Quantum)
- Lattice-based (LWE) with 128-bit post-quantum security
- Threshold scheme: no single validator holds full key
- Two-round protocol for efficiency

// Block is final IFF both certificates are valid
func IsBlockFinal(block Block, cert DualCertificate) bool {
    return verifyBLS(cert.BLSCert, block) && 
           verifyRingtail(cert.RingtailCert, block)
}

Security Analysis

The dual-certificate design provides defense in depth:

Attack Scenario	BLS Certificate	Ringtail Certificate	Result
Classical Attacker	Secure (128-bit)	Secure (harder)	✅ Block Safe
Quantum Attacker	Vulnerable	Secure (128-bit PQ)	✅ Block Safe
Implementation Bug in BLS	Compromised	Secure	✅ Block Safe
Implementation Bug in Ringtail	Secure	Compromised	✅ Block Safe
Both Systems Compromised	Compromised	Compromised	❌ Block Unsafe

Quantum Attack Window

Q-Chain's rapid finality creates an impossibly narrow attack window:

Timeline:
T+0ms:   Block proposed
T+50ms:  Ringtail timeout (mainnet)
T+295ms: BLS aggregation complete
T+350ms: Block finalized

Attack Window: < 50ms

Even with a large-scale quantum computer, breaking BLS12-381 would require:

~2,330 logical qubits
Billions of sequential operations
Far more than 50ms of computation time

System Architecture

Directory Structure

/quasar/
├── choices/          # Consensus decision states
├── consensus/        # Core algorithms
│   ├── beam/         # Linear chain consensus
│   └── nova/         # DAG consensus
├── crypto/           # Cryptographic primitives
│   ├── bls/          # BLS12-381 operations
│   └── ringtail/     # Post-quantum threshold
├── engine/           # Consensus engines
│   ├── common/       # Shared code
│   ├── beam/         # Beam engine
│   └── nova/         # Nova engine
├── networking/       # P2P layer
│   ├── handler/      # Message handlers
│   ├── router/       # Chain routing
│   └── sender/       # Outbound messages
├── validators/       # Validator management
└── uptime/           # Liveness tracking

Key Components

Consensus Engines

type Engine interface {
    // Core consensus operations
    Initialize(validators []Validator) error
    ProposeBlock(txs []Transaction) (*Block, error)
    ValidateBlock(block Block) error
    
    // Quasar integration
    StartCertificateCollection(block Block) error
    GetDualCertificate() (*DualCertificate, error)
    
    // Networking
    HandleMessage(peer ID, msg Message) error
    Gossip() []Message
}

Cryptographic Layer

// BLS Operations
type BLSAggregator struct {
    threshold   int
    validators  map[ID]PublicKey
    signatures  map[ID]Signature
}

func (b *BLSAggregator) Aggregate() ([]byte, error) {
    if len(b.signatures) < b.threshold {
        return nil, ErrInsufficientSignatures
    }
    
    // Pairing-based aggregation
    agg := bls.AggregateSignatures(b.signatures)
    return agg.Marshal()
}

// Ringtail Operations  
type RingtailThreshold struct {
    threshold   int
    shares      map[ID]Share
    publicKey   PublicKey
}

func (r *RingtailThreshold) Combine() ([]byte, error) {
    if len(r.shares) < r.threshold {
        return nil, ErrInsufficientShares
    }
    
    // Lattice-based combination
    sig := ringtail.CombineShares(r.shares, r.threshold)
    return sig.Marshal()
}

Consensus Flow

1. Transaction Submission

func (q *QChain) SubmitTransaction(tx Transaction) error {
    // Validate transaction
    if err := q.validateTx(tx); err != nil {
        return err
    }
    
    // Add to mempool
    q.mempool.Add(tx)
    
    // Gossip to peers
    q.network.Broadcast(&TxMessage{tx})
    
    return nil
}

2. Block Proposal

func (q *QChain) ProposeBlock() (*Block, error) {
    if !q.isMyTurn() {
        return nil, ErrNotProposer
    }
    
    // Gather transactions
    txs := q.mempool.GetBatch(q.maxBlockSize)
    
    // Create block
    block := &Block{
        Height:       q.currentHeight + 1,
        Timestamp:    time.Now(),
        Transactions: txs,
        ProposerID:   q.myID,
    }
    
    // Sign with BLS
    block.ProposerSig = q.blsSign(block.Hash())
    
    // Create Ringtail share
    block.ProposerShare = q.ringtailShare(block.Hash())
    
    // Broadcast proposal
    q.network.Broadcast(&BlockProposal{block})
    
    return block, nil
}

func (q *QChain) CollectShares(block Block) error {
    deadline := time.Now().Add(q.timeout)
    
    for time.Now().Before(deadline) {
        select {
        case share := <-q.shareChannel:
            if q.validateShare(share, block) {
                q.ringtail.AddShare(share)
                
                if q.ringtail.HasThreshold() {
                    return nil
                }
            }
        case <-time.After(time.Millisecond):
            // Continue collecting
        }
    }
    
    return ErrTimeout
}

4. Certificate Aggregation

func (q *QChain) AggregateCertificates(block Block) (*DualCertificate, error) {
    var wg sync.WaitGroup
    var blsCert, rtCert []byte
    var blsErr, rtErr error
    
    // Parallel aggregation
    wg.Add(2)
    
    go func() {
        defer wg.Done()
        blsCert, blsErr = q.blsAgg.Aggregate()
    }()
    
    go func() {
        defer wg.Done()
        rtCert, rtErr = q.ringtail.Combine()
    }()
    
    wg.Wait()
    
    if blsErr != nil || rtErr != nil {
        return nil, ErrAggregationFailed
    }
    
    return &DualCertificate{
        BLSCert:      blsCert,
        RingtailCert: rtCert,
    }, nil
}

5. Consensus Voting

func (q *QChain) VoteOnBlock(block Block, cert DualCertificate) error {
    // Verify dual certificates
    if !q.verifyDualCert(block, cert) {
        return q.voteNo(block)
    }
    
    // Lux-style voting
    for round := 0; round < q.maxRounds; round++ {
        sample := q.randomSample(q.K)
        votes := q.queryVotes(sample, block)
        
        if votes.Yes >= q.AlphaPreference {
            q.preference = block
            q.confidence++
            
            if q.confidence >= q.Beta {
                return q.finalizeBlock(block)
            }
        } else {
            q.confidence = 0
        }
    }
    
    return ErrNoConsensus
}

6. Finalization

func (q *QChain) FinalizeBlock(block Block) error {
    // Update state
    if err := q.state.Apply(block); err != nil {
        return err
    }
    
    // Store certificates
    q.storage.StoreCertificates(block.Height, block.DualCert)
    
    // Update chain tip
    q.currentHeight = block.Height
    q.lastFinalized = block.Hash()
    
    // Notify applications
    q.notifyFinalization(block)
    
    // Log achievement
    q.logger.Info("Quantum-secure finality achieved ✓", 
        "height", block.Height,
        "latency", time.Since(block.Timestamp))
    
    return nil
}

Performance Characteristics

Mainnet Configuration (21 validators)

var MainnetParams = Parameters{
    // Consensus parameters
    K:                21,
    AlphaPreference:  13,
    AlphaConfidence:  18,
    Beta:             8,
    
    // Quasar parameters
    QThreshold:       15,  // 15 of 21 for Ringtail
    QuasarTimeout:    50 * time.Millisecond,
    
    // Performance targets
    BlockTime:        500 * time.Millisecond,
    FinalityTarget:   350 * time.Millisecond,
}

Performance Metrics

Metric	Value	Description
Block Time	~500ms	New block every 0.5 seconds
Finality Latency	<350ms	Dual-cert finality achieved
BLS Aggregation	~295ms	Time to collect classical sigs
Ringtail Aggregation	~7ms	Time to combine PQ shares
Network Overhead	~50ms	Propagation and processing
Certificate Size	~2.9KB	Combined BLS + Ringtail

Latency Breakdown

Block Proposal
     │
     ├─► BLS Collection ────────────────► 295ms
     │     │
     │     ├─► Network RTT (~200ms)
     │     └─► Aggregation (~95ms)
     │
     └─► Ringtail Collection ──► 50ms
           │
           ├─► Share Collection (~48ms)
           └─► Combination (~7ms)
                                          ______
                              Total: ~350ms

Security Considerations

Byzantine Fault Tolerance

Q-Chain maintains safety under standard Byzantine assumptions:

type SecurityParams struct {
    TotalValidators   int     // n
    ByzantineLimit    int     // f < n/3
    HonestMajority    int     // h > 2n/3
    
    // Lux specific
    SafetyProbability float64 // 1 - ε where ε ≈ 10^-10
}

Post-Quantum Security

Ringtail provides security based on lattice problems:

Parameter	Value	Security Level
Lattice Dimension	1024	128-bit PQ
Ring Modulus	2^32 - 5	Standard
Error Distribution	Gaussian σ=3.2	LWE-hard
Share Size	~1KB	Efficient

Slashing Conditions

enum SlashingReason {
    DOUBLE_SIGN,           // Signed conflicting blocks
    MISSING_PQ_CERT,       // Failed to provide Ringtail
    INVALID_SIGNATURE,     // Provided invalid sig
    DOWNTIME,             // Extended offline period
}

function slash(validator address, reason SlashingReason) {
    uint256 penalty = calculatePenalty(reason);
    
    // Burn portion of stake
    stakes[validator] -= penalty;
    
    // Emit event for transparency
    emit ValidatorSlashed(validator, reason, penalty);
}

Network Deployment

Multi-Chain Architecture

Q-Chain can secure multiple blockchains simultaneously:

type ChainManager struct {
    chains map[ChainID]*QuasarInstance
}

func (cm *ChainManager) LaunchChain(config ChainConfig) error {
    var engine ConsensusEngine
    
    switch config.Type {
    case LINEAR:
        engine = NewBeamEngine(config)
    case DAG:
        engine = NewNovaEngine(config)
    }
    
    quasar := &QuasarInstance{
        engine:    engine,
        params:    config.ConsensusParams,
        crypto:    NewDualCrypto(config),
    }
    
    cm.chains[config.ChainID] = quasar
    return quasar.Start()
}

Configuration Examples

High-Security Financial Chain

FinancialChainParams = Parameters{
    K:               30,   // Larger sample
    AlphaPreference: 20,   // Higher threshold  
    Beta:            12,   // More confirmations
    QThreshold:      20,   // 20 of 30
    QuasarTimeout:   30 * time.Millisecond,  // Tighter deadline
}

High-Throughput Gaming Chain

GamingChainParams = Parameters{
    K:               15,   // Smaller sample
    AlphaPreference: 9,    // Lower threshold
    Beta:            5,    // Fewer confirmations
    QThreshold:      11,   // 11 of 15
    QuasarTimeout:   100 * time.Millisecond, // Relaxed deadline
}

Future Enhancements

1. Dynamic Validator Sets

Hot-swapping validators without downtime
Rapid DKG for new Ringtail keys
Forward-secure key evolution

2. Cross-Chain Atomic Operations

Leverage dual-cert finality for atomic swaps
Quantum-safe hash time-locked contracts
Inter-chain certificate validation

3. Light Client Support

Succinct dual-certificate proofs
Post-quantum Merkle trees
Mobile-friendly verification

4. Hardware Integration

HSM support for key protection
Hardware-accelerated lattice operations
TEE integration for share generation

5. Advanced Consensus Features

Adaptive parameters based on network conditions
Machine learning for optimal sampling
Parallel certificate aggregation

Implementation Guidelines

Running a Q-Chain Node

# Launch with Quasar enabled
luxd --chain-id=q-chain --quasar-enabled --config=mainnet.json

# Monitor consensus
tail -f ~/.luxd/logs/q-chain/quasar.log

# Example log output
[QUASAR] Starting round height=1000
[QUASAR] Block proposed by validator-5
[QUASAR] BLS signatures: 21/21 collected
[QUASAR] RT shares collected (15/21) @latency=48ms
[QUASAR] Aggregated cert size=2.9KB
[CONSENSUS] Block 1000 dual-cert finalized latency=302ms
[QUASAR] Quantum-secure finality achieved ✓

Developer Integration

// Connect to Q-Chain
client, err := qchain.NewClient("https://api.q-chain.lux.network")

// Submit transaction
tx := &Transaction{
    From:   myAddress,
    To:     recipientAddress,
    Amount: 100 * units.LUX,
}

receipt, err := client.SendTransaction(tx)

// Wait for quantum-secure finality
confirmed, err := client.WaitForFinality(receipt.TxHash)

Conclusion

Q-Chain and the Quasar protocol family represent a significant advancement in blockchain consensus design. By combining the speed and scalability of Lux-style metastable consensus with both classical and post-quantum cryptography, Lux Network achieves:

Sub-second finality with dual-certificate security
Quantum resistance without sacrificing performance
Modular architecture supporting various blockchain types
Smooth transition from classical to post-quantum era

The dual-certificate mechanism ensures that Q-Chain remains secure against both current and future threats, while the narrow attack window makes real-time quantum attacks physically impossible. This positions Lux Network at the forefront of blockchain security for the next generation of decentralized applications.

References

Lux Network Team, "Quasar: A Quantum-Resistant Consensus Protocol Family with Verkle Trees and FPC"
NTT Research, "Ringtail: World's first two-round post-quantum threshold signature scheme"
Boneh et al., "BLS Signatures: Short Signatures from the Weil Pairing"
Shor, P.W., "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer"
NIST Post-Quantum Cryptography Standardization
LP-4: Quantum-Resistant Cryptography Integration
LP-5: Quantum-Safe Wallets and Multisig
Sui Network, "Fast Path Consensus for Low-Latency Blockchain Finality"
Verkle Trees, "Efficient State Proofs for Blockchain Systems"

Test Cases

Unit Tests

Cryptographic Primitives
- Test key generation
- Verify signature creation
- Test signature verification
Post-Quantum Security
- Verify NIST compliance
- Test parameter validation
- Validate security levels
Performance Benchmarks
- Measure key generation time
- Benchmark signing operations
- Test verification throughput

Integration Tests

Hybrid Signature Schemes
- Test classical-PQ combinations
- Verify fallback mechanisms
- Test key rotation
Network Integration
- Test consensus with PQ signatures
- Verify cross-chain compatibility
- Test upgrade transitions

Copyright

Specification

Normative definitions (APIs, data types, and constants) in this LP MUST be implemented as described to ensure compatibility.

Rationale

Design decisions aim for operational simplicity and robust security while meeting Lux performance targets.

Backwards Compatibility

This LP is additive and does not break existing interfaces. Migration can be performed incrementally as needed.

Q-Chain – Root PQC with Quasar Consensus Protocol Family