文件完整性檢查：為什麼使用雜湊樹而不是雜湊列表？
文件共享系統有時會使用 Tiger Tree Hash 之類的方法在下載文件時檢查文件的完整性。
雜湊樹通常可用於檢查樹葉的完整性，而無需下載完整的樹，而只需要包含感興趣的樹葉的根和樹枝（加上分支中必要的存根）。
我的問題是：當人們可能想要下載完整文件時，為什麼還要使用樹進行文件完整性檢查？一個普通的散列列表（每個文件塊的散列 + 列表的散列）對於實現和管理來說是微不足道的，並且只比樹稍微大一點。在樹的情況下，列表的散列和根散列仍然有效。
事實上，我只知道一個文件共享客戶端，它允許一個人選擇要下載的文件的一部分，所以整個案例看起來很不典型。
那麼，這是早期的、邊緣的、大部分未使用的優化嗎？還是我錯過了什麼？
看起來問題本身需要一些更正。我對“文件共享”中發生的事情的描述過於簡單，添加細節可以解釋問題。
00 年代的 eDonkey/eMule 確實使用了Tiger Tree Hashes，這是一種 Merkle 樹。
但到那時，看起來 BitTorrent 的 torrent 文件只包含一個簡單的雜湊列表，對應於 torrent 文件的塊。塊的數量是固定的，但它們的大小可以調整。這導致了大型 torrent 文件，這給 Web 伺服器帶來了壓力；但是最小化 torrent 文件大小會在 torrent 中強制使用大文件塊，這也很糟糕。
所以在 2009 年左右，BEP 30引入了一種減小 torrent 文件大小和減小散列文件塊大小的方法：新樣式的 torrent 文件僅包含 Merkle 樹的根（因此它的大小最小，減輕Web 伺服器），並且樹是由播種者在內部創建的。每個塊傳輸所需的樹的各個部分都在帶內發送，使其自包含並可通過根進行驗證。
關鍵是樹不是自己傳輸的，而是由播種機生成並根據需要分段傳輸。這種分段傳輸可能會產生很多冗餘，但這種冗餘是在 P2P 協議中，所以這種低效率遠不如對 Web 伺服器的緩解重要。
我在問題中描述的雜湊列表可能可以替代樹，但會導致協議效率更低，並且需要儲存整個雜湊列表（與 torrented 文件的大小成線性關係） ) 即使客戶對某些塊不感興趣。