Increase Maximum Contract Size to 48KB

EIPs
1

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.

2

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

Hi @Giulio2002,

Isn’t EIP-7907 trying to do what you are proposing?

4

I think it should be a power of 2, like 64k

1 Like