昨天那個 recovery validator，是「裝」進帳戶裡的。不是重新部署一個新錢包合約，不是換掉 implementation，就是對既有帳戶呼叫一個叫 installModule 的函式，把一段別人寫好的驗證邏輯掛上去，恢復流程從此生效。這件事能成立，靠的不是善意，是一份規格：帳戶必須事先答應「我接受外掛」，而且要用所有人都認得的方式接受。今天就把這層地基挖出來看——模組化智慧帳戶標準，以及 ERC-7579 跟 ERC-6900 這兩套規格到 2026 年還沒真正打完的那場架。
📖 學
先把問題定義清楚。這幾天講的東西——passkey 簽章、session keys、社交恢復——沒有任何一項屬於「帳戶的核心功能」。它們都是可選的行為擴充。如果每加一個功能就要改一次帳戶合約、重新審計、要求使用者遷移資產，那智慧帳戶的可程式化就只是口號，實際上比 EOA 更難維護。所以整個生態的答案是：把帳戶本體做薄，功能全部外掛化。帳戶只負責「誰有權簽、怎麼執行」的最小骨架，其他一律做成模組，隨裝隨卸。
問題是「模組」得有共同介面。如果 Safe 的模組跟 Kernel 的模組長得不一樣，那寫一個 session key 驗證器的團隊就得為每種錢包各寫各審一份，模組生態根本長不出來。這就是 ERC-7579 想解決的唯一一件事：讓模組跨帳戶可攜。
ERC-7579 的做法出乎意料地保守。它不定義權限系統、不定義升級路徑、不規定帳戶要怎麼存狀態，只定義兩邊的握手。帳戶那側要實作 installModule、uninstallModule、isModuleInstalled，加上一個回報自己身分的 accountId()；模組那側要實作 onInstall、onUninstall，還有一個 isModuleType(uint256) 讓帳戶問「你到底是哪種模組」。
那個「哪種」很關鍵。ERC-7579 把模組分成四類，各有固定的 type ID：
| type ID | 模組類型 | 執行時機 | 典型用途 |
|---|---|---|---|
| 1 | Validator 驗證器 | 驗證階段，決定這筆交易算不算有效簽章 | passkey/P-256 驗章、多簽門檻、session key 權限、恢復模組 |
| 2 | Executor 執行器 | 執行階段，代表帳戶主動發起呼叫 | 定期扣款、自動複利、跨鏈執行、限額轉帳 |
| 3 | Fallback handler | 帳戶收到未知 calldata 時 | 補上帳戶本體沒實作的介面（如各種 receiver 回呼） |
| 4 | Hook 掛鉤 | 執行前後各跑一次 | 花費上限、白名單檢查、風控攔截、事後記帳 |
分類不是為了整齊，是為了安全。規格裡明確警告過：如果帳戶不區分模組類型，就可能讓一個「只該負責驗簽」的 validator 拿到「代表帳戶發交易」的能力——那等於把驗票員直接升級成金庫管理員。type ID 是授權邊界的實體化。
理解了這四類，前幾天的內容就能全部歸位。08-23 那顆 secp256r1 驗章邏輯是 validator；08-24 的 session key 是 validator 加上 hook（前者判斷臨時金鑰的簽名，後者強制花費上限）；08-25 的 recovery validator 就寫在名字裡；而 Safe 那套 Delay Modifier 延遲期，本質是一組 executor 加狀態機。這條系列走到今天，其實是先看了四片拼圖，今天才看到拼盤本身。
不過模組化還有一層更麻煩的問題：權限。裝一個 executor 進帳戶，等於給它「可以代我發交易」的鑰匙——那它能動多少錢？能呼叫哪些合約？跟其他模組衝突時誰優先？ERC-7579 對這些幾乎不表態，理由是「最小規格才能被最多人採用」，權限交給帳戶實作或後續擴充 ERC（例如 ERC-7780 補上 signer、policy、stateless validator 三種新類型）去補。
ERC-6900 走的是完全相反的路。它由 Alchemy 在 2023 年較早提出，路線是「一次把框架做完」：每個 plugin 要附一份 manifest，事前宣告自己需要哪些權限、依賴哪些其他 plugin、要在哪些函式上掛 hook，帳戶在安裝時就能靜態檢查衝突。它管的是整條生命週期，不只是握手。v0.8 之後連 session key 的權限模型都被拆得更細更模組化。
兩條路線的對照大致是這樣：
| ERC-7579 | ERC-6900 | |
|---|---|---|
| 起源 | 2023 年底，Rhinestone、Biconomy、ZeroDev、OKX 等多方聯合 | Alchemy 發起，時間更早 |
| 哲學 | 極簡介面，只保證模組可互通 | 完整框架，權限與依賴事前宣告 |
| 權限模型 | 標準本身不管，靠擴充 ERC 與帳戶實作 | 內建 permission graph 與 hook 生命週期 |
| 代表實作 | Safe（透過 Safe7579 adapter）、ZeroDev Kernel V3、Biconomy Nexus、Etherspot、OpenZeppelin 的 AccountERC7579 preset | Alchemy Modular Account V2 |
| 取捨 | 彈性最大，安全責任落在帳戶實作者身上 | 邊界清楚可靜態驗證，但綁得緊、進階場景難塞 |
到 2026 年，這場架的結果偏得很明顯。ERC-7579 在陣營廣度上贏了：新做智慧帳戶產品的團隊——Biconomy Nexus、ZeroDev Kernel V3、Trust Wallet 的智慧帳戶——幾乎都直接選 7579 當原生模組標準，OpenZeppelin 也把它做成官方 preset。而 Safe 這個部署量最大的智慧帳戶實作，自己的模組系統其實比 7579 更早存在、介面也不一樣，最後選擇的是掛一層 Safe7579 adapter 去兼容外部模組生態，而不是要生態來配合它。這個決定的訊號比任何投票都清楚：模組生態的網路效應，已經大過單一錢包的裝機量。
ERC-6900 沒有消失，但更像 Alchemy 自家棧內部的深度整合方案。ZeroDev 當年公開寫過他們為什麼選 7579 而不是 6900，理由不是 6900 設計差，而是它對「鏈下切換模組」、「簽章聚合器」這類進階需求管太緊——這也精準說明了兩套規格真正的分歧點：一個賭「先鬆再補」，一個賭「先嚴再放」。工程上兩者都有道理，市場最後選了前者。
接下來是我認為今天最該記住、也最容易被行銷語言蓋掉的部分。模組化不是免費的樂高，它是把攻擊面外包出去。 帳戶本體再怎麼審計乾淨，只要你裝了一個第三方 executor，那段程式碼就有權代表你的帳戶發交易；只要你裝了一個 hook，它就跑在你每一筆交易的前後——寫壞的 hook 可以讓整個帳戶再也發不出交易（拒絕服務），惡意的可以靜靜改寫你的資金流向。更陰的細節：卸載時帳戶會呼叫模組的 onUninstall，而一個惡意或寫得糟的模組可以在這裡 revert 或把 gas 燒光，讓「卸載」本身變得困難。規格文件對這類風險是有討論的，但規格能做的只有提醒，擋不住使用者亂裝。
生態對此的答案是 ERC-7484：模組註冊表。核心概念是把「這個模組安全嗎」變成鏈上可查的資料——開發者部署模組，審計者對它做鏈上 attestation（安全簽證），帳戶在安裝甚至執行前去 registry 查一次：這個模組有沒有被我信任的審計者背書？背書數量夠不夠我的門檻？Rhinestone 是這塊的主要推手，他們的 Module Registry 加上 ERC-7484 的介面規格，讓「安裝模組」從盲信變成可設定信任門檻的動作。
我的立場很直接：模組數量不是能力指標，是風險指標。 選錢包時該問的不是「支援幾百個模組」，而是「它有沒有接 registry、預設信任誰、我能不能自己設門檻」。裝模組前該問的是「這個模組被誰審過、attestation 在鏈上查得到嗎、它拿到的是 validator 權限還是 executor 權限」。如果一份模組商店的介面長得像 App Store 卻查不到 attestation 來源，那它賣的不是功能，是你的資金授權。這一點跟前幾天講 session keys 和社交恢復的結論是同一條：智慧帳戶把單一私鑰的風險，換成了一組可設計的風險。可設計不等於自動變小，只等於責任從「保管助記詞」搬到「審查你裝了什麼」。
🧠 記
- 模組化帳戶的目的：帳戶本體做薄只留最小骨架，功能全部外掛，避免每加一個功能就要改合約、重審計、遷移資產。
- ERC-7579 是極簡標準，只解決一件事：模組跨帳戶可攜。帳戶側
installModule／uninstallModule／isModuleInstalled／accountId，模組側onInstall／onUninstall／isModuleType。 - 四種模組類型與 type ID：1 validator（驗簽）、2 executor（代發交易）、3 fallback handler（補介面）、4 hook（執行前後攔截）。區分類型是授權邊界，混用會讓驗證器變成金庫管理員。
- passkey 驗章、session key、社交恢復模組全都是 validator（session key 另加 hook 管限額）——前三天講的東西都是這個框架下的具體模組。
- ERC-6900 由 Alchemy 發起，走完整框架路線：plugin manifest 事前宣告權限與依賴，內建 permission graph 與 hook 生命週期，安全邊界清楚但彈性受限。
- 2026 現況是 7579 陣營明顯占優：Kernel V3、Nexus、Etherspot、Trust Wallet 原生採用，OpenZeppelin 出官方 preset，連 Safe 都選擇掛 Safe7579 adapter 去兼容而非要生態配合自己。
- ERC-7484 module registry 是模組化的必要配套：審計者對模組做鏈上 attestation，帳戶安裝前查詢背書與門檻，把「盲信第三方模組」變成可設定的信任決策。
- 風險立場：模組數量是風險指標而非能力指標。executor 等於代發交易權、hook 跑在每筆交易上（可造成拒絕服務），且惡意模組能在
onUninstall裡 revert 或燒光 gas 讓卸載變困難。
✍️ 實踐
大約 15 分鐘，目標是把「模組」從名詞變成你看得懂的清單。
第一步（約 5 分鐘） 打開 erc7579.com 的 modules 頁面，隨手挑五個模組，逐一標註它屬於四種 type 的哪一種。標的時候不要看它的分類標籤，先自己判斷：這東西是在「決定簽章有效與否」（validator）、「代表帳戶發交易」（executor）、「在每筆交易前後攔一下」（hook），還是「補一個帳戶沒實作的介面」（fallback）？判斷完再對答案。錯的那幾個特別值得停下來想——通常錯在低估了 executor 的權限有多大。
第二步（約 5 分鐘） 挑其中一個 executor 類的模組，寫下三行答案：它能動我帳戶裡多少資產？它有沒有花費上限，上限是誰設的？如果它的部署者跑了或私鑰被偷，我最壞會損失什麼？寫不出來就是資訊不足，那本身就是結論——這個模組現在不該裝。
第三步（約 5 分鐘） 回頭盤點你自己實際在用的智慧帳戶（Safe、任何 4337 錢包，或用 EIP-7702 升級過的地址）。列出：它是哪種帳戶實作？支援的是 7579、6900、還是自家私有模組系統？我目前實際裝了哪幾個模組、各是什麼類型？有沒有任何一個是我已經忘了為什麼裝的？
第三步找到的那個「忘了為什麼裝的」，就是你今天真正的收穫。順手把它卸掉，或至少查清楚它是什麼。
🔗 延伸學習
- ERC-7579: Minimal Modular Smart Accounts — 規格原文。直接跳到 Rationale 與 Security Considerations 兩節，看它為什麼刻意不管權限、以及對模組類型混用的警告。
- erc7579.com — 生態入口，可查有哪些帳戶實作與現成模組，做上面第一步練習的材料。
- Why we are building Kernel on ERC-7579 (and not ERC-6900) — ZeroDev 公開的選邊理由，是理解兩套標準分歧點最省時間的一篇。
- ERC-7484: Registry Extension for ERC-7579 — 模組註冊表與 attestation 的介面規格，模組化安全那半塊拼圖。
💬 問 AI
我在學 ERC-7579 模組化智慧帳戶，請幫我做三件事：
1. 用一個具體的資金損失情境，說明「validator 模組」和「executor 模組」
權限差異有多大。假設我裝了一個惡意 executor，攻擊者實際能做到什麼、
做不到什麼？如果同一段惡意程式碼是以 validator 身分安裝，
後果差在哪裡？
2. 對照 ERC-7579 與 ERC-6900：請分別說明「極簡介面 + 擴充 ERC 補權限」
與「manifest 事前宣告權限」這兩種設計，各自在什麼情境下會出問題。
我想理解的是工程取捨，不要只講哪個採用率高。
3. 假設我要在自己的智慧帳戶上安裝一個第三方模組，
請給我一份安裝前的檢查清單（含要查什麼鏈上資料、
ERC-7484 attestation 該怎麼看、哪些情況應該直接放棄安裝）。
請標示哪幾項是我用區塊瀏覽器就能自己驗證的。