Revise the contract size limit for EOF contracts to be 64 KiB instead of the existing 24 KiB limit. Legacy contracts are unaffected.
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.
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).
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.
This is a backwards compatible change. Existing contracts are unaffected, and only new deployments see the effect.
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.
Copyright and related rights waived via CC0.