EIP-7951: Precompile for secp256r1 Curve Support #817
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
| ;; 3.4.5 R1 membership ;; | ||
| ;; utilities ;; | ||
| ;;;;;;;;;;;;;;;;;;;;;;;;; | ||
| (defun (callToR1Membership k P_x_hi P_x_lo P_y_hi P_y_lo) |
There was a problem hiding this comment.
Only non trivial part of this PR.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
| PHASE_ECPAIRING_DATA 0x080A | ||
| PHASE_ECPAIRING_RESULT 0x080B | ||
| PHASE_P256_VERIFY_DATA 0x100A | ||
| PHASE_P256_VERIFY_RESULT 0x100B |
There was a problem hiding this comment.
Bug: Phase IDs collide for precompile operations
Phase constant collision: PHASE_P256_VERIFY_DATA is set to 0x100A, which is identical to the existing PHASE_BLS_MAP_FP_TO_G1_DATA constant (also 0x100A). These phase identifiers must be unique to correctly distinguish between different precompile operations. This collision will cause the system to confuse P256_VERIFY operations with BLS_MAP_FP_TO_G1 operations.
…X` is inactive (#821)
| ))) | ||
|
|
||
| (defun (precompile-processing---MODEXP---lead-log) (shift [misc/EXP_DATA 5] precompile-processing---MODEXP---misc-row-offset---leading-word-analysis)) ;; "" | ||
| (defun (precompile-processing---MODEXP---modexp-full-log) (+ (precompile-processing---MODEXP---lead-log) (* 16 (precompile-processing---MODEXP---sub-ebs-32)))) |
There was a problem hiding this comment.
Bug: Incorrect MODEXP Gas Pricing
The modexp-full-log calculation multiplies sub-ebs-32 by 16 instead of 8. Since sub-ebs-32 represents bytes and the exponent log is measured in bits, the conversion factor should be 8 bits per byte, not 16. This will cause incorrect gas pricing calculations for MODEXP operations where the exponent size exceeds 32 bytes.
.../call/precompiles/modexp/common/__05__exponent_leading_word_extraction_and_analysis_row.lisp
Show resolved
Hide resolved
| ))) | ||
|
|
||
| (defun (precompile-processing---MODEXP---lead-log) (shift [misc/EXP_DATA 5] precompile-processing---MODEXP---misc-row-offset---leading-word-analysis)) ;; "" | ||
| (defun (precompile-processing---MODEXP---modexp-full-log) (+ (precompile-processing---MODEXP---lead-log) (* 16 (precompile-processing---MODEXP---sub-ebs-32)))) |
There was a problem hiding this comment.
Bug: MODEXP Gas Pricing: Incorrect Calculation Inflates Costs
The precompile-processing---MODEXP---modexp-full-log calculation uses multiplier 16 instead of 8 to convert sub-ebs-32 (bytes) to bits. This doubles the exponent log value, causing incorrect MODEXP gas pricing. All other forks (London, Shanghai, Cancun, Prague) use multiplier 8, which correctly converts bytes to bits.
| (defconstraint g2-membership-circuit-selector () | ||
| (eq! CS_G2_MEMBERSHIP G2MTR)) | ||
| (defcomputedcolumn (CIRCUIT_SELECTOR_G2_MEMBERSHIP :binary@prove) | ||
| G2MTR) |
There was a problem hiding this comment.
Bug: P256_VERIFY: Circuit Selector Integrity Compromised
The circuit-selectors-sum-binary constraint is missing CS_P256_VERIFY in the sum. This fails to verify that only one circuit selector is active at a time when P256_VERIFY is used, potentially allowing multiple circuit selectors to be active simultaneously.
| (* CALL___first_half_nsr___prc_success_wont_revert scenario/PRC_SUCCESS_CALLER_WONT_REVERT) | ||
| )) | ||
|
|
||
| ;; TODO add P256_VERIFY |
There was a problem hiding this comment.
Bug: Precompile Processing Ignores P256_VERIFY
The precompile-processing---2nd-half-NSR and precompile-processing---2nd-half-flag-sum functions don't include P256_VERIFY handling. P256_VERIFY is not part of scenario-shorthand---PRC---common-BLS-address-bit-sum, so when P256_VERIFY is invoked, the NSR and flag sum calculations will be zero instead of the correct values, causing constraint violations.
| INDEX_MAX_ECADD_RESULT 3 | ||
| INDEX_MAX_ECMUL_RESULT 3 | ||
| INDEX_MAX_ECPAIRING_RESULT 1 | ||
| INDEX_MAX_P256_VERIFY_DATA 10 |
There was a problem hiding this comment.
Bug: Data Index Error Impacts Verification
The INDEX_MAX_P256_VERIFY_DATA constant is set to 10, but P256_VERIFY data has 10 limbs with indices 0-9, making the maximum index 9. This off-by-one error causes internal_checks_passed to be read from the wrong HURDLE offset in the justify-success-bit-256-verify constraint.
| (defconstraint g2-membership-circuit-selector () | ||
| (eq! CS_G2_MEMBERSHIP G2MTR)) | ||
| (defcomputedcolumn (CIRCUIT_SELECTOR_G2_MEMBERSHIP :binary@prove) | ||
| G2MTR) |
There was a problem hiding this comment.
Bug: Circuit Selectors: Mutual Exclusivity Broken
The circuit-selectors-sum-binary constraint is missing CS_P256_VERIFY in the sum that validates at most one circuit selector is active at a time. This allows CIRCUIT_SELECTOR_P256_VERIFY to be active simultaneously with other circuit selectors, violating the mutual exclusivity requirement.
|
|
||
| ;; P256_VERIFY flag sum | ||
| (defun (precompile-processing---2nd-half-flag-sum-for-P256-VERIFY) | ||
| (+ (* scenario/PRC_FAILURE_KNOWN_TO_HUB) |
There was a problem hiding this comment.
Bug: Verification Flag Sum Calculation Error
The first term in precompile-processing---2nd-half-flag-sum-for-P256-VERIFY is missing the flag sum function call. It multiplies scenario/PRC_FAILURE_KNOWN_TO_HUB by nothing instead of by (precompile-processing---flag-sum-P256-VERIFY-FKTH), causing incorrect flag sum calculation for the P256_VERIFY failure case.
Note
Adds secp256r1 P256_VERIFY precompile for Osaka and updates MODEXP per EIP-7823 (1024-byte bound, pricing), wiring changes across constants, hub/OOB/MMU/EC modules, plus new blake2fmodexpdata for Osaka and misc fixes.
P256_VERIFYacrossconstants/constants.lisp(gas, sizes, phases, OOB opcode).ecdata/osaka(columns, constants, constraints, circuit selector) and integrates in hub/OOB scenario handling.hub/osaka/...NSRs/flag sums, generalities, success/FKTR flows) and OOB (oob/osaka/...), including return data sizing and phases.EIP_7823_MODEXP_UPPER_BYTE_SIZE_BOUND(1024) and new pricing (min cost 500) with refactored OOB pricing/xbs logic and bound checks.common/__0x__*.lisp), updates success path to use the 1024 bound, and justifies success/return gas under bounds.modexp_data/zeropreprocessing and padding math accordingly.blake2fmodexpdata/osaka/*(columns, constants, constraints, WCP lookup) and includes in Makefile for Osaka.RLP_TXN_RCPT_OSAKAandTRM_OSAKA.ISZEROand adjusts success-bit logic; replaces several circuit selector constraints withdefcomputedcolumn.ct-max-sum.Written by Cursor Bugbot for commit 15aa249. This will update automatically on new commits. Configure here.