Overlook concerning the Merkle tree. Assume that as an alternative, the block header would simply comprise a hash of the concatenation of all transactions.
A light-weight node may then obtain all headers, confirm their proof of labor, and make the belief it has seen the longest chain. It’s now satisfied it has seen the chain the community settle for. That is totally different from a full node, which doesn’t assume a series is accepted till it has seen all block information and verified each single transaction.
Now the light-weight shopper decides to ask friends for the precise block information. When it receives a blocks’ transactions, it is aware of they really match what the block header dedicated to, as it will probably recompute the hash, and examine it to the worth within the header.
However what if the light-weight node will not be inquisitive about all transactions? BIP37 introduces the idea Bloom filtered blocks, the place a light-weight node can reveal what keys/transactions/addresses it’s inquisitive about, and the complete node it’s downloading from will solely give the transactions that match the filter.
Sadly, if the light-weight node doesn’t obtain all transactions, there isn’t any technique to know whether or not they match the hash within the header, and as such, the complete node may lie, and embrace transactions that aren’t really current within the chain.
Enter the Merkle tree.
As a substitute of simply storing a hash, we retailer the foundation of a Merkle tree. The total node can now for every matched transaction embrace the hash values that transaction’s hash is mixed with, to show that the transaction is the truth is included within the tree, although the light-weight node solely is aware of the foundation.
