Fix EIP-8052 markdown validation errors

- Remove document title (already in preamble)
- Remove all section and subsection numbering
- Remove external link to falcon-sign.info
- Comply with EIP markdown requirements

Author: nconsigny

EIPS/eip-8052.md

@@ -8,25 +8,22 @@ status: Draft
 type: Standards Track
 category: Core
 created: 2025-10-17
-
 ---
 
-# Falcon EIP
-
-## 1. Abstract
+## Abstract
 This proposal creates a precompiled contract that performs signature verifications using the Falcon-512 signature scheme by given parameters of the message hash, signature, and public key. This allows any EVM chain -- principally Ethereum roll-ups -- to integrate this precompiled contract easily.
 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 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_SHAKE256` — NIST-compliant Hash-to-Point using SHAKE256.
 * `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
+## 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.
 
@@ -54,7 +51,7 @@ In the context of the Ethereum Virtual Machine, a precompile for Keccak256 hash
 
 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.
 
-## 3. Specification
+## Specification
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
 
@@ -120,7 +117,7 @@ def ethfalcon512_verify(message: bytes, signature: Tuple[bytes, bytes], pubkey:
 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 (normative)
+### 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 a 40-byte salt $r$.
@@ -248,7 +245,7 @@ def FALCON_HASH_TO_POINT_KECCAKPRNG(message: bytes32, signature: Tuple[bytes, by
 * 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
+### Core algorithm
 
 1. **Parse Input Data:** Check the byte sizes and then extract the public key, the Hash To Point Challenge and the signature.
     - The parsed public key  $h$, interpreted as a vector of elements mod $q$,
@@ -319,7 +316,7 @@ def FALCON_CORE(signature: Tuple[bytes, bytes], h: bytes, challenge: bytes) -> b
     return total_norm < ACCEPTANCE_BOUND  # Falcon-512: β² = 34,034,726
 ```
 
-### 3.3. Required Checks in Falcon Verification
+### Required Checks in Falcon Verification
 The following requirements MUST be checked by the precompiled contract to verify signature components are valid:
 
 **Raw Input data**
@@ -337,20 +334,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).
 
 
-## 4. Precompiled Contract Specification
+## Precompiled Contract Specification
 The precompiled contracts are proposed with the following input and outputs, which are big-endian values:
 
-### 4.1. `FALCON_HASH_TO_POINT_SHAKE256` 
+### `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)
 
-### 4.2. `FALCON_HASH_TO_POINT_KECCAKPRNG`
+### `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.3. `FALCON_CORE`
+### `FALCON_CORE`
 
 - **Input data**
     - 666 bytes for Falcon-512 compressed signature
@@ -366,15 +363,15 @@ Same I/O as §4.1, but the XOF is Keccak-PRNG. The construction is normative and
 - Invalid norm  bound 
 - Signature verification failure
 
-### 4.4. Precompiled Contract Gas Usage
+### Precompiled Contract Gas Usage
 
 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.
 
 Thus, the total cost of the signature is 3000 gas.
 
-## 5. Rationale
+## Rationale
 
 The Falcon signature scheme was selected as a NIST-standardized post-quantum cryptographic algorithm due to its strong security guarantees and efficiency.
 
@@ -389,7 +386,7 @@ Falcon offers several advantages over traditional cryptographic signatures such
 
 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. 
 
-### 5.1 Gas cost explanations
+### Gas cost explanations
 
 
 The cost of the **HASH_TO_POINT** and **HASH_TO_POINT_ETH** functions is dominated by the call to the underlying hash function. It represents in average 35 calls to the hash function. Taking linearly the cost of keccak256, and avoiding the context switching it represents 1000 gas.
@@ -398,7 +395,7 @@ The cost of **FALCON_CORE** function is dominated by performing 2 NTTs and 1 inv
 
 The cost is interpolated using rule of thumb from SUPERCOPS signatures benchmark results.
 
-## 6. Backwards Compatibility
+## Backwards Compatibility
 
 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.
 
@@ -445,20 +442,20 @@ In the format of EIP-7932:
 ### 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
+## 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.
 
 
-## 8. Reference Implementation
+## Reference Implementation
 
 An implementation is provided in `assets` (TODO). For the NIST-compliant version, KAT vectors of the NIST submission are valid. 
 
 **TODO: We can modify geth to include falcon-512 as a reference. (Similar to secp256r1 signature verification)**
 
-## 9. Security Considerations
+## Security Considerations
 
 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
 Copyright and related rights waived via [CC0](../LICENSE.md).