以太坊钱包的变革：账户抽象与ECR-4337的机遇与挑战

摘要：

未来钱包的模式更有可能是类似 B2B2C 的模式。钱包作为一个 C 端产品存在的同时，更重要的是提供一套成熟的 SDK 方案用于其他应用集成为应用内钱包，再面向 C 端用户。其中，打包器和聚合器在早期主要是中心化的构建方式，后面有可能形成模块化的网络，但由于这一块是价值捕获的核心，钱包采用他人构建的打包器网络需要经过经济收益的博弈。

随着以太坊应用场景的不断拓展和延伸，传统以太坊钱包的外部账户（Externally Owned Accounts, EOA）方案的劣势逐步显露，其功能简单而且性能一般，不支持并发交易，且存在密钥管理的难题。智能合约钱包使用合约账户（Contract Accounts, CA）作为钱包地址，是一种相对来说新型的以太坊钱包解决方案，它能解决 EOA 钱包的短板并且带来更强大的功能。未来，你将可以选择不去小心翼翼保护好自己的私钥，也能够享受几乎同等级别的安全性；你还可以在去中心化的交易所里享受到目前中心化交易所才有的便捷，但同时资金又是始终掌握在自己的手中，不用担心交易所暴雷的可能……

前段时间发布的新版以太坊路线图中，账户抽象智能合约规范 ERC-4337 作为 EOA 钱包转向智能合约钱包的关键要素被写入 The Splurge 当中。那么，智能合约钱包到底是什么，而账户抽象与智能合约钱包又是什么关系，它们是怎么实现的，其未来的发展形态是什么样的，又存在着什么机遇和挑战呢？

以太坊的账户类型

以太坊有两种类型的账户：外部账户（Externally Owned Accounts, EOA）和合约账户（Contract Accounts, CA）。外部账户是以太坊原生记录用户余额的钱包账户地址，合约账户一开始的设计目的并不是用来记录用户钱包地址余额的。

外部账户

EOA 是以太坊以及其他 EVM 兼容链（或类 EVM 链）才有的概念，严格来说包括 BTC 在内的主流非 EVM 链都没有这个设定。Metamask 钱包使用的就是外部账户，这一类的钱包也被称为「EOA 钱包」，由用户私钥控制，其生成规则是：

私钥 → 公钥 → Keccak256 哈希 → 最后 20 Bytes → 十六进制字符串（EOA 地址）

这个生成规则完全由数学变换而来，该地址未对应任何一段智能合约。使用该类型地址进行交易的时候，其节点验证规则是：

交易签名 → ec_recover → 公钥 → （用上面的规则生成）地址 → 对比要操作的地址

如果验证通过，则继续后面的流程，不通过则拒绝交易。EOA 在以太坊中的核心设定是作为交易的发起方并支付 gas，即交易的触发器，一笔交易无论后面有多少合约调用，一开始都必须由一个 EOA 发起并且支付足够的 gas 才可以进行。一个 EOA 地址的交易流程如下图所示。

外部账户的问题

目前 EOA 账户是用户使用钱包类型的绝对主流的钱包形态。以太坊社区对 EOA 表达了一些担忧，包括：

密钥管理： 获取资金的唯一方法是知道私钥，最大的问题是在于单点故障，对于用户来说，私钥即资产。对于用户来说，一旦私钥丢失或者被盗，那么就意味着资产损失。

依赖 ECDSA 签名： 更简单且抗量子的数字签名是对当前 ECDSA 的明显改进。

事务与操作是一对一的：一次不能执行多个操作会产生不必要的成本和糟糕的用户体验。

随着区块链应用场景的不断扩大，用户在区块链上管理的不仅仅是自己的链上资产，可以还会有链上身份、社交关系甚至链上信用等等。而目前这些内容大多数都简单地通过钱包映射到假匿名的个人，不仅是用户挣扎在以助记词为主的 EOA 钱包私钥管理方案中，而且应用也因 EOA 钱包的简单性在很多应用场景上受到限制。

有很多钱包方案尝试解决这些问题：

