Merge pull request #4 from nconsigny/eip-falcon-contrib

nconsigny · web-flow · commit 1e5adc609361 · 2025-11-05T14:17:10.000+01:00
Nconsigny/eip falcon contrib
diff --git a/EIPS/eip-8052.md b/EIPS/eip-8052.md
@@ -1,13 +1,14 @@
 ---
-eip: 9999
+eip: 8052
 title: Precompile for Falcon support
 description: Proposal to add a precompiled contract that performs signature verifications using the Falcon signature scheme.
-author: Renaud Dubois, Simon Masson, Antonio Sanso (@asanso), Marius Van Der Wijden, Kevaundray Wedderburn, Zhenfei Zhang
-discussions-to: https://ethereum-magicians.org/t/eip-for-a-modular-fndsa/25860
+author: Renaud Dubois, Simon Masson, Antonio Sanso (@asanso), Marius van der Wijden, Kevaundray Wedderburn, Zhenfei Zhang, Nicolas Consigny
+discussions-to: https://ethereum-magicians.org/t/eip-8052-precompile-for-falcon-support/25860
 status: Draft
 type: Standards Track
 category: Core
 created: 2025-10-17
+
 ---
 
 # Falcon EIP
@@ -18,10 +19,12 @@ The signature scheme can be instantiated in two version:
 * Falcon, the standard signature scheme, fully compliant with the algorithm recommended by the NIST,
 * An EVM-friendly version where the hash function is efficiently computed in the Ethereum Virtual Machine.
 
