Useful Links:

• Main Verkle Branch: execution-spec-tests@verkle/main
• Tree Conversion Tests Branch: jsign/execution-spec-tests@jsign-eip7748 (to be merged in verkle/main when possible)

TODO List:

1. Rebase Branch:

   • Rebase the verkle/main branch to the latest main.

2. Configurable Stride for Tree Conversion Tests:

   • Currently, a fixed stride of 7 is used.
   • Make the stride configurable to avoid hard-coded assumptions.

3. Fix Tree conversion tests hacks

   • Fix hacks mentioned in this open PR.

4. Post-State Assertions in Verkle:

   • Not supported today in any kind of tests.
   • In non-tree-conversion tests, witness assertions are primary, and post-state checks are optional, so we survived until now.
   • For tree conversion tests, post-state assertions are critical because there is no witness.
     • The current method relies on debug outputs (vkt.json), which is brittle and may break during refactoring.
     • We need to verify not only that a state exists but also its location (in the new tree versus the old tree). We might need to think a bit how to do this.

5. EIP6800Transition Fork Configuration:

   • The current configuration always injects a prefix and suffix block.
     • I don't remember why we did this, is it strictly necessary? e.g., for tree conversion tests, the first and last (forced) blocks don't add any value usually. And if I wanted, I could create them as part of my test.
     • For some tree conversion tests, I'm interested in executing some txs before the conversion starts (or reaches some accounts if already started). Ideally, I would like to put txs in this forced first block before the conversion starts, but since this is added by the testing framework, I can't do it as a test writer. What I ended up doing is putting the txs in the first block in the conversion and I had to "shift" the account to be converted in the second block in the conversion. This is a bit wasteful!
   • It activates both EIP-7612 (overlay tree) and EIP-7748 (conversion). Since EIP-7748 "effective activation" depends on stride, are we OK with:
     • Using EIP6800Transition with stride=0 for EIP-7612-only tests?
     • Or, creating a separate EIP6800TransitionWithoutConversion configuration?

6. Additional Assertions:

   • Consider adding an assertion to determine if a block is the last one in a tree conversion?
   • Consider implementing a method to deterministically predict the number of blocks required for a conversion, ensuring the testing framework always produces the correct count? (Note this isn't equivalent to previous bullet)

7. Reorg-like Tests:

   • As suggested in the tree-conversion test design doc and discussed during the retreat, implement tests that simulate reorg scenarios.

I think the above are reasonably ordered by importance/sanity.