EIP-170 Contract code size limit
Final · EVM & execution · EIP status Final · created 2016-11-04
Limits the maximum size of contract code that can be deployed on the blockchain to 24,576 bytes (0x6000). Attempting to deploy code larger than this causes contract creation to fail.
Why it is needed
On Ethereum, calling a contract costs only a fixed amount of gas for the call itself. But if the called contract's code is large, the cost a node incurs to read that code from disk, prepare it for execution on the virtual machine (VM), and include the code data in the Merkle proof that proves the block is valid grows in proportion to the code's length. This created an imbalance where the fee paid stays constant while the cost borne by the network grows with the size of the code. The source text points out that while this was tolerable at the gas levels of the time, it would become a bigger problem as the gas limit rose, and would be especially burdensome for future light clients that need to verify proofs of block validity. So a cap was placed on the code size that can be stored on the blockchain, set slightly higher than what could actually be created under the gas limit at the time, so as not to disrupt existing usage.
What changes
Today
- There was no upper limit on contract code size, so in theory arbitrarily large code could be deployed
- Calling a contract with large code made a node incur a hidden cost proportional to the code's length
- The proof data that a light client needed to verify could grow as large as the code size
After EIP-170
- Deployed contract code cannot exceed 24,576 bytes
- Contract creation that tries to produce code exceeding this size fails with an out-of-gas error
- A guaranteed upper bound is placed on the amount of code per contract that nodes and light clients must process
Who is affected
- Contract developer: Since contract creation fails if the code to be deployed exceeds 24,576 bytes, large contracts must be designed to be smaller or split up.
- Client teams: Implementations must check the length of the returned code at contract creation time and fail with out of gas if it exceeds the limit.
- Node operators and light clients: An upper bound is placed on the cost of reading and verifying a single contract, removing the need to worry about excessive load caused by code size.
In depth
MAX_CODE_SIZE and the activation condition
The limit value MAX_CODE_SIZE is 0x6000, i.e. 2**14 + 2**13 = 24,576 bytes. It takes effect at FORK_BLKNUM 2,675,000, targeting CHAIN_ID 1 (mainnet). When block.number >= FORK_BLKNUM, if the initialization code of a contract creation returns data longer than MAX_CODE_SIZE bytes, the contract creation fails with an out-of-gas error. What is checked is not the length of the initialization code itself, but the length of the data it returns, i.e. the code that will actually be stored.
The problem being prevented: an O(n)-cost quadratic vulnerability
A contract call consumes a fixed amount of gas, but the actual work it triggers scales with the code length n. The source text identifies three such costs: reading the code from disk, preprocessing the code for VM execution, and adding O(n) data to the block's Merkle proof of validity. Since the gas paid is constant while the cost incurred is linear, repeating this could cause the burden on the network to grow more than proportionally.
Why it wasn't urgent then, but was preemptively blocked
The source text assesses that at the gas levels of the time, this cost, while not optimal, was acceptable. However, it notes that the gas limit could soon rise significantly under the dynamic gas limit rule, at which point the problem would grow. It points out that while not as severe as denial-of-service (DoS) attacks of the time, it would be a particularly inconvenient problem for future light clients that need to verify proofs of validity or invalidity.
A non-disruptive way of introducing the change
The solution was to place a hard cap on the size of objects that can be stored on the blockchain. The limit was set slightly higher than what could actually be deployed under the gas limit at the time, designed to block only future risk without disrupting deployments that were already possible.
The fork in which it was applied, and its status
This EIP was included in the Spurious Dragon hard fork (EIP-607) and took effect from block 2,675,000. Its status is Final, meaning the specification is settled and will no longer change.