Ethereum data — Transaction trie Simplified
An Ethereum node stores two types of data : block data and state data. State data includes world state trie, account storage trie, transaction receipt trie and transaction trie. Every block has one transaction trie. Transaction trie organises the transactions in the block into a tree structure, and the root hash is saved in the block header (as shown below). But why is it needed?
As the volume of transactions and smart contracts grows in the Ethereum network, the size of the blockchain is expanding quickly. A full node requires ~700GB while an archive node requires ~11TB. This makes it potentially impossible for any small devices to participate in the network. When you want to make a transaction, your only options are to run a full client or to rely on a centralised service.
The ultimate goal is that blockchain should be accessible by all. There must be a simpler way to run Ethereum nodes without storing a large amount of data. The light node is a response to this, and it can run on any small device, such as a smartphone or a Raspberry Pi.
Light clients are nodes that do not contain entire blockchain data. Instead, they download only the chain of block headers. They cannot take part in block validation however they can access the blockchain in a similar way as the full node does.
Assume you want to check in your mobile app (a light node) to see if your most recent transaction was confirmed before initiating another one. Since light nodes only have the block header, they do not know if the transaction is included in the latest block and have to request a full node.
The blockchain’s fundamental assumption is that no node can be trusted. If this is the case, how can the light node be certain that the full node is not malicious? It can request for evidence. What can the light node validate against even if the full node provides additional information? Because light nodes have block headers (assuming majority of the nodes are honest), it is the only data that the light node can rely on.
Let’s take a look at a simple example to see how this might work.
When a block is created, all of its transactions can be hashed to produce a transaction root hash. The root hash is then saved in the block header.
When light node wants to confirm whether a transaction is present in a block, they can request the full node for the complete list of transactions for that block. The light node can then hash them all together and compare them to the root hash of the header to confirm the presence of the transaction.
While the above method works well, the light node must request the entire transaction list from the full node to validate the hash every time it wants to confirm a transaction. Given that light nodes are small devices with limited resources, it can quickly become resource intensive, especially since blocks can have transactions in the hundreds.
New to trading? Try crypto trading bots or copy trading
How do we solve that then? Merkle tree.
Merkle tree computes the root hash by repeatedly taking the hash of pair of its nodes. The merkle tree for the above list of transactions would look like this:
Alright, How does it facilitate verification? If you look closely, you will notice that in order to prove the root hash, the full node does not need to return every transaction hash, but only the hashes required by the light node to validate the proof. Is something unclear? I hope the image below explains it better.
The Merkle tree implementation requires the full node to send three hashes as opposed to ten with the previous implementation. Consider a block with 1000 transactions. Instead of requesting all, Merkle proof only requires 10 (log2(n)) hashes, allowing for quick transaction verification.
I hope this article has given you a better understanding of how transaction trie contributes to network scalability. I’ll deconstruct the transaction receipt trie in my future post. If you want to be notified when that posts, make sure to follow. Feel free to reach out if you have any questions or comments. Twitter | LinkedIn
