本文整理自 imToken Labs 的 Nic 在 ETHTaipei 大会中的分享。

大家好，我是 Nic，目前在 imToken Labs 担任区块链开发者。今天我将和大家分享如何通过「以验证为中心的设计」（Validation Centric Design）构建更安全且用户友好的 AA 钱包。

今天的分享将分为三个部分：

• 当前 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，这样拥有庞大的专业开发者团队维护的项目，也难以完全避免因可升级合约的复杂性而导致的失误。

「以验证为中心的设计」思路构建的 AA 钱包，其核心理念在于将验证逻辑、支付逻辑、可升级性等复杂功能从账户合约中剥离，仅保留账户合约最基础的功能：资产持有和 DApp 交互。

通过这种方式，极大地简化了账户合约，降低其复杂性和维护难度。而其他复杂的功能则被整合到 AccountEntry 合约中，它作为账户合约的「入口点」，承担所有复杂的逻辑处理工作。开发者可以专注于设计 AccountEntry 合约，而用户则无需感知到它的存在，可以轻松地在不同钱包之间切换操作，无需转移资产。

这种设计方案的优势在于：

• 安全迭代：开发者可随时部署新版本验证合约（如从简单签名验证升级到多签 + 生物识别），无需迁移用户账户。
• 敏捷开发：支持快速适配新标准或框架，避免旧版本技术债务限制。
• 用户无感切换：用户通过钱包界面无缝使用新功能，无需感知底层验证合约的变更。

但需要注意的是，如果开发者将 AccountEntry 合约设计为可升级合约，而该可升级合约本身存在漏洞，通过「以验证为中心的设计」（Validation Centric Design）思路构建的 AA 钱包依然会受到黑客攻击。

除了上述优势外，「以验证为中心的设计」还引入了多账户管理功能，能够进一步提升用户体验和开发灵活性。

▶ 多账户管理

通过「以验证为中心的设计」，用户可以轻松管理多个账户。同时，由于账户合约非常简单，用户还可以创建多个账户，并在这些账户之间灵活切换，甚至在同一笔交易内同时控制多个账户。

▶ Gas 费支付难题

AccountEntry 作为交易发起者需要支付 Gas 费，但资产却存储在用户的 Account 合约中，因此如何支付 Gas 费成为了一个问题。当前可选的解决方案有 3 种：

• 直接将用户资金放在 AccountEntry 合约中：这样当 AccountEntry 合约需要支付 Gas 费时，可以直接使用其中的资产。但这种方法的缺点是用户需要知道 AccountEntry 合约的存在，并且需要手动将资金转移到 AccountEntry 合约中。

  
  

• 在需要支付 Gas 费时，从 Account 合约转账到 AccountEntry 合约：这种方法的优点是用户不需要知道 AccountEntry 合约的存在，但缺点是违反了 ERC-4337 技术规则，可能导致部分 Bundler 不支持。

  
  

• 通过 Paymaster 合约为用户交易预先支付：这是目前 imToken 采用的方法。Paymaster 合约会在用户交易之前预先支付 Gas 费，然后在交易完成后从用户的 Account 合约中扣除相应的费用。这种方法可以绕过规则限制，但需要额外的合约管理和安全审计。

▶ 区块链浏览器兼容性

链上的交易记录会显示 AccountEntry 为交易的发送者，而用户并不知道 AccountEntry 的存在，因此难以将其关联到自身账户。这个问题在 Meta Transactions，Safe 这类智能合约钱包和子账户等相关的交易中同样存在。目前需要钱包进行定制化的解析和呈现才能解决这个问题。

以上就是我的分享，感谢大家的聆听！