# VIC 2024-07-01 Notes

July 1 2024 verkle implementers call VIC

rough meeting nodes

## Team Updates
- Guillaume/geth merged a new 4762 spec adjusting gas and access witness costs; includes changes discussed at Nyota
- Tanishq Jasoria - nethermind is providing snap/2 on verkle devnet. clients can join and sync verkle devnet (this presumably is snap/2 implmentation)
- Besu working on storage format, parallelization

## Testing
- questions regarding test data format, Guillaume and Spencer to discuss
- mario/spencer contact, use discord (testing, ref tests transition etc)

## EIP updates
- EIP 2935 now changes to system contract spec to behave more like 4788, in response to feedback. Guillaume expects teams will discover the requested changes do not work in verkle as intended and this (conformed) behavior change will be reverted
- EIP 7709 essentially updates the gas cost of 2935 post-verkle
- also specifies how all system contracts should behave.
- EIP 158 - Guillaume will lobby for removing eip-158 at next acd. there was no opposition on the call.
- Danno raised concerns about eip-158 empty contract rule for system contracts without deployed code. He proposed a change to account for L2s which might not correctly/completely implement 2935
- It was highlighted that the implementation specifics around EIP-7702 might impact or be impacted by removing eip-158

## Preimage distribution convo
- Besu lobbied for including pre-image keys in the execution witness. In the short term, to aid in sync during the transition, and in the long-term to aid in parallelizing transaction execution in blocks on import
- Guillaume is going to publish a proposal regarding exec witness, parallelization
- There was a question regarding verkle sync, what is the format used for the flat db for nethermind (snap/2). Does the flat db use keccak or stem? Tanishq clarified - stem.
- Guillaume indicated the flat db design space needs to be explored more.
- He offered up that the exectuion witness could include stem(only) that are accessed by transactions via a bitmap index. He will include this in his proposal.

- EIP-4762 updates since Nyota - significant gas cost / access witness changes:
- https://github.com/ethereum/EIPs/pull/8707
- check the changes, He would like teams confirm/disconfirm at a break-out session next week (july 8th at the VIC meeting time) whether the spec is complete and fully specified.

# Post VIC

Gary/Karim getting on the same page, we had different understandings of certain parts of Verkle.

- transition range is based on keccak or preimage
- 🤔 gary thinks keccak, karim thinks preimage

- Gary wants to confirm how we can verify that transition ranges are completely covered by the stateDiff in imported/proposed blocks.
- Gary thought we needed preimages to verify statediff is complete,
- ✅ Karim said that it should be the responsibility of each client to individually handle the transition ranges, so there isno need to reverse the pedersen hash in the witness back to keccak key to verify completeness/inclusion

- 🧠During the Regarding execution witness only needing stems vs stems and suffixes for parallelization, we agreed that only having stems (which Guillaume was offering) would enable parallelization, but only at a "gross" level of granularity. Having the suffixes accessed per stem would allow for a greater degree of parallelism if the one contract was accessed by multiple transactions, but the storage suffix accesses were independent.

- Gary thought execution witness would be stored with block/headers
- ✅ Karim thinks it is a separate element coming from the CL which should be stored apart from chain data, and would only be tracked during sync (or perhaps near head). This would jibe with some of the points Guillaume was making during the preimage distribution conversation.

- Flat-db-during-transition strategy converstation regarding performance (not causing read amplification) versus not causing code complexity or feature roadblocks
- performance: existing bonsai flat db should account for both merkle trie and verkle trie flat values, so that we do not have to check verkle first and fallback to merkle if verkle key is not found. Doing this is good for read performance during transition, but can complicate the snap/1 implementation, IF besu is going to serve snap/1 during the transition while the merkle trie is frozen-but-not-deleted.
- simplicity: initially implement with the read-amplification penalty, keep snap/1 support simple. This is conservative in a code complexity sense, but will definitely have a read amplification effect that will slow down besu block execution speed until the transition finalizes. This is undesirable for several reasons including the expectation that new snap-syncing clients will have to 'full sync' blocks starting at the block the merkle trie is frozen. Besu full sync is slow already and making it even slower would make for gradyally worsening sync behavior during the transition window.

# What we want to verify:
* transition range ordering (keccak or preimage)
* find a reference that spells this out explicitly

# Open question(s) \ TBD:
* how many leaf nodes can besu handle per transition block without impacting performance significantly.
* do we want to serve snap sync or be bad citizens and rely on other clients to serve snap/1 ?
* Gary: AFAIK, this requires nodes to keep complete state. Gary thinks geth is planning to incrementally delete PMT and might not be planning to serve snap/1. Karim thinks Nethermind would not be a viable snap/1 option during transition due to their storage format.
* can we handle a full sync strategy for clients which snap sync during transition

* in execution witness bitmap structure we want to have stem with (leaf/slot) suffix (for better parallelization)