I’m withdrawing my previous proposal related to the contract size limit given new updates from core devs and how the related EIPs have developed.
Motivation
The contract size limit on Arbitrum and Ethereum is 24kb. It’s quite small and is one of the only parts of Ethereum which has never been improved since launch.
3 days ago, Core devs threw out EIP-7907. it would have greatly increased Ethereums contract size limit through a metering system. reference: EIP-7907 - Forkcast
Instead, EIP-7954 is now proposed for Glamsterdam inclusion which sets the limit to 32kb, a 33% increase. The new change is much smaller but can go through more immediately because it’s much simpler.
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
- Implement EIP-7954 on Arbitrum ahead of Glamsterdam
- Choose 64kb as a new contract size limit, and 128kb init code
Raises limits so developers can deploy slightly larger contracts: up to 64kb deployed code and 128kb initcode after an upgrade. Existing contracts remain valid.
Initcode includes:
The constructor logic, the embedded runtime bytecode that will be returned and stored on-chain, deployment-time setup (initial storage writes, immutable resolution, library linking, constants baking). Even just 96kb of initcode should be okay
Increasing the limit in this way, without any other protocol changes, ensures Arbitrum maintains 100% reverse compatibility with mainnet, and that all contracts on mainnet would work as expected on Arbitrum (given the other unrelated differences).
Steps to implement
-
Social consensus that this is worth investing resources into researching and implementing. Comment below!
-
Research possible tradeoffs and what a theoretical contract size limit could be
-
Add to the next arbOS upgrade
-
Ratify as a DAO
Timeline
Once 7954 has been 100% confirmed for inclusion in Glamsterdam, Arbitrum should make the proposed parameter changes to it.
Thank you! I welcome any feedback.
1 Like
Hello @cupofjoseph! Thank you for this proposal and forum post. Similar to our reply on your other proposal about EIP-7907, we remain committed to supporting both: (1) compatibility with all of Ethereum’s hard forks and associated EIPs and (2) continued improvements aimed at enabling developers on Arbitrum to succeed.
To that end, we’re delighted to share that we have completed most of the work to enable Stylus contracts (written in Rust) to have a 96 KB size limit, which is 4x the contract size limit of Solidity contracts today. This increase in the Stylus smart contract size limit will be available in the next ArbOS release & an upcoming version of the Stylus Rust SDK. We believe this approach balances the need to maintain strong compatibility with Ethereum for developers and the need to give Arbitrum developers (specifically Stylus teams) the tools and infrastructure they need to excel.
As for EIP-7954, we expect to propose to the DAO the inclusion of all Scheduled For Inclusion (SFI’ed) EIPs in Ethereum’s upcoming Glamsterdam hard fork, where relevant. This means that if EIP-7954 is indeed SFI’ed, then we would work to implement this for all Arbitrum chains to use via a proposed ArbOS upgrade in the future. At the time of writing and as of the most recent ACDE call that took place on Jan 15, however, EIP-7954 appears to be only Considered for Inclusion (CFI’ed).
Secondly, your request to not only adopt but modify EIP-7954 to use higher limits (64 KB for contract sizes and a 128 KB limit for initcode) is a welcome one. The status quo approach we would normally expect to take for EIP-7954 is one where we would use the same specification as whatever the Ethereum Core Developers decide to adopt: whether it be 32KB, higher than 32KB, or no change at all. We agree with you that performing this modification while keeping existing contracts valid would benefit Arbitrum Solidity developers.
While we have not yet made a decision on specifically what we would propose to the Arbitrum DAO if this EIP were to be scheduled for inclusion in Glamsterdam, we are always interested in community and Ethereum Core Developers’ proposals and opinions (including yours). We can confirm that we are currently conducting an analysis and it would seem that doing this change (adopt & modify) is prudent and possible on Arbitrum. Of course, if the Ethereum Core Developers agree collectively to take the same approach (adopt & modify), then it would be straightforward to implement and adopt for Arbitrum.
Thank you again for your post. We will stay abreast of any new developments on this topic and will share an update if we have one.
3 Likes
