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

The problem The current expectation is that a preimage file will be generated at the fork boundary, by clients which have preimages. The preimage will almost immediately be incomplete as new accounts and slots are written by subsequent blocks. Clients can save all new preimage values at the fork boundary, and combined with the preimage file, should have a complete set of preimage keys to use for the verkle transition. However if a client start snap syncing after the fork boundary, it would not have all of the new preimage keys since the fork. Since clients must stay within 128 blocks of head in order to snap sync, and the current expectation is that the frozen state will be incrementally pruned during transition, there isn't a viable way to "replay" blocks since the transition in order to save these new keys. Sync During Transition Option 1 If clients do NOT incrementally delete patricia merkle trie, syncing clients can still use snap/1 to get the complete frozen state, and replay verkle blocks since the transition to catch back up to head.