EIP-8052: Precompile for Falcon support

EIPs
1

EIP for a Modular FNDSA

Abstract

This EIP introduces two precompiles for Falcon-512 signatures. The signatures is split into two to provide both alignment with the NIST standardization and ensuring compatibility with NIST Known Answer Test (KAT) vectors and ZK-friendlyness and flexibility of the hash function.

Motivation

Falcon (Fast Fourier Lattice-based Compact Signatures over NTRU) is one of the NIST-selected post-quantum signature schemes, designed to offer strong security guarantees against both classical and quantum attacks. Based on lattice cryptography and the Short Integer Solution (SIS) problem over NTRU lattices, Falcon provides an efficient alternative for quantum-resistant authentication.

The proposal brings Falcon verification capabilities natively into Ethereum smart contracts, enabling future-proof authentication and secure decentralized applications with compact signatures. It also use a modular approach to anticipate the ZK end game.

Specification

Modular Architecture: Separating Challenge Generation from Core Verification

The main difference of this proposal compared to existing ones is the modular design that separates signature verification into two distinct components:

  1. HASH_TO_POINT (challenge generation)

  2. FALCON_CORE (signature verification)

This separation provides significant flexibility and opens up multiple use cases:

  • Standard Compliance: Using SHAKE256-based HASH_TO_POINT ensures full NIST compliance

  • EVM Optimization: Using Keccak256-based ETH_HASH_TO_POINT dramatically reduces gas costs

  • ZK-Friendly Future: The modular design allows future implementations to substitute challenge generation with SNARK/STARK-friendly hash functions, enabling efficient ZK proofs of Falcon signatures. A Cairo implementation using the blake2s built-in has been developped.

If adopted, this precompile will allow ZKEVM to adopt partial compliance with L1 on the core verification, but adopt efficient hashing (avoiding keccak ZKEVM DDOS).

Examples and operational contracts are also provided in the assets.

HASH_TO_POINT Precompile (1000 gas)

The HASH_TO_POINT precompile implements the NIST-compliant challenge computation using SHAKE256, which:

  • Computes the HashToPoint challenge according to the Falcon specification

  • Takes a 32-byte message hash and 666-byte signature as input

  • Returns an 897-byte polynomial challenge

  • Is fully compliant with NIST KAT test vectors

This ensures that on-chain challenge generation behaves identically to the standardized cryptographic primitives — a crucial property for interoperability, auditing, and security.

ETH_HASH_TO_POINT Precompile (1000 gas)

While the standard version uses SHAKE256 as the underlying hash function, this can be inefficient in the EVM environment since the Keccak_f permutation lacks a dedicated opcode. To address this, we introduce an alternative variant, ETH_HASH_TO_POINT, which:

  • Replaces SHAKE256 with Keccak256 in counter mode (Keccak-PRNG)

  • Reduces the computational overhead significantly by leveraging existing Keccak256 precompiles

  • Keeps the algorithm semantically equivalent, but optimized for the EVM

  • Maintains the same security properties while reducing gas costs

This variant is provided as a first example of HashToPoint/CORE separation, providing gas reduction for the “progressive approach” (enabling cheaper verification from today while the EIP is discussed).

(By analogy, at the moment we publish this post, secp256r1 is still not deployed with incoming Fusaka, and solidity emulation code is still in use in several wallet such as Coinbase one.

FALCON_CORE Precompile (2000 gas)

The FALCON_CORE precompile handles the core verification algorithm, which:

  • Takes the challenge polynomial, public key, and signature as input

  • Performs Number Theoretic Transform (NTT) operations for efficient polynomial multiplication

  • Verifies the L2 norm bound to ensure signature shortness

  • Returns success or failure (1 or no output)

  • Estimated gas cost: 2000 gas

Importantly, this component is independent of the hash function choice, meaning the same core verification works with either challenge generation method.

Total Gas cost

The full signature requires a call to both function, leading to a total 3000 (plus some negligible data handling).

Rationale

Comparizon with Other Signature Schemes

The choice of post-quantum signature scheme for Ethereum is not finalized and multiple candidates are being evaluated by the community.

Falcon pros:

  • Compact signatures: Around 666 bytes for Falcon-512 (compared to 2420 bytes for ML-DSA), which is attractive for on-chain storage and gas costs

  • Efficient verification: Fast verification times suitable for blockchain environments

  • Moderate public key size: 897 bytes (compared to 1312 bytes for ML-DSA)

Falcon cons:

  • Signing complexity: Falcon has higher signing complexity compared to ML-DSA, which can make generating signatures slower and more resource-intensive, especially in constrained environments

  • Implementation complexity: Lattice-based signatures over NTRU require careful implementation

By contrast, ML-DSA offers simpler signing and verification procedures, with larger signature sizes. This EIP provides an alternative approach that prioritizes signature compactness and verification efficiency, and is meant to be compared directly with the ML-DSA proposal to inform the community’s final decision.

The following table compares the public key and signature sizes:

Scheme Public key Signature
ML-DSA 1312B 2420B
FN-DSA 897B 666B

EIP-7932 Compatibility

The proposal specifies EIP-7932 fields (Algorithmic Transaction Types), defining:

  • ALG_TYPE = 0xFA for NIST-compliant Falcon-512

  • ALG_TYPE = 0xFB for EVM-friendly Falcon-512

  • MAX_SIZE = 699 bytes for the signature_info container

  • GAS_PENALTY ≈ 3000 gas (subject to benchmarking)

This ensures seamless integration with the emerging transaction type framework for alternative signature schemes.

Next Steps and Community Feedback

We invite the Ethereum community to:

  • Review the Draft EIP

  • Experiment with the contracts

  • Contribute to gas optimization efforts

Current repositories allows to use Python signers and verify signatures on-chain. All of these are public goods delivered to the community.

Open discussion

In a first version of the EIP, a “falcon with recovery” mode was specified, in order to mimic the ecrecover APIs. For easiness of integration and testing it has been decided not to do so, but the provided smart contracts offer this extra feature.

Reference Implementation

Security Considerations

A derivation path shall be specified to standardize the way keys are generated by wallets. The value of the string is TBD.

1 Like