BEP-707: add Post-Quantum Cryptography Migration Roadmap for BNB Chain - #707
BEP-707: add Post-Quantum Cryptography Migration Roadmap for BNB Chain#707zzzckck wants to merge 3 commits into
Conversation
zzzckck
changed the title
Pull Request ReviewThis PR adds BEP-707, an informational roadmap for migrating BNB Chain to post-quantum cryptography across P2P key exchange, account signatures, and pairing-based cryptography. It also adds a diagram illustrating the proposed three-phase migration sequence; no executable protocol or smart-contract code is changed. Sensitive ContentNo sensitive content detected. Security IssuesNo serious security issues detected. Generated by Hashdit Bot. This tool can absolutely NOT replace manual audits. |
Add Section 5 to track the PQC migration roadmap of each chain in the BNB Chain family (BSC, opBNB, Greenfield, and the new chain under development), since the three phases share a direction but not one activation schedule. - 5.1 per-chain cryptographic surface, plus launch requirements for the new chain (crypto-agility from genesis rather than a phase schedule) - 5.2 roadmap status index with defined status values - 5.3 cross-chain dependencies: opBNB is bounded by BSC's Phase 2, and mutually verified cross-chain channels need coordinated hardforks - 5.4 deviations register Also state the multi-chain scope in the Summary and Abstract, note that Phase 2 covers non-account EC signing keys, and add the rationale for per-chain roadmaps. Greenfield's surface and schedule are marked TBD. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pull Request ReviewThis PR adds BEP-707, an informational post-quantum cryptography migration roadmap covering hybrid P2P key exchange, post-quantum account signatures, and replacement of pairing-based cryptography. It also introduces per-chain migration tracking for BSC, opBNB, BNB Greenfield, and a new chain, along with cross-chain coordination requirements and a roadmap diagram. Sensitive ContentNo sensitive content detected. Security IssuesNo serious security issues detected. Generated by Hashdit Bot. This tool can absolutely NOT replace manual audits. |
1 participant
BEP-707: Post-Quantum Cryptography Migration Roadmap for BNB Chain
1. Summary
This BEP is the umbrella roadmap for making BNB Chain resistant to attacks from large-scale quantum computers. It describes the quantum threat, sets shared guiding principles, and defines a three-phase plan. It is the first of a series of BEPs: this document is intentionally high-level, and each phase will be specified in detail by its own companion Standards BEP.
2. Abstract
Once available, large-scale quantum computers running Shor's algorithm will break the public-key cryptography that secures BNB Chain today — elliptic-curve account signatures, pairing-based cryptography in consensus and data availability, and node-to-node key exchange. No such machine exists yet, and mainstream estimates place its arrival ("Q-Day") between 2029 and 2035, but migrating a chain with hundreds of millions of accounts and a large ecosystem takes years, so preparation must begin now.
The full migration is deliberately structured as multiple BEPs delivered in phases, not a single monolithic change. This umbrella BEP (Information type) covers the strategy only; the technical specifications live in companion Standards BEPs, one (or more) per phase:
Scope here is the core chain. Application-ecosystem migration (bridges, stablecoins, DAOs, wallets, etc.) is addressed as a coordination responsibility, since chain-level quantum resistance does not by itself protect application-layer cryptography.
3. Motivation
The quantum threat
Two quantum algorithms matter:
This split — Shor breaks structured problems, Grover only halves hash strength — is the dividing line for the whole migration.
Running Shor against 256-bit curves needs a fault-tolerant machine with on the order of millions of physical qubits, far beyond today's hardware, so Q-Day timing is uncertain (mainstream: 2029–2035). Urgency is nonetheless real because of (1) "harvest-now, decrypt-later" — recorded encrypted data can be decrypted after Q-Day, so exposure accrues today — and (2) the multi-year lead time to migrate the chain and its ecosystem.
Standards are ready to follow: NIST has finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), with FN-DSA (Falcon) in final publication; hybrid post-quantum key exchange is already deployed in mainstream TLS.
What is vulnerable on BNB Chain
The last three all rely on pairing-friendly curves, share one vulnerability, and are migrated together as a single "pairing family" — hence one phase, not three.
4. Specification
Phase 1 — P2P key-exchange upgrade
Replace the elliptic-curve key exchange in node communication with a hybrid post-quantum key exchange, closing the harvest-now-decrypt-later exposure. Highest priority and most mature: a node-software upgrade only — no consensus, user, or address impact — and equivalent hybrid schemes are already proven in TLS. Execute first. Details in the Phase 1 Standards BEP.
Phase 2 — ECDSA account-signature upgrade
Introduce post-quantum account signatures alongside ECDSA, with an address-preserving migration path. This is the largest asset-security surface: because addresses are reused, any address that has transacted has an exposed public key. Migration is opt-in and gradual — an account binds a new post-quantum key using its existing key, keeping the address unchanged — prioritizing high-value, already-exposed accounts. Note that post-quantum signatures are tens of times larger than ECDSA, pressuring bandwidth, storage, and performance; scheme selection weighs this. Details in the Phase 2 Standards BEP.
Phase 3 — Pairing-based cryptography upgrade
Migrate the pairing family — BLS aggregate signatures (fast finality), KZG commitments (L2/rollup data), and BN254 pairing precompiles — to post-quantum (hash-based) alternatives. This is the hardest, longest phase:
Because the aggregation problem is research-gated, this phase is "start when research-ready," with no fixed activation date; crypto-agility keeps these components swappable so the eventual solution can be adopted without further disruptive forks. Details in the Phase 3 Standards BEP(s) — possibly more than one, given the three distinct components.
Roadmap at a glance
Cross-cutting throughout: hybrid deployment, crypto-agility, address preservation, NIST alignment.
5. Rationale
Order. Sequencing follows threat shelf-life and solution maturity, not raw difficulty: Phase 1 first (threat accrues today, fix is mature and non-disruptive), Phase 2 next (largest asset surface, clear standardizable answer, gradual rollout), Phase 3 last (contains the one open research problem — post-quantum aggregation — so a fixed schedule would be premature).
Multiple BEPs. The work spans very different subsystems with different stakeholders and maturity levels. Splitting the roadmap (this Information BEP) from the per-phase technical specifications (companion Standards BEPs) lets each phase progress, gather review, and activate independently while staying anchored to shared principles — rather than coupling a ready-to-ship change (Phase 1) to a research-gated one (Phase 3).
6. Ecosystem Considerations
Chain-level quantum resistance does not automatically protect applications. Bridges, stablecoin/RWA issuers, DAO treasuries and multisigs, wallets, oracles, and any contract verifying signatures or pairing-based proofs each carry their own vulnerable assumptions. Two cannot be fully fixed after the fact: non-upgradeable contracts with hard-coded vulnerable cryptography (design in crypto-agility before deployment, or plan migration to successor contracts), and existing encrypted data (irreversible harvest-now-decrypt-later risk). Core-protocol BEPs are delivered by the core team; ecosystem teams are expected to prepare in parallel, and the core team intends to publish migration standards, reference implementations, and guidance — cross-chain security is only as strong as the weakest connected component.
7. Backward Compatibility
Every phase runs in hybrid mode, coexisting with the existing classical mechanisms during transition rather than replacing them abruptly. Detailed compatibility analysis (transaction formats, node-software compatibility, wind-down of legacy channels) is provided per phase in the companion Standards BEPs. Phases affecting consensus, the economic model, or UX compatibility follow the standard BNB Chain governance process, including a governance vote where required.
8. License
All the content is licensed under CC0.