Limits of State Verification Post-Fork in Solidity

The goal is to verify the integrity of a deployed contract state after a network fork, but Solidity’s deterministic nature only guarantees that execution is identical when the block header and global state are the same.

Likely Explanation

Because a fork creates a new chain history, nodes that follow different fork branches may have divergent state trie roots even if their storage slots appear identical. Standard EVM verification, which checks execution given an identical header, cannot guarantee that the contract’s storage values match across all reachable fork histories.

Confirmed Facts

Research indicates that EVM state verification guarantees deterministic execution for identical block headers and state, but it does not automatically reconcile divergent fork branches. Documented mechanisms for cross‑fork verification are limited to per‑storage‑slot Merkle proofs (EIP‑1982) and explicit state‑root comparisons.

To verify state after a fork you must:

1. Identify the exact fork block number and obtain the expected state‑root hash for the contract at that block from a trusted full node.
2. Retrieve the contract’s storage slot proofs (e.g., via eth_getProof) for the relevant slots.
3. Compute the Merkle root of the proof and compare it with the expected state‑root hash.
4. Confirm that the client software uses the same fork definition (chain ID, hard‑fork parameters) and version as the reference node.

If any of these steps fail, the contract state may be inconsistent with the forked chain, and the verification cannot be trusted.

Please provide the fork block number and the expected state‑root hash for the contract at that block so the verification steps can be applied.