高級
P2P 訊息類型
比特幣 P2P 協議中的各種訊息類型，包括控制訊息、數據訊息和區塊傳播。
15 分鐘
訊息分類
比特幣 P2P 協議定義了多種訊息類型，可分為控制訊息、數據請求和數據回應三大類。
控制訊息
version / verack
握手訊息。version 包含節點信息，verack 確認版本接受。
ping / pong
心跳檢測。ping 包含 nonce，pong 回應相同 nonce。用於測量延遲和檢測死連線。
sendheaders
請求對方直接發送新區塊頭，而非 inv 通知。提高區塊傳播效率。
sendcmpct
啟用 Compact Block 協議（BIP-152）。減少區塊傳播所需頻寬。
feefilter
設定交易過濾閾值。低於此費率的交易不會被中繼到此節點。
數據請求訊息
| 訊息 | 說明 | 回應 |
|---|---|---|
| getdata | 請求特定物件（區塊/交易） | block / tx |
| getblocks | 請求區塊雜湊列表 | inv |
| getheaders | 請求區塊頭（最多 2000 個） | headers |
| mempool | 請求 mempool 中的交易 | inv (多個) |
| getaddr | 請求節點地址 | addr / addrv2 |
數據回應訊息
inv
庫存通知。告知對方自己有哪些區塊或交易可用。接收方可用 getdata 請求。
類型: MSG_TX (1), MSG_BLOCK (2), MSG_FILTERED_BLOCK (3), MSG_CMPCT_BLOCK (4)
block
完整區塊數據，包含區塊頭和所有交易。
tx
單筆交易數據。
headers
區塊頭列表。用於 headers-first 同步，每個區塊頭 80 bytes。
addr / addrv2
節點地址列表。addrv2 (BIP-155) 支援 Tor v3、I2P 等地址格式。
Compact Blocks (BIP-152)
Compact Blocks 大幅減少區塊傳播的頻寬需求：
傳統區塊傳播: 1. 節點 A 發送 inv (區塊雜湊) 2. 節點 B 發送 getdata 3. 節點 A 發送完整 block (~1.5 MB) Compact Block 傳播: 1. 節點 A 發送 cmpctblock - 區塊頭 - 短交易 ID (6 bytes each) 2. 節點 B 從 mempool 重建區塊 3. 如有缺失，發送 getblocktxn 請求 4. 節點 A 發送 blocktxn (缺失的交易) 效果: 約 99% 的交易已在 mempool，只需傳輸 ~20 KB
高頻寬模式 vs 低頻寬模式
高頻寬模式
節點主動發送 cmpctblock，不等待 getdata。 更快但可能重複傳送。用於信任的對等方。
低頻寬模式
先發送 inv，等待 getdata 後才發送 cmpctblock。 避免浪費頻寬，是預設模式。
交易傳播流程
1. 用戶廣播交易到節點 A 2. 節點 A 驗證交易有效性 3. 節點 A 加入 mempool 4. 節點 A 發送 inv 到所有連接的節點 5. 節點 B 收到 inv，檢查是否已有 6. 節點 B 發送 getdata 請求交易 7. 節點 A 發送 tx 8. 節點 B 驗證、加入 mempool、繼續廣播 隱私優化 (BIP-133 Dandelion): - Stem 階段: 交易沿隨機路徑傳播 - Fluff 階段: 正常廣播 - 效果: 難以追蹤交易來源
區塊同步流程
Headers-First 同步 (現代方法): 1. 發送 getheaders (從創世區塊開始) 2. 收到 headers (最多 2000 個區塊頭) 3. 驗證區塊頭的 PoW 和連結 4. 重複 1-3 直到達到最新高度 5. 對每個區塊發送 getdata 6. 下載並驗證完整區塊 7. 並行下載多個區塊加速同步 優點: - 先驗證 PoW，避免下載無效區塊 - 可並行下載區塊 - IBD (初始區塊下載) 更快
訊息速查表
| 類別 | 訊息 |
|---|---|
| 握手 | version, verack, wtxidrelay, sendaddrv2 |
| 心跳 | ping, pong |
| 地址 | getaddr, addr, addrv2 |
| 區塊 | getheaders, headers, getdata, block, inv |
| 交易 | tx, inv, mempool |
| 緊湊區塊 | sendcmpct, cmpctblock, getblocktxn, blocktxn |
已複製連結