Unlimit the contract code size so that users can deploy a large-code contract without worrying about splitting the contract into several sub-contracts.
I think you’re going to get a ton of pushback from core devs on this. I’d recommend bringing this up in the Eth R&D discord to gather some consensus before going forward with standardization.
Glad to know that Arbitrum has already enabled this. Out of curiosity, I am wondering if Arbritum has a customized solc to support this feature. I know that current solc will stop compilation if the contract size exceeds 24KB.
Because the EIP does not give any considerations to the security rational explained in EIP-170 (where the restriction was imposed) nor explanation for why those concerns are either mitigated or no longer valid I feel it should be tabled until such details are added and accepted.
Thanks for the comment. Introducing proper gas metering adjustment to avoid possible attacks in EIP-5027 is to address the issue found in EIP-170, especially
O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution.
The basic idea of gas metering is to treat calling a contract with size > 24K as that of calling multiple contracts with size <= 24K. E.g., calling a contract with size 24K + 1 will charge the gas as calling two contracts (2 * 700 gas).
Further, to avoid DoS attack, EIP-5027 recommends implementing a mapping from codehash => codesize at the client side, so that EVM can pre-charge the gas of calling a potentially-large contract with O(1) KV get cost. This should eliminate the DoS attack considered in EIP-170 without changing the current Ethereum state structure.
All of above will be presented to AllCoreDev meeting. Free to let me know if you have further comments.
(a) this rationale belongs in the EIP.
(b) “preprocessing the code for VM execution” is a separate concern from “reading the code from disk.” This needs separate exposition as the attacks are unique to EVM preprocessing.
(a) We are collecting the feedback from ACD to complete the Rationale and Security Consideration subsections, but the current rationale should be a minimal version to illustrate the idea.
(b) Preprocessing is basically the JUMPDEST-analysis of the EVM code, which is part of the 700 call gas to my understanding.
However, looks like the current JUMPDEST-analysis of the EVM code is not correctly metered, and EIP-3860 is tracking that (EIP-3860: Limit and meter initcode).
My weakly held position is that any adjustments to how contracts are costed and sized for creation should be done in conjunction with the other EOF related changes and should require a contract in an EOF container. Legacy code deployment should remain unadjusted.
Increased contract size would be a nice incentive for developers to switch over to EOF containers.