閃電錢包安全性光譜

作者：Jack Ronaldi

來源：https://vls.tech/posts/lightning-security-spectrum/

長話短說

“非託管” 無法作為閃電錢包的安全模式描述。因為簽名的時候必須聯網，真正的問題是：如果聯網的節點被攻陷，那會發生什麼事？絕大部分閃電錢包都是聯網的錢包（熱錢包）。如果只是為了花錢消費，那沒什麼問題，但風險會隨著資金體量增加而迅速上升。等級 3（強化的環境）可以降低被攻陷的概率。等級 4（VLS）則通過在節點外部強制執行一些支出條款來限制爆炸範圍，所以即使節點被攻陷，也無法盜竊資金。如果你是開發者、節點運營者或是持有大量閃電通道資金的服務端，這其中的區別不可小視。

（譯者注：作者的思路是將一個功能完整的閃電節點分成兩個模塊：一個是負責聯網、通信、管理閃電通道的 “節點”，另一個是在通道狀態轉換（收款或支付）時負責簽名的 “簽名器”；這兩個模塊在不同的閃電錢包實現中可能是合併的，也可能是隔離的。）

安全光譜一瞥

• 等級 1：無驗證簽名。無意義，別開發。
• 等級 1：完全託管的熱錢包。服務商持有你的密鑰。
• 等級 2：非託管的熱錢包。你自己持有密鑰，只是密鑰存放在聯網設備商。
• 等級 3：強化的節點。使用了安全飛地（enclaves）、硬件簽名設備（HSM），帶有更強的隔離措施。
• 等級 4：帶驗證的閃電通道簽名器（VLS）。隔離的簽名器，並強制執行支出條款。
• 等級 5：VLS + 門限簽名（未來）

一個有用的區分

• 等級 3：讓節點更難被攻破。
• 等級 4：讓節點爆破更不危險（節點無法使用支出條款不允許的行為來盜竊資金）。

追問你的錢包的開發者或服務商

• 如果節點被攻陷，它能否獲得簽名來盜竊資金？
• 簽名的支出條款是在節點之外，由一個單獨的模塊來執行的嗎？
• 最糟的情況下，損失有多大？什麼東西能夠阻止失血？
• 檢查你的錢包的現狀

如果簽名器本身被攻陷，那任何措施都無濟於事。所以，我們的目標是讓它比節點更加難以攻破。

閃電網絡的承諾和問題

你仔細研究，挑選了一款 “非託管的” 閃電錢包，因為你篤信 “無私鑰，即無幣”。你謹慎低保管你的種子詞，你自己持有私鑰。

某日清晨，你醒來發現自己的閃電通道已經被關閉了，你的聰被髮到了你不認識的地址上。軟件的日誌顯示你的節點允許了所有操作。就這樣，你的比特幣不翼而飛。你的閃電錢包抽走了你的凳子。

閃電網絡承諾要在即時支付上保持比特幣的安全性和自主保管原則。可是，似乎哪裡出了問題。

“非託管” 不算一種安全模式

在比特幣基礎層上，“非託管” 很明顯跟安全性是配對的：私鑰放在不聯網的設備（冷存儲）中，只在你選擇的時候才簽名。閃電錢包改變了這種約束。支付、哈希時間鎖合約（HTLC）和通道更新，都是有響應時限的，所以簽名密鑰必須聯網，要麼在你的手機上、要麼在一個服務商那裡，再要麼，在兩者之間。在閃電錢包裡，“我持有私鑰” 並不天然意味著 “我的資金是安全的”。

• “非託管” 當然還是必要的。它意味服務商不能隨意轉移你的資金。
• 但單純 “非託管” 還不夠。因為簽名時候是聯網的，你需要一種災備模式。假設一個攻擊者控制了你的閃電節點，什麼東西能夠阻止他們獲得你的簽名、盜走你的資金？

