# Quantus ↔ Ethereum ↔ Solana Bridge Roadmap (Plonky3-Only) ## Introduction This document outlines the roadmap for a trust-minimized bridge between Ethereum (ERC-20), Solana (SPL), and Quantus (Substrate PoW, PQ). The design uses **Plonky3** exclusively, leveraging its transparent setup, recursion, and alignment with a post-quantum security narrative. Groth16 and other SNARKs are not in scope. --- ## Phase 0 — Trusted MVP - **Mechanism:** Multisig/MPC validators. - **Ethereum side:** `TokenVault` escrows ERC-20. - **Solana side:** `TokenVault` program escrows SPL. - **Quantus side:** `pallet-bridge-core` + `pallet-assets`. - **Relayers:** Submit signed events cross-chain. - **Security:** Economic trust in validator set, strict rate limits, circuit breaker. - **Goal:** Enable ERC-20 ↔ Quantus and SPL ↔ Quantus transfers quickly. --- ## Phase 1 — Plonky3 Light Client (Quantus → Ethereum & Solana) - **Circuit:** Proves Quantus headers are valid descendants of a known checkpoint. - **Consensus checks enforced:** - Proof-of-Work validity (`hash(header) < target`). - Difficulty adjustment algorithm correctness. - Timestamp bounds. - **Public inputs:** Checkpoint hash, final header hash, cumulative work. - **Formula:** ``` W = Σ floor(2^256 / (target_i + 1)) ``` - **Bridge logic:** Ethereum contract and Solana program both accept Plonky3 proofs of Quantus headers. - **Message inclusion:** Outbound burns proven by Merkle proofs anchored in Quantus headers. --- ## Phase 2 — Ethereum & Solana → Quantus zk Verification - **Ethereum side:** Plonky3 circuit verifies Ethereum finalized headers + Merkle Patricia proofs of events. - **Solana side:** Plonky3 circuit verifies Solana finalized block headers + Merkle proofs of account state/events. - **Quantus runtime:** - `pallet-eth-lightclient` accepts Ethereum proofs. - `pallet-sol-lightclient` accepts Solana proofs. - **Result:** Bidirectional zk verification with both Ethereum and Solana. - **Fallback:** Validator signatures retained for liveness. --- ## Phase 3 — Recursive Batching + Efficiency - **Recursive composition:** Aggregate large ranges of Quantus, Ethereum, and Solana header proofs into succinct proofs. - **Anchoring cadence:** Post these aggregate proofs periodically on Ethereum and Solana. - **Gas/compute savings:** Lower on-chain costs; easier management of cross-chain commitments. - **Unified relayers:** One relayer stack can submit recursive proofs to both Ethereum and Solana. --- ## Phase 4 — Full Trustless Production - **Canonical selection:** Only proofs extending the last accepted checkpoint are valid. - **Fork handling:** - For Quantus (PoW): heaviest chain via cumulative work. - For Ethereum (finality): rely on finalized headers. - For Solana: rely on confirmed supermajority finalization. - **Mitigations:** - Finality delays and challenge windows. - Rate limits, pause functionality, operator bonds/slashing. - **Outcome:** Secure, zk-enforced interoperability across Ethereum, Solana, and Quantus. --- ## Security Assumptions 1. **Checkpoints:** - Anchored on Ethereum and Solana. - Prevents fake offline forks; proofs must extend accepted headers. 2. **Post-checkpoint forks:** - **Quantus:** resolved by cumulative work (`W = Σ floor(2^256 / (target_i + 1))`). - **Ethereum/Solana:** resolved by relying on their finality rules. 3. **Finality & Stability:** - N-block delays on Quantus; native finality guarantees on Ethereum and Solana. - Challenge windows allow disputes to surface. 4. **Trust model:** - Transparent setup only (Plonky3). - Strengthened by bonds, slashing, and governance-controlled limits. --- ## Why Plonky3? - **Transparent setup:** No ceremony needed. - **Recursion:** Efficient aggregation across *three chains*. - **STARK-like security:** PQ-aligned cryptography. - **Narrative win:** Unique positioning by unifying Ethereum, Solana, and Quantus bridging on Plonky3. --- ## Conclusion This roadmap expands the bridge scope to Ethereum and Solana, using Plonky3 exclusively. Checkpoints and fork-choice ensure correct chain selection, while recursive proofs reduce cost. The design provides a secure, efficient, and narrative-strong interoperability layer across three major ecosystems.