Verkle Implementers Call #19

[jrudolf]

Get added to the calendar event here

Meeting Info

• June 17, 15:00 UTC
• Duration: 60 minutes
• Meet link: shared in #verkle-trie-migration Eth R&D Discord right before the call
• Recording: https://youtu.be/fwBCbA-28H0
• Thread recap: https://twitter.com/rudolf6_/status/1803684902996451797

Agenda

1. Client team updates
2. Testing updates
3. Code size in Verkle
4. Testnet relaunch
5. Preimage distribution (background reads here and here)

[shemnon]

I’d like to raise the issue storable code size in the verkle layout. Currently it is set at 64k max. While larger than the current 24k max I think it would be more responsible to set a much higher max (like 2GiB, 2^31). My reason for this is I expect pressure from smart contract developers to want contracts larger than 64k, if not on mainnet then on L2s that adopt or genesis with Verkle. Happy to discuss details on the call, (This is also orthogonal to EOF, in a world without EOF I would still be making this request, now)

[jrudolf]

@shemnon sounds good! fyi code_size is currently set to 4 here: https://github.com/ethereum/EIPs/pull/8550/files#diff-a7ef47379aef6f6303eb68f28f81141850cf251c93d57e93dc4f5ed6f9b4b94bR171 (thx to ignacio for pointing this out)

[shemnon]

That puts us at 4 GiB for reported code size (which should be sufficient for at least 10 years). But does the actual encoding of the code storage in the trie support all 4GiB of storage?

[jsign]

That puts us at 4 GiB for reported code size (which should be sufficient for at least 10 years). But does the actual encoding of the code storage in the trie support all 4GiB of storage?

If the size has 4 bytes, then the maximum code size is $2^{32}$, which means a ~maximum of $\frac{2^{32}}{32}=2^{27}$ code-chunks. Doing /32 is assuming a chunker without overhead which isn't correct -- so let's say $2^{28}$ max chunks to have a big upper bound (2x overhead).

Looking at the current tree embedding, the last chunk would map to $2^{28}+CODEOFFSET=2^{28}+128 < 2^{29}$.

For storage slots that don't live in the account header, we see they're offseted by MAIN_STORAGE_OFFSET. This means the first storage-slot outside the account header is mapped after $256^{31}=2^{248}$.

$2^{29} < 2^{248}$, which means that the last chunk shouldn't collide with the first storage slot living outside the account header.

(Please double-check the math!)

[shemnon]

That should be sufficient. I'm still wondering why the verkle implementers I asked and the meetings I mentioned it in all said 64k was the limit. Was the code size originally only 2 bytes?

[jsign]

That should be sufficient. I'm still wondering why the verkle implementers I asked and the meetings I mentioned it in all said 64k was the limit. Was the code size originally only 2 bytes?

Uhm, I don't remember that part of the call but maybe was some confusion?

Technically, in today's current state of the EIP the code-size had a fully dedicated subindex, which means 32-bytes.

There's now a new proposal for 6800/4762 (originally proposed by Vitalik in Kenya) to group many of the account values in a single 32-byte. So this idea of a bounded code-size is quite recent, and here's the TL;DR of the bounds.

Maybe at some point before this PR someone was considering using 2-bytes? But if that happened, I haven't seen that in any formal PR or proposal. Or maybe is a very recent idea that someone might want to propose.

[shemnon]

It was on-site at nyota that I asked about and was told the 64k limit, not on a call. Looks like whoever I asked didn't have the spec memorized and was going off of other implementation details.

As for the new proposal anything more than 32 bytes will cause implementation issues as some languages don't handle long indexes very well, indexing by chunk gets us to 128 Gigs, which used to be a decent hard drive. And until we get well into billions and trillions of gas for a block limit deploying that large of a contract is impossible. I expect it will easily last us more than 10 years. (5 years is my horizon for "needs a good reason not to do it now")

[gballet]

It was on-site at nyota that I asked about and was told the 64k limit, not on a call. Looks like whoever I asked didn't have the spec memorized and was going off of other implementation details.

that was me, and indeed I remembered that was 2 bytes.

The current spec draft says 4 bytes, but it should be 2 as this would force us to allocate 2 extra bytes out of the 5 that would be "reserved" for a feature we won't really be able to handle: namely, how do we deploy a 2GB contract? This looks like it will take several weeks of design work, and meanwhile these 2 extra bytes are allocated and not being used. Let's discuss this during the VIC, I'm happy to change my mind if there is a shorter-term use case.