（譯者注：攻擊者無需盜竊私鑰、控制節點就可能盜竊資金的原理在於，閃電通道的狀態變更本身就要求獲得簽名，也即節點申請、簽名器許可；如果簽名器不驗證申請的內容，那麼自然只需控制節點，就可以將受害者在通道中的資金都轉走。）

重要的是：

如果你的閃電節點被劫持了，攻擊者接下來能做些什麼？

我們先來看看常見的閃電錢包。

閃電錢包安全性光譜

這個光譜是用一個簡單的測試排列出來的：攻擊者盜竊受害人的資金有多難？

我們在光譜上移動的時候，是在犧牲簡潔性、換來更小的攻擊節點和更強的災備保障。

無驗證簽名（壞模式）

它是什麼樣的：簽名器與節點分離，但它會許可節點發來的任何請求，不會獨立地驗證請求的安全性。

節點被劫持會發生什麼事：只要節點（或任何可以影響它的模塊）被攻破，它就可以欺騙簽名器去授權有害的動作。

為什麼它不好：它比標準的熱錢包更復雜，卻更不安全，因為你現在承受了兩個攻擊界面（節點和簽名器），而不是隻有一個攻擊界面。

案例：今天的主流產品中沒有這樣做的。這裡提醒開發者：不要去開發這樣的產品。

託管熱錢包

它是什麼樣的：服務供應商控制密鑰，並代你運行閃電節點。

節點被劫持會發生什麼事：供應商的違規行為或內部人可以轉移你的資金。

取捨：最好的使用體驗、用戶責任最少、最高的信任和商業責任。

最適合：小金額和新手入門。

案例：Cash App、Strike、River

非託管的熱錢包

它是什麼樣的：你自己持有密鑰，但它存放在運行你的閃電節點（錢包）的聯網環境（設備）裡

節點被劫持會發生什麼事：如果節點被劫持，資金可能會被盜走。

取捨：自治，但是安全性嚴重依賴於你的節點運行環境有多安全。

最適合：日常消費。

案例：Phoenix (ACINQ)、ZEUS、Voltage

本地 vs 雲：非託管的錢包可以運行在用戶自己的設備上（本地），也能運行在由某個團隊運行的服務器上（雲）。雲並不必然更安全或更危險。它可以減少用戶錯誤，並且專業團隊可以提升操作效率，但通常會增加遠程攻擊界面，並讓風險集中在基礎設施訪問權上。

強化的節點環境（安全飛地/HSM）

它是什麼樣的：標準的閃電節點模式，但運行在一個強化後的環境中（安全飛地、HSM、鑑權驅動（attestation-driven）的秘密分發）。

它強化了什麼：讓 “服務器劫持” 和 “管理員權限” 難以轉化成密鑰抽取，辦法是隔離敏感內存以及加強對密鑰的管理。

節點被劫持會發生什麼事：如果攻擊者成功在節點中執行了惡意邏輯（比如說通過軟件漏洞或劫持軟件更新源），節點將許可盜竊。強化措施可以減少被劫持的可能性，但並不限制爆破範圍。

取捨：通常來說，強化措施的成本很高，需要專門的基礎設施、工具鏈和運營操作（鑑權、私鑰注入、受控的軟件部署）。甚至全球頂級的運營者也說花費了許多年才取得一個可以接受的局面。

最適合：大體量的運營者，且（a）暫時無法改變基礎設施；（b）擁有專門的安全和運營預算。這是普通熱錢包的合理 “起點”，但如果你想要很強的保證，這就不是終局。

案例：LEXE (Intel SGX)、ACINQ: Securing a ~$100M Lightning node (Nitro Enclaves)（中文譯本）

VLS（帶驗證的閃電通道簽名器）

它是什麼樣的：一個隔離的簽名器，在簽名之前會驗證請求並強制執行支出條款。

它強化了什麼：改變了故障模式：節點被劫持也無法通過支出條款不允許的操作來盜竊資金。

