種子資料庫檢查僅發現七個健康節點,比特幣核心開發者考量放棄 CJDNS 支援
重點速覽
- •一場 GitHub 討論促使比特幣核心開發者重新評估原生 CJDNS 支援是否仍應保留在用戶端中。
- •針對 25 個已知 CJDNS 位址的測試發現 22 個有回應交握,但僅七個對等節點符合可靠區塊與交易傳播的標準。
- •開發者警告,對等節點池如此小的僅 CJDNS 節點更容易遭受日蝕攻擊,攻擊者可藉此孤立節點並扭曲其對網路的認知。
- •支持保留 CJDNS 的人士表示,其低使用率可能反映整合與認知不足,且若 Tor 或 I2P 遭遇封鎖或中斷,它仍可作為有用的緊急備援。
- •移除 CJDNS 不會改變比特幣共識規則,也不會阻止營運者在外部使用 CJDNS,但會使比特幣核心不再於內部管理這些連線。

目前尚未移除任何程式碼,也未做出最終決定,但持續偏低的採用數據已促使比特幣核心貢獻者重新檢視在主比特幣用戶端中維護舊有覆蓋網路的實際安全性與工程取捨——這場辯論如今聚焦於加密路由網路 CJDNS 是否仍值得在參考實作中佔有一席之地。
七個「良好」節點引發更大範圍的基礎設施審視
這場技術討論源自一個公開的 GitHub issue,開發者在其中質疑比特幣核心是否應繼續支援一個幾乎沒有記錄在案的實際流量的加密路由層。為比特幣增加替代網路傳輸層的核心目標在於冗餘:避免出現任何單一的網路層級故障點或審查點。然而,只有在底層網路上有活躍的對等節點網格參與時,冗餘路徑才能發揮作用。
在對僅使用 CJDNS 的節點設定進行自動化測試時,核心開發者 Marco Falke 回報,他的節點實例在任何時間點都無法與超過三或四個不同的對等節點建立連線。針對這項觀察進一步追查後,另一位貢獻者查詢了一個既有的網路種子資料庫——即為剛啟動的節點提供首批對等節點位址的啟動服務——其中包含 25 個已知的 CJDNS 位址。在受測的 25 個位址中,有 22 個回應了基本交握,但僅七個符合被歸類為可靠「良好」對等節點、可進行活躍區塊與交易傳播的技術標準。
單次種子查詢並不代表對整個 CJDNS 生態系中所有運作節點的絕對普查;私密、未公告的節點與未被索引的對等節點仍可能存在於公開種子清單之外。即便如此,這些數字仍凸顯了一個嚴峻的現實:一個可存取路由目標少於一打的覆蓋網路,無法提供一個具韌性的生產節點所需的運作冗餘。就規模而言,長期運作的公開爬蟲所統計到的 Tor 公告可達比特幣節點為數千個等級,而 CJDNS 種子資料庫僅持有 25 個位址。
認識 CJDNS:加密 IPv6 路由與共識規則的區別
CJDNS 是一種加密的 IPv6 網狀網路覆蓋層,使用公開金鑰密碼學進行位址分配與分布式路由。在比特幣之外,該協定最為人熟知的身分,是志工營運的社群網狀網路 Hyperboria 的路由層。比特幣核心於 2022 年在版本 23.0中加入原生 CJDNS 支援,讓節點營運者可以在 IPv4、IPv6、Tor 與 I2P 之外,同時透過 CJDNS 路由對等流量。
根據比特幣核心的文件,CJDNS 會對流量進行端對端加密,並可使流量分析與過濾變得更加困難。然而,它並非與 Tor 意義相同的匿名網路:中間的 CJDNS 路由器仍能看見其轉發封包的密碼學來源與目的地位址。
該提案僅涉及比特幣核心如何尋找並連線至對等節點。移除 CJDNS 支援不會改變區塊驗證、挖礦、腳本規則或交易格式;節點將繼續執行相同的比特幣共識規則。
日蝕攻擊的安全機制
在比特幣節點安全中,網路傳輸與對等節點選擇直接關係到資料完整性。加密能對第三方隱藏封包內容,但若節點的對等節點選擇過於受限,加密並無法防止節點被餵入錯誤或延遲的資訊。稀薄的對等節點池會削弱安全性,使惡意行為者更容易隔離並操縱僅使用 CJDNS 的節點。
孤立節點面臨的主要威脅是日蝕攻擊。在日蝕攻擊中,攻擊者會入侵或控制目標節點所建立的所有對等連線。藉由完全包圍目標節點,攻擊者實質上將其與合法的全球比特幣網路隔離開來。從這個位置,攻擊者可以透過延遲區塊公告、審查特定傳入交易,或對未確認交易嘗試雙重支付攻擊,來操縱受害者對區塊鏈的認知。
在標準 IPv4、IPv6 或 Tor 路由下,比特幣核心透過跨越多元網路群組與網路範圍建立多條獨立連線,來降低日蝕攻擊風險;預設情況下,該軟體會同時保持八條出站完整轉發連線。當節點僅透過一個只有七個可靠對等節點的網路運作——少於這些預設出站連線數——可用連線的總數就遠遠不足:攻擊者只需極少資源,即可壟斷僅使用 CJDNS 節點的所有傳入與傳出連線,使原本設計為安全備援的機制淪為嚴重的單點故障。
程式碼複雜度與棄用的論據
除了偏低的採用數據與安全疑慮之外,支持移除的開發者還強調 CJDNS 程式碼對整體比特幣核心軟體儲存庫造成的持續維護負擔。
與標準協定處理器不同,CJDNS 整合並未與標準 IPv6 連線邏輯完全隔離。由於 CJDNS 使用特殊格式的 IPv6 位址,程式碼庫需要自訂處理邏輯、專屬啟動參數(如 -cjdnsreachable),以及特殊的邊界情況因應措施。隨著時間推移,開發者注意到這些自訂邏輯路徑會帶來程式錯誤風險,並使網路堆疊的例行重構變得複雜。傳輸層本身也在積極開發中:BIP 324 加密 v2 傳輸在版本 26.0 中以選項形式推出,並於版本 27.0 預設啟用——在 CJDNS 等舊有路徑被重新評估之際,新的連線程式碼持續加入。
數位核心貢獻者已對棄用該協定表示「Concept ACK」。在開源比特幣核心的開發術語中,「Concept ACK」代表貢獻者同意某項提案的高層目標;這並不構成最終表決、程式碼合併,或立即移除該功能的承諾。
長期緊急備援的論據
在議題的另一端,呼籲審慎的開發者主張,不應僅以當前流量指標評斷節點的實用性。貢獻者 Jon Atack 指出,自動化 CJDNS 對等節點探索直到 2025 年初才整合進核心。在那次更新之前,節點營運者必須手動設定對等節點位址——相較於 Tor 或 I2P 的一鍵式設定,這個過程形成了顯著的進入門檻。
支持者認為,CJDNS 使用率偏低源自使用者認知不足,以及其在熱門一站式節點軟體發行版中的整合有限,而非其底層價值欠缺。若 Tor 或 I2P 等主要公開匿名網路遭遇集中式封鎖、基礎設施中斷或國家級過濾,CJDNS 這類替代網狀協定可提供維持對等連線的重要緊急備援管道。
Atack 也已自願親自維護 CJDNS 整合程式碼,回應了對開發者負擔的疑慮。核心貢獻者如今必須決定,是要為罕見的緊急情況保留一條替代傳輸路徑,還是透過移除低使用率的網路邏輯來精簡程式碼庫。
潛在移除對節點營運者的意義
如果比特幣核心最終在未來的版本中移除原生 CJDNS 整合,該軟體將只是停止在應用程式層內部管理 CJDNS 對等連線。這項變更不會阻止營運者在作業系統層級於外部執行 CJDNS,也不會改變更廣泛的比特幣網路處理交易的方式。
比特幣核心的功能移除通常遵循緩慢且有文件記錄的軌跡——棄用會在版本說明中標註,程式碼則要等到之後的主要版本才會真正移除,該專案的發布週期約為六個月——因此值得關注的指標包括 GitHub 討論串、任何正式的棄用拉取請求,以及 2025 年加入的自動化對等節點探索能否在維護者做出決定前改善採用數據。
對於絕大多數依賴標準 IPv4、IPv6、Tor 或 I2P 連線的節點營運者而言,CJDNS 的移除將完全不會被察覺。這場持續進行的討論反映了比特幣核心嚴謹的工程哲學:每一行程式碼都必須透過經證實的安全性與實際效用,來證明其存在的價值。
本文僅供資訊參考之用,不構成投資建議。
來源:Coindoo