Falcon Post‑Quantum Signatures

[MatusKysel]

  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.

Proposal: Integrating Falcon Post‑Quantum Signatures on BNB Chain

Draft – 6 May 2025

---

• Proposal: Integrating Falcon Post‑Quantum Signatures on BNB Chain

  • 1. Summary

  • 2. Status

  • 3. Motivation

  • 4. Scope & Approach

    • 4.1 Phase 1 – Falcon Verification Precompile
    • 4.2 Phase 2 – Falcon‑Secured Voting

  • 5. Technical Specification (Phase 1)

  • 6. Implementation Notes

  • 7. Security Considerations

  • 8. Backward Compatibility

  • 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)

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) 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.

[Copilot]

Pull Request Overview

This draft BEP defines a new precompiled contract to integrate Falcon post-quantum signature verification into BNB Chain and outlines a staged rollout including governance support.

• Introduces BEP-575 with metadata, summary, motivation, scope, and roadmap for Falcon PQ signatures.
• Specifies Phase 1 precompile ABI, gas cost, and input/output format.
• Provides implementation notes, test vector requirements, and security/backward-compatibility considerations.

Comments suppressed due to low confidence (2)

BEPs/BEP-575.md:61

• The unescaped | in the table cell breaks markdown table rendering. Escape it (e.g., \|) or reformat the cell so the pipe doesn’t split the column.

| **Return**              | `uint256 (0                                                                         | 1)` success flag |   |

BEPs/BEP-575.md:1

• [nitpick] Using an HTML <pre> block for front-matter is unconventional in markdown. Consider switching to YAML front matter or fenced code blocks for better consistency and rendering.

<pre>

[Copilot]

The spec doesn’t state whether pk_len and sig_len are big- or little-endian. Explicitly specifying the byte-order for these 2-byte length fields will prevent ambiguity.

Suggested change

	Input = mode(1) ‖ pk_len(2) ‖ pubkey ‖ sig_len(2) ‖ signature ‖ msg
	Input = mode(1) ‖ pk_len(2, big-endian) ‖ pubkey ‖ sig_len(2, big-endian) ‖ signature ‖ msg

[octavio12345300]

List