围绕着单点故障，MPC 钱包通过使用阈值签名方案 (TSS) 提供了一个更好的私钥管理方案，而智能合约钱包则可以通过社交恢复、多重签名等方案解决这个问题。

诸如批量交易、自定义验证逻辑等而更好的用户体验、更强大的功能和可扩展性，则主要由智能合约钱包带来。

MPC 钱包和智能合约钱包并不是完全独立的方案，智能合约钱包也可以使用 MPC+TSS 技术实现智能合约钱包的管理，Unipass 是一个很好的例子。

注：MPC 钱包指的是使用多方安全计算技术的钱包，它相当于为你的资产金库雇佣了 M 个管家，每个管家都不能够独立打开金库，而使用阈值签名方案 (TSS) 相当于给你的金库设置了一把需要 N 把钥匙才能打开的锁，那么 MPC + TSS 钱包方案相当于提供了一个多角色金库管理方案，M 个管家中需要有 N 个管家同时提供他们所管理的钥匙才能够打开金库。

合约账户

CA 是具备内部逻辑的以太坊账户，里面既可以是业务逻辑（Token 合约用来记账，质押合约用来放贷和清算），也可以是账户逻辑（比如 gnosis safe 的多签逻辑），而后者就是智能合约钱包（Smart Contract Wallet/Account, SCW）。Argent 钱包使用的就是智能合约钱包，其开创了社会恢复这种模式，合约由内部逻辑代码控制，其生成规则有 CREATE 和 CREATE2 两种方式，这里不展开。

与 EOA 不同的是，CA 和公钥没有必然对应关系。比如 gnosis safe 创建的 CA 里可以设定任意多把公钥来解锁它的地址对应的资产；当然 CA 也可以不设定任何密钥，而是由其他 CA 的逻辑决定是否可以解锁，比如 DeFi 的借贷合约，只要还了钱就能取回质押的资产。

以太坊上除 ETH 之外的所有资产都是由 CA 承载，DeFi 等业务逻辑就更是全都由 CA 来实现。然而 CA 无法主动进行操作和支付 gas 的设定也限制了它的能力，早在 2016 年就有提案希望能让 CA 自己支付 gas。

由于交易只能从 EOA 开始，为了改善用户体验，通常智能合约钱包会提供中继（Relayer）服务，从用户那里获取签名消息并从服务提供商的 EOA 提交到链上，其自定义费用机制可以将 ETH 退回给用户的 EOA 钱包实现免 Gas 费用。

目前来说，智能合约钱包没有运行标准（EIP-4337 有希望成为标准），所以每个项目都必须使用像以太坊加气站网络（Gas Station Network, GSN ）这样的元交易解决方案，或者努力创建和管理自己的中继服务，以及管理费用机制和审计他们复杂的智能合同。

智能合约钱包

顾名思义，智能合约钱包（Smart Contract Wallet/Account, SCW）就是用 CA 作为地址的钱包方案，特点是具备内部逻辑，智能合约钱包可以实现很多 EOA 无法实现的功能，比如 gas 代付、批量交易、多重签名、权限管理、离线授权和社交恢复等等。

合约账户是与签名者（授权者）分离的智能合约，它可以有自己的签名和恢复逻辑。这意味着，如果您失去对 Signer 的访问权限，并不一定意味着您失去了对帐户的访问权限。同样，这就是 Account Abstraction 这个名字的由来。账户是从签名者那里抽象出来的。

账户抽象

目前以太坊的现状是绝大多数人都在使用 EOA 钱包，因为目前以太坊中的所有交易都必须从 EOA 开始，EOA 必须有一些 ETH 来支付 gas，这使得新用户无法快速进入。我们需要一种方案，来允许用户使用包含任意验证逻辑的智能合约钱包，这种方案称为账户抽象（Account Abstract, AA）。简单的来说，账户抽象的结果是：

过去你将钱存在以太坊 EOA 钱包地址上，受到各种 EOA 地址限制的同时享受拥有私钥就拥有资产的简单便捷；

现在你将钱存在以太坊智能合约地址上，你可以通过不管理私钥的方式控制你的钱包资产，签名者和账户本身的分离使得你可以在一个更低安全级别进行交易的操作，而将账户本身放置于更高的安全级别。

