linter: bullet errors correction

Author: rdubois-crypto

EIPS/eip-8051.md

@@ -10,26 +10,21 @@ category: Core
 created: 2025-10-15
 ---
 
-
-# ML-DSA EIP
-
 ## Abstract
 
 This proposal adds precompiled contracts that perform signature verifications using the NIST module-lattice signature scheme. Two instantiations are supported:
 
-
-
 * **ML-DSA** — NIST-compliant version using SHAKE256 (FIPS-204),
 * **ML-DSA-ETH** — EVM-optimized version for cheaper on-chain verification:
-    - Uses Keccak-based PRNG instead of SHAKE256 (leverages native KECCAK256 precompile)
-    - Stores public-key polynomial `t1` in the NTT domain to skip one NTT during verification (convertible to regular encoding offline)
+    * Uses Keccak-based PRNG instead of SHAKE256 (leverages native KECCAK256 precompile)
+    * Stores public-key polynomial `t1` in the NTT domain to skip one NTT during verification (convertible to regular encoding offline)
 
 Two precompile contracts are specified:
-- `VERIFY_MLDSA` — verifies a ML-DSA signature compliant to FIPS-204.
-- `VERIFY_MLDSA_ETH` — verifies a ML-DSA-ETH signature replacing SHAKE256 with a more efficient hash function, deviating from FIPS-204.
 
-## Motivation
+* `VERIFY_MLDSA` — verifies a ML-DSA signature compliant to FIPS-204.
+* `VERIFY_MLDSA_ETH` — verifies a ML-DSA-ETH signature replacing SHAKE256 with a more efficient hash function, deviating from FIPS-204.
 
+## Motivation
 
 Quantum computers pose a long-term risk to classical cryptographic algorithms. In particular, signature algorithms based on the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP) such as secp256k1, are widely used in Ethereum and threaten by quantum algorithms. This exposes potentially on-chain assets and critical infrastructure to quantum adversaries.
 
@@ -60,22 +55,24 @@ The following specification provides two precompiled contract:
 While ML-DSA can be instantiated for three security levels: NIST level II, III and IV, this EIP only covers NIST level II, corresponding to 128 bits of security.
 
 For the two variants of ML-DSA of this EIP, the following parameters are fixed:
-- Polynomial degree: `n = 256`,
-- Field modulus: `q = 8380417`,
-- Matrix dimensions: `k=4`, `l=4`,
-- Bounds of rejection: `γ_1 = 2¹⁷`, `γ_2 = (q-1)/88`,
-- Additional parameters: `η = 2`, `τ = 39`, `d = 13`.
+
+* Polynomial degree: `n = 256`,
+* Field modulus: `q = 8380417`,
+* Matrix dimensions: `k=4`, `l=4`,
+* Bounds of rejection: `γ_1 = 2¹⁷`, `γ_2 = (q-1)/88`,
+* Additional parameters: `η = 2`, `τ = 39`, `d = 13`.
 
 These parameters strictly follows NIST. More precisely, `q`, `n`, `k`, `l` and `η` are chosen in order to ensure a hard MLWE related problem, and the remaining parameters are chosen for the hardness of MSIS as well as for the efficiency of the scheme.
 
 In terms of storage, ML-DSA public key can be derived by the verifier, making the overall public key of 1312 bytes. However, this increases the verifier cost, making the on-chain verification too expensive from a practical point of view. In this EIP, the verification algorithm takes the public key in raw format, meaning that the storage for the public key is:
-- The full matrix `A_hat` of 16 384 bytes,
-- `tr` is stored in order to save one hash, with 32 bytes,
-- `t1` is stored in the NTT domain in order to save one NTT, with 4096 bytes.
+
+* The full matrix `A_hat` of 16 384 bytes,
+* `tr` is stored in order to save one hash, with 32 bytes,
+* `t1` is stored in the NTT domain in order to save one NTT, with 4096 bytes.
 
 The overall storage for the **public key** is **20512 bytes**. The signature follows the same format as specified in FIPS-204: 32 bytes for `c_tilde`, 2304 bytes for the coefficients of `z`, and 84 bytes for `h`. In total, a **signature** requires **2420 bytes**.
 
-###  Sub-algorithms of ML-DSA
+### Sub-algorithms of ML-DSA
 
 #### Number Theoretic Transform
 
