this is a good question, i guess you mean since codesize==0 can be inferred from the codehash being the empty codehash right? i would say it reduces implementation complexity to always have the codesize in there, but i’m not particular about this, if core devs want to add that case for optimization reasons i’m happy to change it.
Yes good point, actually this makes it easier, so don’t do it if code size is 0 (so for newly created EOAs do not add the codeSize field since it can be derived from codeHash that it is 0).
One might consider to only add the codeSize field if the code > 24 KiB, but I’m not sure if I like that. The nice thing of this is that there is no difference between “old accounts” and “new accounts” of <= 24 KiB. However it removes the in-protocol ability to get the code size quicker (when one reads the new account it thus directly has the codeSize in it and we don’t have to lookup codeHash)
Decrease for gas cost from 4 to 2 per word was done without reasoning. Gas cost for state access is already underpriced, depending on other EIPs that got inclued, it could even be increased in this PR. I would leave it as is, and evaluate depending on other EIPs
i think the EIP originally had 2 gas per word. 4 gas per word is weird to me, since the marginal cost per byte is actually higher than the cost per byte for the protected initial 24kb
I think 2 is fine since EIP-3860 defines gas paid for initcodes (for JUMPDEST analysis) is 2 per 32-byte chunk, and the reading part is already paid for in EXCESS_CODE_COST.
saparate table is still needed for geth and nethermind iirc, so this needs to stay
is it? if it is added to account tuple, the codesize does not need a separate lookup
I don’t think so, however for clarity maybe note in the EIP that if the account has no codeSize field it is implicit (on Mainnet) that it is lower than 24 KiB and EXCESS_CODE_COST is thus zero.
Why? EIP-170 was introduced in the Spurious Dragon fork, before that fork there was no limit. But on Mainnet there could have been no contract larger than 24 KiB deployed, because: at the fork block 2675000 of Spurious Dragon the gas limit was 2 million, and it costs 200 gas when deploying a contract per byte. So one could only deploy at most 2_000_000 // 200 = 10_000 bytes of contract (not taking into account the extra costs which have to be paid).
I’ll note this here as my stance, coming from the prototyping team (but my personal opinion) and thus not from a client team:
This EIP solves the problem of the max code size partially (it still has an upper bound). However, due to EIP-7825 and due to possible increases of code size deposit cost (gas repricing) this limit is already implicitly there, being the tx gas cap of EIP-7825 (2^24) and the code deposit cost per byte (200) the limit is ~83KB if we would have no capped limit of EIP-170`s 24 KiB. Due to gas repricing for storage costs this might decrease. Note that this analysis does not take into account the extra cost like tx intrinsic cost, memory, calldata, etc.
It is clear however that we should increase the max code size, as dealing with code which needs more than the limit of 24 KiB is now either a task of the compiler (not sure if this is already being done) or developers have to figure this out themselves (using the diamond pattern). Also the limit imposed years ago really has to be lifted.
However I feel that this EIP solves the problem only short-term. The problem I see is that you always pay for large contracts, even if you don’t use the code. It’s only “fair” if the extra cost you pay is cheaper or close to what you would pay without this EIP. Without this EIP, you would need extra contract(s) to call+load (paying EVM opcode overhead + warming up that account).
I feel that this EIP will, once shipped, first be used “greedily”. Then after a while people realize that based on the usage patterns of the contracts they deployed, it makes optimize the sizing of the contracts and what code is put together to reduce the gas costs which users pay.
I’m not sure what this means in practice, but I think that the size of contracts we will see in practice are close to the current max of 24 KiB, where the oversized contracts make sense because (1) all the code is always being used and (2) it is more expensive to split up the contracts in 2, because of the EVM overhead costs + warming of that second account.
Therefore after analysis of these > 24 KiB contracts developers will group together contracts which are, if you would execute the same (but now gas-golfed/optimized) code (but now optimized over split contracts), cost less than the current. So I think that due to gas golfing we will see only slightly oversized contracts. Only contracts which always use all the code will be “largely oversized” (> 48 KiB).
Although already DFId, EIP-2926: Chunk-Based Code Merkleization makes users pay for what they use, and not pay for unused code. It also removes the code size limit at all (so future-proof). I want to add that my feeling is that this EIP 7907 will add a feature which will only be used short-term (adds code debt). This EIP will solve the drastic need for the code size increase, but I think this is a short-term solution, and from a long-term protocol perspective I would rather have a long-term solution like EIP-2926.
if the only reason to push 7907 is an expedient increase of the code size limit, just raise the code size limit to a higher but still safe value. No need to introduce a new gas model for that, which will give rise to the gas golfing issues you described.