解決比特幣自主託管的三難困境 (Solving Bitcoin's Self-Custody Trilemma)
作者：Luke Childs | 發布時間：2026 年 8 月 7 日 | 原文來源：lu.ke上週，攻擊者開始清空 Coldcard 錢包。由於一個韌體漏洞導致其隨機數生成器（RNG）變得可預測，攻擊者完全不需要接觸實體設備，就能重新推算並生成種子詞（seed phrase）。目前損失金額已超過 1.3 億美元，且仍在持續上升。
我的種子詞最初就是在受影響的 Coldcard 上生成的。我之所以沒有損失畢生積蓄，唯一的理由是：多年前在設定該設備時，我拒絕完全信任它的隨機數生成器。我當時在 MacBook 上生成了 256 位元的熵（entropy），拋硬幣 256 次，並將這些熵全部混合輸入到 Coldcard 本身的熵之中。在此之前，我還做了一次測試演練，從頭重寫了 Coldcard 的種子衍生邏輯，以驗證我的額外熵來源會被正確地組合。
• 來自 Coldcard 內部 SRNG 的 256 位元
• 來自 MacBook 透過 Node.js crypto.randomBytes 生成的 256 位元
• 來自宇宙（拋硬幣）的 256 位元
要避免損失畢生積蓄，居然需要達到這種「偏執狂（paranoid schizophrenia）」級別的防範，這簡直荒謬至極。任何人都不應該被逼著做到這種地步。
直接原因是一個韌體 bug。但根本原因是：我們整個加密貨幣行業的標準建議，把使用者的全部積蓄都押在單一設備上，並盲目祈禱該設備的硬體、韌體、供應鏈和隨機數生成器永遠完美無瑕。
大家現在都在問：我們要如何防止這種悲劇再次發生？要回答這個問題，你必須先理解為什麼目前的每一種方案都是有缺陷的。
比特幣自主託管的三難困境 (Bitcoin's Self-Custody Trilemma)
今天，你只能三選二。市場上沒有任何一個自主託管方案能夠同時滿足這三個特性。讓我們逐一檢視現有的選擇：
1. 單簽 (Singlesig: 熱錢包或單一硬體錢包)
單簽具備無須信任與易用性（一台設備，點擊即可支付）。但它存在巨大的單點故障（Single Point of Failure）。一次漏洞、一次偷竊，或一次不良的備份，就會導致資產全毀。上週絕大多數 Coldcard 受害者都位於三角形的這條底邊上，並因此損失了畢生積蓄。
2. 多廠商多簽 (Multivendor Multisig)
多簽兼具安全性與無須信任。但它的使用體驗極其痛苦：需要管理多台設備、多個種子詞備份、多個安全存放地點、多個 PIN 碼，還要每年進行巡禮以檢查設備是否損壞。如果把這種方案推薦給普通人，因操作失誤和帳號鎖死造成的資金損失，最終會比駭客盜竊的還多。這對大多數人來說不是一個現實的選擇。
3. 協同託管 (Collaborative Custody，如 Casa, Bitkey)
協同託管（例如 Casa 和 Bitkey）讓事情變得有趣。Casa 讓多簽變成了普通人真正能用的產品。Bitkey 在用戶體驗上更近一步：無種子詞，手機可以在硬體預先授權的限額內直接支出，只有大額提款才需要碰硬體錢包。這是感覺像熱錢包的冷儲存。
問題在於信任模型。託管服務商持有其中一枚協同簽署金鑰，且控制著手機 App 的更新管道。一次惡意 App 更新，他們就能掌握 3 枚金鑰中的 2 枚。我並不是說這很可能發生——他們顯然是聲譽良好的公司。但試想一下，如果發生類似行政命令 6102（Executive Order 6102，強制沒收黃金/資產）的事件，私有託管被定為非法，政府強制要求公司配合沒收資產，他們的員工是不會為了保護我的資產而替我去坐牢的，我也不能這樣要求他們。
三角形的三條邊，代表了目前所有解決方案被迫做出的三個妥協。這就是自主託管的三難困境。
介紹 Anzen：破解三難困境
自 Coldcard 事件爆發以來，我和許多人一樣徹夜難眠。我一直在思考如何徹底防止此類事件再次發生。我相信我設計出了一種全新的錢包架構，機能同時滿足自主託管三難困境的三個頂點。
Anzen 的設計目標是極度易用且極難出錯——幾乎不可能弄丟資金。它具備與「2-of-3 多廠商多簽」同等的安全性，使用體驗卻像熱錢包一樣簡單，同時保持完全的無須信任（Trustless），無需任何第三方參與。
這是一個金庫（Vault）架構，完全可以在當前的比特幣網路上運行。不需要第三方協同簽署者、不需要伺服器、不需要軟分叉、不需要新的 Opcode。完全由比特幣的共識規則進行無須信任的強制執行。
Anzen 只使用兩枚金鑰：一台手機，和一個硬體錢包。金庫就是你的冷儲存；手機則同時充當日常熱錢包與金庫的協同簽署者。攻擊者必須同時攻破這兩枚金鑰才能盜走資金。
Anzen 金庫透過組合上述腳本與一系列預簽名的時間鎖交易鏈（Presigned Timelocked Transactions），實現了比特幣初衷中的可程式化貨幣功能。它支援：
- 每月額度 (Monthly allowances)： 每個月，有一筆預先設定好的固定金額釋放出來。手機可以單獨將其從冷儲存中提取到內建的熱錢包中。
- 緊急提款 (Emergency access)： 手機可以隨時發起預先設定的大額提款。提款觸發後需要等待 1 週的延遲（1-week delay），在此期間可以隨時被撤銷。如果偷車賊偷了你的手機並觸發緊急提款，這只相當於響起了長達一週的警報，讓你隨時可以關閉並阻斷提款。
- 撤銷機制 (Revocations)： 每一個預授權的每月額度都可以被隨時、永久地撤銷，並將資金回滾重置回冷儲存中。
可以把這想像成支票帳戶與儲蓄帳戶：熱錢包是你的支票帳戶，金庫是你的儲蓄帳戶。每月額度就像是每個月 1 號從儲蓄帳戶自動轉帳固定金額到支票帳戶。緊急提款就像是一筆需要 1 週時間審核交割的大額轉帳申請，在此期間你可以隨時取消。
每年一次（最好在每年同一天），你在硬體錢包上重新核准金庫政策。這會自動觸發手機與硬體錢包之間的簽署儀式，滾動更新金庫（重置時間鎖），並預先授權未來一整年的支出額度。
在一年的其餘 364 天裡，你只需要使用手機。這就是核心價值所在：擁有熱錢包的操作體驗，同時享有冷儲存的背後保障。
為什麼這些主張成立？ (Why the claims hold)
我這裡做出了非常強烈的主張，但我相信每一個主張都是精確且相對容易驗證的：
安全性媲美 2-of-3 多簽： 在 2-of-3 多簽中，攻擊者需要攻破 2 台設備。安全性取決於你最脆弱的兩台設備。Anzen 要求攻擊者同時攻破位於完全獨立設備上的兩枚完全獨立的金鑰。這是相同的門檻，但需要管理的設備更少。且與 2-of-3 多簽一樣，Anzen 在單一金鑰丟失或洩漏時依然安全。Anzen 甚至具備可選的社交恢復路徑，即使兩台設備同時遺失也能恢復。這比 2-of-3 多簽具備更強的抗遺失能力。
| 發生何種異常狀況 (What goes wrong) | 你該怎麼做 (What you do) | 攻擊者能獲得什麼 (What the attacker gets) |
|---|---|---|
| 手機遺失、損壞或被盜 | 從加密雲端備份復原，幾分鐘內搞定 | 一台鎖定的手機。什麼也拿不到。 |
| 硬體錢包遺失或被盜 | 靠每月額度維持生活；待手機的 14 個月時間鎖到期後，恢復整個金庫 | 一個鎖定的設備。什麼也拿不到。 |
| 手機金鑰遭攻破/洩漏 | 從備份復原，取消所有懸而未決的提款，轉移資產至新金庫 | 最多只能拿到當時已存在手機熱錢包內的餘額 |
| 硬體錢包金鑰遭攻破/洩漏 | 你的手機解鎖日期比攻擊者早整整一個月（14 個月 vs 15 個月）。直接轉移資金，你在競賽中獲勝 | 什麼也拿不到（只要你在這一個月的領先期內採取行動） |
| 兩台設備同時遺失 | 使用可選的社交恢復路徑復原 | 無 |
| 兩枚金鑰同時被同一個攻擊者在同一時間視窗內攻破 | 資產全失（這是所有頂級架構人都會失守的極限門檻） | 全部資金 |
你真的必須非常「努力」才有可能在 Anzen 中弄丟資產。只要你不要蒙著眼睛、張開雙臂走在大街上，一手拿著解鎖的手機，另一手拿著解鎖的硬體錢包，你就是安全的。
無須信任 (Trustless)： 沒有第三枚金鑰、沒有協同簽署伺服器、沒有掌握資金控制權的公司更新管道。連恢復機制都不增加任何信任假設：雲端備份是你的手機金鑰，並經過加密，只有你的硬體錢包可以解密。社交恢復只是在雲端增加另份副本，加密至信任聯絡人的金鑰：他們不持有任何資產，甚至不知道自己是你的恢復聯絡人，直到你告訴他們。他們僅僅是協助你解密雲端備份。即使恢復出了金鑰，仍需等待金庫的時間鎖到期。
所有資金流向均寫入你可以親自審閱的比特幣腳本中，或由你自己的硬體簽署。沒有任何人能被法院傳喚來沒收你的錢包，因為沒有其他人參與其中。
易用 (Easy to use)： 設定良好後，硬體錢包每年只需要核准一次。其餘所有操作都在手機上完成。這比單簽硬體錢包還要省力（單簽硬體錢包每次支出都需要手持設備）。日常使用中，Anzen 的體驗無限接近行動熱錢包。
「但是預簽名交易聽起來很複雜」
底層技術確實複雜：年度簽署儀式會將金庫拆分為多個區塊，並預先簽署一整套結構嚴密的交易。但這些複雜性完全不需要呈現在使用者面前。這純粹是一個工程問題，且完全可解。就像沒有人需要理解 Diffie-Hellman 金鑰交換演算法才能透過 HTTPS 瀏覽網頁一樣，也沒有人需要理解如何管理預簽名交易鏈才能核准 Anzen 金庫政策。
真正的缺口在於硬體：目前的硬體錢包都不支援這類設計，因為它們都是圍繞著「簽署這筆交易（sign this transaction）」這一原語建立的。我們需要的原語是：「核准此政策（approve this policy）」。手機草擬計劃，硬體錢包的螢幕用通俗易懂的語言顯示全部內容。硬體錢包上的金庫政策審核畫面，對於 Anzen 的意義，就像瀏覽器網址列上的綠色鎖頭對於 HTTPS 的意義一樣。
金庫未來十二個月所需的所有交易，均透過一次按鍵完成簽署：每月額度、可取消額度的撤銷交易，以及緊急交易包。手機加密儲存這些交易並用其運行金庫，硬體錢包則放回抽屜，直到明年同一天前都無需使用。
我們下一步該怎麼走？ (Where do we go from here?)
這不僅僅是一個想法。我已經在主網（Mainnet）上運行了一個概念驗證原型，使用真實資金，完全實現了所有金庫功能與恢復路徑。雖然尚未達到生產級標準（還很早期），但如果你想用少量資金進行測試，它已經可以使用了。
此外還有一套在 regtest 上運行的端到端測試套件，以及一個互動式 CLI 工具，可完整模擬手機、硬體錢包及它們之間的所有操作。
這是我的主網金庫地址，熱烈歡迎大家嘗試去攻擊它：
bc1pvaultn3953ns47dw6rpm6ahfpz449vcnns5rpnr5v2d0u55fekxq39v257
我非常歡迎同行進行技術審查（Peer review），也樂於接收任何反饋。目前專案庫還很簡陋，但歡迎讓你的 AI Agent 對準 github.com/lukechilds/anzen 並請它帶你瀏覽整個架構設計。
雖然目前它還只是一個 CLI 工具，但我將致力於開發 Anzen 的全棧參考實現，以完整展示其 UX 可以多麼流暢。這很可能是一個 iPhone App 加上一個自訂的側載 Companion Ledger App。
『譯注：這句話翻譯過來是： 「這（參考實現）很可能會包含一個 iPhone App，以及一個專為 Ledger 硬體錢包開發、可供使用者自行『側載』安裝的搭配程式。」
白話一點來說，作者（Luke Childs）的意思是：
為了向大家展示這套系統到底可以做得多順手，他計畫開發兩個互相搭配的軟體：
- iPhone 上的 App（手機端）： 你日常使用的主要介面，就像一般的行動銀行或熱錢包，用來查看餘額、領取每月額度或發起緊急提款。
- Ledger 硬體錢包裡的專用小程式（硬體端）： 因為目前市面上的硬體錢包（如 Ledger）預設都不支援這種「核准金庫政策」的新功能，所以他必須自己寫一個裝在 Ledger 裡的配套小程式，用來跟手機溝通，完成每年一次的核准儀式。
關鍵字淺白拆解：
- Companion（搭配 / 配套）： 指這個 Ledger 小程式是專門用來跟 iPhone App 湊成一組、互相配合運作的。
- Sideloadable（可側載 / 手動安裝）： 「側載」是指繞過官方應用商店。一般人下載 Ledger 小程式都是透過官方軟體（Ledger Live）直接搜尋安裝；但因為這是作者自己寫的原型測試版，還沒通過 Ledger 官方審核上架，所以使用者必須透過傳輸線，把軟體檔案手動「燒錄/安裝」進自己的硬體錢包裡。』
我的目標是同時開發參考實現與開放的 Anzen 協議。這個想法是讓任何人都能實現該協議。如果我能透過參考實現驗證其使用場景，並且大家看到了其中的價值、獲得了一些關注，那麼未來我們可能會看到：你可以在原生 Ledger 搭配 Ledger Live 上創建 Anzen 金庫；或者使用 Trezor 作為硬體簽署端、BlueWallet 作為熱錢包端；甚至是 Bitkey 支援可選的主權模式（Sovereign mode），將他們的協同簽署者替換為 Anzen 基於共識的替代方案。
Anzen 是作為個人副業專案開發的，與 Umbrel 無關，採 MIT 開源授權。
致謝：感謝 Casa、Bitkey 與 Liana 將比特幣自主託管帶入現代。Anzen 的設計深受這三個團隊開創的技巧啟發。
結語 (Final thoughts)
Coldcard 的狀況極其令人痛心，因為 Coldcard 用戶做對了一切。就我而言，產業標準建議一直都是單簽硬體錢包。雖然這次問題表現為 Coldcard 的韌體漏洞，但這歸根結底是比特幣技術社群的一次慘痛失敗。我們辜負了使用者，未能提供優質、高水準的自主託管工具。
事件發生後，我看到有人宣稱自主託管不適合大多數用戶；我看到有人宣稱每個人都應該轉向多廠商多簽；我看到有人宣稱用戶有責任自學安全的隨機數生成法。這令人失望，我們正在重複同樣的錯誤。
比特幣的腳本能力雖然有限，但遠未到束手無策的地步。金庫（Vault）類型的架構長期以來被嚴重低估與忽視。
我們擁有構建更好自主託管方案的工具，現在只需要開始動手構建。
