EIP-7823: Set upper bounds for MODEXP

EIPs EIPs core
1

Discussion topic for EIP-7823

Update Log

External Reviews

None as of 2024-11-11.

Outstanding Issues

  • Need to run a full sync to extract edge cases / uses outside the limits. Done.
  • Verify that no reasonable use case exists outside of the limits.
1 Like
2

We set the exactly same limit on the zkEVM: zkevm-rom/main/precompiled/pre-modexp.zkasm at v9.0.0-rc.2-fork.13 · 0xPolygonHermez/zkevm-rom · GitHub
More context on why we decided to set up that limit is explained in this issue: Computing the maximum ModExp input length · Issue #419 · 0xPolygonHermez/zkevm-rom · GitHub

This EIP will also make life easier to Rollups in order to be fully compliant with Ethereum.

2 Likes
3

Thank you @krlosmata, that is very useful feedback. Will incorporate some of this into the EIP.

1 Like
4

The following is an analysis of MODEXP precompile calls, the dataset was collected by tracing calls to the MODEXP precompile since ~Byzantium Hard Fork until Block 21550926 (January 4th, 2025), the analysis contains the different input sizes used in all MODEXP calls and its frequency, being size 32 the most commonly used base/exponent/mod size, and 512 the maximum observed size (with the exception of a couple of transactions using size 513 for baseLen):

1 Like
5

Could this analysis be updated to explicitly define if these are bits or bytes? Even though the max bits/bytes reported seem to be 513 (2 entries in base_len), it is not clear to me if those are bits or bytes. (The 513 would fit in the EIP requirement of < 8192 bits / 1024 bytes, but would be nice to know by the analysis if the current “max” usage is 513 bits or bytes (likely: bytes?))

6

If any of these inputs are larger than the limit, the precompile execution stops, returns an error, and consumes all gas.

A quick note that current precompiles do not return any errors. They leave empty returndata which indicates there has been an error.

7

Yes, the values in the analysis results are given in bytes. I have updated the document to make it explicit. Thanks!.

2 Likes
8

I’m interested in two more restrictions:

  1. How often the modulus is even? If is, how often is it a power of 2? If this is not often used I’d restrict the modulus to odd or power-of-two values.
  2. How often the base >= modulus? Requiring base < modulus saves us from complicated initial base reduction.
9

Updated the EIP with the result of analysis.

10

Note: Scroll sets an upper bound of 32 bytes.

11

Can a note be added that the precompile inputs <length_of_BASE> <length_of_EXPONENT> <length_of_MODULUS> are expressed in bytes, not in bits?

EIP reads this:

We introduce an upper bound to the inputs of the precompile, each of the length inputs (length_of_BASE , length_of_EXPONENT and length_of_MODULUS ) MUST be less than or equal to 8192 bits (1024 bytes).

For a quick implementation of this EIP, people are likely going to check if these lengths are less than or equal to 8192. (This should be 1024)

12

EIP 7883 (the price changes to MODEXP (fun side note, that EIP uses ModExp)) will likely be shipped with this one.

It has a test cases section EIP-7883: ModExp Gas Cost Increase which covers most (all?) test cases from ethereum-tests. Looking at the names it seems that some of those are now invalid. I don’t think this is a problem (they are likely benchmark/stress tests for some specific values?) but it might be handy to add this also in the EIP as note.

This EIP mentions:

While we don’t suggest to rework the pricing function, it may be possible in a future upgrade once the limits are in place.

Are you happy with the price changes from 7883?

13

Yes, just the scope of the EIP was limited to exclude repricing. The repricing EIP can make use of these new limits when considering the pricing formula.

1 Like