-
Notifications
You must be signed in to change notification settings - Fork 47
EIP-7883 --- MODEXP pricing tests
#2529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EIP-7883 --- MODEXP pricing tests
#2529
Conversation
...zation/src/test/java/net/consensys/linea/zktracer/precompiles/modexp/ModexpEIP7883Tests.java
Outdated
Show resolved
Hide resolved
...zation/src/test/java/net/consensys/linea/zktracer/precompiles/modexp/ModexpEIP7883Tests.java
Show resolved
Hide resolved
...zation/src/test/java/net/consensys/linea/zktracer/precompiles/modexp/ModexpEIP7883Tests.java
Show resolved
Hide resolved
...zation/src/test/java/net/consensys/linea/zktracer/precompiles/modexp/ModexpEIP7883Tests.java
Outdated
Show resolved
Hide resolved
...zation/src/test/java/net/consensys/linea/zktracer/precompiles/modexp/ModexpEIP7883Tests.java
Outdated
Show resolved
Hide resolved
...zation/src/test/java/net/consensys/linea/zktracer/precompiles/modexp/ModexpEIP7883Tests.java
Outdated
Show resolved
Hide resolved
...zation/src/test/java/net/consensys/linea/zktracer/precompiles/modexp/ModexpEIP7883Tests.java
Show resolved
Hide resolved
|
|
||
| BytecodeRunner bytecodeRunner = BytecodeRunner.of(program.compile()); | ||
| bytecodeRunner.run(List.of(codeOwnerAccount), chainConfig, testInfo); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Parameter exponentLeadingWord unused in test body
The exponentLeadingWord parameter in modexpEIP7883TestBody is never used in the method body. The test pre-computes leading words for exponents but doesn't incorporate them into the test input. This parameter should be used to construct the exponent portion of the MODEXP input data.
| cdsValues.add(bbs + extra); | ||
| } | ||
| return cdsValues; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Missing 96-byte header offset in call data size calculation
The cdsValues method computes call data sizes without accounting for the 96-byte MODEXP header. The MODEXP precompile input format places bbs, ebs, mbs (each 32 bytes) before the actual base, exponent, and modulus data, so valid call data sizes are 96 + bbs + .... The current calculation produces values like bbs + ebs instead of 96 + bbs + ebs, causing tests to pass much smaller call data sizes than intended and not properly testing the EIP-7883 pricing scenarios. The BASE_MIN_OFFSET constant (0x60 = 96) should be added to each computed cds value.
OlivierBBB
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| final String leadingWordAsHex = | ||
| leadingWord.signum() != 0 ? leadingWord.toString(16) : ""; | ||
| final String leftPaddedLeadingWordAsHex = | ||
| "0".repeat(Math.max(0, 2 * minEbs32 - leadingWordAsHex.length())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just add a sanity check that leftPaddedLeadingWordAsHex has length (as a string) of 2 * minEbs32.
| for (Integer extra : ebs != 0 ? List.of(ebs / 2, ebs, ebs + mbs) : List.of(0, mbs)) { | ||
| cdsValues.add(bbs + extra); | ||
| } | ||
| return cdsValues; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need the 96 likely ...
| + "00".repeat(bbs) | ||
| + exponentLeadingWord | ||
| + "00".repeat(Math.max(0, ebs - Math.min(ebs, 32))) | ||
| + "00".repeat(mbs)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be simpler to stop at
Bytes.fromHexString(
bbsHex
+ ebsHex
+ mbsHex
+ "00".repeat(bbs)
+ exponentLeadingWord;and then either right 0 pad, or don't even bother and just give the right cds.
| .op(OpCode.EXTCODESIZE) // size | ||
| .push(0) // offset | ||
| .push(0) // targetOffset | ||
| .push(codeOwnerAddress) // address |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
codeOwnerAddress could be renamed as callDataAsByteCodeAddress
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
codeOwnerAddress makes sense whenever we use that bytecode say as initialization code for a CREATE(2). Here we are using that account's "byte code" as call data for the MODEXP call.
| .push(mbs) // retSize | ||
| .push(input.size()) // retOffset | ||
| .push(cds) // argSize | ||
| .push(0) // argOffset |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cds and input.size() ought to be the same.
Note
Add parameterized EIP‑7883 MODEXP tests (with nightly full matrix) and move existing Modexp tests into the modexp package.
ModexpEIP7883Testswith parameterized/nightly matrices generating calldata permutations (bbs,ebs,mbs,cds, exponent leading words), invokingSTATICCALLtoAddress.MODEXPand asserting return size on success.ModexpTestsintonet.consensys.linea.zktracer.precompiles.modexppackage.Written by Cursor Bugbot for commit b6103d0. This will update automatically on new commits. Configure here.