The current 24KB contract size limit can be restrictive for complex contracts and applications. Increasing the limit to 48KB allows for more feature-rich contracts while maintaining reasonable constraints on block and state growth.
4 Likes
Hi @Giulio2002,
Iām interested in the proposal to increase the maximum contract size from 24KB to 48KB, as it could enable more complex and feature-rich smart contracts. However, Iād like to better understand how this change balances the benefits for developers with potential impacts on network performance and security. Could you clarify the following points?
- Gas Metering Adjustments: The current 24KB limit (EIP-170) was set to prevent DoS attacks due to the O(n) costs of loading large contracts (e.g., disk reads, JUMPDEST analysis, Merkle proof sizes). Would the proposed 48KB limit rely solely on the existing gas metering from EIP-3860 (2 gas per 32-byte chunk), or are additional gas cost adjustments planned to account for the increased contract size?
- Impact on Node Performance: Doubling the contract size could increase the resource demands on nodes (e.g., disk I/O, memory usage). Has there been any benchmarking or analysis to ensure that a 48KB limit wonāt strain full nodes or light clients, especially as block gas limits continue to evolve?
- Backward Compatibility: The proposal mentions enabling more complex contracts, but how will it ensure backward compatibility with existing contracts and tools (e.g., Etherscan, block explorers) that rely on the 24KB limit? Could this introduce new challenges for contract verification or debugging?
- EOF Contracts Consideration: With EIP-7830 proposing a 64KB limit for EOF contracts (due to simplified JUMPDEST analysis), how does the 48KB limit align with or complement EOFās approach? Would a unified limit (e.g., 64KB for both legacy and EOF contracts) be more consistent for developers?
I think increasing the contract size limit is a promising idea to support richer dApps, but Iād love to hear more about how it mitigates the risks that originally justified the 24KB cap.
3 Likes
Hi @Giulio2002,
Isnāt EIP-7907 trying to do what you are proposing?
I think it should be a power of 2, like 64k
2 Likes
Update: it will be 32KiB
1 Like
If EIP-7907 is too complex, then this is a great step. I strongly support including this in Glamsterdam.
A moderate increase now is better than spending years trying to perfect/optimize for an infinite or massive increase that grows with the gas limit, given the technical constraints.
3 Likes
Agreed, Iāll take a moderate improvement over nothing.
In general increasing the size helps reduce gas for extcalls and helps reduce some of the more idiosyncratic ways of splitting up code just to get around it (which imo are often more bug-prone).
Obviously would prefer if we could get it to a clean 48kbāa 2x in size probably helps eliminate the majority of limits that people bump into today, but Iāll take whatever we can reasonably get.
+1 to @cupOJoseph and @owenās comments - this is definitely an improvement!
1 Like
Hereās a short presentation with an overview of current contract size limit discussions and reasoning too:
Long term we should aim for higher.
1 Like
Hey, do you plan on proposing it to ACDE? If so, I suggest putting it on the next ACDE agenda and joining. I can champion this again if there is interest
1 Like
I think we should do the opposite: Reduce the maximum contract size for EVM Legacy on a schedule (or at least keep it at its current size) while increasing for EOF. This way, we will gradually phase out EVM Legacy more effectively at the protocol level, thereby paving the way for EOF.
Update: without my own realization, this was CFIed for Glamsterdam.
1 Like
Yes. I did the whole research for the viability of this and presented it in ACD. Not really arguing for your EIP (as 64kB is totally viable). But definitely arguing against any repricing that is unneeded for these sizes (EIP-7907).
More on the topic here: https://ethresear.ch/t/data-driven-analysis-on-eip-7907/23850
1 Like
Hello, Ernesto from BGD Labs here, a team that has been building the Aave core protocol over the last few years. I would want to support the increase and comment on its importance from the perspective of Ethereum application developers.
For the last few years until now, when developing any type of mature smart contract, the 24kb limit is highly frequently one of the most ātypicalā blockers that force us to change architecture/flow-model. While one of the design principles of smart contracts is simplicity, and composition patterns almost always allow for introducing functionality without being affected by contract size limits, the reality is that the architectural/development flow works as follows:
- We come up with a product idea with a list of features. For example, a smart contract acting as a gateway/controller, with multiple public functions.
- One frequent architectural principle we have in some designs is: keep the business logic on the same contract, to 1) minimise the indirections for humans reviewing the code from a security perspective, and 2) minimise external calls. Meaning that we use composition (e.g., external libraries), but in certain systems, we want to minimise even those.
- We implement applying that principle.
- Very frequently, we notice we are above the 24kb limit after some prototyping, or that we are relatively close (up/down).
- Given that we donāt want to start with ādarkā optimisations or not having any āroomā to add new functionality that could appear later during development, we frequently go back to the architectural whiteboard and divide into more components. Or we simply discard some of the features to not bloat the complexity.
In some design/implementations, having strict limitations āforcingā compatibility patterns is positive for good practises. However, after years of developing various types of contracts and reaching the 24kb limit, I honestly believe that, regardless of the rationale for maintaining it, the 24kb limit is harming the Ethereum development ecosystem.
As a developer already trying to be very resource-minimisation oriented and design-conscious for the type of hosting machine that Ethereum is, it is very frustrating to find very strict blockers, whose rationale is relatively artificial. And I believe that me/my teamās case is actually not a very problematic one, because we have followed Ethereum from the beginning, and we understand there are nuances and reasons to keep the limit conservative. But for people with visibility strictly on the application development layer, the limit, I imagine, is even more frustrating.
Another example of the type of blocker this is: while doing features discussion with the team, the 24kb limitation is a first-class citizen on the discussion, from the angle of āThat function is good/seems to belong on this contract, but considering the rest, it feels we will hit the 24kbā. While other blockchain-specific constraints **should** actually be part of the conversation (e.g., reduce iteration), this one simply feels wrong.
So in summary, big support to the increase, ideally to 48kb, but even to 32kb would be a pretty good improvement.
5 Likes
I am also in favor of increasing the max contract size on Ethereum.
Itās pretty simple:
- Some applications require contracts larger than the current max, and therefore must be split into multiple contracts.
- Splitting functionality into multiple contracts increase security risk
When I was at Origin Protocol, we had to do a two tier proxy system for our most important contract, since the vault code would not fit into one. It would have been much cleaner code and have not required us to build extra safety infrastructure if we had had a larger contract size to use.
Incidentally, Monad has supports 128kb contracts.
2 Likes
I too am very much in favor of a contract size limit increase, however modest it is.
Since 2022, Alchemix has had several instances where our contract sizes were barely over the limit, or just under the limit, requiring us to refactor, split code out into other contracts, and/or make painful feature cuts. It makes development a bit too constrained and limits expressiveness to a minor, but real degree.
Having to fight with the contract size limit also presents security related issues. Refactoring and modularization of the code requires more code review and even sometimes extra security audits, hurting smaller teams structurally as we try to navigate this adversarial space on modest budgets. Also, for contracts that are just under the limit, it severely limits what security patches we can make to contracts in the case that a major bug is found on a deployed contract.
Even the minimal proposed increase to 32kb in 7954 would be a godsend to the development process and ongoing contract maintenance. I think especially with the gas cost reductions as projected from raising the block gas limit in Glamsterdam, any minor increase in calldata cost will easily be offset in absolute cost terms for end users.
2 Likes
These are great points I think many people donāt think of.
Would be nice to run a sim on how it would affect validators. Donāt want to lock out the decentralized validators. If fees increase that would be great. If total disk and ram and cpu requirements increase with no fee benefits I worry about the decentralization and economic security of POS.
As a dapp dev I highly support this. In fact I wish we made this a meta. Made it easier to continuously test and iteratively increase Contract size limits. Either automatically Like the difficulty increase or via a formal process that can be kicked off by future contributors with a SOP.