拆開一台正品 Ledger 之後，TBC 談自托管的真正邊界

一台從正規渠道買來的硬體錢包，包裝完好，防偽貼紙沒動過，開機自檢一切正常。但它內部已經被植入了一枚用於捕獲恢復短語的隱藏元件。

2026 年 10 月 15 日，Ledger 官方回應了這起事件：攻擊者購買正品設備，拆機植入硬體，再通過東南亞經銷渠道重新流入市場。Ledger 強調晶片、操作系統和伺服器均未被攻破，定性為局部經銷渠道攻擊，而非系統性供應鏈入侵。

10 月 14 日，Tom's Hardware 援引 Bloomberg 的報導給出的損失估算約為 9300 萬美元。需要說清楚：這個數字來自第三方媒體，不是 Ledger 官方聲明確認的金額。

數字歸屬誰並不重要。重要的是它暴露的那件事。

一 自托管沒有消滅風險只是把風險換了位置

過去十年，行業講了一個很乾淨的故事：把幣放在交易所，你就把命運交給了一家公司；把私鑰握在自己手裡，你就自由了。

這個故事有一半是真的。

交易所托管的風險是集中的、可見的：挪用、擠兌、破產、監管凍結。FTX 之後，「Not your keys, not your coins」被更多用戶接受，行業也開始更認真地討論自托管工具與助記詞保管。

但自托管不是風險的終點，而是風險的轉移。

它把「平台會不會作惡」這個問題，換成了另外一串問題：你的設備從哪來？固件是否被改過？助記詞在什麼環境下生成？簽名時螢幕上顯示的內容，和實際簽的交易是否一致？誰有權發起這筆轉帳？

這串問題裡，任何一個環節失守，結果和交易所跑路沒有區別。9300 萬美元的第三方估算，本質上買的就是這個教訓。

更麻煩的是，這類攻擊的形態變了。它不攻破密碼學，不攻破晶片，不攻破共識算法。它攻破的是物理世界和信任鏈條的接縫處：經銷渠道、拆機環節、二次封裝、物流中轉。

密碼學可以證明一筆簽名有效，但證明不了簽名的那隻手是不是被脅迫的，也證明不了那台設備有沒有在你看不見的地方，把助記詞悄悄發出去。

安全模型裡最脆弱的一環，從來不是算法，是人、設備和流程。

二 把單點私鑰拆成多個可驗證條件

Ledger 事件的真正啟示不是「別用硬體錢包」，而是：只依賴「私鑰在我手裡」這一條假設，本身就是單點故障。

正確的方向是讓資金轉移需要同時滿足多個條件，且這些條件分佈在不同的信任域裡。

TBC 在這件事上的位置，需要說得克制一些。它不宣稱能消除終端攻擊，任何一條鏈都做不到這一點。它的價值在於：UTXO 原生合約與多簽工具，讓項目可以把單點私鑰風險拆成多個可驗證條件。

具體來說，TBC 採用 SHA256 PoW 與 UTXO 模型，節點代碼 TBCNODE 公開可查。UTXO 模型的天然特性是：每個未花費輸出可以被獨立的腳本條件約束，而不是掛在一個全局賬戶餘額上。這意味著支出規則可以寫進鏈上，而不是寫在某個後台服務裡。

tbc-contract SDK 提供鏈上查詢、UTXO 獲取、交易構造、簽名和廣播，並包含 MultiSig、NFT、FT 與 Pool 工作流。官方 MultiSig 示例支持在 3 至 10 個公鑰中設置 1 至 6 個簽名門檻，文檔給出了 2-of-3 的示例。

這裡必須把話說完整：多簽是可配置的風險控制工具，不是自動安全，更不是絕對安全。

如果有人以為配了 2-of-3 就萬事大吉，那和相信「買了硬體錢包就安全」是同一個錯誤。多簽改變的是攻擊成本結構，不是攻擊的可能性。

TBC AMM 文檔說明了另一件事：SDK 在本地構造、報價和簽名，廣播由應用顯式發起；池狀態和資產控制依賴 UTXO 與腳本規則。這構成了非托管交易和權限分離的基礎。

同樣要說清楚邊界：這不意味著 AMM 沒有合約風險、價格風險或前端風險。本地簽名解決的是「私鑰不離開設備」，解決不了「你簽的那筆交易是不是你真正想簽的」。

三 多簽為什麼常常只是形式上的分散

這是最容易被跳過、也最致命的一段。

如果多個簽名密鑰來自同一份助記詞，保存在同一台設備上，或者由同一個人控制，多簽就只是形式上的分散。

攻擊者拿到一份助記詞，就等於拿到全部簽名權。設備被植入一次，就等於所有門檻同時失守。這種配置在鏈上看起來是 3-of-5，在現實中是 1-of-1。

所以真正要問的不是「我配了幾個簽名」，而是幾個更硬的問題：

• 這些密鑰的生成環境是否相互獨立？
• 它們是否存放在物理隔離的不同設備上？
• 發起交易的人，和批准交易的人，是不是同一批人？
• 高風險轉帳有沒有延時和人工複核？
• 密鑰輪換和恢復流程有沒有演練過？

TBC 的 UTXO 模型不會自動修復被盜私鑰。 這一點必須承認。鏈上規則能做的是：當某個條件被破壞時，阻止未經授權的資金轉移；它做不到的是：在私鑰已經洩露的情況下憑空恢復資產。

配套的工程實踐仍然不可省略：獨立簽名設備、密鑰輪換、單筆與日限額、時間鎖、高風險交易的多方複核，以及可執行的恢復預案。

還有一層必須坦白：TBC 自身仍需繼續改善。 多簽互動的易用性、與主流硬體錢包的兼容深度、開箱即用的權限模板、獨立第三方基準測試，以及 SDK、錢包、AMM 各組件的持續審計，都是進行中的工作。

TBCNODE 已有 CertiK 與 SlowMist 的版本化安全審查記錄。但審計只能證明特定版本、特定範圍被檢查過，它覆蓋不了硬體終端，覆蓋不了用戶的密鑰管理習慣，覆蓋不了未來提交的代碼，也覆蓋不了全部應用層邏輯。把審計報告當作安全證書，是另一種形式的偷懶。

四 真正的自托管是一條鏈上規則

回到那台被拆開的設備。

它提醒我們，「私鑰在自己手裡」是一句必要條件，不是充分條件。 設備來源、簽名權分配、鏈上支出規則，這三件事必須同時成立，安全結構才站得住。

行業接下來的變化大概率是：硬體錢包廠商會加強渠道管控和防拆設計，保險和托管服務會重新定價物理供應鏈風險，而項目方會開始把「權限設計」當成和「代碼審計」同等重要的工程議題。

TBC 在這個圖景裡的位置，不是「解決硬體攻擊的方案」，而是提供把權限規則寫進鏈上的工具：UTXO 原生合約約束支出條件，多簽把簽名權拆到不同信任域，非托管交易組件讓私鑰不離開本地。

真正的自托管，不是只有一把私鑰，而是任何單點失守之後，鏈上規則仍然能阻止未經授權的資金轉移。

資料來源 來源鏈接： Ledger · Tom's Hardware · TBCNODE · Contract SDK · MultiSig · AMM · CertiK · SlowMist