# Verkle Transition, Preimage Distribution

## 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.

### Pros:
can serve snap/1 until the patricia merkle trie storage is truncated after the transition finalizes.

### Cons:
Back-of-the-napkin math indicates it would require roughly 25% additional storage during transition.

This still leaves a synced node with a "preimage gap" for keys/slots that occurred post-transition, up until the client completed state sync. If one of these sync'd nodes needs to propose a block with a range of keys to transition, it would not have a complete set of preimages to "know" what state has already been superseded in the verkle trie by blocks subsequent to the transition (prior to it having started sync)

## "Preimage Gap" Solution 1
Use snap/2 protocol to augment preimages. Add a message to the snap/2 spec that allows clients to request preimages for specific hashes (the new slots and accounts that have occurred since the fork). These are self-consistent and easy to verify. Clients, given the preimage file, should be able to determine which keys they do not have preimages for by iterating over storage.

### Pros:
Zero trust is required for a syncing client to 'catch up' to the head in terms of new preimages since the fork transition, regardless of when they started syncing.

### Cons:
Preimage messages in snap/2 might not serve a useful purpose after the transition. Arguably this could be a useful protocol feature for future transition efforts.

## "Preimage Gap" Solution 2
Include the preimage in the execution witness rather than (or in addition to) the hashed keys. This way the chain data itself can serve to 'catch up' from the static preimage file.

### Pros:
* can rely on weak subjectivity guarantees
* if preimages replace hashed keys, the execution witness slot key data would be smaller than full hashed slot keys
* including preimage key values in the execution witness can unlock partial parallel evm execution

### Cons:
* additional cpu is necessary for stem calculation and hashing is required
* ?