Transaction Trie

Overview

When a block is built, its transactions are encoded according to protocol rules and inserted into an authenticated structure, often using their position as a key. Hashes connect the lower nodes to one root value.

Any change to a transaction, its encoding, or its position changes the root. Validators independently reconstruct the transaction trie or commitment and compare it with the value in the block header. A mismatch makes the block invalid.

An inclusion proof provides the encoded transaction plus the nodes needed to reconstruct the path to the root. The verifier must also establish that the block header is canonical and sufficiently final. A valid proof against an orphaned block proves inclusion only in that discarded branch.

The transaction trie is separate from state and receipt structures. A transaction can be included in the transaction trie but fail during execution. The receipt trie records execution outcomes, while the state root commits to resulting ledger state.

Developers should follow exact serialization and indexing rules. A logically identical transaction represented with different bytes can produce another hash and root. Transaction tries provide compact integrity for ordered block contents, but they do not by themselves prove successful execution or business payment completion.

Proof consumers should validate transaction position and encoded bytes exactly. A proof for one index cannot be reused for another transaction, even if human-readable fields look similar. Historical tools should preserve the block header and proof nodes together. Protocol upgrades that change transaction envelope types must define how old and new encodings enter the trie so clients can reconstruct roots consistently across the transition.