fix(provider): handle storage wipes in batched persistence

[decofe]

Summary

• detect whole-storage-trie deletions before using the node-level disjoint merge
• fall back to the existing wipe-aware batch merge for those rare persistence batches
• cover the reported three-block storage-v2 persistence failure and verify the trie is cleared

Tests

• cargo test -p reth-provider --features partial-persistence providers::database::provider::tests::test_save_blocks_
• cargo +nightly clippy -p reth-provider --all-targets --features partial-persistence -- -D warnings
• cargo +nightly fmt --all -- --check

Prompted by: @mattsse

[klkvr]

cyclops audit

[github-actions]

cc @klkvr

Cyclops audit event published. View workflow run

Config: config: default, iterations: default, hours: default

[tempoxyz-bot]

👁️ Cyclops Review

Reviewed the current PR head 4c8b95290ac2769c0e19dad95b819c324f99e9c4 after head drift. The storage-wipe fallback still has actionable issues: two findings are inline on the changed fallback, and one defense-in-depth item is body-only because its primary line is outside the diff.

🛡️ [DEFENSE-IN-DEPTH] The sibling hashed-state disjoint merge still panics on wiped storage

Severity: Low
File: crates/storage/provider/src/providers/database/provider.rs:780

The new guard only protects the trie update merge. The same save path still calls HashedPostStateSorted::disjointed_merge_batch(&batch, &mask) before the guarded trie merge, and that implementation contains release-mode assert!(!storage.wiped) checks (crates/trie/common/src/hashed_state.rs:729-731 and :747-749). Current in-tree producers appear to encode destroyed storage as explicit zero-valued slots rather than wiped = true, so this is latent today, but downstream/future providers can still panic the persistence task instead of returning a typed error.

Recommended Fix: Mirror the trie fallback for HashedPostStateSorted when hashed storage is wiped, convert the asserts into typed provider errors, or explicitly enforce/document that block hashed states must never carry wiped storage.

Reviewer Callouts

• ⚡ Proof-v2 cursor resets: Add an end-to-end proof-v2 regression with mixed unknown/known parent target groups over a wiped storage trie; the unit-level cursor PoC covers the state machine, but the production reset site should be pinned too.
• ⚡ Producer semantics and observability: The current comments/tests document that serial updates can contain empty/transient wipes, but operators still cannot tell when partial-persistence masking has been disabled. A metric around the fallback would make the operational tradeoff visible.
• ⚡ Hashed wipe assumptions: If future code starts propagating HashedStorageSorted::wiped, both the hashed-state disjoint merge and the hashed cursor reset path need the same treatment as trie-side wipes.

[tempoxyz-bot]

🚨 [SECURITY] InMemoryTrieCursor::reset() can drop the wipe that this fallback relies on

This safety claim depends on the masking suffix keeping a wiped storage trie opaque. On current head, InMemoryTrieCursor::reset() (crates/trie/trie/src/trie_cursor/in_memory.rs:371-381) always changes DbCursorState::Wiped to NeedsPosition. proof_v2::ProofCalculator::proof_inner calls self.trie_cursor.reset() between overlapping/backward sub-trie target ranges (crates/trie/trie/src/proof_v2/mod.rs:1564) without calling set_hashed_address again. After this branch persists the batch unmasked, a subsequent seek can read stale DB nodes that only the suffix wipe was supposed to hide.

Recommended Fix:
Preserve DbCursorState::Wiped across reset() (or persist a separate wipe flag and reconstruct the state), and add cursor plus proof-v2 regression tests for wiped storage overlays across reset.

[tempoxyz-bot]

⚠️ [ISSUE] Batch-wide fallback uses producer-dependent is_deleted semantics

contains_storage_wipe treats any StorageTrieUpdatesSorted::is_deleted in the persisted prefix or mask as a whole-storage wipe and switches the entire batch to unmasked merge_batch. The serial TrieUpdates::finalize path sets this flag for every destroyed account, including storage-less accounts (crates/trie/common/src/updates.rs:153-156), while sparse trie updates normally do not set it (crates/trie/sparse/src/state.rs:345, :415-417). Since timeout handling races sparse results against serial fallback (crates/engine/tree/src/tree/state_root_strategy/mod.rs:1185-1223), this can make physical trie persistence non-deterministic and silently disable partial-persistence masking for a whole window.

Recommended Fix:
Normalize the flag semantics and narrow the fallback to actual/per-account storage wipes. Add observability for when this fallback disables masked persistence.