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