Title: Increasing_contract_size_limit_with_increasing_gas
Category: EIPs

Author: 0xTraub
Date: 2024-04-18T21:37:48.261Z

Vitalik’s EIP-170 which set the current contract size limit at 24.5 Kb was written in 2016, over 8 years ago. Since then a lot has changed about the protocol, including the roadmap decision to include the verge and the purge. I think it is time to reconsider our current contract size limitations. As contracts get bigger and Dapps more complex, this limit becomes a bottleneck for many developers. The restriction has resulted in several design suggestions as well, with the Diamond-Standard being the most popular. However, writing and interacting with Diamond-contracts is a pain point for many developers, and it is not without its own issues. I  want to get started the conversation about how we can increase the contract size-limit without compromising on things like state-growth, decentralization, and security.
My current idea is fairly simple. The current contract size limit should be doubled from ~24.5Kb to ~49Kb. However, 24.5Kb should remain as target, with additional bytes incurring an increasing gas cost per byte, up to the max limit.
Current code cost is defined in the EVM as code_deposit_cost = 200 * deployed_code_size 
Based on the memory expansion cost, this should put the equation as something like 200 * contract_size + floor(size^2 / 24500)
I think that this cost should be defined either as a step-function, or more likely as an exponential increase beyond a floor, similar to the memory-expansion cost. A hard-cap should probably be maintained to guard against the DOS-Vector Vitalik lays out in EIP-170, but increased nonetheless. However, it could be possible to conceive of a proposal where exponentially increasing cost combined with block-gas-limits prevents against any security issues, and the cap can be removed entirely.
A second potential proposal could be something akin to multi-dimensional EIP-1559, where a target amount of new code is set per-block and the gas cost of deployment dynamic with a target. However, this would be contingent upon other major consensus changes, and is not suggested in the interim.
There’s definitely an appetite in the solidity community for increasing the limit, the question is how to do it with minimal consensus changes. Implementation would be fairly simple as its only a question of what the gas equation ought to be, and can be tweaked in the future as hardware requirements and further state-expiry proposals shift as well.
There must be some reason why nobody has taken this question up? Contract size limitations are a major pain point for solidity developers. The only discussion i’ve seen on this forum is from 2019, pre-merge/1559 and discussion seems to have stalled out.

Author: matt
Date: 2024-04-18T22:35:34.707Z

There have been many discussions about this in different forums. One major issue is code analysis on large contracts. To increase the size, we’d need to see worst case analysis for all the clients vs. current numbers.

Author: 0xTraub
Date: 2024-04-18T23:18:40.699Z

I figured that there were but I couldn’t find them. I assumed people much smarter than me had already discussed this since it seemed like an obvious idea. Could you link them please. Also, what’s the impact on verification if its one contract vs several? I.E three contracts at say ~12Kb each deployed in one tx vs a single 36 Kb contract? Similarly how would EOF make this verification easier/more difficult?

Author: matt
Date: 2024-04-18T23:25:42.367Z

I don’t think it is perfectly linear like that. I believe a 36kb contract has higher overhead than 3 12kb contracts. That’s at least the concern which has generally kept the 170 limit in place.
Some discussions:

Removing or Increasing the Contract Size Limit
https://x.com/lightclients/status/1737587978032001060

Kinda hard to track them down, would just search eip-170 or code size on twitter.
–
EOF does jump dest analysis one time at deploy and then never again. Non-EOF contracts do jump dest analysis everytime they’re executed.

Author: 0xTraub
Date: 2024-04-18T23:29:58.163Z

That makes it sound like once EOF gets put in place then we can revisit the idea of increasing the size. I noticed from the EOF spec doc that they only allocate a uint16 for keeping track of code size so raising the limit to ~65Kb instead of unlimited seems reasonable to me as long as its priced appropriately. Obviously unlimited is better than 65Kb but that should still alleviate some concerns about security from EIP-170 and set an upper limit on which we can benchmark the different implementations.
I think raising the limit but not unlimited is a good stopgag measure we can implement in the interim on the way to fully lifting the cap. I’m sure that people would love to have completely unlimited sized contracts but for now even doubling it will go a long way for a long time, and something like this may be less contentious as it allows the community to tweak the parameters and slowly increase size over time.
Sorry if I’m wasting your time with questions or pointless solutions when I’m missing a lot of established research. Just tryna contribute however I can.

Author: matt
Date: 2024-04-19T02:57:37.811Z

No worries at all. I think one main issue is that no one has taken the time to run the analysis and champion the change. If you’re willing to do that, it would be great. The best way to run all the clients and time them is this: GitHub - holiman/goevmlab: Evm laboratory

Author: shemnon
Date: 2024-04-19T14:30:27.040Z

0xTraub:

EOF spec doc that they only allocate a uint16 for keeping track of code size so raising the limit to ~65Kb instead of unlimited seems reasonable to me as long as its priced appropriately.


(a) That’s 64 Kib per code section, with up to 1024 code sections.  So in theory the current format supports 64Mib contracts.
(b) Once in place the container format can be revised (without breaking changes) to support header elements using variable-width encodings.

Author: 0xTraub
Date: 2024-04-19T15:42:48.444Z

Can you provide any insights on what analysis would need to be done first?

Author: hlau
Date: 2024-10-02T00:48:16.353Z

Is there an update on this? ~25 KB is simply not enough. I should also add that this bottleneck usually pops up at the worst time as dev tooling will continue to compile locally. This leads to hellish refactors that stall momentum when one least expects it.
Also agree that the diamond proxy pattern is not an ideal solution.

Author: itsdevbear
Date: 2024-10-03T17:10:21.516Z

