EIP-7951: Precompile for secp256r1 Curve Support

[lorenzogentile404]

Note

Add secp256r1 (P-256) VERIFY precompile tracing with counters, Osaka constants, MMU/OOB wiring, and extensive tests; refactor BLS OOB helpers under post-Cancun.

• Precompile/EC Data (Osaka):
  • Implement PRC_P256_VERIFY in EcDataOperation: input parsing, internal checks (range, nonzero, on-curve), callToR1Membership, result formatting; expose returnData.
  • Add isP256VerifyData/Result trace flags and phases; use WCP.ISZERO for zero checks.
• Counters/Modules:
  • Add PRECOMPILE_P256_VERIFY_EFFECTIVE_CALLS to ModuleName; new incrementing modules in ZkCounter and Hub; wire into EcData.
• Scenario/Addressing:
  • Extend PrecompileScenarioFragment with PRC_P256_VERIFY (address mapping, data/result phases, validation, line counts); add to CallSection.
• MMU/OOB refactor (post-Cancun):
  • Introduce P256VerifyOobCall.
  • Generalize MMU helpers to *PostCancunPrecompiles and select EC/BLS paths; adjust expected return sizes.
  • Move BLS OOB classes to common.postCancun packages.
• Trace/Constants:
  • Switch Modexp and Blake2f data indices and micro-row counts to TraceOsaka.
• Tests:
  • Add P256VerifyTest and large vector file p256_verify_test_vectors.json.

^{Written by Cursor Bugbot for commit c9aa4d2. This will update automatically on new commits. Configure here.}

[cursor]

Bug: Flawed P256 Verify Handling: Misread Result, Unused Variable

In handleP256Verify, the successBit is set based on return data size (returnData.bitLength() / 8 == TOTAL_SIZE_P256_VERIFY_RESULT) rather than the actual verification result. The return data extraction and validation logic appears incomplete, and the recoveredAddress variable is declared but never used meaningfully.

 

[cursor]

Bug: Incomplete RAM failure categorization for precompiles

P256_VERIFY is excluded from the check that sets PRC_FAILURE_KNOWN_TO_RAM scenario when OOB succeeds but the precompile fails. Like ECADD, ECMUL, and ECPAIRING, P256_VERIFY performs internal validation checks (signature parameters, curve membership) that can fail after OOB checks pass. Without this, P256_VERIFY failures won't be properly categorized as RAM-level failures.

 

[cursor]

Bug: Standardize Precompile Failure Handling Logic

PRC_P256_VERIFY is missing from the condition that sets the scenario to PRC_FAILURE_KNOWN_TO_RAM when hubSuccess && !callSuccess. The TODO comment on line 136 explicitly questions whether P256_VERIFY should be included. Since P256_VERIFY is an elliptic curve precompile similar to ECADD, ECMUL, and ECPAIRING, it likely needs the same failure handling logic to correctly set the scenario when hub validation succeeds but the precompile call fails.

 

[cursor]

Bug: Incomplete P256 Verification Output

In handleP256Verify(), the result limbs are not populated correctly. limb.set(10, Bytes.EMPTY) should instead set it to returnData.slice(0, 16) to capture the full hi/lo parts of the verification result, similar to other precompile handlers like handleRecover().