[譯]BIP130發送消息頭

概述

當添加一個新消息-「sendheaders」時，比起「inv」消息來，節點更喜歡經過 「headers」 消息來接收新塊的廣播。

動機

自 0.10 引入「headers-first」下載塊以來，假設塊不可以鏈接到（有效）頭文件鏈，塊將不會被處理。所以，塊中繼工做一般以下：

1. 節點（N）用包含塊 hash 的「inv」消息來廣播新的提示
2. 其餘節點（P）用「getheaders」消息（請求 headers 直到有新的提示出現）和新提示自己的「getdata」消息來響應「inv」
3. N 用一個「headers」消息（帶有新 block 的 headers 以及任何前面的 headers，P 未知）和包含一個新 block 的「block」消息來響應

然而，在創建提示且其中一個新的 block 被廣播的狀況下，對於一個新區塊這一般是更加高效的，就是這個節點 N 只廣播block-header而不是去廣播 block-hash 以及保存其餘節點生成和傳輸的 getheaders 消息（和所需的塊定位符）。

在 reorg 的狀況下，其中 1 個或多個 blocks 被斷開鏈接，節點當前只是爲新提示發送「inv」。在請求這些塊以前，須要等到中間塊的 headers 被交付，此時其餘節點能夠當即請求新的提示。 經過廣播 headers，其餘節點能夠當即請求從上一個fork點開始到塊公告中的新提示出現全部中間塊。

規範

1. sendheaders消息被定義爲一個空的消息，其中 pchCommand == 「sendheaders」
2. 收到「sendheaders」消息後，將容許節點（但不是必需）經過發送新塊的block-header來通知新的blocks（爲了塊鏈接，節點所認爲的對等點可能須要與其餘的塊一塊兒）
3. 經過檢查協議 version >= 70012 來啓用功能發現

附加限制

因爲對sendheaders的支持是可選的，因此實現這一點的軟件也能夠選擇性地施加其餘的約束，例如只在創建鏈接後纔去遵照sendheaders消息。

向後兼容

在這種變化以後，老客戶端仍然徹底兼容而且能夠互操做。

實現

github.com/bitcoin/bit…

引用

原文連接：sendheaders message

---

本文由 copernicus團隊 冉小龍 翻譯，轉載無需受權。

原文連接: mp.weixin.qq.com/s/rq3HTa2k4…