大家好，我是 Nic，目前在 imToken Labs 擔任區塊鏈開發者。今天我將和大家分享如何透過 Validation Centric Design 建構更安全且用戶友好的 AA 錢包。
今天的分享將分為三個部分：
- 當前 AA 錢包的構建方式
- Validation Centric Design
- 技術挑戰與解決方案
一、當前 AA 錢包的構建方式
AA 錢包，即透過帳戶抽象（Account Abstraction）技術實現的智能合約錢包，其核心功能包括：
- 多元交易驗證：支援多簽（Multi-Sig）、Passkey、Email 授權等驗證方式
- 靈活 Gas 支付：可用 USDC、USDT 等穩定幣、信用卡支付 Gas 費，或由第三方贊助交易
- 帳戶控制權恢復機制：密鑰遺失或被盜後，可透過預設規則恢復帳戶控制權
- 第三方代理操作：可授權第三方執行自動化操作
然而，目前的 AA 錢包普遍採用 Account Centric Design，它具有以下特點：
- 帳戶即交易主體：帳戶合約作為交易發起者，持有用戶資產並整合驗證邏輯（如多簽、Passkey）、支付邏輯（USDC 支付、贊助交易）、恢復邏輯等。
- 可升級性：開發者可持續迭代升級同一帳戶合約（如 v0.1→v1.0→v2.0）
- 模組化：可采用 ERC-6900、ERC-7579 等模組化標準
這種設計導致用戶在使用不同 AA 錢包時面臨諸多不便。在使用普通 EOA 錢包時，用戶可以透過導入私鑰或助記詞，在不同的錢包之間無縫切換。然而，在 AA 錢包的世界中，由於各錢包公司自行設計合約，用戶無法在不同錢包間使用同一帳戶。每次使用新錢包，用戶都需創建新帳戶，並將資產從舊帳戶遷移到新帳戶，過程繁瑣且可能遺失部分資產，嚴重影響用戶體驗。
此外，合約的可升級性雖然為功能的豐富和更新提供了便利，但也引入了潛在的風險。以 2024 年 Ronin Bridge 被盜事件為例，該事件凸顯了可升級合約可能帶來的安全隱患。當時，Ronin Bridge 的合約定義了 v3 和 v4 兩個版本的初始化函數，但在實際操作中，僅 v4 初始化函數被執行，v3 被遺漏，導致合約漏洞，造成約 1200 萬美元的資產損失。
此類失誤的發生，往往源於可升級合約在版本迭代過程中面臨的複雜挑戰。設想一下，當某個錢包的最新版本已升級至 v2.0.0，而用戶 Bob 的錢包仍停留在 v0.1.0 這樣的低版本時，如何將他的錢包安全地升級至最新版本？
這要求在錢包從舊版本逐步升級至最終的 v2.0.0 版本的過程中，每一次升級的參數初始化都必須被準確無誤地執行。對於開發者而言，這是一個巨大的挑戰，因為任何一步的疏忽都可能導致嚴重的安全漏洞。
這也解釋了為什麼即使是像 Ronin Bridge 這樣由龐大專業開發者團隊維護的項目，也難以完全避免因可升級合約的複雜性而導致的失誤。
二、Validation Centric Design
Validation Centric Design 構建的 AA 錢包，其核心理念在於將驗證邏輯、支付邏輯、可升級性等複雜功能從帳戶合約中剝離，僅保留帳戶合約最基礎的功能：資產持有和 DApp 交互。
透過這種方式，極大地簡化了帳戶合約，降低了其複雜性和維護難度。而其他複雜的功能則被整合到 AccountEntry 合約中，它作為帳戶合約的「入口點」，承擔所有複雜的邏輯處理工作。開發者可以專注於設計 AccountEntry 合約，而用戶則無需意識到它的存在，可以輕鬆在不同錢包之間切換，無需轉移資產。
這種設計方案的優勢在於：
- 安全迭代：開發者可隨時部署新版本驗證合約（如從簡單簽名驗證升級到多簽+生物識別），無需遷移用戶帳戶。
- 敏捷開發：支援快速適配新標準或框架，避免舊版本技術債務限制。
- 用戶無感切換：用戶透過錢包界面無縫使用新功能，無需感知底層驗證合約變更。
但需要注意的是，如果開發者將 AccountEntry 合約設計為可升級合約，而該可升級合約本身存在漏洞，透過 Validation Centric Design 構建的 AA 錢包依然會受到因漏洞導致的駭客攻擊。
除了上述優勢外，Validation Centric Design 還引入了多帳戶管理功能，進一步提升用戶體驗和開發靈活性。
多帳戶管理
透過 Validation Centric Design，用戶可以輕鬆管理多個帳戶。由於帳戶合約非常簡單，用戶可以創建多個帳戶，並在這些帳戶之間靈活切換，甚至在同一筆交易內同時控制多個帳戶。
三、技術挑戰與解決方案
1. Gas 費支付難題
AccountEntry 作為交易發起者需支付 Gas 費，但資金卻儲存在用戶的 Account 合約中，因此如何支付 Gas 費成為了一個問題。當前可選的解決方案有 3 種：
- 直接將用戶資金放在 AccountEntry 合約中：
- 當 AccountEntry 合約需要支付手續費時，可以直接使用其中的資金。
- 缺點：用戶需要知道 AccountEntry 合約的存在，並且需要手動將資金轉移到 AccountEntry 合約中。
- 在需要支付 Gas 費時，從 Account 合約轉賬到 AccountEntry 合約：
- 優點：用戶不需要知道 AccountEntry 合約的存在。
- 缺點：違反 ERC-4337 規則，可能導致部分 Bundler 不支援。
- 透過 Paymaster 合約預先為用戶交易付款：
- 這是目前 imToken 採用的方法。Paymaster 合約會在用戶交易之前預先支付 Gas 費，然後在交易完成後從用戶的 Account 合約中扣除相應的費用。
- 優勢：可以繞過規則限制。
- 挑戰：需要額外的合約管理和安全審計。
2. 區塊鏈瀏覽器兼容性
鏈上的交易記錄會顯示 AcountEntry 為交易的發送者，而用戶並不知道 AccountEntry 的存在，因此難以將其關聯到自身帳戶。這個問題在 Meta Transactions、Safe 這類智能合約錢包，以及子帳戶等相關的交易中同樣存在。目前需要錢包進行客製化的解析和呈現才能解決這個問題。
以上就是我的分享，感謝大家的聆聽！