SIMD-0461: enabling falcon signature verification as a precompile

[zz-sol]

Summary

This SIMD proposes adding a precompile for Falcon-512 (FN-DSA) signature verification, providing post-quantum cryptographic capability for Solana.

Scope

• Verification only — key generation and signing are off-chain
• Does NOT replace Ed25519 — provides an additional verification option
• Exploratory — gauging interest before committing to a PQC strategy

Related

• EIP-8052: Ethereum's Falcon precompile proposal
• Draft FIPS 206: NIST FN-DSA standard

[simd-bot]

Hello zz-sol! Welcome to the SIMD process. By opening this PR you are affirming that your SIMD has been thoroughly discussed and vetted in the SIMD discussion section. The SIMD PR section should only be used to submit a final technical specification for review. If your design / idea still needs discussion, please close this PR and create a new discussion here.

This PR requires the following approvals before it can be merged:

• At least one approval from a Anza team member: t-nelson, sakridge, or bw-solana
• At least one approval from an Firedancer team member: ptaffet-jump, topointon-jump, 0x0ece, lidatong, or ripatel-fd

Once all requirements are met, you can merge this PR by commenting /merge.

[zz-sol]

A note on PQC scheme selection:

The elephant in the room is whether we should also introduce Dilithium (ML-DSA) and SPHINCS+ (SLH-DSA), the other two NIST-selected PQC signature schemes. Proposing only Falcon might appear to be picking winners prematurely.

Why Falcon first:

Falcon-512 offers the best balance for blockchain use cases:

• Smallest signatures among the three (~666 bytes vs ~2,420 bytes for Dilithium2 vs ~17KB+ for SPHINCS+)
• Reasonable verification performance (~ 5 us, credit @Rexicon226)

That said, Dilithium has merits too—simpler implementation and no floating-point concerns. OTOH SPHINCS+ is probably a no-go as it has impractical signature sizes for on-chain use (if you disagree, please convince us).

Ethereum's approach:

For reference, Ethereum has separate EIPs:

• EIP-8052: Falcon precompile
• EIP-8053: Dilithium precompile

Options for Solana:

• Single exploratory SIMD (current approach) — start with Falcon, add others if demand emerges
• Parallel SIMDs — write separate SIMDs for Dilithium (and SPHINCS+) now (more comprehensive but more work for exploration)
• Umbrella SIMD — one SIMD covering all two/three schemes with separate feature gates

Looking for feedback on the preferred approach. This SIMD is exploratory—we're gauging interest and identifying implementation considerations before committing to a specific PQC strategy.

[t-nelson]

please no more precompiles. we need to kill them conceptually. they're a scourge on optimizing the execution pipeline. can this not be done via syscall instead? ideally with primitive building blocks.

[zz-sol]

please no more precompiles. we need to kill them conceptually. they're a scourge on optimizing the execution pipeline. can this not be done via syscall instead? ideally with primitive building blocks.

yes. refactored into a syscall

[zz-sol]

seem like I cannot edit the title of this PR. so admin please help to rename this PR:

SIMD-0461: enabling falcon signature verification as a precompile

SIMD-0461: enabling falcon signature verification as a syscall

[simd-bot]

Thanks, 0x0ece!

⚠️ Status: Cannot merge yet

• Missing approval from: Anza (t-nelson, sakridge, or bw-solana)

[simd-bot]

Thanks, 0x0ece!

⚠️ Status: Cannot merge yet

• Missing approval from: Anza (t-nelson, steviez, or bw-solana)

[t-nelson]

i'm not necessarily opposed, but the motivation section doesn't really help me understand why we want to add this to the protocol. afaik we have winternitz vaults already, with no additional simds, so we have some degree of quantum resistant protection. is there external demand for the features that it enables? are we building stuff with it? if so is there demand for that? i have heard nothing about this in any prioritization conversations and we aren't generally keen to change the protocol for the sake of changing the protocol.

[xAdamPos]

i'm not necessarily opposed, but the motivation section doesn't really help me understand why we want to add this to the protocol. afaik we have winternitz vaults already, with no additional simds, so we have some degree of quantum resistant protection. is there external demand for the features that it enables? are we building stuff with it? if so is there demand for that? i have heard nothing about this in any prioritization conversations and we aren't generally keen to change the protocol for the sake of changing the protocol.

One thing that comes to mind is that Winternitz vaults are one-time use only, whereas with FN-DSA / ML-DSA / SLH-DSA you don’t need to rotate the public key after every spend, which can be much more practical for non-vault use cases. I agree that it’s not clear there is meaningful demand for these schemes today.