「账户抽象」的目标是将账户类型的数量从 2 种（EOA 和合约）减少到 1 种（只有合约），并将签名验证、gas 支付和重放攻击保护等功能从核心协议中移到 EVM。一直以来，实现账户抽象都是许多以太坊开发者的努力方向，这一点从 EIP 的历史可以看出。

EIP 历史

账户抽象的概念从 2016 年开始最早由 Vitalik 提出，2017 年他本人发起了第一个提案。这么多年来，账户抽象相关的提案有非常多，其中最主要的解决方案是 EIP-3074 和 EIP-4337。EIP-3074 的提出比 EIP-4337 要早一年，但 EIP-4337 却被纳入了以太坊的新版路线图，其主要原因是 EIP-4337 的实现要更为轻量，无需修改以太坊的核心协议，同时也没有 EIP-3074 那样的安全隐患。而 EIP-4337 存在的用户迁移问题、Gas 过高问题以及潜在智能合约安全问题是智能合约钱包的共通问题，Vitalik 认为账户抽象最佳现实途径是在短期内开始大力支持 ERC-4337，然后随着时间的推移添加 EIP 来弥补其弱点。

EIP-86：2017 年，Vitalik 提出了 EIP-86，试图引入可以被视为「转发合约」的智能合约钱包。这些转发合约将只接受来自「入口点」地址的交易，只要交易遵循特定格式，任何人都可以从该地址发送交易。

EIP-1014：这些转发合约将根据它们的代码被部署到一个特定的地址，引入了后来演变成 EIP-1014 的想法，提出了 CREATE2 操作码。由于 EIP-86 需要对协议进行重大更改，最终没有被合并，而 EIP-1014 于 2018 年合并。

EIP-2938：2020 年 9 月，Vitalik Buterin、Ansgar Dietrichs 和 Matt Garnett 提出了 EIP-2938，该协议要求被识别为智能合约钱包的特殊智能合约将只接受账户抽象交易，这一新型交易由 EIP-2718 引入。他们将以编程方式设置交易的最大 gas 并实施任意验证方法。EIP-2938 需要在 EVM 中添加两个新的操作码才能使交易可行。这些操作码显着改变了核心协议，包含此类更改的过程可能会拖很长时间。

EIP-3074：2020 年 10 月，Ansgar Dietrichs 和 Matt Garnett 等人提出了 EIP-3074，引入了两个新的操作码：AUTH 和 AUTHCALL。当一起使用时，它们允许智能合约代表 EOA 发送交易，这使得例如多重签名、批量和赞助交易、密钥恢复以及更易于访问的 CeFi 交易所存款变得可能。但该 EIP 存在一些安全风险，受到了一些批评，新的操作码还会修改核心协议，研究人员开始思考一个更好的解决方案，最终被提议为 EIP-4337。

Layer2：随后，由于 L2 没有以太坊 L1 的技术债务，可以开箱即用地引入帐户抽象，Optimism 和 Starknet 都有自己的账户抽象实现，ArgentX 是 Argent 在 Starknet 上的钱包版本，使用受 EIP-4337 启发的自定义帐户抽象实现。最近的例子是 Visa Crypto Auto Payments on StarkNet，Visa 的以太坊自动支付解决方案是利用账户抽象概念并创建一种新型账户合约——可委托账户，其主要想法是扩展交易的可编程有效性规则以包括预先批准的允许列表。简单来说，账户抽象可以将用户账户发起的自动支付操作委托给预先批准的自动支付智能合约。StarkNet 的账户模型就是 Visa 目前所说的账户抽象，其实现受 ERC-4337 的启发，抽象账户则会检查交易是否来自给定地址。

EIP-4337：2021 年 9 月，Vitalik Buterin 与来自 OpenGSN 和 Nethermind 的以太坊研究人员吸取了以往努力的经验教训，提出了 EIP-4337。EIP-4337 添加了新的 UserOperation 内存池希望完全取代当前的交易内存池，从而实现账户抽象。用户将 UserOperation 对象发送到以太坊节点，而不是交易，他们将一组这些对象打包成一个包含在以太坊链中的交易。这种打包交易称为「入口点」智能合约，它处理 UserOperation 对象并为其部署智能合约钱包。

