這幾天這條線一路往下拆:Paymaster 把 gas 從使用者身上移開,passkey 與 WebAuthn 換掉了簽章的形式,session keys 再把授權和簽名切成兩件事。三者都在回答同一類問題——怎麼簽、誰代簽、能簽多久。但它們全都建立在同一個前提上:那把金鑰還在你手上。今天要處理的,正是這個前提破掉之後的世界。金鑰弄丟了、或是被偷了,帳戶還有沒有救,這件事決定了前面所有便利性到底值不值得。
📖 學
要理解社交恢復為什麼可能,得先看清楚 EOA 和智慧帳戶在結構上的根本差異。EOA 的地址是公鑰算出來的雜湊,地址本身就是金鑰的函數——換金鑰就是換地址,沒有第三條路。智慧帳戶的地址屬於一份合約,誰有權動用這個帳戶,是寫在合約儲存空間裡的一個欄位。欄位可以被改寫,這就是全部的關鍵。金鑰在智慧帳戶裡從「身分本身」降級成「一項可替換的設定」,恢復與輪替才有討論的餘地。
順著這個結構往下想,金鑰輪替(rotate)大概是智慧帳戶最被低估的能力。市面上介紹智慧帳戶,講的多半是免助記詞、免 gas、一鍵批次交易這些體感層面的東西,但真正不可取代的是:金鑰換掉,資產不用搬家。在 EOA 的世界裡,只要你懷疑私鑰外洩,唯一的處置就是開新帳戶、把所有東西搬過去——NFT、質押部位、鎖倉合約、白名單資格、DAO 成員身分、ENS 反解、鏈上累積的紀錄,一項一項處理。更荒謬的是,搬家的每一筆交易都必須用那把「可能已經被別人拿到」的金鑰去簽,等於在跟攻擊者搶時間。智慧帳戶把這一整套災難壓縮成一筆更換 validator 的交易,原地換鎖,門牌不動。
守護者機制就是替這個「換鎖」動作找到授權來源。做法是預先指定一組守護者(guardian)地址,設定 M-of-N 門檻,當使用者失去主要金鑰時,由其中 M 位共同簽名,授權把帳戶的簽章驗證器換成新的。守護者不保管你的金鑰,也拿不到你的金鑰,他們手上只有一張「同意換鎖」的選票。在模組化智慧帳戶標準 ERC-7579 的做法裡,社交恢復被封裝成一個可插拔的 validator 模組,模組內維護守護者清單與門檻,恢復流程本質上就是讓守護者的簽名去驗證一筆更換 owner validator 的 UserOperation。Safe 那邊則走另一條路,用 Recoverer 加上 Zodiac Delay Modifier,由恢復者提出更換簽署人與門檻的提案。
真正撐住整個安全模型的,其實是延遲期。守護者機制有個結構性的漏洞:守護者能繞過原本的簽署門檻改寫帳戶控制權,那他們自己就成了新的單點風險。延遲期把這件事從「不可逆」變成「可否決」。Safe 的 RecoveryHub 預設延遲 28 天,介面另外提供 7 天、14 天、56 天等選項,並且可以另外設定交易到期時間(預設不限)。恢復是兩段式的:恢復者先送一筆提案上鏈啟動倒數,延遲期滿之後才能執行,而執行這一步任何地址都做得到。在倒數期間——甚至在期滿之後——現有簽署人只要湊得到門檻,就能取消這筆恢復。這代表守護者串謀想搶你的帳戶,你有整整四週可以反應。
但這裡有個必須講清楚的不對稱:延遲期保護的是「金鑰還在你手上,但守護者想搶」這種情境。如果你的金鑰是真的弄丟了,那你就沒有能力按下取消鍵——這時延遲期不但幫不上忙,還單純只是讓你多等四週。同一個參數,對兩種失效模式的作用剛好相反,這正是設定值不好挑的原因。
| 設定取向 | 偏保守 | 偏平衡 | 偏便利 |
|---|---|---|---|
| 守護者數 N | 5～7 | 3～5 | 2～3 |
| 恢復門檻 M | 4/7 | 2/3 或 3/5 | 1/2 |
| 延遲期 | 28～56 天 | 7～14 天 | 24～48 小時 |
| 最容易踩到的坑 | 湊不齊人、拖太久 | — | 串謀、來不及發現 |
| 適合 | 長期冷持倉 | 主力日常帳戶 | 小額熱錢包 |
這張表裡最容易被忽略的是通知這一環,而它偏偏是整套設計最脆弱的地方。Safe 官方文件自己就寫得很坦白:恢復的設定、提案、執行,系統都不會發出任何通知,想知道有人正在恢復你的帳戶,唯一的辦法是打開介面自己看。延遲期的價值完全建立在「你會在期限內看到」這個假設上,而這個假設對一個四週不登入錢包的人來說根本不成立。所以只要你要用恢復模組,就必須自己補上鏈上監控——訂閱帳戶的事件、接到 Telegram 或 email——否則 28 天的延遲期跟 28 秒沒什麼差別。
還有幾個常見誤解值得拆開。第一個是把社交恢復當成「把助記詞切成幾份分給朋友」。那是 Shamir 秘密分割,本質完全不同:分片走的是「重建同一把金鑰」,一旦重組出來,那把金鑰就永久暴露在重組者面前,而且沒有任何延遲期擋著;守護者機制走的是「授權更換金鑰」,守護者從頭到尾看不到任何祕密,而且動作全部在鏈上、可以被否決。第二個誤解是以為當守護者需要懂加密貨幣、需要保管什麼東西——不用,他只需要有一個能簽名的地址,平時什麼都不必做。第三個誤解跟 EIP-7702 有關:2025 年 Pectra 升級之後,EOA 可以委派到合約取得智慧帳戶能力,但這不等於自動獲得恢復。委派的目標合約必須真的實作恢復模組才算數,而且更關鍵的是,原本那把 ECDSA 私鑰在多數實作裡仍然有能力重新指定委派目標。這代表「輪替」在 7702 的情境下未必徹底——舊金鑰若已外洩,攻擊者可能只是被換掉了實作,而不是被關在門外。要用 7702 做恢復,務必先確認該實作怎麼處理原生金鑰的權限。
最後是隱私與串謀。守護者名單放在鏈上,等於公開了你的一小片社交圖譜,同時也把攻擊面標示得清清楚楚——攻擊者知道該去騙誰、該去威脅誰。緩解方向有幾個:名單只存承諾雜湊、恢復時才揭露;請守護者使用專門的地址而不是他們的主錢包;守護者跨關係圈挑選,家人、同事、機構服務、加上一個自己保管但完全不上鏈的硬體錢包,避免整組人能在同一場家庭聚餐裡被一次搞定。至於門檻,M 太低容易串謀,M 太高容易失聯,而實務上更常發生的失效不是背叛,是找不到人、換了手機、忘記當初用的是哪個地址。這種失效只能靠定期演練發現。
得說清楚立場:裝恢復模組不是純粹的加分項。恢復模組本身就是一份擁有特權的合約,它在你的帳戶上開了一條可以繞過原本門檻的路,攻擊面是實打實變大的。所以該看的是模組的程式碼與審計紀錄、模組能不能被移除、以及更改守護者名單這件事本身有沒有延遲保護——如果攻擊者拿到金鑰後可以瞬間把守護者換成自己,那整套設計就白做了。一份沒有審計、來路不明的恢復模組,比完全不裝恢復更危險。
🧠 記
- 智慧帳戶把金鑰從「身分本身」變成「合約裡一個可寫的欄位」,rotate 才成為可能;EOA 換金鑰等於換地址,只能搬家。
- 金鑰輪替的真正價值是「換鎖不換門牌」:資產、部位、聲譽、ENS 全部留在原地,一筆交易解決。
- 守護者不保管你的金鑰,只持有一張「同意換鎖」的選票;M-of-N 門檻決定要幾張票才算數。
- 延遲期把守護者作惡從不可逆變成可否決。Safe RecoveryHub 預設 28 天,另提供 7/14/56 天;提案與執行分兩段,現有簽署人可在期間內取消。
- 延遲期只保護「金鑰還在但守護者想搶」;金鑰真的丟了的時候,它只是讓你多等。
- 沒有通知就沒有延遲期。Safe 明講恢復的設定、提案、執行都不發通知——監控要自己接。
- 社交恢復 ≠ 助記詞分片。分片是重建同一把祕密且無法撤回;守護者是授權更換金鑰且全程可否決。
- EIP-7702 的 EOA 升級不會自動帶來恢復,而且原生 ECDSA 金鑰常常仍能重新委派,輪替未必徹底。
✍️ 實踐
打開你目前實際在用的智慧帳戶(Safe 或任何 ERC-4337 錢包),進到安全設定頁,花十分鐘把四件事抄下來:現在的簽署人是誰、門檻是幾分之幾、有沒有安裝恢復模組、延遲期設幾天。多數人抄到第三項就會發現答案是「沒有」。如果是這樣,今天先別急著往主帳戶上裝——挑測試網,或開一個只放零頭資金的帳戶,把恢復模組設起來,然後實際跑一次「提出恢復提案 → 用原簽署人取消」的完整流程,重點是親手找到取消按鈕在哪、確認它真的按得下去。剩下的五分鐘做三個自我檢查:如果今天手機掉進海裡,我要幾天才能拿回帳戶控制權;如果我最信任的那位守護者今晚被社交工程騙走簽名,我會在幾小時內知道,還是四週後才發現;我的守護者名單裡,有沒有兩個以上的人會固定出現在同一個飯桌上。三題只要有一題答不出來,你的恢復設定就還沒完成。
🔗 延伸學習
- Why we need wide adoption of social recovery wallets — Vitalik Buterin
- Account recovery with Safe{RecoveryHub} — Safe 官方知識庫(延遲期、Recoverer、取消機制)
- How to recover an account using the Social Recovery Module — ERC-7579
- ERC-7579: Minimal Modular Smart Accounts
💬 問 AI
我目前使用的智慧帳戶是 <錢包名稱 / Safe>，主要在 <鏈名> 上，帳戶內資產規模大約 <金額級距>，
日常使用頻率是 <每天 / 每週 / 每季一次>。
請幫我做四件事：
1. 針對我的情況，建議守護者數量 N、恢復門檻 M、延遲期天數的具體組合，
並逐項說明每個選擇犧牲了什麼、換到了什麼。
2. 分別分析「守護者串謀」與「守護者失聯」這兩種失效模式，在我的設定下
各自需要幾個人出事才會導致資產不可恢復。
3. 我的使用頻率能不能撐住你建議的延遲期？如果不能，請設計一套通知與監控方案，
讓我能在惡意恢復提案上鏈後的 24 小時內知道。
4. 幫我寫一份年度演練清單：每年我應該實際操作哪些步驟，才能確認恢復流程真的可用。
最後請直接指出我這套方案裡最脆弱的一環，並說明攻擊者最可能從哪裡下手。
不要給通用建議，請針對我提供的條件回答。