**Useful Links:**

- **Main Verkle Branch:** [execution-spec-tests@verkle/main](https://github.com/ethereum/execution-spec-tests/tree/verkle/main)
- **Tree Conversion Tests Branch:** [jsign/execution-spec-tests@jsign-eip7748](https://github.com/jsign/execution-spec-tests/tree/jsign-eip7748) (to be merged in `verkle/main` when possible)

**TODO List:**

1. **Rebase Branch:**
- Rebase the `verkle/main` branch to the latest `main`.

1. **Configurable Stride for Tree Conversion Tests:**
- Currently, a fixed stride of 7 is used.
- Make the `stride` configurable to avoid hard-coded assumptions.

1. **Fix Tree conversion tests hacks**
- Fix hacks mentioned in this [open PR](https://github.com/ethereum/execution-spec-tests/pull/1312/files).

1. **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.

1. **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?

1. **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)

1. **Reorg-like Tests:**
- As suggested in the [tree-conversion test design doc](https://hackmd.io/@jsign/tree-conversion-tests) and discussed during the retreat, implement tests that simulate reorg scenarios.

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