[Non Constitutional] Proposal to direct the Arbitrum Foundation to implement an extended version of EIP-7907. And for the DAO to ratify its deployment on Arbitrum One

Technical Discussion
1

Direct the Arbitrum Foundation to research an extended version of EIP-7907 and ratify the change in an update to Arbitrum as the DAO. (Non-constitutional)

Motivation

The contract size limit on Arbitrum is currently the same as Etheruem mainnet. This is one of the single worst aspects of EVM contract developer experience. EIP-7907 is coming soon, and will dramatically increase this limit, according to constraints imposed by Ethereum architecture that do not necessarily effect Arbitrum One.

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

Competing chains to arbitrum like MegaETH and RISE are already increasing the limit significantly on their testnets. Arbitrum must out compete on dev-ex and continue to push what is possible on EVMs forward.

Specifications

  • Arbitrum currently uses EIP-170 to impose 24kb contract size limit
  • EIP-7907 will soon replace the contract size limit on Ethereum with a more dynamic system.

Accourding 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

Arbitrum 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 OCL or the foundation since they would be the only ones with the experience and expertise to decide what the theoretical limit for Arbitrum could be such that it doesnt brake anything else in the network’s architecture.

Steps to Implement

  1. Social consensus that this is worth investing resources into researching and implementing. Comment below!
  2. Research possible tradeoffs and what a theoretical contract size limit could be
  3. Add to the next arbOS upgrade
  4. Ratify as a DAO

Timeline

I will leave this to any protocol engineers who want to chime in, but I do not believe we should delay or wait for Ethereum to include 7907 in an Ethereum hard fork upgrade. But rather move on this as soon as possible, as it can really be something that gives Arbitrum an edge.

Thank you.

Edit: after discussing with Derek from OCL (THANK YOU!) i think it makes more sense to wait until Ethereum adds the EIP first to maintain backwards compatibility. OCL reports that this is already on their roadmap to be added to a near future upgrade. (Woohoo!)
The DAO should support them and grant any extra resources that they need to do further R&D to expand the limit further.

I will continue to get dev feedback.

if you are building something cool & need a bigger size limit, post what you’re building or DM me!

2 Likes
2

Hi, interesting proposal.
There are several valid concerns:

Unproven Impact on L2 Security
EIP-7907 alters certain aspects of transaction handling at the protocol level. For Arbitrum, where security relies on proper interaction with Ethereum L1, these changes could introduce unforeseen vulnerabilities or require significant auditing to ensure safe integration
Yes, theoretically the size of Arbitrum contracts is not within the sphere of influence of the mainnet, but without testing it is impossible to do. It would be good to wait for testing from the mainnet, since at this stage Arbitrum has full compatibility, and I would not like to do double work

Mainnet Compatibility
Despite the fact that Arbitrum is a separate chain and even implements its own Stylus for creating contracts that are not compatible with mainnet contracts on Solidity, I believe that it is necessary to be as compatible as possible so that projects that can migrate to Arbitrum from the mainnet and vice versa can do so without major changes. Contract size greatly affects such compatibility