-Three OPCODES are specified:
-- `HASH_TO_POINT`, that implements the NIST-compliant HashToPoint as described in [Algorithm 3](https://falcon-sign.info/falcon.pdf) of Falcon.
-- `ETH_HASH_TO_POINT`, a EVM-friendly version of HashToPoint.
-- `FALCON_CORE`: the core algorithm of Falcon, that verifies the signature from the obtained (HashToPoint) challenge.
+Three precompiled contracts are specified (formerly called `ETH_HASH_TO_POINT` / `HASH_TO_POINT_ETH` in drafts):
+
+* `FALCON_HASH_TO_POINT_SHAKE256` — that implements the NIST-compliant HashToPoint as described in [Algorithm 3](https://falcon-sign.info/falcon.pdf) of Falcon.
+* `FALCON_HASH_TO_POINT_KECCAKPRNG` — EVM-friendly Hash-to-Point using a Keccak-based XOF/PRNG.
+* `FALCON_CORE` — the core algorithm of Falcon, that verifies the signature from the obtained (HashToPoint) challenge.
+
 
 ## 2. Motivation
 
@@ -43,11 +46,11 @@ For FalconRec,
     TOTAL=1324
 -->
 
-In the context of the Ethereum Virtual Machine, a precompile for Keccak256 hash function is already available, making Falcon verification much faster when instantiated with an extendable output function derived from Keccak than with SHAKE256, as specified in NIST submission. This EIP specifies a split of the signature verification into two sub procedures: 
-- `HASH_TO_POINT` or `ETH_HASH_TO_POINT`, instantiated with a different eXtendable Output Function: the first with SHAKE256 (as recommended by NIST), the second with Keccak-PRNG (a version that is more efficient when computed in the EVM). In the future, it is possible to define it for SNARK/STARK circuits. An appropriated hash function choice reduces drastically the circuit size and the proving time in the context of ZK applications.
+In the context of the Ethereum Virtual Machine, a precompile for Keccak256 hash function is already available, making Falcon verification much faster when instantiated with an extendable output function derived from Keccak than with SHAKE256, as specified in NIST submission. This EIP specifies a split of the signature verification into two sub procedures:
+- `FALCON_HASH_TO_POINT_SHAKE256` or `FALCON_HASH_TO_POINT_KECCAKPRNG`, instantiated with a different eXtendable Output Function: the first with SHAKE256 (as recommended by NIST), the second with Keccak-PRNG (a version that is more efficient when computed in the EVM). In the future, it is possible to define it for SNARK/STARK circuits. An appropriated hash function choice reduces drastically the circuit size and the proving time in the context of ZK applications.
 - `FALCON_CORE`, that does not require any hash computation. This sub-algorithm follows the NIST recommendation so that:
-    - using the SHAKE256 `HASH_TO_POINT`, the signature is fully compliant with the NIST standard,
-    - using the KeccakPRNG `ETH_HASH_TO_POINT`, the verification can be efficient even in the EVM.
+    - using the SHAKE256 `FALCON_HASH_TO_POINT_SHAKE256`, the signature is fully compliant with the NIST standard,
+    - using the KeccakPRNG `FALCON_HASH_TO_POINT_KECCAKPRNG`, the verification can be efficient even in the EVM.
 
 Using this separation, two important features are provided: one version being fully compliant with the NIST specification, the other deviating from the standard in order to reduce the gas cost, and opening up to possible computations of Falcon signature ZK proofs.
 
@@ -114,13 +117,13 @@ def ethfalcon512_verify(message: bytes, signature: Tuple[bytes, bytes], pubkey:
     return FALCON_CORE(signature, pubkey, challenge)
 ```
 
-The functions `falcon512_verify` and `ethfalcon512_verify` call the opcodes specified in the next sections: `HASH_TO_POINT`, `ETH_HASH_TO_POINT` and `FALCON_CORE`.
+The functions `falcon512_verify` and `ethfalcon512_verify` call the precompiles specified in the next sections: `FALCON_HASH_TO_POINT_SHAKE256`, `FALCON_HASH_TO_POINT_KECCAKPRNG` and `FALCON_CORE`.
 
 
-### 3.1. Hash To Point Challenge
+### 3.1. Hash-to-Point challenge (normative)
 
 1. **Parse Input Data:** Check the byte sizes and then extract the message and the signature. The parsed signature is a tuple of values $(r, s_2)$. $r$ is denoted as the salt and contains bytes, and $s_2$ is denoted as the signature vector, a vector of elements mod $q$.
-2. **Verify Well-formedness:** Verify that the signature contains 40 bytes of salt for $r$.
+2. **Verify Well-formedness:** Verify that the signature contains a 40-byte salt $r$.
 <!-- See the `Required Checks in Verification` section for more details. -->
 3. **Compute the challenge $c$:** the challenge is obtained from hash-to-point on the salt $r$ of the signature and the message. The output $c$ is a polynomial of degree 512, stored in 896 bytes.
 The hash-to-point function computes eXtendable Output from a hash Function (XOF). This EIP provides two instantiations of a XOF:
@@ -167,9 +170,9 @@ The hash-to-point function computes eXtendable Output from a hash Function (XOF)
         ```
         Precompile of `Keccak256` are available in the Ethereum Virtual Machine, making this XOF very efficient in the EVM.
 
-Using one of the XOFs above (SHAKE256 or Keccak-PRNG), it is possible to instantiate two (opcode) algorithms for hashing into points:
+Using one of the XOFs above (SHAKE256 or Keccak-PRNG), it is possible to instantiate two (precompiles) algorithms for hashing into points:
 ```python
-def HASH_TO_POINT(message: bytes32, signature: Tuple[bytes, bytes]) -> bool:
+def FALCON_HASH_TO_POINT_SHAKE256(message: bytes32, signature: Tuple[bytes, bytes]) -> bool:
     """
     Compute the Hash To Point Falcon Challenge.
     Args:
@@ -205,7 +208,7 @@ def HASH_TO_POINT(message: bytes32, signature: Tuple[bytes, bytes]) -> bool:
 ```
 
 ```python
-def ETH_HASH_TO_POINT(message: bytes32, signature: Tuple[bytes, bytes]) -> bool:
+def FALCON_HASH_TO_POINT_KECCAKPRNG(message: bytes32, signature: Tuple[bytes, bytes]) -> bool:
     """
     Compute the Hash To Point Falcon Challenge using Keccak-PRNG.
     Args:
@@ -240,6 +243,11 @@ def ETH_HASH_TO_POINT(message: bytes32, signature: Tuple[bytes, bytes]) -> bool:
     return c
 ```
 
+#### Encoding of the challenge polynomial `c` (897 bytes, normative)
+* Domain: degree-512 polynomial with coefficients in `[0, q)`, `q = 12289`.
+* Order: coefficients are serialized in index order `c[0], c[1], …, c[511]`.
+* Bit-packing: each coefficient is a 14-bit **big-endian** unsigned integer. Concatenate all 512 encodings into a bitstring, then left-pad the final byte with zero bits to reach exactly **897 bytes**. Consumers MUST reject encodings that are not exactly 897 bytes.
+
 ### 3.2 Core algorithm
 
 1. **Parse Input Data:** Check the byte sizes and then extract the public key, the Hash To Point Challenge and the signature.
@@ -329,66 +337,20 @@ if one of the above condition is not met then all the gas supplied along with a
 it shall also be burned if an error happens during decompression (incorrect encodings).
 
 
-### 3.4. Compliance with EIP-7932
-
-In compliance with EIP-7932,  the necessary parameters and structure for its integration are provided. `ALG_TYPE = 0xFA`  uniquely identifies Falcon-512 transactions, set MAX_SIZE = 699 bytes to accommodate the fixed-length signature_info container (comprising a 1-byte version tag, a 666-byte Falcon signature, and a 32-byte public key hash), and recommend a `GAS_PENALTY` of approximately `3000` gas subject to benchmarking. The verification function follows the EIP-7932 model, parsing the signature_info, recovering the corresponding Falcon public key, verifying the signature against the transaction payload hash, and deriving the signer’s Ethereum address as the last 20 bytes of keccak256(pubkey). This definition ensures that Falcon-512 can be cleanly adopted within the `AlgorithmicTransaction` container specified by EIP-7932.
-
-```python
-signature_info = Container[
-    # 0xFA for Falcon-512 NIST-compliant,
-    # 0xFB for Falcon-512 for the EVM-friendly version,
-    version: uint8
-    # Falcon-512 signature, padded if shorter
-    signature: ByteVector[666]
-    # keccak256(pubkey)[12:]
-    pubkey_hash: ByteVector[20]
-]
-```
-
-In the format of EIP-7932:
-- For the NIST-compliant version:
-    ```python
-    verify(signature_info: bytes, payload_hash: Hash32) -> Bytes:
-        assert len(signature_info) == 699
-        version      = signature_info[0]
-        signature    = signature_info[1:667]
-        pubkey_hash  = signature_info[667:687]
-        assert version == 0xFA
-        pubkey = lookup_pubkey(pubkey_hash)
-        assert falcon512_verify(pubkey, signature, payload_hash)
-        return pubkey
-    ```
-- For the EVM-friendly version:
-    ```python
-    verify(signature_info: bytes, payload_hash: Hash32) -> Bytes:
-        assert len(signature_info) == 699
-        version      = signature_info[0]
-        signature    = signature_info[1:667]
-        pubkey_hash  = signature_info[667:687]
-        assert version == 0xFB
-        pubkey = lookup_pubkey(pubkey_hash)
-        assert ethfalcon512_verify(pubkey, signature, payload_hash)
-        return pubkey
-    ```
-
-
 ## 4. Precompiled Contract Specification
+The precompiled contracts are proposed with the following input and outputs, which are big-endian values:
 
-### 4.1. Hash To Point precompiled contract
-The precompiled contract HASH_TO_POINT is proposed with the following input and outputs, which are big-endian values:
-
-- **Input data**
-    - 32 bytes for the message
-    - 666 bytes for Falcon-512 compressed signature
-    <!-- - 897 bytes for Falcon-512 public key -->
-- **Output data**:
-    - the polynomial Hash To Point challenge as (14*512 = ) 897 bytes.
+### 4.1. `FALCON_HASH_TO_POINT_SHAKE256` 
+**Input**
+* 32 bytes: message hash `m`
+* 666 bytes: Falcon-512 compressed signature `(r || s2_compressed)`
+**Output**
+* 897 bytes: packed challenge polynomial `c` (see §3.1 encoding)
 
-#### Error Cases
-- Invalid input length (not compliant to described input)
+### 4.2. `FALCON_HASH_TO_POINT_KECCAKPRNG`
+Same I/O as §4.1, but the XOF is Keccak-PRNG. The construction is normative and MUST define: state initialization, domain-separation (if any), counter width and endianness, and block concatenation order.
 
-### 4.2. Falcon Core precompiled contract
-The precompiled contract FALCON_CORE is proposed with the following input and outputs, which are big-endian values:
+### 4.3. `FALCON_CORE`
 
 - **Input data**
     - 666 bytes for Falcon-512 compressed signature
@@ -404,9 +366,9 @@ The precompiled contract FALCON_CORE is proposed with the following input and ou
 - Invalid norm  bound 
 - Signature verification failure
 
-### 4.3. Precompiled Contract Gas Usage
+### 4.4. Precompiled Contract Gas Usage
 
-The cost of the **HASH_TO_POINT** and **HASH_TO_POINT_ETH** is set to 1000 gas.
+The cost of the **FALCON_HASH_TO_POINT_SHAKE256** and **FALCON_HASH_TO_POINT_KECCAKPRNG** is set to 1000 gas.
 
 The cost of **FALCON_CORE** is set to 2000 gas.
 
@@ -438,7 +400,50 @@ The cost is interpolated using rule of thumb from SUPERCOPS signatures benchmark
 
 ## 6. Backwards Compatibility
 
-No backward compatibility issues found.
+In compliance with EIP-7932,  the necessary parameters and structure for its integration are provided. `ALG_TYPE = 0xFA`  uniquely identifies Falcon-512 transactions, set MAX_SIZE = 667 bytes to accommodate the fixed-length signature_info container (comprising a 1-byte version tag and a 666-byte Falcon signature), and recommend a `GAS_PENALTY` of approximately `3000` gas subject to benchmarking. The verification function follows the EIP-7932 model, parsing the signature_info, recovering the corresponding Falcon public key, verifying the signature against the transaction payload hash, and deriving the signer's Ethereum address as the last 20 bytes of keccak256(pubkey). This definition ensures that Falcon-512 can be cleanly adopted within the `AlgorithmicTransaction` container specified by EIP-7932.
+
+As per EIP-7932, this EIP defines two Falcon algorithm types:
+* `ALG_TYPE = 0xFA` — Falcon-512 with SHAKE256 H2P
+* `ALG_TYPE = 0xFB` — Falcon-512 with Keccak-PRNG H2P
+
+**Container and sizes.** The `signature_info` container omits any pubkey hash; the public key is recovered by `verify(...)` and the 7932 sig-recover precompile derives the address as `keccak(ALG_TYPE || pubkey)[12:]`. Therefore:
+* `MAX_SIZE = 667` bytes (1-byte `ALG_TYPE` + 666-byte Falcon compressed signature).
+
+```python
+signature_info = Container[
+    # 0xFA Falcon-512 (SHAKE H2P), 0xFB Falcon-512 (Keccak H2P)
+    version: uint8,
+    # Falcon-512 signature (compressed). If an implementation produces a shorter form, it MUST be left-padded to 666 bytes.
+    signature: ByteVector[666]
+]
+```
+
+In the format of EIP-7932:
+- For the NIST-compliant version:
+    ```python
+    verify(signature_info: bytes, payload_hash: Hash32) -> ExecutionAddress:
+        assert len(signature_info) == 699
+        version      = signature_info[0]
+        signature    = signature_info[1:667]
+        assert version == 0xFA
+        pubkey = lookup_pubkey(pubkey_hash)
+        assert falcon512_verify(pubkey, signature, payload_hash)
+        return ExecutionAddress(keccak256(pubkey)[12:])
+    ```
+- For the EVM-friendly version:
+    ```python
+    verify(signature_info: bytes, payload_hash: Hash32) -> ExecutionAddress:
+        assert len(signature_info) == 699
+        version      = signature_info[0]
+        signature    = signature_info[1:667]
+        assert version == 0xFB
+        pubkey = lookup_pubkey(pubkey_hash)
+        assert ethfalcon512_verify(pubkey, signature, payload_hash)
+        return ExecutionAddress(keccak256(pubkey)[12:])
+    ```
+
+### Addresses
+**TBD by ACD.** Final precompile addresses will be selected within the EIP-managed range of EIP-1352, explicitly **avoiding `0x0100–0x01FF` reserved for RIPs** by EIP-7587.
 
 ## 7. Test Cases
 
@@ -453,7 +458,7 @@ An implementation is provided in `assets` (TODO). For the NIST-compliant version
 
 ## 9. Security Considerations
 
-The derivation path to obtain the private key from the seed is (tbd).
+The derivation path to obtain the private key from the seed is (tbd). Hash-to-Point functions MUST follow the specified XOFs byte-for-byte; domain separation and padding are normative.
 
 ## 10. Copyright
 Copyright and related rights waived via [CC0](../LICENSE.md).
