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.