比特幣核心評估移除CJDNS支援，僅7個健康節點加劇風險

比特幣核心正在評估棄用CJDNS路由，因種子節點僅發現七個健康節點，使僅使用CJDNS的營運商暴露於日蝕攻擊風險。

「某個種子節點資料庫中存有25個CJDNS位址，實際連線達到22個，但僅有七個被歸類為健康節點，」比特幣核心成員Andrew Chow在公開的GitHub議題#36041中表示。

議題發起人Martin Zumsande報告稱，儘管比特幣核心內建了11個固定的CJDNS種子節點，他僅觀察到三到四個對等節點。該提案建議在32.x版本中向使用者發出警告，再計畫於33.x版本中移除支援，不過版本序列是以提問形式提出的。截至8月23日，該議題仍掛在32.0里程碑下，且未附帶任何實作分支或拉取請求。

如此稀薄的對等節點池可能使僅使用CJDNS的節點更容易遭到日蝕攻擊包圍——攻擊者壟斷某個節點的所有連線，以塑造其對網路全貌的認知。比特幣核心通常維持八條完整中繼外送連線及兩條僅區塊中繼連線，有貢獻者建議將任何CJDNS閾值建立在填滿這些連線槽位的成本之上。

單一種子節點快照中的七個健康節點

種子節點數據描述的是一個爬蟲程式在某個時間點的資料庫狀態。全球CJDNS節點總數可能更大，因為該數據僅涵蓋該爬蟲程式的資料庫。

種子節點對「健康」的判定使用比可達性更嚴格的技術篩選標準。在Chow的DNSSeedrs實作中，節點必須通過涵蓋連接埠、公布的網路服務、協定版本、鏈高度及滾動可靠性的檢查。可靠性測試使用多個時間窗口並要求最低嘗試次數。這解釋了為何種子節點能連線22個位址，卻僅將七個歸類為健康。

Zumsande的節點僅找到三或四個對等節點，他提出三位數下限作為可能足以證明繼續支援合理的粗略水準。這個三位數下限基準是Zumsande個人的建議，為維護者提供一個可以辯論的具體數字，而非僅是對低使用率的籠統抱怨。

僅靠對等節點數量算術無法得知日蝕攻擊的成本。成功的日蝕攻擊取決於的不只是十個常規外送連線槽位。位址可用性、位址選擇、爬蟲可靠性門檻以及偶爾出現的額外外送連線，都會影響實際暴露程度。測量到的節點池確實支持對僅使用CJDNS節點的集中度擔憂，但利用這項擔憂的成本仍未量化。

冗餘效果取決於CJDNS的使用方式

當CJDNS只是多條路徑之一時，它提供了不同的價值主張。比特幣核心的文件將其定位為IPv4、IPv6、Tor和I2P之外的補充選項，使節點在某一網路出現問題時仍能保有另一條可用的路由。

這個選項變得更容易使用。CJDNS 22.1於2025年1月8日引入了DNS種子自動對等連線，使手動新增對等節點成為可選操作。比特幣核心隨後於2026年3月30日合併了更新後的設定文件，以新的流程取代過時的對手動對等連線的說明。比特幣核心又於2026年8月18日合併了另一項文件變更，明確勸阻僅使用CJDNS的做法，因為位址池仍過小，無法可靠填滿外送連線槽位。

未來的棄用將移除傳輸設定，但保留區塊有效性規則不變。比特幣核心在23.0版本中將完整的CJDNS支援作為P2P網路功能加入。此次辯論僅限於位址處理與連線選項；比特幣的共識及區塊有效性規則不在此範圍內。

直接受影響的營運商是那些使用-cjdnsreachable（指示比特幣核心將相關的IPv6範圍視為CJDNS）或-onlynet=cjdns（將自動外送連線限制為該傳輸方式）的使用者。目前該選項可與其他網路結合使用，而在-onlynet模式下，入站連線及手動新增的連線仍然可用。

議題#36041仍保持開啟狀態，警告及移除的序列僅作為提案記錄在案。該議題顯示了觀察到的對等節點數量偏少、多個支持棄用的意見，以及一個提議的版本發布序列。它也說明了為何僅靠使用量統計是不完整的測試：備援能力在主路由失效前最有價值，但若備援網路無法填滿連線，其實際提供的韌性可能不如其存在於程式碼中所暗示的那麼高。

比特幣核心目前仍支援CJDNS。合併後的警告或移除拉取請求將改變這場辯論的狀態。七個健康節點使傳輸多樣性的取捨變得可量化，也讓移除決策保持開放。

本文僅供參考用途，不構成投資建議。