Typo EIP-76i84 -> EIP-7684

Wait is it the right EIP though?

Ah I think you meant EIP7864?

The comment on "binary trie format" can have more clarity. I'm personally not sure what it's referring to.

(FIO = First Instruction Offset (Assuming this is the abbreviation, I think great to mention somewhere before for clarity 😄 👍 ))

(Just writing this down for myself for clarity)

If we have C = PUSH32 x STOP then we get:

0x00 0x79 x[1:31] (chunk 0)
0x02 x[31:] 00 (chunk 1)

it's confusing that x is indexed starting from 1 and also that the upper bound b in [a:b] isn't included, but it's correct.

So VERSION_KEY is max(u256) -> this key is thus 0xffff..ff? (32 bytes key?). The value is 0x00 and not 0x? Storing 0x00 in a storage trie in MPT would delete the value, not store it (from EVM point of view). Likely want to set this version to 1 maybe for clarity? Or make this indeed the empty bytes and not store this? (Difference between storing nothing, the empty bytes, and the 1-byte 0x00, so three different options here I think!)

That's a good point, I think it should be version 0 and then set to 1 if there is another version in the future.

I think for MPT implementations the leading zero bytes are stripped of the key... right?

I think for key we can just use the big-endian reprenstation of i, with stripped zeros at the front (?). We might reserve however in the code trie the keys of 4 bytes for code sections and thus reserve anything else (> 4 byte keys) to store different things (I think this is the idea?).

Leading zero bytes are preserved in the key (see geth's imp). And if we do strip them off, then we might run into key collisions.

(I would argue hours here, we have 1.5M+ unique codeHashes and not sure how many accounts we should transition to here)

I think you meant that the transition process should read all accounts instead of contracts? At least in Geth, there's no way of iterating only the contract accounts.

The transition does take about 1 and half day as we need to iterate all of the accounts, but the actual code conversion time should only take minutes. I think we can add more clarifications between the transition and the code conversion. Or we don't have to mention this code conversion part at all.

pushing some update in a minute, let me know if that solves your questions.

This process has to be specified, especially for newly created accounts. For new accounts we should thus dump (?) the new format. For the iterator, we thus skip over the already-converted accounts? As remark this conversion thus only works if it is not possible to create more than ITERATOR_STRIDE new accounts per block (?) otherwise the iterator will never end (theoretical DoS vector, in practice this should not happen).

Assuming 30M gas limit, new account creation occurs only via ether transfers (21000 gas cost).
30000000 / 21000 = ~1428 accounts per block

So the current ITERATOR_STRIDE value will not be a DoS vector.

I agree further explanation in this procedure is required. Too much stuff in the air otherwise.

Does this EIP remove the max code size limit?

200 gas/byte deposit -> 500 gas/byte deposit costs are clear in the EIP, but not the 200 warming read costs. What is this and when is this being charged?

reformulated, let me know what you think.

(note: I did not check these URLs)

Why would you waste 32 bytes on this when a byte or 2 might suffice. Even u64

Ahh nvm. Storage slot is going to consume 256bits anyways I see. Can't we mix it with another field or similar? Such that both meld into one?

For reference. In current deployments, the gas/byte cost is 202 gas/byte. So we should at the very least match it or make it more expensive (as deploying is the cheapest way to introduce data within the DB). And it's way cheaper than a simple SSTORE with 625 gas/byte.

I agree further explanation in this procedure is required. Too much stuff in the air otherwise.

What does "safely" mean here? Any ideas on how minimal-hardware requirements (#9270) is affected by this parameters and if it can keep up?

We need to do a benchmark for this. One of the possible scenarios that I can think of:

With the given hardware, calculate the time taken to process the worst case, which is 50000 contract accounts, each with distinct bytecode and is 24kB. If the code size limit increases to 256kB, then we need to adjust accordingly.

We also need to simulate the worst case conversion on real-time block processing, since there is resource contention.

agreed, after the spec stage is done. So far, it's a back-of-the-envelope computation based on the performance of verkle.

Is this intended after each transaction, or after each block? (I would assume block?). I think this needs some pseudocode, we likely want to do the proposed logic as in the tree transition EIPs. Thus we iterate the tree starting on the "left" (lowest values when interpreting keys as big-endian) and iterate over the leaves, ITERATOR_STRIDE each time and either convert or do not convert, and leave the current key we are at in the database. (init value of this key is thus 0, and we start at that value)

I just realized that this might be a big problem, especially in the sense of EXTCODECOPY. I assume that we also charge these gas costs. We will need to analyze if this breaks anything, because this will now massively increase the cost of copying large amounts (for instance copying all the code of a contract).

Reading after 24 KiB limit does this incur a read cost of 500 gas? (It now says "written" which might be confused with code deposit?)

We also need to specify how we track the accessed code chunks. It is clear from a transaction which has non-reverting/aborting call frames. But what if a call frame aborts? Is the code accessed in that frame then still considered "accessed"? (I would assume: yes, but then we have to specify this 😄 👍 )

it is normal that this increases the cost of reading code, but I don't see how it would break contracts beyond requiring more gas.

Reading after 24 KiB limit does this incur a read cost of 500 gas? (It now says "written" which might be confused with code deposit?)

what do you mean by "code deposit"? the 500 is a cost you pay for writing code, not reading. The reading cost is 200, as explained by the warming comment on the next line.

, but then we have to specify this

it is specified, since we are talking about "warming" costs. Once this is warm, it's free.

This section is obsolete per current EIP rules so can be just removed.

I'd put this as the first case, as it is shorter, plus makes it clear what happens for EOAs.

Would perhaps add a comment that this is an "EOA" in practice.

I don't remember why we had this configurable, @s1na ?

Generally agree with picking this EIP and modifying it for today's context. Let's sort out most of the comments on this PR before merging.

Will approve from my side after that, just to avoid having inconsistent versions merged.

cc @s1na