EIP-5003：2022 年 3 月，Dan Finlay，Sam Wilson 提出了 EIP-5003，希望通过部署代码代替外部帐户，允许从 ECDSA 迁移。这个 EIP 引入了一个新的操作码，它在 EIP-3074 授权地址 AUTHUSURP 部署代码。对于外部拥有的账户（EOA），连同 EIP-3607，这有效地撤销了原始签名密钥的权限。这是对 EIP-3074 的补充，EIP-3074 只能授予额外的参与者权限，但不能撤销。

EIP-5792：2022 年 10 月， Moody Salem 提出了 EIP-5792，该 EIP 添加 JSON-RPC 方法，用于从用户钱包发送多个函数调用，并检查其状态。新方法在底层交易方面比现有交易发送 API 更抽象，以允许钱包实现之间存在差异，例如使用 EIP-4337 的智能合约钱包或支持通过 EIP-3074 捆绑交易的 EOA 钱包。Dapps 可以使用这个更抽象的接口来支持不同类型的钱包而无需额外的工作量，并提供更好的用户体验来发送函数调用包（例如 EIP-20 #approve 后跟一个合约调用）。

EIP-4337 详解

在 EIP-4337 中，一共有 6 个组件：入口点合约（EntryPoint contract）、出纳合约（Paymaster contract）、用户操作（UserOperation）、打包器（Bundler）、发送人合约（Sender Contract）和聚合器（Aggregator）。

EntryPoint: 入口点合约处理传递给它的交易操作的执行和验证。全局入口点合约接收来自各个 Bundler 的打包交易，并通过每个 UserOperations 来运行验证和执行循环。

Paymaster: 这是可选合约，可以代表用户为交易支付 gas。用户可以不依赖他们的钱包，而是获得由出纳员赞助的交易费用。

UserOperations: 这些是为代表用户执行交易而创建的交易对象。执行发生在 Sender Contract 确认之后。这些操作由 Dapp 生成。

Bundlers: Bundler 从内存池中获取 UserOperations，并将它们打包在一起以将它们发送到 EntryPoint contract 以供执行。

Sender Contract: 这些是智能合约形式的用户钱包账户。

Aggregator: 聚合器是钱包信任的辅助合约，用于验证聚合签名。

整个 ERC-4337 标准的运行逻辑包括两个循环：验证循环的执行循环，它们组合在一起完成了账户抽象的逻辑。

验证循环：入口点合约通过每个 UserOperation 并调用 Sender Contract 中的「检查功能」。Sender Contract 运行此功能以检查 UserOperation 的签名并补偿打包这些交易的 Bunder。

执行循环：将每个 UserOperation 中的调用数据发送到 Sender Contract 。钱包运行执行操作以执行操作中指定的交易。然后 Sender Contract 将在操作执行后退还剩余的气体。

引入的出纳员角色允许应用程序开发人员为其用户补贴费用。当 paymaster 不等于零地址时，入口点执行不同的流程：

在验证循环中，入口点合约除了调用「检查功能」以外，还必须检查 paymaster 是否被质押，并且还有足够的 ETH 存入入口点合约以支付操作费用，然后调用 paymaster 上的「检查功能」以检查 paymaster 是否愿意支付。

在执行循环中，入口点合约必须在主执行调用后调用 paymaster 上的 Post-op。它必须通过在内部调用环境中进行主要执行来保证 Post-op 的执行，并且如果内部调用环境回撤，则尝试在外部调用环境中再次调用 Post-op（即使用户操作回撤，也应当支付 gas 费用）。

Vitalik 总结认为 ，ERC-4337 作为一个纯自愿的 ERC 可以做很多事情。然而，在一些关键领域，它比真正的协议内解决方案更弱：

用户迁移问题，现有用户如果不将其所有资产和活动移动到新帐户，则无法升级；

