Proposal: Increase the contract size limit using EIP-7907 or other simpler means

Polygon Improvement Proposals Proposal Ideas
1

The current contract size limit MAX_CODE_SIZE limit uses the same structure as EIP-170 but is 32kb, as set in PIP-30.

Polygon should implement EIP-7907, or flatly just set a higher max code size, with a target of at least 256 kb.

Use cases with greater contract size limit

  1. Larger trustless self-contained contracts that are immutable

  2. More complex onchain NFTs. Think Loot NFTs with 10x more complexity.

  3. New types of onchain media: instead of only SVGs and text written onchain, think mini AI LLM models deployed entirely inside smart contracts.

  4. More things that we havent even thought of, which arent possible on any other blockchain today.

Rationale

Chains competing with Polygon, like MegaETH and RISE, are already increasing the limit significantly on their testnets. Polygon must out compete on dev-experience and continue to push what is possible on EVMs forward.

Specifications

  • Polygon currently uses EIP-170 with an updated parameter to impose 32kb contract size limit

  • EIP-7907 will soon replace the contract size limit on Ethereum with a more dynamic system.

According to the EIP, the new limit of 256 kb has chosen due to these limiting factors of ethereum mainnet:

1. The additional disk I/O for retrieving larger contract code
5. The increased computational resources for preprocessing larger code for execution (a.k.a. "JUMPDEST analysis").
6. The growth in Merkle proof sizes for blocks containing very large contracts

Polygon does not have the same constraints and as such I believe an even larger limit can be chosen. However, this will require additional research from protocol devs to make sure this fits in with the network’s architecture.

The most exciting lofty goal with this is the idea of putting entire LLM into a single or few broken up contracts. The smallest GPTnano model is 2MB. TinyLLaMA is slightly less than 3MB. We’re only about a 20x increase in size off of cramming one these into smart contracts.

1 Like
2

We are interested in the implications of increasing the contract size limit in the context of stateless verification.

Our current understanding is that the witness size itself does not change directly when the contract size grows. However, we are concerned that validators performing stateless verification may face increased burdens in other dimensions. For example, larger contract bytecode could raise storage requirements for pre-downloaded code, and the computational load of verifying witnesses might also increase when larger contracts are involved.

Could you clarify how validator hardware requirements or performance expectations might evolve if contract size limits are significantly expanded?
Are there concrete considerations for validators who will be running stateless verification under this design?