@@ -85,8 +82,9 @@ Polynomial arithmetic is computed efficiency using Number Theoretic Transform (N
 
 The verification algorithm requires an eXtendable Output Function (XOF) made from a hash function.
 This EIP provides two instantiations of a XOF:
-- SHAKE256 is the XOF provided in NIST submission, a sponge construction derived from SHA256. Extracting bytes using SHAKE256 calls the `Keccak_f` permutation as described in Section 3.7 of FIPS-204. While this construction is standardized, it is expensive when computed in the Ethereum Virtual Machine because `Keccak_f` has no EVM opcode.
-- Keccak-PRNG is a XOF that is build from a counter-mode PRNG based on Keccak256. Generating new chunks of bytes requires an incrementing counter, as described in NIST SP800-90A revision 1. This XOF has the same interface as SHAKE256, but requires a `flip()` function that initiate a counter to `0`. Then, the `squeeze` function outputs as many bytes as needed using a counter mode as specified in SP800-90A revision 1. A precompile of `Keccak256` is available in the Ethereum Virtual Machine, making this XOF very efficient in the EVM.
+
+* SHAKE256 is the XOF provided in NIST submission, a sponge construction derived from SHA256. Extracting bytes using SHAKE256 calls the `Keccak_f` permutation as described in Section 3.7 of FIPS-204. While this construction is standardized, it is expensive when computed in the Ethereum Virtual Machine because `Keccak_f` has no EVM opcode.
+* Keccak-PRNG is a XOF that is build from a counter-mode PRNG based on Keccak256. Generating new chunks of bytes requires an incrementing counter, as described in NIST SP800-90A revision 1. This XOF has the same interface as SHAKE256, but requires a `flip()` function that initiate a counter to `0`. Then, the `squeeze` function outputs as many bytes as needed using a counter mode as specified in SP800-90A revision 1. A precompile of `Keccak256` is available in the Ethereum Virtual Machine, making this XOF very efficient in the EVM.
 
 #### Hints in ML-DSA
 
@@ -119,13 +117,12 @@ def VERIFY_MLDSA(public_key, message, signature) -> bool:
     return check_norm_bound(z, γ_1 - β) and c_tilde == shake_256(μ + w_prime).extract(32)
 ```
 
-
 ### ML-DSA-ETH verification algorithm
 
 The verification of ML-DSA-ETH signatures follows the same algorithm with another hash function, with two differences:
-- `t1` from the public key is stored in the NTT domain in order to save one NTT. The multiplication by `2^d` is also precomputed. Note that this change can be seen as a change of representation.
-- A variant of `sample_in_ball` is defined using KeccakPRNG. The only difference from Algorithm 29 of FIPS-204 is that it requires a `flip()` between lines 3 and 4 so that it initializes the counter to `0` before starting squeezing. Note that this can be implemented in `absorb()` and `squeeze()` so that the same interface can be used as in SHAKE256.
 
+* `t1` from the public key is stored in the NTT domain in order to save one NTT. The multiplication by `2^d` is also precomputed. Note that this change can be seen as a change of representation.
+* A variant of `sample_in_ball` is defined using KeccakPRNG. The only difference from Algorithm 29 of FIPS-204 is that it requires a `flip()` between lines 3 and 4 so that it initializes the counter to `0` before starting squeezing. Note that this can be implemented in `absorb()` and `squeeze()` so that the same interface can be used as in SHAKE256.
 ```python
 def VERIFY_MLDSA_ETH(public_key, message, signature) -> bool:
     A_hat, tr, t1 are decoded from public_key
@@ -146,61 +143,59 @@ def VERIFY_MLDSA_ETH(public_key, message, signature) -> bool:
 
 ### Required checks in ML-DSA(-ETH) verification
 
-- The hint `h` needs to be properly encoded. The malformation of the hint is specified in Algorithm 21 of FIPS-204.
-- The element `z` must have a norm satisfying `||z||_∞ < γ_1 - β`. The norm `||.||_∞` is defined page 6 of FIPS-204.
-- The final hash output must be equal to the signature bytes `c_tilde`.
+* The hint `h` needs to be properly encoded. The malformation of the hint is specified in Algorithm 21 of FIPS-204.
+* The element `z` must have a norm satisfying `||z||_∞ < γ_1 - β`. The norm `||.||_∞` is defined page 6 of FIPS-204.
+* The final hash output must be equal to the signature bytes `c_tilde`.
 
 ### Precompiled contract specification
 
-### ML-DSA precompiled contract 
+### ML-DSA precompiled contract
 
 The precompiled contract VERIFY_MLDSA is proposed with the following input and outputs, which are big-endian values:
 
-- **Input data**
-    - 32 bytes for the message
-    - 2420 bytes for ML-DSA signature
-    - 20512 bytes for the ML-DSA expanded public key
-- **Output data**:
-    - If the algorithm process succeeds, it returns 1 in 32 bytes format.
-    - If the algorithm process fails, it returns 0 in 32 bytes format.
+* **Input data**
+    * 32 bytes for the message
+    * 2420 bytes for ML-DSA signature
+    * 20512 bytes for the ML-DSA expanded public key
+* **Output data**:
+    * If the algorithm process succeeds, it returns 1 in 32 bytes format.
+    * If the algorithm process fails, it returns 0 in 32 bytes format.
 
 #### Error Cases
 
-- Insufficient gas has been provided.
-- Invalid input length (not compliant to described input)
-- Invalid field element encoding (≥ q)
-- Invalid norm  bound 
-- Invalid hint check
-- Signature verification failure
-
+* Insufficient gas has been provided.
+* Invalid input length (not compliant to described input)
+* Invalid field element encoding (≥ q)
+* Invalid norm  bound
+* Invalid hint check
+* Signature verification failure
 
-### ML-DSA-ETH precompiled contract 
+### ML-DSA-ETH precompiled contract
 
 The precompiled contract VERIFY_MLDSA_ETH is proposed with the following input and outputs, which are big-endian values:
 
-- **Input data**
-    - 32 bytes for the message
-    - 2420 bytes for ML-DSA-ETH signature
-    - 20512 bytes for the ML-DSA-ETH expanded public key
-- **Output data**:
-    - If the algorithm process succeeds, it returns 1 in 32 bytes format.
-    - If the algorithm process fails, it returns 0 in 32 bytes format.
+* **Input data**
+    * 32 bytes for the message
+    * 2420 bytes for ML-DSA-ETH signature
+    * 20512 bytes for the ML-DSA-ETH expanded public key
+* **Output data**:
+    * If the algorithm process succeeds, it returns 1 in 32 bytes format.
+    * If the algorithm process fails, it returns 0 in 32 bytes format.
 
 #### Error Cases
 
-- Insufficient gas has been provided.
-- Invalid input length (not compliant to described input)
-- Invalid field element encoding (≥ q)
-- Invalid norm  bound 
-- Invalid hint check
-- Signature verification failure
+* Insufficient gas has been provided.
+* Invalid input length (not compliant to described input)
+* Invalid field element encoding (≥ q)
+* Invalid norm  bound
+* Invalid hint check
+* Signature verification failure
 
 ### Precompiled contract gas usage
 
 The cost of the **VERIFY_MLDSA** and **VERIFY_MLDSA_ETH** functions is dominated by the call to the NTTs, and the required hash calls for sampling in the ball (and for μ and the final check).
 It represents in average 5 calls to the hash function. Taking linearly the cost of keccak256, and avoiding the context switching it represents 4500 gas.
 
-
 ## Rationale
 
 The ML-DSA scheme was selected as a NIST-standardized post-quantum cryptographic algorithm due to its strong security guarantees and efficiency.
@@ -211,11 +206,9 @@ ML-DSA (based on CRYSTALS-Dilithium) offers a strong balance between security, e
 
 Given the increasing urgency of transitioning to quantum-resistant cryptographic primitives or even having them ready in the event that research into quantum computers speeds up.
 
-
 ## Backwards Compatibility
 
-In compliance with EIP-7932,  the necessary parameters and structure for its integration are provided. `ALG_TYPE = 0xD1`  uniquely identifies ML-DSA transactions, set MAX_SIZE = 2420 bytes to accommodate the fixed-length signature_info container, 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 Dilithium 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 ML-DSA can be cleanly adopted within the `AlgorithmicTransaction` container specified by EIP-7932.
-
+In compliance with EIP-7932,  the necessary parameters and structure for its integration are provided. `ALG_TYPE = 0xD1`  uniquely identifies ML-DSA transactions, set MAX_SIZE = 2420 bytes to accommodate the fixed-length signature_info container, 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 Dilithium 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 ML-DSA can be cleanly adopted within the `AlgorithmicTransaction` container specified by EIP-7932.
 ```python
 signature_info = Container[
     # 0xD1 for ML-DSA (NIST-compliant version),
@@ -229,8 +222,9 @@ signature_info = Container[
 ```
 
 In the format of EIP-7932:
-- For the NIST-compliant version:
-    ```python
+
+* For the NIST-compliant version:
+```python
     verify(signature_info: bytes, payload_hash: Hash32) -> ExecutionAddress:
         assert len(signature_info) == 699
         version      = signature_info[0]
@@ -240,9 +234,10 @@ In the format of EIP-7932:
         pubkey = lookup_pubkey(pubkey_hash)
         assert VERIFY_MLDSA(pubkey, payload_hash, signature)
         return ExecutionAddress(keccak256(pubkey)[12:])
-    ```
-- For the EVM-friendly version:
-    ```python
+```
+
+* For the EVM-friendly version:
+```python
     verify(signature_info: bytes, payload_hash: Hash32) -> ExecutionAddress:
         assert len(signature_info) == 699
         version      = signature_info[0]
@@ -252,13 +247,12 @@ In the format of EIP-7932:
         pubkey = lookup_pubkey(pubkey_hash)
         assert VERIFY_MLDSA_ETH(pubkey, payload_hash, signature)
         return ExecutionAddress(keccak256(pubkey)[12:])
-    ```
+```
 
 ## Test Cases
 
 A set of test vectors for verifying implementations is located in a separate file (to be provided for each opcode). For the NIST compliant version, KATs are reproduced.
 
-
 ## Reference Implementation
 
 An implementation is provided in `assets` of this EIP. For the NIST-compliant version, KAT vectors of the NIST submission are valid.
@@ -268,4 +262,5 @@ An implementation is provided in `assets` of this EIP. For the NIST-compliant ve
 The derivation path to obtain the private key from the seed is (tbd).
 
 ## Copyright
+
 Copyright and related rights waived via [CC0](../LICENSE.md).