Contract size limit increase for EOF

Abstract

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.

Copyright

Copyright and related rights waived via CC0.