Revise the contract size limit for EOF contracts to be 64 KiB instead of the existing 24 KiB limit. Legacy contracts are unaffected.
Motivation
The contract size limit was introduced as a measure against DoS attacks. JUMPDEST-analysis is required for legacy contracts, and many of the algorithms performing it are not linear and/or have unknown unknowns. This is one of the reasons for the hesitance of a limit increase.
For contract developers the limit poses annoying problems, given modern contracts with good error reporting would consume more space. They are forced to work with workarounds, like “libraries” (using DELEGATECALL), splitting an application across regular contracts (and CALL-ing across), or working with proxies (e.g. the “diamond pattern”). All these solutions have resulted in suboptimal patterns, bugs in deployed contracts, and loss of funds.
With EOF the JUMPDEST-analysis is removed from runtime and a validation process is peformed once during deployment. The initcode cost EIP-3860 introduced accounts for this validation too. Therefore with EOF there are no known problems for increasing the limit, because the overheads are already accounted for.
Storage cost is already paid per contract byte.
Specification
EIP-170 specifies MAX_CODE_SIZE as 24576 bytes, and EIP-3860 specifies MAX_INITCODE_SIZE as 2 * MAX_CODE_SIZE (49152 bytes).
Starting FORK_BLOCK, for EOF initcode/code (code starting with the 0xEF 0x00 bytes) the limit is changed:MAX_CODE_SIZE is set to 65536 bytes (64 KiB). This means MAX_INITCODE_SIZE becomes 131072 bytes (128 KiB).
Rationale
The 64 KiB limit is over 2x of existing limit, while it is not a significant increase, it is the realistic increase given the limitations of initcode. In EOF deployment the to-be-deployed code is stored as a section (“subcontainer”), which has a size limit of 64 KiB, therefore it is not possible to deploy larger contracts without introducing a large or variable-length-encoded size field.
A further increase can be proposed with applying these changes to EOF.
This increase still fits within the gas schedule, limiting the size to less than what gas limits allow. In EIP-170 the gas limit was first set “by setting the cap at a value slightly higher than what is feasible with current gas limits.” At that time the gas limit had not exceeded 5M gas.
A simple analysis shows contract deployements for 64 KiB contracts to be between 14M and 16M gas, roughly close to the current 15M target.
Cancun
This EIP
30M Gas
Max Initcode
Initcode bytes
200
200
200
65,536
Deployed Bytes
24,576
65,536
137,656
65,536
Zero byte ratio
10%
10%
10%
10%
Initcode Cost
4/16
4/16
4/16
4/16
Intrinsic Gas
53,000
53,000
53,000
53,000
Calldata Gas
366,685
972,893
2,043,880
1,939,866
EIP-3860 Gas
49,552
131,472
276,200
262,144
EVM Execution
100,000
100,000
100,000
100,000
Code Deposit
4,915,200
13,107,200
27,580,000
13,107,200
Total Cost
5,484,437
14,364,565
30,000,181
15,462,210
Note that the Max 30M gas contract size of 135 KiB is outside the limits of what is proposed in this EIP and is included to show what it would take to exceed current gas limits.
Backwards Compatibility
This is a backwards compatible change. Existing contracts are unaffected, and only new deployments see the effect.
Security Considerations
Given the analysis cost is paid as part of deployment, the size of contract should have no effect on the runtime.
A more thorough analysis may be needed to detemine whether the proposed limit poses any risk because of client storage architectures.