Rollback enabled shomei

[garyschulte]

PR Description

builds on #164 and #165. This is a claude-driven implementation of a trielog rollback facility in shomei.

Tested locally. It works as expected, and correctly errors when trying to roll back past a pre-eip-6780 selfdestruct.

Fixed Issue(s)

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

---

Note

High Risk
High risk because it introduces multi-step rollback reconstruction of historical world states and changes account/storage deletion semantics across in-memory, layered, and persisted storages, which can affect core state integrity and RPC results.

Overview
Adds a rollback path to reconstruct historical ZkEvmWorldStates from stored trie logs when snapshots are missing, via ZkWorldStateArchive.getOrLoadWorldState and a new multi-step rollBackToBlock that replays decodeTrieLogForRollback + accumulator rollBack on an ephemeral LayeredWorldStateStorage.

Extends worldstate storage updaters with removeStorageForAccount and wires it into account deletion in ZkEvmWorldState (including overlay tombstoning rules in LayeredWorldStateStorage), so storage-trie data is removed/hidden correctly during clears and rollbacks.

Updates trie-log decoding to support both forward decoding against an explicit WorldStateStorage and a dedicated rollback decoder, updates the virtual merkle-proof RPC to load/reconstruct the parent worldstate instead of requiring it to be cached, and adds an integration test suite with real trie logs to validate rollback behavior (including a documented failure case across pre-EIP-6780 SELFDESTRUCT).

^{Reviewed by Cursor Bugbot for commit d8c2952. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Rollback of account creation fails to remove account

High Severity

When rolling back a block that created a new account, the account is never removed from the trie. After rollBack swaps the trie log's prior/updated, the ZkValue ends up with prior=AccountX, updated=null, isCleared=false, isRollforward=false. The dynamic isCleared() method's backward-direction check (!isRollforward && prior == null && updated != null) fails because prior is now AccountX (not null) — the swap made the original "updated" into "prior". Since isCleared() returns false, the removal block in updateAccount is skipped, and since getUpdated() is null, no insertion happens either. The account remains in the trie, producing an incorrect state root. The integration test passes only because blocks 29–33 in the test data don't create any new accounts.

 

^{Reviewed by Cursor Bugbot for commit 584208f. Configure here.}

[garyschulte]

The cursor-bot's mistake: it assumes the "prior→AccountX swap" happens before isCleared() is evaluated, but isCleared() is evaluated on the unmodified TrieLogLayer ZkValue. By
the time the accumulator ZkValue exists with prior=AccountX, the isCleared=true value has already been computed and stored in isCleared_field. The criticism is invalid.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

There are 3 total unresolved issues (including 1 from previous review).

^{Reviewed by Cursor Bugbot for commit 4b33263. Configure here.}