Title: EIP_7823__Set_upper_bounds_for_MODEXP
Category: EIPs

Author: axic
Date: 2024-11-23T14:55:40.817Z

Discussion topic for EIP-7823
Update Log

2025-01-27: updated EIP with analysis, clarified Backwards Compatibility and Security Considerations sections
2024-11-26: merged as EIP: EIP-7823: Set upper bounds for MODEXP
2024-11-11: initial draft Add EIP: Set upper bounds for MODEXP by axic · Pull Request #9046 · ethereum/EIPs · GitHub

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.

Author: krlosmata
Date: 2024-11-28T09:39:50.785Z

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.

Author: axic
Date: 2024-11-28T11:53:46.172Z

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

Author: hugo-dc
Date: 2025-01-16T03:06:34.299Z

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):


github.com


hugo-dc/modexp_analysis/blob/master/modexp.ipynb
{
 "cells": [
  {
   "cell_type": "code",
   "execution_count": 1,
   "id": "1d7aca17-4c1f-482a-8aa5-e7d2b425e03d",
   "metadata": {},
   "outputs": [],
   "source": [
    "import pandas as pd\n",
    "import numpy as np"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 2,
   "id": "42d5e60e-b058-4df0-b21d-5583b2ee4c37",
   "metadata": {},
   "outputs": [],
   "source": [




  This file has been truncated. show original

Author: jochem-brouwer
Date: 2025-01-20T12:14:13.175Z

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?))

Author: Arvolear
Date: 2025-01-20T17:30:07.527Z

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.

Author: hugo-dc
Date: 2025-01-20T18:25:06.026Z

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

Author: chfast
Date: 2025-01-27T18:20:27.660Z

I’m interested in two more restrictions:

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.
How often the base >= modulus? Requiring base < modulus saves us from complicated initial base reduction.

Author: axic
Date: 2025-01-27T18:38:21.529Z

Updated the EIP with the result of analysis.

Author: axic
Date: 2025-01-30T13:46:03.940Z

Note: Scroll sets an upper bound of 32 bytes.