24kb is definitely small, but this is a change that as @matt said, is something that I can only see being changed if someone has the data, changing it to some arbitrary number based on a feeling is probably more counterproductive

Author: 0xTraub
Date: 2024-10-03T17:22:41.453Z

there’s been some discussion in the past about doubling the size. I think the best method is to adopt a 1559-like mechanism whereby the limit is doubled but with an exponentially increasing cost for each byte beyond the 24.5kb target to prevent unnecessary bloat.
What kind of data is necessary. Im willing to kick off the research and work on it but I have no idea what kind of things are necessary to get that accomplished.

Author: shemnon
Date: 2024-10-04T16:12:01.177Z

A floating fee market for contract size beyond 24k seems excessive and unrelated to the reasons for the contract size, which was never bloat. If this was part of a multi-variable fee market the 24k limit would be an undeserved subsidy to small contracts when every byte should be subject to an equal fee.
The reason the contract size limit has survived past the shanghai attacks is that there were some vulnerabilities related to JUMPDEST analysis that kept the size in place until a recent fork where pay-per-initcode-byte fees were put into place.
On the horizon is EOF which eliminates this JUMPDEST analysis and only requires contract validation during a contract creation transaction or when parsing genesis file allocations.
Based on this I’m looking at proposing, for EOF only, an increase in contract size after EOF ships. After that a general uncapping of the limit for EOF can be investigated.
Regardng the notion that the size limit will prevent bloat: it won’t.  Authors will use creative ways to split their contracts, such as the diamond pattern.  Keeping the contract size in place does not reduce the total amount of storage on the chain but marginally increases it because of the overhead imposed by contract splitting techniques like the diamond pattern.

Author: 0xTraub
Date: 2024-10-07T15:23:13.025Z

I don’t think it needs to be free-floating. I was picturing more of a memory-expansion cost type fee, where after a floor of 24.5 Kb the cost increases exponentially per Kb, which would still be predictable. While I agree that EOF is a good reason to wait, its unclear when the L2 EVMs will implement that, so this could be an interim fix to support that in the meantime. Perhaps moving this to a RIP would be more suitable.

Author: shemnon
Date: 2024-10-07T15:24:46.212Z

Some L2’s tend to hoover up all L1 changes fairly quickly, since they are a “diff” from geth.

Author: hlau
Date: 2024-10-10T20:11:27.803Z

Is there an established process to port/mirror an EIP to an RIP? And out of curiosity is EOF a lock in the next Pectra upgrade or has that not been finalized yet?

Author: shemnon
Date: 2024-10-10T21:12:40.325Z

(a) I don’t see EIP → RIP as the path, it would be RIP → EIP.  When EOF is a part of released fork most L2s will have it fairly quick.
(a) EOF is “scheduled for inclusion” in the fork meta for osaka. The next highest status is “shipped”

Author: 0xTraub
Date: 2024-10-10T21:45:20.211Z

There’s no official EIP right now for what i’m proposing so starting as an RIP would make sense and then allow for porting to an EIP later. I would be concerned about using EOF as the key timeline since who knows how long it will be before a majority of L2s adopt it (ex: tstore/tload) which is why starting as an RIP and interim solution for temporarily alleviating the issue seems reasonable to me.

Author: shemnon
Date: 2024-10-17T00:15:49.112Z

I do not see raising the code limit without EOF as a long term viable path. The size cap is the mitigation to not having code validation.

Author: 0xTraub
Date: 2024-10-22T18:15:21.915Z

I’m not suggesting eliminating the cap entirely and not anytime soon but i don’t think its an unreasonable idea that we consider an interim solution while we wait for EOF that makes contract deployments slightly more flexible, as long as we keep a target of 24.5 Kb but allow slightly more up to a point. Clients can handle it.

Author: Jackie
Date: 2024-11-25T15:24:27.811Z

Very much interested in seeing the contract size limit go up. We’re currently extremely constrained by this, as we’ve already tried to minimize our contract footprint (formatted, it’s around 5k SLOC of Yul right now) as much as we can, but still continuously hit the limit–even with optimizer runs set to relatively low values.
Admittedly, I only recently started reading this board more, so am new to EOF. Will explore that too!

Author: axic
Date: 2024-12-02T13:14:05.307Z

We have published an EIP for this: EIP-7830: Contract size limit increase for EOF

Author: axic
Date: 2024-12-02T13:15:01.842Z

Also Removing or Increasing the Contract Size Limit was a relevant prior thread.

Author: 0xTraub
Date: 2024-12-02T15:21:31.293Z

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.

Author: shemnon
Date: 2024-12-02T16:26:56.479Z

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.

Author: 0xTraub
Date: 2024-12-02T17:21:14.915Z

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.

Author: axic
Date: 2024-12-02T18:16:16.937Z

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.

Author: 0xTraub
Date: 2024-12-02T18:24:04.330Z

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.

Author: axic
Date: 2024-12-02T18:26:37.356Z

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.

Author: 0xTraub
Date: 2024-12-02T18:33:45.856Z

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.

Author: charles-cooper
Date: 2025-03-15T11:14:53.130Z

i have drafted an EIP to remove the contract size limit, and replace it with metering.




EIP: Remove Contract Size Limit


    discussions-to for Add EIP: Remove Contract Code Size Limit by charles-cooper · Pull Request #9483 · ethereum/EIPs · GitHub

Author: charles-cooper
Date: 2025-03-15T11:18:51.649Z

i did the benchmarks here. jumpdest analysis is linear, as expected by inspection of the algorithm.




EIP: Remove Contract Size Limit


    I performed jumpdest analysis benchmarks for eip 7903, which are relevant here.