為什麼 getheaders P2P API 返回的比 getblocks 多？

我一直在閱讀比特幣 P2P 協議文件以及嘗試使用 Bitcore 庫，但對一件事感到困惑。

所以getblocks似乎返回了庫存對象，它們只是指針，所以你必須getdata使用這些庫存發出另一個請求來獲取實際的塊。

並且getheaders似乎將標頭從startsto返回stop。

它們的行為相似，除了getheaders返回的不僅僅是指針。我在這裡很困惑，因為我覺得getheaders應該是“輕模式”，與getblocks. getheaders預設情況下最多下載 2000 個標頭，而getblocks最多僅下載 500 個庫存，這也表明了這一點。

所以我誤解了這些嗎？為什麼getheaders返回的資訊比getblocksAND 還返回更多的結果getblocks（2000 vs 500）？

真的getblocks應該被呼叫getblockhashes，因為響應只包含塊雜湊，而不是完整塊。

可以通過三種不同的方式觀察每個塊：

• 包含所有交易和標頭資訊的完整塊。
• 沒有交易的塊，但只有 80 字節的標頭，其中包括送出到交易的 Merkle 根。
• 只是塊頭的 32 字節散列（用於標識整個塊，因此也稱為塊散列）。

getblocks被設計用於同步塊。通常的順序是節點 A 會發送 a getblocks，B 會用塊雜湊響應a ，A 會為他失去的每個塊inv回复 a ，然後 B 會使用消息發送完整的塊。限制為 500，因為一次下載超過 500 個塊可能被認為太多且毫無意義（因為這可能是高達 500 MB 的數據）。getdata``block

getheaders另一方面，它是為標頭同步而設計的，當時僅由輕量級客戶端使用。這些不會下載（所有）完整塊，並且作為響應發送的標頭通常是唯一的進一步通信。由於每個塊的標頭只有 80 個字節，因此即使 2000 個標頭也只有 160 kB 的數據。

由於引入了標頭優先同步（本質上用於getheaders同時了解塊雜湊和標頭，然後一次從多個對等點下載失去的塊），舊getblocks的基於同步被取代（它仍然實現與不兼容的軟體’ t 具有基於標頭的同步，但除了實現複雜性之外，其他方面都較差）。

引用自：https://bitcoin.stackexchange.com/questions/88094