This EIP proposes the removal of the initcode size limit of 49152 bytes introduced in EIP-3860. The restriction complicates deploying multiple contracts addressing the EIP-170 limit (24576 bytes) within a single transaction, while the existing gas metering for initcode, already ensures fair initcode costing, including for JUMPDEST analysis.
The EIP-3860 initcode size limit imposes an unnecessary constraint on deployment patterns, particularly for creation transactions creating large logical contracts composed of multiple physical sub-contracts in a single transaction.
A key argument for retaining EIP-170's 24KB runtime code limit is that high-level languages (HLLs) should abstract it away.
However, the EIP-3860 limit prevents HLLs from cleanly abstracting this, as deploying large logical contracts exceeding 49152 bytes of initcode requires splitting into multiple transactions, undermining the abstraction.
Removing the cap simplifies smart contract deployment and enables HLLs to cleanly abstract large contracts, without compromising network security or cost attribution.
Revert the initcode size limit introduced in EIP-3860. Specifically:
initcode size during contract creation.initcode execution, including the 2 gas per byte for JUMPDEST analysis, as defined in EIP-3860.No changes to deployed contract size limits (EIP-170) or gas schedules beyond removing the size restriction are proposed.
This proposal is driven by the need to restore flexibility in contract deployment patterns, such as factory contracts creating multiple sub-contracts in one transaction. The design decision to remove the 49152-byte cap leverages the pre-existing gas metering system, which scales linearly with initcode size (i.e., 2 gas per byte), ensuring fair cost attribution without artificial limits.
A key justification for EIP-170's 24576-byte limit is that high-level languages (HLLs) should abstract it away. However, EIP-3860's initcode cap undermines this by forcing multi-transaction deployments for large contracts, breaking the abstraction HLLs aim to provide. Removing the cap aligns with this philosophy by enabling single-transaction deployments.
Alternative designs, such as increasing the cap (e.g., to 98304 bytes), were considered but rejected as arbitrary; gas metering already mitigates resource concerns. The per-block gas limit already naturally restricts initcode (at the current gas limit of 35 million, initcode is restricted to ~16mb). Furthermore, initcode has additional implied costs - it must have already been paid for via calldata or memory expansion, limiting it even more.
This change is fully backwards compatible. Existing contracts and transactions remain unaffected, as the proposal only lifts a restriction without altering execution semantics or gas costs.
No new security risks are introduced. The current gas schedule already mitigates denial-of-service concerns by charging per-byte for initcode. Benchmarks were performed, and ns/byte remained consistent across a range of different bytecodes, ranging from 128 bytes to 15MB.
Copyright and related rights waived via CC0.