Update EIP-7612: Add test cases for EIP-7612 overlay tree

EIPS/eip-7612.md

@@ -155,22 +155,95 @@
 
 ## Test Cases
 
-<!--
-  This section is optional for non-Core EIPs.
-
-  The Test Cases section should include expected input/output pairs, but may include a succinct set of executable tests. It should not include project build files. No new requirements may be be introduced here (meaning an implementation following only the Specification section should pass all tests here.)
-  If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. External links will not be allowed
-
-  TODO: Remove this comment before submitting
--->
+The following test cases should be implemented to verify the correct functionality of the overlay tree:
+
+### Test Case 1: Reading from MPT when data is not in VKT
+
+1. Setup: Initialize a state with MPT containing account A with balance 100 ETH
+2. Action: Read account A's balance after fork activation
+3. Expected: Balance should be 100 ETH, read from MPT
+
+### Test Case 2: Writing to VKT and reading back
+
+1. Setup: Initialize a state with MPT containing account A with balance 100 ETH
+2. Action: After fork activation, update account A's balance to 200 ETH
+3. Action: Read account A's balance
+4. Expected: Balance should be 200 ETH, read from VKT
+
+### Test Case 3: Writing new account to VKT
+
+1. Setup: Initialize a state with no account B in MPT
+2. Action: After fork activation, create account B with balance 50 ETH
+3. Action: Read account B's balance
+4. Expected: Balance should be 50 ETH, read from VKT
+
+### Test Case 4: Storage slot operations
+
+1. Setup: Initialize a state with account C having storage slot 0x1 = 0x5 in MPT
+2. Action: After fork activation, update storage slot 0x1 = 0x10
+3. Action: Read storage slot 0x1
+4. Expected: Value should be 0x10, read from VKT
+5. Action: Read storage slot 0x2 (not set in either tree)
+6. Expected: Value should be 0x0
+
+### Test Case 5: Code storage and retrieval
+
+1. Setup: Initialize a state with account D having code "0x60806040..." in MPT
+2. Action: After fork activation, deploy new contract E with code "0x608060..."
+3. Action: Read code from contract E
+4. Expected: Code should be correctly chunked and retrievable from VKT
+
+### Test Case 6: Block header state root
+
+1. Setup: Initialize a state before fork activation
+2. Action: Create block at timestamp < FORK_TIME
+3. Expected: Block header state root should be MPT root
+4. Action: Create block at timestamp >= FORK_TIME
+5. Expected: Block header state root should be VKT root
+
+### Test Case 7: Reorgs across fork boundary
+
+1. Setup: Initialize a state before fork activation
+2. Action: Create blocks A1, A2, A3 with timestamps < FORK_TIME (MPT blocks)
+3. Action: Create blocks A4, A5 with timestamps >= FORK_TIME (VKT blocks)
+4. Action: Reorg by creating competing blocks B3, B4 where:
+   - B3 has timestamp < FORK_TIME (MPT block)
+   - B4 has timestamp >= FORK_TIME (VKT block)
+5. Expected: After reorg, state should correctly reflect:
+   - Blocks A1, A2 remain in the canonical chain
+   - Blocks A3, A4, A5 are removed from the canonical chain
+   - Blocks B3, B4 are added to the canonical chain
+   - All state transitions are correctly applied/reverted
+6. Action: Create additional blocks B5, B6 with timestamps >= FORK_TIME (VKT blocks)
+7. Expected: State continues to be correctly maintained in the VKT
+
+### Test Case 8: Complex reorgs with multiple tree switches
+
+1. Setup: Initialize a state before fork activation
+2. Action: Create blocks A1, A2 with timestamps < FORK_TIME (MPT blocks)
+3. Action: Create blocks A3, A4 with timestamps >= FORK_TIME (VKT blocks)
+4. Action: Perform a deep reorg with competing chain B:
+   - B1, B2 with timestamps < FORK_TIME (MPT blocks)
+   - B3 with timestamp >= FORK_TIME (VKT block)
+5. Expected: System correctly switches from chain A to chain B, with proper state transitions
+6. Action: Perform another reorg back to an extended chain A:
+   - Original A1, A2 (MPT blocks)
+   - New A3', A4', A5' with timestamps < FORK_TIME (MPT blocks)
+   - A6' with timestamp >= FORK_TIME (VKT block)
+7. Expected: System correctly:
+   - Reverts all changes from chain B
+   - Applies all changes from the extended chain A
+   - Maintains correct state roots (MPT for blocks before FORK_TIME, VKT after)
+8. Action: Create additional blocks A7', A8' with timestamps >= FORK_TIME (VKT blocks)
+9. Expected: State continues to be correctly maintained in the VKT
 
 ## Reference Implementation
 
- * `transition-post-genesis` branch in `github.com/gballet/go-ethereum` implements this when setting `--override.overlay-stride=0` on the command line.
+ - `transition-post-genesis` branch in `github.com/gballet/go-ethereum` implements this when setting `--override.overlay-stride=0` on the command line.
 
 ## Security Considerations
 
 <!--
   All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. For example, include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
 
   The current placeholder is acceptable for a draft.