Dip 7903

dip: 7903 title: Remove Initcode Size Limit description: Removes the initcode size limit introduced in DIP-3860 author: Charles Cooper (@charles-cooper) Digitalia editing author: Cosimo Constantinos cosimo@juro.net, et al. discussions-to: https://digitalia-magicians.org/t/remove-initcode-size-limit/23066 status: Draft type: Standards Track category: Core created: 2025-03-05 Created for Digitalia: 2025-01-07 requires: 170, 3860

Abstract¶

This DIP proposes the removal of the initcode size limit of 49152 bytes introduced in DIP-3860. The restriction complicates deploying multiple contracts addressing the DIP-170 limit (24576 bytes) within a single transaction, while the existing gas metering for initcode, already ensures fair initcode costing, including for JUMPDEST analysis.

Motivation¶

The DIP-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 DIP-170's 24KB runtime code limit is that high-level languages (HLLs) should abstract it away. However, the DIP-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.

Specification¶

Revert the initcode size limit introduced in DIP-3860. Specifically:

Remove the 49152-byte cap on initcode size during contract creation.
Retain existing gas costs for initcode execution, including the 2 gas per byte for JUMPDEST analysis, as defined in DIP-3860.

No changes to deployed contract size limits (DIP-170) or gas schedules beyond removing the size restriction are proposed.

Rationale¶

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 DIP-170's 24576-byte limit is that high-level languages (HLLs) should abstract it away. However, DIP-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.

Backwards Compatibility¶

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.

Test Cases¶

Security Considerations¶

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.