節點被劫持會發生什麼事：節點被劫持也沒有什麼影響。簽名器才是關鍵的安全邊界。

取捨：要求軟件預先集成，並且需要持續維護，換來更加強大的安全保證。

最適合：你會介意的金額，尤其是放在雲環境中的錢包。

案例：Blockstream Greenlight、Blockstream App

VLS + 門限簽名（未來）

它是什麼樣的：需要 N 個簽名器中任意 M 個來授權簽名閃電通道狀態變更（比如 3-of-5）。

現狀：還不是現在的閃電節點的標準模式，但如果有需求，也是一個可行的方向。

取捨：最強的安全保證，但也最複雜（可能有更多的運營負擔）。

最適合：財庫式的閃電資金，為實現多方控制，值得克服摩擦。

案例：還沒有，但人們的興趣在增加

需求信號：一些閃電節點運營者希望閃電通道的簽名流程可以跟企業內部的財務管理（比如多人許可）相匹配。Flowrate 最近聯繫了 VLS 項目，表示對使用門限許可來保管客戶資金的興趣。目前還在探索節點，還沒有出現能夠進入生產環境的 “閃電通道多簽名簽名器” 架構。

如何選擇正確的安全等級

閃電錢包的安全性有兩個關鍵：被攻破的可能性（有人能黑進去的概率）和爆炸範圍（如果真有人黑進去，損失會有多大。

實用的選擇辦法是：在它真的出問題的時候，你能接受多少損失？

用較為簡單的模式保管較小的金額。隨著金額增加，變得不能忽視了，或者對你的企業舉足輕重，那就要選擇能夠減少最壞情況下損失的設計，而不僅僅是降低災難概率的設計。

安全性是一個產品抉擇。正確的等級取決於你要保護多少東西、你能忍受多大風險，以及你能應對的故障模式。

強化的節點環境（安全飛地/HSM）

等級 3 是一種常見的思路：如果節點運行環境有風險，那就強化它。更強的隔離、收緊訪問權限，還有依靠硬件的保護措施，可以降低 “服務器被攻破” 演變成 “密鑰被盜” 的概率。

這樣做可以大幅提高閾值，尤其適合具備成熟的安全和部署經驗的運營者。但它依然是一個聯網的系統，所以最壞情況沒有改變：被攻破的節點會簽名什麼東西？

以下是等級 3 在現實中的樣子：

