大家好，我是 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 合约需要支付 Gas 费时，可以直接使用其中的资金。但这种方法的缺点是用户需要知道 AccountEntry 合约的存在，并且需要手动将资金转移到 AccountEntry 合约中。
- 在需要支付 Gas 费时，从 Account 合约转账到 AccountEntry 合约：这种方法的优点是用户不需要知道 AccountEntry 合约的存在，但缺点是违反了 ERC-4337 规则，可能导致部分 Bundler 不支持。
- 通过 Paymaster 合约预先为用户交易付款：这是目前 imToken 采用的方法。Paymaster 合约会在用户交易之前预先支付 Gas 费，然后在交易完成后从用户的 Account 合约中扣除相应的费用。这种方法可以绕过规则限制，但需要额外的合约管理和安全审计。
2. 区块链浏览器兼容性
链上的交易记录会显示 AcountEntry 为交易的发送者，而用户并不知道 AccountEntry 的存在，因此难以将其关联到自身账户。这个问题在 Meta Transactions， Safe 这类智能合约钱包，以及子账户等相关的交易中同样存在。目前需要钱包进行定制化的解析和呈现才能解决这个问题。
以上就是我的分享，感谢大家的聆听！