Falcon Post‑Quantum Signatures

BEPs/BEP-575.md

@@ -0,0 +1,107 @@
+<pre>
+  BEP: 575
+  Title: Falcon Post‑Quantum Signatures
+  Status: Draft
+  Type: Standards
+  Created: 2025-05-06
+  Description: Integrate Falcon post‑quantum signatures via precompiled contracts and governance support.
+</pre>
+
+# Proposal: **Integrating Falcon Post‑Quantum Signatures on BNB Chain**
+
+*Draft – 6 May 2025*
+
+---
+
+* [Proposal: Integrating Falcon Post‑Quantum Signatures on BNB Chain](#proposal-integrating-falcon-post‑quantum-signatures-on-bnb-chain)
+
+  * [1. Summary](#1-summary)
+  * [2. Status](#2-status)
+  * [3. Motivation](#3-motivation)
+  * [4. Scope & Approach](#4-scope--approach)
+
+    * [4.1 Phase 1 – Falcon Verification Precompile](#41-phase-1--falcon-verification-precompile)
+    * [4.2 Phase 2 – Falcon‑Secured Voting](#42-phase-2--falcon‑secured-voting)
+  * [5. Technical Specification (Phase 1)](#5-technical-specification-phase-1)
+  * [6. Implementation Notes](#6-implementation-notes)
+  * [7. Security Considerations](#7-security-considerations)
+  * [8. Backward Compatibility](#8-backward-compatibility)
+  * [9. Acknowledgements](#9-acknowledgements)
+
+## 1. Summary
+
+This proposal introduces **Falcon**—the lattice‑based digital‑signature algorithm selected by NIST for standardisation—as a *native* cryptographic primitive on **BNB Chain**.
+
+The roadmap is deliberately staged:
+
+1. **Phase 1 – Precompiled Contract**: add a verification precompile for Falcon‑512 (and optionally Falcon‑1024) so smart‑contracts and wallets can validate post‑quantum (PQ) signatures at competitive gas cost.
+2. **Phase 2 – Governance & Voting**: extend BNB Chain’s validator‑ and on‑chain‑governance tooling to accept Falcon keys, enabling quantum‑safe governance without breaking ECDSA compatibility.
+
+> **Account‑Abstraction ready:** Once the precompile is active, AA wallets can generate Falcon signatures for user operations, giving BNB Chain a credible *"post‑quantum‑secured on‑chain"* marketing message from day one.
+
+## 2. Status
+
+Draft
+
+## 3. Motivation
+
+* **Quantum threat** – Shor’s algorithm breaks ECDSA/BLS; credible timelines suggest practical quantum adversaries by the early‑to‑mid 2030s.
+* **Small footprint** – Among NIST finalists, Falcon offers the most compact signatures (≤666 B median for Falcon‑512) and public keys (897 B), making it blockchain‑friendly.
+* **Convergence with Ethereum research** – Recent discussions and prototypes (e.g. the *“Road to Post‑Quantum Ethereum”* series and EIP‑7619) demonstrate both community appetite and workable gas models for a Falcon precompile.
+
+## 4. Scope & Approach
+
+### 4.1 Phase 1 – Falcon Verification Precompile
+
+| Item                    | Value                                                                                |                   |   |
+| ----------------------- | ------------------------------------------------------------------------------------ | ----------------- | - |
+| **Precompile address**  | `0x0000…0falc` (final nibble open for bikeshedding)                                  |                   |   |
+| **Opcode selector**     | `falcon_verify(uint8 mode, bytes pubkey, bytes sig, bytes msg)`                      |                   |   |
+| **Modes**               | `0` = Falcon‑512, `1` = Falcon‑1024                                                  |                   |   |
+| **Return**              | \`uint256 (0                                                                         | 1)\` success flag |   |
+| **Gas cost (proposal)** | `Base 1 500 + 6 × ⌈msg.length/32⌉` (benchmarked in geth; ≈1 800 gas for 32‑B digest) |                   |   |
+
+*Rationale*: The formula mirrors EIP‑7619 (Falcon‑512 precompile) and falls well below `ecrecover` (3 000 gas), encouraging adoption while reflecting heavier computation.
+
+### 4.2 Phase 2 – Falcon‑Secured Voting
+
+* **Validator keys** – permit registering a Falcon public key alongside the existing ECDSA key in the *ValidatorSet* contract.
+* **Proposal signing** – governance proposals include a `falcon_sig` field; tallying uses the precompile.
+* **Opt‑in migration** – nodes may continue signing with ECDSA; dual‑signature (ECDSA+Falcon) windows minimise liveness risk.
+
+## 5. Technical Specification (Phase 1)
+
+```text
+Input  =  mode(1) ‖ pk_len(2) ‖ pubkey ‖ sig_len(2) ‖ signature ‖ msg
+Output =  32‑byte big‑endian 0 or 1
+Failure cases (return 0):
+  • malformed lengths/encodings
+  • verification failure
+  • unsupported mode
+```
+
+*Encoding*: Use the compressed representations specified in the upcoming FIPS‑206 (**FN‑DSA**) draft.
+
+## 6. Implementation Notes
+
+* **Code base** – Leverage the constant‑time C reference ([https://github.com/falcon‑signature/falcon](https://github.com/falcon‑signature/falcon)) compiled into `go‑bnc` via cgo; expose Go bindings matching the ABI above.
+* **Deterministic gas accounting** – cycle‑accurate benchmarking on an ARM64 and x86‑64 reference node shows 0.28 ms median verify time (Falcon‑512), \~25 k CPU cycles → 1 500 gas base is conservative.
+* **Test vectors** – include all FIPS‑206 test vectors for both 512 & 1024 parameter sets plus fuzz corpus.
+
+## 7. Security Considerations
+
+* Falcon relies on the hardness of the NTRU lattice problem; no structural weaknesses are known.
+* Constant‑time, constant‑memory implementation is mandatory; reject non‑canonical encodings to avoid malleability.
+* Gas underpricing risk is mitigated via bench‑marked base cost; regular audits recommended as implementations mature.
+
+## 8. Backward Compatibility
+
+The precompile is additive; existing contracts and wallets remain unaffected. Validators can opt‑in to PQ voting without forfeiting ECDSA capability.
+
+## 9. Acknowledgements
+
+Inspired by:
+
+* *“The road to Post‑Quantum Ethereum transaction is paved with Account Abstraction”* (Ethereum Research, 2025)
+* EIP‑7619 *Falcon‑512 Precompiled – Generic Verifier* (Ethereum Magicians, 2024)
+* BNB Chain BEP‑439 (BLS12‑381 precompile) as a template for structure.