My assumption is that when transaction proof of inclusion occurs, it takes place only at full nodes, since this may happen when a block is mined (as a node has to evict transactions from its mempool to make sure the same txns aren’t added in their candidate block) and when someone queries a block explorer and the full nodes hold all the transactions (needed for merkle proofs). Is this true?
In these cases then, wouldn’t it be quicker to just search through the transactions for a match instead of doing merkle proofs? How does a node know which block a TX is in? The transaction data doesn’t contain what block it is in, so does a node start scanning the chain downwards?
When someone queries a proof-of-inclusion, a bitfield is constructed as a derivation path down to the leaf in question. For this to work, I assume that for each merkle root, is a mapping, and the associates nodes and all transactions. Doesn’t this defeat the purpose of a merkle tree then, still needing to hold all information + more? So is it just to summarise the transaction data in a block header to add some more entropy to a block hash?
If only the root and leaf are known, how is a derivation path found?
Is it so that that a light clients queries full nodes on who construct the merkle tree on the fly, providing a tree which the light client can then perform proof of inclusion?
I know I am missing something. Could someone please fill me in here? Thank you.
PS: Apologies for the long drawn out question.