A state proof connects an account record to an accepted state root.
LET’S PICTURE IT
A directory path can authenticate one record inside an official ledger snapshot.
SEE IT FOR YOURSELF
Build a root and follow one membership proofStep 1 / 4
This example hashes UTF-8 A, B, C and D. The displayed hashes are abbreviated, and the tree uses the playground’s sorted-pair convention.
This example hashes UTF-8 A, B, C and D. The displayed hashes are abbreviated, and the tree uses the playground’s sorted-pair convention.Each pair of raw child hashes is sorted, concatenated and hashed. The resulting parent fingerprints commit to their children.Hash the two parents under the same rule to obtain one root commitment. Changing a leaf changes the hashes on its path.The highlighted siblings are B and hash(C,D). Starting with A, the verifier recomputes its path and compares the final result with a trusted root.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Choose the account and block
The requested address and block context determine the claim. An account record at one block does not automatically describe its state at a later block.
Verify the key path
The account proof follows the state trie’s specified key and node encoding rules. It cannot be checked by the sorted-pair playground algorithm.
Interpret the account record
The familiar account model includes nonce, balance, storage root and code hash. Those fields have distinct meanings and do not directly contain all contract storage.
Authenticate the state root
A server can supply proof nodes, but the accepted state root must come from the verifier’s trusted chain context. Otherwise the proof can authenticate an irrelevant invented snapshot.
Follow the proof model
accepted state root
→ account trie path
→ account record
→ storage root for further storage claims
Binary examples use the stated local playground convention. They are not Ethereum account or storage trie proofs.