Quantum Bridge & Lab Mode (PQC)
Relevant source files
The following files were used as context for generating this wiki page:
The Quantum Bridge is a governed hybrid execution platform that facilitates classical-quantum orchestration. It routes computational tasks through a 13-step pipeline involving normalization, policy authorization via ARGUS, and execution via various quantum backends including PennyLane and Qiskit. The system operates in Lab Mode to provide prototype Post-Quantum Cryptography (PQC) attestations, ensuring cryptographic integrity for ledger blocks and agent sessions using advanced lattice-based algorithms.
Sources: src/lib/quantum/orchestrator.ts:1-12, server.ts:446-460, scripts/quantum/isabella_quantum_bridge.py:1-5
System Architecture
The Quantum Bridge architecture coordinates multiple federations to ensure secure and auditable execution. It integrates identity management, policy enforcement, and hardware security modules (HSM) into a unified flow.
The diagram shows the 13-step governed pipeline from initial user request to final ledger replication.
Sources: src/lib/quantum/orchestrator.ts:6-12, src/lib/quantum/orchestrator.ts:45-160
Quantum Bridge Execution Pipeline
The orchestrator manages the lifecycle of a quantum request. It enforces strict data contracts and performs cryptographic validation at every stage.
1. Request Normalization & Validation
The system validates incoming requests against the QuantumRequestSchema or QuantumBridgeRequestSchema. It checks parameters like wire counts, shot limits, and provider-specific scopes.
Sources: src/lib/quantum/contracts.ts:25-42, src/lib/quantum-bridge.server.ts:12-21
2. ARGUS Policy Evaluation
The policy engine evaluates if the principal has the necessary permissions. It enforces rules such as:
- Tenant Isolation: Verifies the principal's
tenantIdmatches the request. - Scope Checks: Ensures
quantum:executeor specific provider scopes (e.g.,quantum:qiskit) are present. - Resource Caps: Caps wires (e.g., max 16 for
lightning.qubit) and shots (max 100,000).
Sources: src/lib/quantum/orchestrator.ts:74-95, src/lib/quantum-bridge.server.ts:29-39
3. Execution & Fallback
Tasks are executed via a Python-based bridge script. If the bridge fails or Python is unavailable, the system invokes a Classical Fallback mechanism to provide a deterministic estimate rather than returning a raw error.
Sources: src/lib/quantum-bridge.server.ts:114-125, scripts/quantum/isabella_quantum_bridge.py:73-77
Lab Mode & Post-Quantum Cryptography (PQC)
When FEATURE_LAB_MODE is set to true, the system enables prototype PQC attestations. This mode is used for testing cryptographic resistance against future quantum threats.
PQC Algorithms
The system utilizes the CRYSTALS-LATAMV profile for cryptographic operations:
| Category | Algorithm | Purpose |
|---|---|---|
| Key Encapsulation | ML-KEM-768 | Secure key exchange |
| Signature (Lattice) | ML-DSA-87 | Primary digital signature |
| Signature (Hash) | SLH-DSA-128s | Long-term signature preservation |
| Sources: server.ts:468-472, src/lib/postQuantumCrypto.ts:16-30 |
LITLE-32 Gates Attestation
Lab Mode includes the evaluateLitle32Gates function, which simulates a 32-gate quantum attestation matrix. This matrix provides high-fidelity logical verification (fidelity > 0.999) for signed blocks.
Sources: src/lib/postQuantumCrypto.ts:122-144
This sequence illustrates the PQC lease attestation process used in agent sessions.
Sources: server.ts:479-495
Device Registry
The system maintains a registry of available quantum providers, categorized by trust levels and capabilities.
| Provider | Implementation | Mode | Trust Level |
|---|---|---|---|
default.qubit | PENNYLANE_SIMULATOR | Analytic | local |
lightning.qubit | PENNYLANE_LIGHTNING | Sampled | remote-simulator |
qiskit.aer | PENNYLANE_QISKIT_AER | Sampled | remote-simulator |
| Sources: src/lib/quantum/contracts.ts:85-101, scripts/quantum/isabella_quantum_bridge.py:20-25 |
BookPI Quantum Ledger
Every successful execution is committed to the BookPI Quantum Chain. This is an append-only audit log where each block is linked via content hashes.
- Integrity Check: The
verifyChainIntegrityfunction performs O(1) incremental verification by checking blocks since the last checkpoint. - PQC Dual Signing: Blocks are signed using both ML-DSA and SLH-DSA signatures to ensure long-term immutability.
Sources: src/lib/quantum/bookpi-quantum.ts:1-20, src/lib/quantum/bookpi-quantum.ts:158-170, src/lib/quantum/bookpi-quantum.ts:210-222
// Example of a BookPI Quantum Block structure
export interface BookPIBlock {
version: "bookpi-quantum-v1";
blockHash: string; // sha256(prevHash + blockData)
previousHash: string;
requestId: string;
circuitHash: string;
status: "completed" | "degraded" | "rejected" | "failed";
signerKeyId: string;
teeVerified: boolean;
createdAt: string;
}
Sources: src/lib/quantum/contracts.ts:58-71
The Quantum Bridge and Lab Mode ensure that all AI-driven quantum tasks are auditable, restricted by safety policies, and protected by future-resistant cryptographic standards. All Lab Mode PQC features are strictly labeled as PROTOTYPE and are not intended for production-grade security guarantees without hardware attestation.
Sources: server.ts:463-467, src/lib/isabella-quantum.ts:140-146