包含證明：Merkle Tress，推導路徑
我的假設是，當包含交易證明發生時，它只發生在完整節點上，因為這可能發生在一個區塊被探勘時（因為一個節點必須從它的記憶體池中驅逐交易以確保相同的 txns 沒有添加到他們的候選區塊）以及當有人查詢區塊瀏覽器並且完整節點持有所有交易（默克爾證明所需）時。這是真的？
那麼在這些情況下，在交易中搜尋匹配而不是進行默克爾證明不是更快嗎？節點如何知道 TX 在哪個區塊中？交易數據不包含它所在的區塊，那麼節點是否開始向下掃描鏈？
當有人查詢包含證明時，將建構一個位域作為向下到相關葉的推導路徑。為此，我假設對於每個 merkle 根，是一個映射，並且關聯節點和所有事務。這難道不是破壞了默克爾樹的目的，還需要保存所有資訊+更多資訊嗎？那麼是否只是在區塊頭中匯總交易數據以向區塊雜湊添加更多熵？
如果只知道根和葉，如何找到派生路徑？
是不是這樣一個輕客戶端就可以在執行中查詢誰建構了默克爾樹的完整節點，提供一棵樹，輕客戶端可以執行包含證明？
我知道我錯過了一些東西。有人可以在這裡填寫我嗎？謝謝你。
PS：為冗長的問題道歉。
我的假設是，當包含交易證明發生時
您在談論哪些包含證明？我在比特幣 P2P 協議中所知道的唯一協議是 BIP37（交易的伺服器端 Bloom 過濾）中的協議。雖然還有其他用途（例如 utreexo），但您需要具體說明。
它只發生在完整節點上，因為這可能發生在一個塊被探勘時（因為一個節點必須從它的記憶體池中驅逐事務以確保相同的 txns 不會被添加到他們的候選塊中）以及當有人查詢一個塊瀏覽器時並且全節點持有所有交易（默克爾證明所需）。這是真的？
區塊瀏覽器與包含證明無關。他們只是在他們的數據庫中搜尋交易。他們不需要任何證據，因為他們執行自己的節點，所以他們知道他們所包含的交易——如果不是，他們就不會被輸入到他們的數據庫中。
那麼在這些情況下，在交易中搜尋匹配而不是進行默克爾證明不是更快嗎？
默克爾證明僅在一方需要向另一方證明交易包含在區塊中時使用。他們根本不參與區塊瀏覽器，因為他們只是顯示使用者數據——沒有任何證據被證明。
節點如何知道 TX 在哪個區塊中？
普通比特幣 P2P 節點不需要，也不需要這樣做。該協議支持查詢最近中繼的未確認交易（因此它們還沒有在一個區塊中），並支持按區塊查詢。使用 BIP37（由於不良隱私和 DoS 風險而越來越多地被放棄），可以/可以通過發送 Bloom 過濾器首先告訴節點您感興趣的地址/腳本/事務，然後請求“過濾”塊- 刪除不相關交易的區塊，並替換為剩餘交易的包含證明。
交易數據不包含它所在的區塊，那麼節點是否開始向下掃描鏈？
至少在比特幣 P2P 協議中，這根本不會發生，因為它是不必要的。
除此之外，還使用索引。對於本地使用，Bitcoin Core 可以建立一個索引來記住哪個交易是在哪個區塊中找到的，因此可以通過 txid 進行查找。Electrum 協議（使用單獨的 Electrum 伺服器）也可能支持通過 txid 進行查詢，並且它的伺服器也需要一個索引。我相信他們也確實建構了包含證明（根據要求即時建構）。
當有人查詢包含證明時，將建構一個位域作為向下到相關葉的推導路徑。為此，我假設對於每個 merkle 根，是一個映射，並且關聯節點和所有事務。這難道不是破壞了默克爾樹的目的，還需要保存所有資訊+更多資訊嗎？那麼是否只是在區塊頭中匯總交易數據以向區塊雜湊添加更多熵？
如果不知道您正在談論的具體應用程序，很難回答這個問題。一般來說，包含證明與查找數據的問題無關——有人需要它，他們可以用它來向其他人證明它。
如果只知道根和葉，如何找到派生路徑？
你不能。證明用於向已經擁有根（並信任它）的人證明特定葉子實際上是該根所送出的樹的一部分。顯然，建構證明的一方需要以某種方式知道哪個葉子，以及塊的其餘部分。
是不是這樣一個輕客戶端就可以在執行中查詢誰建構了默克爾樹的完整節點，提供一棵樹，輕客戶端可以執行包含證明？
是的，這就是 BIP37 過濾塊查詢中發生的情況，並且可能也在其他協議中發生。