Contract code size limit
The EIP-170 proposal is an Ethereum Improvement Proposal that suggests a limit on the size of contract code. The purpose of this proposal is to prevent the creation of excessively large contracts that could potentially cause issues with network performance and scalability. The proposal suggests a limit of 24,576 bytes for contract code, which is roughly equivalent to 24 kilobytes. This limit would apply to all new contracts created on the Ethereum network. The proposal also suggests that existing contracts that exceed this limit should be grandfathered in and allowed to continue operating as they currently do. The rationale behind this proposal is to ensure that the Ethereum network remains efficient and scalable as it continues to grow and evolve. In summary, the EIP-170 proposal aims to limit the size of contract code on the Ethereum network to improve network performance and scalability. (Word count: 120)
Video
Original
Hard fork
Parameters
MAX_CODE_SIZE:0x6000(2**14 + 2**13)FORK_BLKNUM: 2,675,000CHAIN_ID: 1 (Mainnet)
Specification
If block.number >= FORK_BLKNUM, then if contract creation initialization returns data with length of more than MAX_CODE_SIZE bytes, contract creation fails with an out of gas error.
Rationale
Currently, there remains one slight quadratic vulnerability in Ethereum: when a contract is called, even though the call takes a constant amount of gas, the call can trigger O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution, and also adding O(n) data to the Merkle proof for the block's proof-of-validity. At current gas levels, this is acceptable even if suboptimal. At the higher gas levels that could be triggered in the future, possibly very soon due to dynamic gas limit rules, this would become a greater concern—not nearly as serious as recent denial of service attacks, but still inconvenient especially for future light clients verifying proofs of validity or invalidity. The solution is to put a hard cap on the size of an object that can be saved to the blockchain, and do so non-disruptively by setting the cap at a value slightly higher than what is feasible with current gas limits.
References
- EIP-170 issue and discussion: https://github.com/ethereum/EIPs/issues/170
- pyethereum implementation: https://github.com/ethereum/pyethereum/blob/5217294871283d8dc4fb3ca9d8a78c7d416490e8/ethereum/messages.py#L397
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all