We have published an EIP for this: EIP-7830: Contract size limit increase for EOF
1 Like
Also Removing or Increasing the Contract Size Limit was a relevant prior thread.
My only concern right now is the over-reliance on EOF as the primary mechanism to enable contract size-limit expansion, as who knows how long it could be until a critical mass of L2 networks start implementing EOF. With the massive growth of cross/multi-chain applications many developers might feel disheartened that the increased contract size is inaccessible until all of their networks adopt EOF which could be years away. The relevant example here being transient-storage which many networks are yet to support.
L2s are free to set their own contract size limits. Today.
I know many testnets and devnets that have done it, so the configuration settings and code paths already exist. They don’t need to wait for L1 contract size limit changes to do it on their own L2.
They have the capacity to do it now but given the multi-chain world we’re moving to, it’s still a bottleneck for smart contract devs cause otherwise you need to write two different versions of your contract one that fits the size limit and one that doesn’t.
It may be unfortunate, but if you read the reasoning in the EIP it is clear why it is only suggested for EOF. The unknown unknowns are solved with EOF, while they are outstanding with legacy, i.e. it is more realistic to increase with EOF, while it would take way more effort (and convincing) for legacy.
I understand the reasoning, my argument is that there’s some amount of increase that can be achieved and reasonable without requiring EOF, and that we should raise it to that now with further raising the cap achievable after implementation of EOF.
The work needed to get such a change adopted does not correlate well with how much we increase, i.e. even if you increase to 32k in legacy you’ll likely have to put in more work and effort than increasing it to 64k in EOF.
Anyone is free to do the championing, but I personally won’t volunteer to champion a legacy code size increase.
That’s reasonable. I’m just coming at this from the perspective of a cross-chain protocol who is continuously bottleneck by the L1 moving faster than the L2s and being unable to take advantage of a lot of these EVM improvements that aren’t being implemented by enough networks. I know that’s not the responsibility of the l1 devs but its an issue that a lot of people are experiencing.