额外的 gas 开销（基本 UserOperation 用户操作约 42 k，而基本交易约为 21 k）；

智能合约安全问题，它较少受益于协议内抗审查技术（例如 crLists），该技术以交易为目标而会忽略用户操作（user operation）

而实现最佳效果的一条现实途径，是在短期内开始大力支持 ERC-4337，然后随着时间的推移添加 EIP 来弥补其弱点。这并不一定需要大家专门承诺遵守 ERC-4337。相反，可以将协议内支持设计为更通用，并支持 ERC-4337 及其替代方案和改进。目前 ERC-4337 的实现方案有 Biconomy、Soul Wallet 和 eth-infinitism，他们都编写了自己的入口点合约实现方案，而入口点合约是该标准下智能合约安全的核心所在。

Vitalik 提出了账户抽象的可能路线图。

可能的路线图

短期

将 ERC-4337 全面投入生产。理想情况下，可以使用签名聚合功能对其进行扩展，以实现 rollup 友好性。

应该有接入 ERC-4337 的易于使用的浏览器钱包。

考虑实现签名聚合和压缩，以使 ERC-4337 对 L2 更加友好；

在 L2 协议中引导 ERC-4337 生态，其中 gas 成本问题会较少；

中期

实施 Verkle 树，添加 EIP 以降低 gas 成本；

添加可选的 EOA-to-ERC-4337 转换；

在提议者 / 建设者分离（Proposer/Builder Separation, PBS） 推出的同时或不久之后添加 crList 逻辑；

长期

考虑强制转换，执行不规则的状态转换，将字节码部署到每个可能是 EOA 的帐户中，但这种方法的缺点是需要修改核心协议以及对于矿工 / 验证者来说成本很高。

项目扫描

SevenX 对市场上的智能合约钱包进行了简单扫描，收集整理了一些市场上比较主流的智能合约钱包项目，其综合情况如下：

我们选取了两个项目进行案例介绍，对他们的功能和相应的实现原理进行了解析。其中 Unipass 是传统智能合约钱包的典型代表，而 Candide Wallet 是使用 ERC-4337 标准钱包的典型代表，他们拥有丰富的公开文档，对他们的产品功能实现进行了详细地解释。

实现案例——Unipass

UniPass Wallet 是一个支持邮件社交恢复的智能合约钱包解决方案。通过 UniPass Wallet，开发者可以在产品内提供流畅的免私钥、免 gas 的用户体验，从而快速地吸引海量的 Web2 用户。其特点是：免私钥、抗审查、免 gas、邮件恢复、隐私保护、多平台和支持多链。

免私钥、抗审查、邮件恢复和隐私保护的特性主要是由 Unipass 的秘钥管理方案带来的。UniPass Wallet 的合约账户中支持用户设置多种类型的密钥。已经支持的密钥类型包括：

我们经常使用的外部地址，支持 EIP-1271 协议（一个合约的标准签名验证方法）的合约账户。

UniPass 的用户还可以使用邮箱来作为密钥。我们在链上部署的智能合约，可以通过 DKIM（域名密钥识别邮件）来以密码学的手段验证用户对于一个互联网邮箱的所有权。在验证过程中，UniPass 采用了零知识证明技术，确保用户邮件信息的隐私安全。

在未来， UniPass Wallet 还将考虑支持相比于 secp256k1 更高效更简洁的签名算法（比如：Schnorr，BLS），后量子安全签名算法（比如：Lamport，Winternitz）等等。

秘钥主要有三种角色：

Owner 是账户的所有者。Owner 控制账户的部署、升级、销毁等核心功能，是账户的最高权限控制者。

Operator 是账户资产的执行者。Operator 负责账户的资产转账、合约调用、授权许可等功能，是用户日常使用的密钥。

Guardian 是账户的守护者。当账户内的密钥损毁或丢失，用户失去账户控制时，可以通过 guardian 来恢复账户。UniPass 提供的一大特色功能就是：链上邮件社交恢复。

