EIP-7823 MODEXP Input Cap (Set upper bounds for MODEXP)
Final · EVM & execution · EIP status Final · created 2024-11-11
Limits the base, exponent, and modulus input lengths of the MODEXP precompile to at most 8192 bits (1024 bytes) each. A call that exceeds the limit is treated as an error and consumes all gas.
Why it is needed
The MODEXP (modular exponentiation) precompile has had no limit on input length until now. This made it possible to deliberately craft inputs so long that they are never used in practice, and such inputs have in fact caused several consensus bugs (bugs where different clients compute different results). With unbounded input, the number of cases to test is also unbounded, so it is hard to catch every bug. The gas pricing formula is also complicated because it assumes unlimited input. Capping the input makes the test scope finite, which reduces the chance of bugs and makes it easier later to replace this precompile with ordinary EVM code using features such as EVMMAX. An analysis of actual usage found that no successful call in the past exceeded the new limit, so existing use cases remain protected.
What changes
Today
- MODEXP input length is unlimited, so a value of any size can be passed in
- The input space to test is effectively infinite, and consensus bugs have recurred
- A complex gas formula that assumes unlimited input must be maintained
After EIP-7823
- The lengths of the base, exponent, and modulus are each limited to 8192 bits (1024 bytes) or less
- A call that exceeds the limit returns an error and consumes all gas
- The test scope becomes finite, and a path opens to replace the precompile with EVMMAX and similar tools
Who is affected
- Users and existing contracts: Every successful call in the past falls within the new limit (at most 513 bytes), so existing usage is unaffected.
- Contract developer: RSA verification with keys up to 8192 bits still works, but new designs that use larger inputs become impossible.
- Client teams: The input range that must be verified becomes finite, which reduces the implementation and testing burden.
In depth
Specification: 8192-bit Cap on Each Length Input
In the MODEXP input format defined by EIP-198, <length_of_BASE> <length_of_EXPONENT> <length_of_MODULUS> <BASE> <EXPONENT> <MODULUS>, each of the three length inputs (length_of_BASE, length_of_EXPONENT, length_of_MODULUS) MUST be at most 8192 bits (1024 bytes). If any one exceeds the limit, precompile execution is aborted, an error is returned, and all gas is consumed.
Why 8192 Bits
This cap accommodates all existing use cases. First, RSA verification is possible with keys up to 8192 bits. Commonly used keys are 1024, 2048, and 4096 bits. Second, elliptic curve use cases are usually under 384 bits, so there is ample headroom.
Possible Replacement with EVMMAX
Once the input is finite, it becomes easier to reimplement the precompile as EVM code using an instruction set such as EVMMAX. A setup is possible where the commonly used cases (256, 381, 1024, 2048) are implemented on dedicated fast paths and the rest are handled on a slow general path. The source also mentions options such as giving dedicated paths to specific commonly used moduli, or restricting lengths further to only specific inputs.
On-Chain Usage Analysis
The analysis covered calls from block 5472266 (April 20, 2018), after the Byzantium hard fork that introduced MODEXP, to block 21550926 (January 4, 2025). For base and modulus, 32 bytes dominates at about 2.44 million calls each, followed by 128, 256, and 160 bytes. For the exponent, 32 bytes accounts for about 2.44 million calls and 3 bytes for 4771. No successful call had an input length above 513 bytes. There were also a few invalid calls, such as empty input, input consisting only of 0x9e5faafc or 0x85474728, and long but invalid input.
Backwards compatibility and security
Formally, this is a backward-incompatible change. However, based on the analysis up to block 21550926, no past transaction would behave differently after this change. Because it only narrows the range of accepted inputs, it is not expected to create a new security attack surface. The status of this EIP has been finalized as Final.