Verkle Implementers Call #8

[jrudolf]

Get added to the calendar event here

Meeting Info

• November 28, 2023, 14:00 UTC
• Duration: 60 minutes
• Meet link: https://meet.google.com/odf-tghm-ttu
• Recording: https://youtu.be/UOEfqSfE4wg

Agenda

1. Client team updates
2. Kaustinen relaunched
   1. verkle-gen-devnet
   2. see here for more info
3. Proposal for new perf optimization for the conversion (MPT -> Verkle)
4. BLOCKHASH opcode for new stateless clients
   1. Discussion in R&D Discord
   2. Note from Micah: two plans I have seen are to include the needed mappings in the witness, or move the mapping into the state trie (so BLOCKHASH opcode is basically just an SLOAD of sorts).
   3. Note 2: also need to think about BLOBHASH in a post-dencun world
5. Verkle proof verification precompile
   1. Proto’s proposal for adding MPT to the precompile
   2. Also, adding new feature to the precompile so you can determine whether the key is in the witness or not. Verifying keys belong to the witness.

[holgerd77]

Hi everyone, Holger from the JavaScript team here, not sure if I can make it on today's call but generally planning to join the Verkle calls more often in the future.

Some notes on the 4. BLOCKHASH opcode discussion respectively sorting this a bit, so there seems to be the following options:

1. Include mappings in the wittness. This adds some significant amount of extra data to the block size, if all mappings are used something like at least 10KB+ (32 Bytes * 256 just for the hashes). This solution also disallows/hinders dynamic statless execution contexts (e.g. running arbitrary eth_calls for a stateless client, e.g. in combination with getting state from somewhere else (portal network e.g.)), at least for the case that there is no alternative way to retrieve num -> hash mapping for the last 256 blocks (also by portal network e.g.?).

2. move the mapping into the state trie. I wonder what this means? Is this some sort of specialized solution? Or does this mean to deploy this as as an additional (system) contract?

Micah mentioned in the discussion that it is pretty much unlikely that BLOCKHASH will be deprecated. Guess it nevertheless can't hurt to put this into the discussion here at least as a theoretical option and not unnecessarily narrow the discussion from the beginning, since BLOCKHASH definitely is a factor of making stateless execution harder (or to say: "less pure").

3. (theoretical) Deprecate BLOCKHASH opcode. This will break contracts.

Maybe (?) there is room for a fourth option to discuss which would be to narrow down on the 256 blocks range by HF or at least analyze/discuss what the effects would be if this would be lowered to a "waitable" number (so that stateless clients have to wait for max 10 blocks/slots e.g. until all mappings are available).

4. Lower BLOCKHASH range from 256 to x. Likely also will break contracts.

Here are some numbers for orientation:
256 blocks: 51,2 min
100 blocks: 20 min
50 blocks: 10 min
10 blocks: 2 min

Ok, maybe this helps a bit for sorting. 🙂

Someone any other possibilities/solutions in mind?

[holgerd77]

And some first round googling adds this e.g.:

• https://ethresear.ch/t/the-curious-case-of-blockhash-and-stateless-ethereum/7304/4

[jrudolf]

Closing in favor of #917