在 UniPass Wallet 的智能合约中，用户是通过一系列具有角色权重的密钥来管理账户的。除了以安全多方计算（MPC）方案实现的 Master key 外，用户还可以设置多种其他类型的密钥。每一个密钥都有一个对应的角色及权重。用户只有在集齐了总角色权重门限超过要求的密钥后，才可以获得该角色的授权。

一个密钥允许被赋予单个或多种角色。密钥在被赋予某个角色的时候，会同时被设定对应的权重。而用户要开始执行某身份的相关操作时，需要用该角色总权重达到 100 及以上的单把或多把密钥进行签名。例如在初始注册账户时，用户可以跳过守护者设置。相关参数可以设置如下：

免 gas 的特性是通过一个第三方 relayer 实现的，用户发起交易时需要 relayer 帮助用户发起交易。在这个过程中，relayer 可以支持用户使用任意代币支付 gas，甚至可以完全帮助用户代付 gas，实现免 gas 的体验。Relayer 是个开源的服务端程序，UniPass 会运行默认的 relayer，合作方或者任意第三方也都可以运行 relayer。

实现案例——Candide

CANDIDE 是一群贡献者，他们公开合作构建的公共产品，没有单一的实体或公司控制其发展。Candide Wallet Beta 是一款自托管移动智能合同钱包。它目前部署在 Goerli 测试网上。它现在可以在 Android Test 和 IOS Testflight 上使用。

Candide Beta 其技术基础是 Stackup 分叉的 ERC-4337 实现和 Gnosis Safe 的开源框架，其特性包括无助记词、社会恢复、批量交易、免 Gas 费等。

其中，无助记词、批量交易、免 Gas 费等特性其实现逻辑与 ERC-4337 的逻辑相同，采用 eth-infinitism 开发的入口点合约完成。Candide 运行自己的打包器，将 UserOperation 打包为自己钱包的服务。该方案中，大部分的安全取决于入口点合约，而非钱包本身的构建。

此外，社会恢复的特性来源于 Candide 将 Safe 用于其基础钱包合约。这让 Candide 可以利用最受信任的 DAO 合约来管理数字代币。 Candide 将使用 Gnosis Safe 模块化设计来交付其核心功能，包括社交恢复，以及未来的功能，如时间锁定和取款限制。该社交恢复模块与 Unipass 的逻辑相同，不同的是 Unipass 主要是邮件恢复，但 Candide 的守护人可以是任何具有公共地址的签名者，如家人朋友、机构和硬件钱包。

关于合约钱包的思考

早期的智能合约钱包都是根据非常具体的问题进行合约开发，如 Gnosis Safe 的多签以及 Argent 的社会恢复功能。早期的这些产品设计复杂，很多时候也不公开透明，且没有形成统一的标准，很难作为中间件插入到其他的应用当中。对于这一类型的产品，其判断标准更多需要从使用场景出发，有没有抓住用户的核心需求，如 Safe 的多签功能就抓住了用户的核心需求之一。

随着 ERC-4337 的诞生，快速构建一个拥有无助记词、批量交易、免 Gas 费的钱包变得非常方便，统一的标准也让基于该标准构建的开发套件具有可组合性，能够作为中间件插入不同的应用，并且保持互操作性。

因此，在考量早期的智能钱包方案的时候，能够 ERC-4337 兼容是非常重要的一点。而对于基于 ERC-4337 的解决方案，由于技术大多是开源的，其考量方案建议围绕以下几点：

技术：入口点合约、打包器和聚合器（如果有）的构建方案，以及除了 ERC-4337 带来的功能以外的功能构建方案，如社会恢复功能；

运营：如何构建社区、推向市场和赢得用户；

体验：钱包使用用户体验是否足够好，如流畅、稳定等；

以及一些其他 to C 产品的主要考察逻辑。

未来钱包的模式更有可能是类似 B2B2C 的模式。钱包作为一个 C 端产品存在的同时，更重要的是提供一套成熟的 SDK 方案用于其他应用集成为应用内钱包，再面向 C 端用户。其中，打包器和聚合器在早期主要是中心化的构建方式，后面有可能形成模块化的网络，但由于这一块是价值捕获的核心，钱包采用他人构建的打包器网络需要经过经济收益的博弈。