真實世界案例：ACINQ 團隊的博客文章《保護一個價值 1 億美元的閃電節點》](https://acinq.co/blog/securing-a-100M-lightning-node)（[中文譯本](https://www.btcstudy.org/2023/08/21/securing-a-100M-lightning-node/)）介紹了他們的經驗。他們在 AWS Nitro 安全飛地裡面運行自己的節點（隔離 + 鑑權），並使用 Ledger 硬件簽名器來手動確認敏感操作（比如軟件部署）。這大大減少了運營者風險和服務器權限風險。

ACINQ 也強調，這並非 “終極” 安全性：

• 安全飛地並不讓倚賴項變得可以信任。應用依然要驗證自己在跟正確的服務端通信。
• 你依然有一個在線的節點。嚴重的節點軟件漏洞依然可能濫用簽名授權。
• 重度依賴於運營。非常複雜的安全工程，帶來了真實的運營負擔。

真實事故和已經披露的漏洞

有一些跟閃電網絡相關的真實事故（其中一個還揭曉了允許盜竊的漏洞），表明資金損失可以在沒有 “打破閃電網絡密碼學” 的條件下發生。它們的共性是一樣的：如果攻擊者可以影響得到簽名的東西，他們就能偷盜資金。

LNBank（BTCPay Server 插件）：併發取款的賽跑吸乾了大約 4.07 BTC

LNBank 的餘額處理中的一個競爭條件（race condition）允許一個攻擊者在數據庫反映真實的減計之前，觸發許多併發的取款，通過向外支付吸乾一個閃電錢包。

• 光譜位置：對運營者來說是等級 2 。注意：LNBank 自身對用戶來說是一個託管層（等級 1）。
• 影響：據稱轉移了 407,361,805 聰（大約 4.07 BTC）。
• 問題根源：在併發條件下，餘額檢查可能使用已經過時的狀態。
• 問題的重要性：“節點需要任何事情” 可以是危險的，即使沒有抽取私鑰。

資料來源：受害者報告 、維護者回顧

更多細節：

• 機制：攻擊者提交了許多並行的 取款/支付 請求，讓軟件的狀態在 “接受請求” 和 “數據庫更新” 之間來回跳躍。
• 觀察到的動作：迅速發生一連串的閃電網絡出賬支付，導致餘額用盡。
• 響應：曝出問題之後，修復版本迅速發佈；也發佈了公開報告。

LNbits：惡意路由費吸走 >0.1 BTC

一份公開的報告（以 LNbits 代碼庫的一個 Issue 形式發佈）聲稱，攻擊者通過迫使取款經過一個收取高昂手續費的節點，吸乾了一個以 LNbits 為後端的錢包。如果沒有嚴格的單筆支付手續費限額，這個錢包會因為路由費而完全清空。

• 光譜位置：等級 1 和等級 2 之間（熱錢包邏輯，加上手續費支出條款限制，取決於 LNbits 是如何部署的）。
• 影響：報告聲稱損失 “總共超過 0.1 BTC”。
• 問題根源：缺少單筆支付手續費限額和 “支付數額 + 手續費” 把關（或有漏洞）。
• 問題的重要性：在閃電網絡上，手續費就是價值。手續費限額也是安全邊界的一部分。

資料來源：LNbits Issue

更多細節：

• 機制：攻擊者影響了支付路徑選擇，所以唯一可行的路徑包含了一個由攻擊者控制的、收取昂貴路由費的節點。
• 觀察到的動作：支付會成功，但錢包的餘額中有一大部分都變成路由手續費付了出去。
• 響應：報告是公開的；該 Issue 隨後被關閉了（修復措施和部署手段各不相同）。

LND “替換交易停滯”（已經披露的允許盜竊的漏洞）

一份 LND 漏洞的披露（“替換交易停滯”）介紹了一種允許盜竊的情形：強制關閉通道，觸發受害者節點清掃未結的 HTLC 並在此過程中發送替換交易；報告還建議了升級辦法。

• 光譜位置：等級 2 和等級 3 之間（熱節點；基礎設施強化無法消除這種風險）。
• 影響：允許盜竊的漏洞（公開披露並不總是包含已確認的損失）。
• 問題根源：實現層面的故障，出現在清掃資金的罕見情形中。
• 問題的重要性：即使有更強的基礎設施控制，軟件的 bug 依然可能帶來損失。

資料來源：披露報告

更多細節：

• 誰會受到影響：使用受影響的 LND 版本運行節點的人。
• 重要性：圍繞強制關閉和鏈上清掃的敵意條件。
• 緩解措施：升級到修復後的版本。

這些都不是罕見的攻擊。它們是常見的軟件和操作故障，會變成事故，是因為被攻破的節點是一個熱錢包，擁有批准所有操作的權限。

VLS：攻擊界面更小的單獨簽名器

VLS 希望通過改變架構（而不僅僅是強化原有的架構）來應對劫持。

它同時做了三件事：

1. 隔離：私鑰和簽名決策從節點中移出，放到一個專門的簽名器中。
2. 縮減：簽名器要做的事比節點少得多；更少依賴項，攻擊界面也就更少。
3. 強制：在簽名之前，簽名器會根據一套支出條款來驗證請求，所以被劫持的節點也無法執行有害的動作。

它的承諾是：

即使節點被攻破，攻擊者也無法讓違反支出條款的動作獲得簽名。

支出條款例子：

• 關閉通道時，資金只能發送到白名單地址
• 手續費總量以及費率限制
• 支付數額限制以及頻率限制
• “緊急按鈕”（如果有些東西看起來不對勁，就停止簽名功能）
• 還有更多

VLS 在行動

實戰證據：Greenlight

Greenlight 是等級 4 模式的一個真實案例：雲節點便利性，搭配一個基於 VLS 的帶驗證簽名器。

這回答了一個常見的質疑：

“隔離和驗證當然是好事，但你怎麼證明它不會破壞使用體驗？”

Greenlight 證明了，你可以擁有云節點的便利性，而無需讓 “服務器熱私鑰” 變成更大的生存風險。

如何檢查你正在使用的裝置

絕大部分閃電錢包產品都可以告訴你它是託管的或非託管的。但幾乎沒有一款會清楚地告訴你，如果某個模塊被攻破會發生什麼事。以下是一個檢查清單，可以質詢出真實回答。

問題 1：”如果節點環境被攻破了，攻擊者能夠偷走我的錢嗎？“

有力回答：“節點劫持也是可以應對的。因為簽名器會在節點之外強制執行花費條件。”

無力回答：“用戶自己持有私有，這是一個非託管的錢包。”

誠實回答：“是的。如果節點被攻破，資金可能會被轉走。”（把它當成等級 2 或等級 3。）

問題 2：“簽名權限放在哪裡？”

“在 app/節點 進程中 ”，意味著你需要信任整個運行環境。
“在一個單獨的簽名器中，它會強制執行花費支出條款”，表明了不同的安全性邊界。

問題 3：“在節點 之外 強制執行了具體哪些支出條款？”

• 通道關閉時，只能取款到白名單地址
• 支付數額限制和頻率限制
• 手續費限額和安全默認設置
• 緊急鎖定，或者說停止簽名的 “緊急模式”

“我們有安全設置的”，但無法舉出細節，通常等於 “你就信我吧，兄弟”。

深入探究：更多問題

最壞情況的分析、可觀察性、內部人風險，還有復原計劃。

問題 4：”如果出現問題，最壞情況下，我的損失有多大？“

好的團隊會用一個長段落來回答你，介紹能夠止血的措施。

如果他們無法描述最壞情形，你就當成回答是：“錢全部丟失”。

問題 5：“如果有個攻擊者嘗試偷我的錢，我在日誌裡能看到什麼？”

清晰的審計線索，記錄下被拒絕的嘗試，警告違反了支出條款。

“我們不知道”，或者 “這要分情況”，意味著可觀察性較差。

問題 6：“如何防止監守自盜？”

責任分割、受控制的部署流程、管理員動作受限、危險操作需要人工確認。

如果一個管理員密鑰就能做任何事情，那算不上一種安全模式！

問題 7：“如果出現劫持，要如何復原？”

有詳細說明的事故響應計劃、緊急鎖定步驟、通道關閉策略，以及密鑰輪換或重置計劃。

沒有明文計劃，意味著你是小白鼠。

如果你得到的保障僅僅是 “這是非託管的錢包”，其實你沒有得到答案。

開發者們行動起來

在回答這個艱難的問題時，別再用 “非託管” 來搪塞。請推出明確的保障措施。

1. 定義最壞情況下的劫持模式（要寫下來）。
2. 說明什麼措施能夠防止未經授權的通道關閉和違反支出條款的動作。
3. 撰寫復原、可審計性和操作性安全措施的文檔。
4. 如果你希望獲得雲服務體驗，請瞄準帶驗證簽名器模式，這樣節點被劫持不會導致資金越過支出條款被轉走。

安全性是一種架構選擇，不是一個待辦事項。

現狀：你的錢包有多安全？

以下是主要的閃電錢包和閃電網絡服務商在安全性光譜上的實際位置。

注：分類基於在 2026 年 2 月 11 日可得的公開信息。歡迎供應商們驗證和更新自己的狀態。

（完）