推特：@SteveIsEmployed（欢迎关注）

微信：clairvoyant_98（欢迎交流探讨）

简介

以太坊改进提案4337（EIP 4337）定义的账户抽象是一组协议层的接口。它不仅集成了web2用户熟悉的交互形式，如多因素认证（multi-factor authentication），还给web3特有的用户痛点提出了解决方案，如无需手续费（gasless）的交易。作为引入下十亿用户的协议接口，用户体验是账户抽象最关注的重点。

虽然许多现有的文章很好地解释了账户抽象，但是大多偏科普向，也有少数十分深入于技术细节。**本文旨在融合两者：既提供关于账户抽象概念的全面技术解读，也分类剖析现有应用和基础设施的案例。**因此本文分为三部分：在第一部分，我们将探讨EIP 4337的起源，并深入了解其技术细节，包括用户操作（UserOperation）、打包器（Bundler）、入口点合约（Entry Point Contract）、代付合约（Paymaster）、钱包工厂（Wallet Factory）和签名聚合器（Signature Aggregator）。在第二部分，我们将分析现有的市场玩家，包括智能合约钱包和第三方基础设施提供商。在第三部分，我们将讨论账户抽象的发展方向，包括该领域的创新展望和预测。

本文篇幅较长，第一部分主要为账户抽象的技术解读，只对账户抽象的应用场景感兴趣的读者可以直接跳到第二部分。

第一部分：EIP 4337的全面技术分析

首先来简要回顾一下基础知识，以太坊有两种类型的账户：外部拥有的账户（externally owned accounts，即EOA）和合约账户。

• EOA是用户控制的账户，可以发送交易。EOA通过其私钥控制账户的所有权，可以通过签名执行交易，从而改变EOA的内部状态或外部合约账户的状态。由于私钥（或种子短语）是EOA所有权的唯一代表，EOA不适合定义复杂的所有权或交易逻辑，如使用社交媒体账户登录（social login）和多方签名（multisig）的交易。**EOA的局限性导致用户体验不佳：一些冗杂的步骤，如私钥和种子短语管理，更是直接阻碍了Web2用户进入Web3。**大多数最受欢迎的钱包，如MetaMask，都是基于EOA的账户模型。

• 合约账户可以托管任意的Solidity代码，因此可以发挥EVM全部的图灵完备特性。遗憾的是，合约账户不能发送交易，因此它们的功能必须由EOA触发。智能合约钱包是一种合约账户，通过钱包提供商的EOA网络间接地被其用户触发，无论是通过中继器（relayer）还是打包器（Bundler）。

图：EOA与合约账户（来源：Bitcoin Insider）

智能合约钱包早在EIP 4337之前就已存在。EIP 4337的提出是为了标准化设计智能合约钱包及其相关基础设施的通用功能。EIP 4337遵循以下几个设计原则：

• 总体而言，所有的技术实现都在顶层（智能合约层），从而避免触及共识层和执行层等底层基础设施。账号模型这种基本设计如果在底层改动会成为像以太坊PoS主网合并一样的重要升级。因为开发人员的精力有限，只能采用合约层实现的轻量级技术路线。

• 协议接口的设计应该是模块化的，这样用户可以自定义选项，包括交易打包处理（Bundler）、gas代付（Paymaster）和签名聚合（Aggregator）。

• 理想情况下，上述每项服务都将成为一个具有竞争性的开放市场。用户可以根据提供商的价格和声誉选择最佳的服务。

EIP 4337为标准化智能合约钱包定义了六个合约接口：

• 首先，智能合约钱包本身，会通过打包器触发入口合约来间接触发，在链下验证交易，然后在链上执行。

• 其次，打包器（Bundler），用于批量验证和执行用户操作（UserOperation，即EIP 4337定义的智能合约钱包的交易类型）。

• 第三，**入口合约（Entry Point Contract）**是在以太坊只存在一份的全局合约，用于标准化交易执行并防止打包器受到恶意交易的DoS攻击。

• 第四，代付合约（Paymaster），用于代表钱包用户处理gas支付。

• 第五，合约工厂（Wallet Factory），用于标准化钱包创建的参数和流程。

• 第六，签名聚合器（Signature Aggregator），用于将多个交易的签名聚合为字节，以便更快地验证和执行交易。

下面我将详细介绍用户操作（UserOperation）和上述的六个合约接口，是对官方EIP 4337文档和David Philipson@Alchemy账户抽象系列的解读。

1. 账户操作（UserOperation）

UserOperation**本质上和普通交易相同，只是基于EIP 4337的合约接口定义了额外的参数。**这里回顾一下，一个EOA触发的普通以太坊交易有交易目标地址、转账以太坊数量、gas数量和gas价格等参数。

此外，考虑到EIP 4337合约接口的模块化设计，UserOperation包括以下主要参数用于定义接口的触发：

• calldata：定义要在智能合约钱包上调用的函数签名（function signature）和输入参数，calldata在普通交易中也有

• signature：验证交易确实来自某智能合约钱包地址，signature在普通交易中也有

• nonce：防止重放攻击，在普通交易中也有

• sender：指定执行UserOperation的智能合约钱包地址

• paymasterAndData：用于交易手续费抽象（gas abstraction），包含代付合约（Paymaster）地址和gas支付的具体参数

• initCode：用于钱包创建，包含钱包工厂（Wallet Factory）合约地址和创建智能合约钱包的参数，如钱包的合约代码

除了需要额外的参数以外，UserOperation的工作流程与普通交易类似：它们都被广播到mempool中进行验证、执行并最终完成出块。UserOperation的验证和执行由打包器（Bundlers）触发，我将在下文中解释。

图：官方EIP 4337文档对UserOperation参数的定义

2. 打包器（Bundler）

Bundler是一个外部账户（EOA），代表用户在智能合约钱包上验证和执行UserOperation交易，因为在以太坊上，所有交易都必须由EOA触发。Bundler使用户不用创建和记忆EOA的私钥就可以触发智能合约钱包交易，这也是智能合约钱包存在的初衷。

虽然Bundler具有很强的公共物品（public goods）属性，他们也可以获得经济上的利益，因为：

• Bundler可以在执行UserOperation后将最大优先gas费（maximum priority fee）与实际gas花费之间的差额收入囊中

• 与普通交易的中继器（Relayer）类似，Bundler可以通过排序捆绑交易（bundle）中的UserOperation来获取MEV

尽管用户付出了成本，但Bundlers对于节省gas是有好处的，因为每执行一笔交易都需要21,000 gas的固定成本，而执行捆绑交易可以把一笔交易的固定成本分摊给捆绑交易里的多UserOperation，从而节省gas成本。此外，在同一笔交易中多次修改storage，每次额外操作的gas费都会边际递减。

需要注意的是，尽管以太坊上的交易是线性执行（非并行）以避免状态冲突（state conflict），多个UserOperations可以放在一个捆绑交易里执行，因为Bundlers可以设置同一智能合约钱包地址最多包含一个UserOperation，这样捆绑交易在修改状态时不会相互冲突。

除了这些差异之外，Bundlers与区块构建者（Block Builder）类似，因为它们都将经过验证的UserOperation广播到公共或私有的mempool中。接下来，我们将介绍入口点合约（Entry Point Contract），Bundler需要与之交互来执行UserOperation。

3. 入口点合约（Entry Point Contract）

入口点合约是一个全局单例（global singleton）合约，所有Bundlers都需要调用它来执行UserOperation。它充当了Bundler与智能合约钱包之间的中间人：

• 一方面，Bundlers调用入口点合约的handleOp函数，该函数接受一个UserOperation作为输入参数。handleOp负责根据UserOperation的calldata验证并执行智能合约钱包的函数

  • handleOp首先在链上验证UserOperation，检查它是否由指定的智能合约钱包地址签名，以及钱包是否拥有足够的gas来补偿Bundler

  • 如果验证成功，handleOp将根据UserOperation的calldata中定义的函数签名和输入参数执行智能合约钱包函数

• 另一方面，智能合约钱包需要向入口点合约存入代币用于支付gas费用给Bundlers。当Bundler使用EOA触发handleOp函数时，会产生gas费用。

  • 除此之外，智能合约钱包也可以用自己的账户余额支付gas费用给Bundler，也可以请求代付合约（Paymaster）代为支付，我们稍后会详细解释

  • 没有足够gas的UserOperation在目标智能合约钱包中无法通过验证步骤，因此在执行之前就会失败

  • 即使有足够的gas，UserOperation在执行步骤中仍可能失败，例如runtime error

  • 无论执行是否成功，入口点合约都将支付gas费用给Bundler触发handleOp函数

  • 入口点合约提供了智能合约钱包添加或提取代币抵押的函数

图：官方EIP 4337文档中的入口点合约工作流程

4. 智能合约钱包主合约

智能合约钱包主合约将UserOperation的验证和执行步骤分开：

• 验证步骤在validateOp函数中定义。此函数会被调用两次：第一次是Bundler在链下模拟验证，验签UserOperation中的签名，并确保智能合约钱包有足够的gas余额；第二次是入口点合约在执行UserOperation之前进行链上验证

• 执行步骤在UserOperation的calldata中定义，用于指定智能合约钱包函数的签名和输入参数

通过分离UserOperation的验证和执行，Bundler可以在链下验证UserOperation，从而不需支付gas就可以过滤掉恶意交易。 因此validateOp函数也起到了链下debug API的作用。

5. 代付合约（Paymaster）

代付合约（Paymaster）定义了智能合约钱包的gas抽象的逻辑。**Gas抽象的形式包括用ERC20同质化代币支付以太坊gas和无需gas的交易，两者都可以由Paymaster来实现。**ERC-4337的模块化设计允许UserOperation通过paymasterAndData参数指定任意的Paymaster地址和输入参数。Paymaster具有以下功能和要求：

• 本质上，Paymaster是由dApp部署的智能合约，可以通过Bundler触发Paymaster的validatePaymasterOp函数以任意逻辑有选择性地为合约指定的UserOperation支付gas

• Paymaster需要在入口点合约上存入以太坊用于支付UserOperation的gas

• 除了存入gas外，Paymaster还需要在入口点合约上额外质押以太坊。这个质押不会被slash，但可以防止机器人恶意批量创建Paymaster

Paymaster（至少在官方的愿景中）是一个充满竞争的开放市场。虽然官方没有定义Paymaster的链上信誉系统，Bundlers可以在链下记录Paymaster的服务质量并停止使用质量较低的Paymaster，从而激励Paymaster为UserOperation提供可靠的服务。

Paymaster接口定义了两个函数：

• validatePaymasterOp：定义gas抽象逻辑。例如，在一个智能合约钱包以ERC20代币支付gas的场景中，此函数将确保钱包具有足够的余额。validatePaymasterOp在执行UserOperation之前被调用，符合将验证步骤和执行步骤分开的设计逻辑

• postOp：在智能合约钱包执行某一函数的最后一步被调用。如果钱包没有足够的ERC20余额来支付gas费给Paymaster，postOp会取消函数执行。即使在此步骤中函数执行因为runtime error失败，gas仍然会被扣除。

图：官方EIP 4337文档中的Paymaster工作流程

图：官方EIP 4337文档中的Paymaster接口

6. 钱包工厂（Wallet Factory）

Wallet Factory是一个创建智能合约钱包的合约。 回顾一下，UserOperation有一个可选的initCode字段。当initCode为空时，UserOperation只是触发智能合约钱包的功能。当initCode填充了Wallet Factory地址和新智能合约钱包的参数时，Bundler将触发相应的Wallet Factory使用指定参数创建智能合约。

Wallet Factory在以下方面有助于实现账户抽象：

• 用户可以通过提交填充了initCode的UserOperation来请求Bundler创建智能合约钱包，而无需拥有EOA来自行创建

• 用户可以通过选择具有特定定制选项的Wallet Factory并传入自己的参数来定制智能合约钱包。此外，因为Wallet Factory合约是公开的，而且受欢迎的Wallet Factory会经过全面的代码审计，所以使用Wallet Factory创建新钱包对用户更安全

• 用户可以选择让Paymaster代付创建钱包的gas或者用任意ERC20代币支付gas，无需拥有以太坊。此外，Paymaster可以选择只为其信赖的Wallet Factory部署的智能合约钱包支付gas

• 用户可以在创建钱包之前通过调用CREATE2函数获取他们的智能合约钱包地址。该函数使用触发智能合约钱包创建的EOA地址、一个salt和initCode确定性地生成智能合约地址。用户在创建钱包时不需要支付gas，只需要在用钱包进行第一笔交易时同时支付创建钱包和交易的gas，从而提高用户体验。

Wallet Factory还有其他职责。与Paymaster类似，它们需要在入口点合约上抵押ETH并持续性地为UserOperations提供良好的服务，以便从Bundler那里获得更多流量。

7. 签名聚合器（Signature Aggregator）

因为不同的智能合约钱包使用不同的签名算法，所以需要先将使用相同签名算法的UserOperations聚合起来，然后分别进行验证。此外，由于链上密码学计算会消耗大量gas，支持聚合的签名方案（如BLS）可以在链上验证过程中节省gas。因此我们需要一个名为签名聚合器（Signature Aggregator）的EIP 4337智能合约接口。它可以通过实现以下两个函数来支持特定的签名算法：

• aggregateSignatures：输入参数为一个UserOperations数组，并使用特定的签名算法输出一个聚合签名

• validateSignatures：输入参数为一个UserOperations数组和一个聚合签名，用于对数组里的所有UserOperation进行验签

与其一次验证一个UserOperation，Bundler首先会使用多个签名聚合器合约（每个签名算法使用一个）生成多个聚合签名（每个签名算法生成一个）。之后，Bundler将UserOperation数组、聚合签名和聚合器地址传递给入口点合约，每个UserOperation数组会调用其对应的签名聚合器的validateSignature函数。验证通过后，Bundler就会在智能合约钱包上执行这组UserOperations。

与Paymaster和Wallet Factory类似，聚合器也需要在入口点合约上质押以太坊并保持为UserOperations提供良好服务的记录。

图：官方EIP 4337文档中的签名聚合器接口

8. 整体工作流程总结

EIP 4337的模块化设计将智能合约钱包的账户抽象功能分为多个接口。这些接口的功能合在一起可以总结为如下的工作流程：

• 用户向Bundler发送UserOperation

• 如果UserOperation填写了initCode参数，Bundler会触发Wallet Factory来创建有确定地址的新钱包

• 如果UserOperation填写了paymasterAndData参数，Bundler会收取Paymaster在入口点合约上质押的以太坊来支付gas。如果没有填写paymasterAndData，Bundler会收取智能合约钱包在入口点合约上质押的以太坊来支付gas

• Bundler可以选择性地使用签名聚合器

• Bundler会使用validateOp、validatePaymasterOp和validateSignatures函数在链下模拟验证UserOperation，确保签名正确且UserOperation有足够的gas

• 如果链下模拟验证通过，Bundler将使用上述函数在链上验证UserOperation

• 如果链上验证通过，Bundler将在链上执行UserOperation，无论执行是否成功，都会扣除gas

图：没有签名聚合器的账户抽象工作流程（Alchemy提供）

图：带签名聚合器的账户抽象工作流程（Alchemy提供）

9. 其他注意事项

UserOperation在链下和链上都会触发validateOp等函数进行交易验证。为了防止智能钱包合约外部的状态变化（state change）导致链下和链上的验证结果不一致，EIP 4337禁止验证函数使用读取合约外部storage和读取全局状态（如时间戳）的OpCodes。这种禁止适用于validateOp、validatePaymasterOp和validateSignatures这些验证函数。

第二部分：账户抽象市场参与者

1. 智能合约钱包及配套SDK

智能合约钱包是账户抽象市场中最大的参与者。为了与EIP 4337兼容，它们通常会实现自己的打包器（Bundler）、代付合约（Paymaster）、钱包工厂（Wallet Factory）和签名聚合器（Signature Aggregator）。这些钱包还配备了方便dApp集成钱包的SDK。智能合约钱包市场比较拥挤，既有老牌大玩家如多签钱包Gnosis Safe在原有产品基础上实现账户抽象功能，也有市场新人如Candide专注于构建完全兼容EIP 4337的智能合约钱包。本节将介绍这些钱包的共同特点以及每个特点中的差异化。

a. 社交登录（social login）和社交恢复（social recovery）

社交登录为智能合约钱包提供了Web2用户非常熟悉的交互体验，例如使用已有的Google帐户创建和登录钱包。同样的逻辑也可以延伸到社交恢复上，例如使用邮箱重置智能合约钱包的密码。社交登录和社交恢复的逻辑一般在钱包的主合约中定义。

这里我们引入守护者（Guardian）的概念。守护者是指可以授权用户访问某账户或帮助用户重制恢复某帐户的实体。守护者可以是Web2账号也可以是邮箱地址。这个概念在Web2中已经有了很广泛的应用，现在也可以通过账户抽象的概念在智能合约钱包中实现。

一个智能合约钱包可以有多个守护者。用户需要在创建钱包过程中或之后设置守护者，并达到一定的守护者验证阈值，例如3个守护者中的2个，以登录或恢复钱包。这个过程通常被称为多因素认证（multi factor authentication）。以下是常见的智能合约钱包守护者类型：

• Web2服务提供商：例如钱包用户的社交媒体帐户，通常通过实施OAuth（Open Authorization，即开放授权）标准来实现。该标准允许钱包获取用户授权来访问由另一个Web2应用托管的用户账号信息

• 用户设备：例如浏览器存储和移动端存储

• 电子邮件：例如通过点击可以发送签名的电子邮件链接进行授权

• 多签名：用户可以设置多个个人拥有的EOA或智能合约钱包作为守护者

• MPC：用户可以将私钥分割成多个份额，每个份额由MPC网络中的一个节点控制，且不会泄露完整的密钥

• SWIE（sign in with Ethereum，即用以太坊登录）

让我们看看一些市场上玩家对此功能的实现：

• Web3Auth是许多高流量智能合约钱包使用的社交登录和MPC服务，这些钱包包括Biconomy、Etherspot和0xPass。Web3Auth把用户密钥分割成多份给社交登录、用户设备和其MPC节点网络等守护者。产品逻辑实现完全在链下，且没有任何一个守护者会存储完整的私钥。（请参见下图。）

• BLS Wallet和Argent使用多签技术（multisig）通过用户指定的多个EOA地址进行密钥恢复。

• UniPass实现了一种创新的方法，通过电子邮件进行社交恢复。用户在链上提交守护者的邮箱，并通过智能合约在链上验证邮箱的DKIM签名。DKIM（Domain Keys Identified Mail，即域名密钥识别邮件）是一种电子邮件身份验证协议，用于创建数字签名。邮箱供应商可以使用该数字签名验证邮件发送者的身份。UniPass还使用零知识证明对链上的用户信息进行脱敏处理。UniPass也支持邮件之外的社交恢复方法。

• Soul Wallet在链上验证守护者的邮箱地址以进行社交恢复。

图：Web3Auth社交登录和社交恢复，此案例中有三个守护者

b. Gas Abstraction（gas抽象，gas即交易手续费）

Gas abstraction包含无gas交易和使用任意ERC20代币支付gas。这些逻辑可以在代付合约（Paymaster）中实现，也可以通过中继器（Relayer）实现。

许多智能合约钱包自己实现了与EIP 4337兼容的Paymaster合约，并在入口点合约上质押代币，帮助用户支付gas。

Relayer是在EIP 4337之前就存在的另一个gas abstraction的解决方案。 Relayer是用户信任的交易转发者，执行一种称为“元交易”（meta-transaction）的特殊类型的无gas交易。元交易是一种以太坊交易，它在原始交易中插入另一个交易。用户使用私钥对元交易进行签名，并将其发送给Relayer，后者对其进行验证，将其提交给区块链，并代付gas。Relayer只是执行交易，而不改变交易本身。 Relayer会获取经济上的利益，因为它们会向执行交易的合约收取gas费用加上一小笔利润。例如，Relayer可以向支持无gas交易的去中心化应用（dApp）收费。Relayer可以是中心化的可信第三方，也可以是去中心化的网络。Relayer与代付合约（Paymasters）的区别在于以下几点：

• 除了支付gas外，Relayer还会对交易进行签名，类似于EIP 4337中的Bundler所做的事情

• Relayer不只处理UserOperations类型的交易

• Relayer不在入口点合约上质押gas

让我们看看一些市场上玩家对此功能的实现：

• Biconomy不仅自行实现了与EIP 4337兼容的Paymaster，还有一个支持任意ERC20代币支付gas的Relayer网络。

• Argent使用第三方Relayer以元交易的形式支付gas。

• Candide自行实现了Paymaster。

• UniPass使用自己的Relayer节点支付gas，计划在未来添加“观看广告免gas交易”模式并支持使用跨链桥（bridge）支付gas。

到目前为止，大多数ERC20支付gas的解决方案（如Candide和Soul Wallet）仅支持非常有限的代币类型，主要是稳定币，尽管我预见这在未来会发生变化。

图：Biconomy 使用Paymaster支持无gas交易（基于EIP 4337的技术实现）

图：Biconomy 通过Relayer使用任意ERC20支付gas（并非基于EIP 4337的技术实现）

c. 法币出入金通道（ramps）和跨链桥（bridges）

许多现有的钱包，如MetaMask，已经通过和第三方供应商合作的方式把法币出入金通道和跨链桥集合在钱包中。这些出入金通道和跨链桥可以进一步与gas abstraction中的代付合约（Paymaster）进行集合。

让我们看看一些市场上玩家对此功能的实现：

• Biconomy和0xPass与Transak合作提供法币通道。Biconomy还提供跨链桥和跨链通信服务。

• Argent Vault与Moonpay、Transak和Wyre合作提供法币通道，并具有内置的DeFi协议聚合器。

• Etherspot、UniPass和Braavos支持法币通道、swap和跨链桥。

d. 交易批处理（transaction batching）

**交易批处理是智能合约钱包独有的功能，允许钱包用户在一个链上交易中执行多个交易。**一种实现方法是调用一个multiCall函数，它接受两个参数：一个calldata数组（每个calldata定义一个函数调用）和一个合约地址数组（每个函数调用的合约地址）。multiCall函数中有一个循环（loop）并在每次循环里执行一个函数调用。交易批处理可以使多个交易分摊一个以太坊交易的固定gas费，从而减少成本。

请注意，交易批处理不同于签名聚合（signature aggregation），后者接受一个UserOperations数组作为输入参数并输出一个聚合签名字节以加快多个签名验证的速度。而这个数组中的每个UserOperation都可以调用一个multiCall来执行交易批处理。

在EIP 4337中实现交易批处理的方式如下：入口点合约调用handleOp函数，然后该函数再调用智能合约钱包主合约内定义的multiCall函数。

让我们看看一些市场上玩家对此功能的实现：

• Biconomy设置了一个MultiCall合约，智能合约钱包可以调用这个合约来批量执行交易。

• Argent通过名为Transaction Manager的智能合约模块来批量执行交易，该模块支持multiCall和用户会话密钥（session key）。

• Etherspot、Candide、Openfort和0xpass都支持交易批处理。

图：示例 MultiCall 合约（Solidity by Example提供）

e. 智能合约钱包的模块化设计（modular design）

**智能合约钱包相对于EOA的一个主要优势是其模块化设计。钱包的功能可以通过钱包提供商开发的合约模块进行扩展。这些模块提供了EIP 4337接口中未定义的功能，并可以由用户自定义。**模块化设计下，智能合约钱包是可升级的。这种做法在EIP 4337发布之前就已经是行业标准，由诸如Gnosis Safe之类的产品率先推出。Gnosis Safe是一款主要针对商业用户的多签名钱包，提供一系列EIP 4337没有定义的功能：

• 支出限制：限制有签名权限的帐户可以从钱包中提取的金额。

• 定期打款：根据自定义时间自动打款。

• 角色和授权：为钱包不同的交易和行为定义所需的角色和授权。

• 组织权限：基于组织内不同角色的权限设置。

• 白名单和黑名单

同样的模块化设计也被EIP 4337兼容的钱包继承，包括Argent、Candide、Soul Wallet和zeroDev。

**另一种扩展智能合约钱包功能的方法是在钱包里原生地集成去中心化应用（dApps）。**例如，Gnosis Safe为dApps提供了一个SDK。使用此SDK的dApp可以直接出现在钱包界面中，等同于为钱包提供了一个内置的应用商店。其他类似解决方案包括WalletConnect。然而，这些前端解决方案并不是协议层的设计，因此超出了本文讨论的范围。

图：Candide钱包的模块化设计与Safe（即Gnosis Safe）类似（Candide钱包官网提供）

2. 基础设施提供商

下面将讨论各种Layer 2对账户抽象的支持以及打包器（Bundlers）和代付合约（Paymasters）的第三方基础设施提供商。

a. Layer 2上的账户抽象

鉴于最近L2的爆炸式增长，许多智能合约钱包已将开发重点转向L2。许多L2都原生地支持与EIP 4337非常相似的账户抽象合约标准，本节将对此进行探讨。

Optimism

Optimism的第一版通过引入三个EVM不支持的OVM OpCodes来实现账户抽象。在Optimism的技术实现中，智能合约是唯一的账户类型（不存在EOAs），因此所有用户钱包都是智能合约钱包。智能合约钱包还可以通过调用upgrade函数升级合约代码。

不幸的是，为了与EVM保持完全一致和出于安全方面的考虑，Optimism的第二版移除了这三个OVM Opcodes和对账户抽象的支持。

虽然目前有少数智能合约钱包正在Optimism上构建，但是尚无关于支持账户抽象的官方声明。

Arbitrum

虽然目前有少数智能合约钱包正在Arbitrum上构建，但是尚无关于支持账户抽象的官方声明。

Starknet

与以太坊不同，Starknet不区分EOA和合约账户。因此，所有Starknet账户都是智能合约账户。Starknet的账户模型受到EIP 4337的很大影响，具体表现在以下方面：

• 所有Starknet智能合约账户都必须包含validate和execution函数。validate是必需的函数，通过验证签名确保只有账户所有者才能发起交易，同时保证交易执行者可以获得足够的gas费。用户可以在validate和execute函数中实现任意逻辑，从而灵活扩展账户的各种功能。例如，用户可以在validate函数中实现不同的验签算法。

• 为了防止交易通过验证但无法执行，Starknet禁止validate函数调用外部合约的状态（state）。

Starknet对账户抽象的实现和以太坊相比依旧存在显著的差异：

• Starknet不区分常规交易和UserOperations，因为所有交易都是由合约账户触发的。在以太坊中，Bundlers执行UserOperation交易，而在Starknet中，序列器（Sequencer）执行所有交易。

• Starknet尚未实现类似Paymaster的交易手续费抽象协议。

• Starknet要求有代币余额的账户通过调用一个专门的deploy_account函数来创建新的合约账户。而在EIP 4337中，Bundler通过执行initCode参数不为空的UserOperation交易来部署合约账户，部署过程不必须有代币余额的账户，因为gas费可以由Paymaster代付。

• 如果通过验证的交易在执行步骤失败，Starknet的序列器将无法抽取任何gas费，而以太坊没有这个问题。

图：Starknet没有EOA账户类型，只有合约账户（Starknet官网提供）

zkSync

zkSync也不区分EOA和合约账户，因此原生地支持账户抽象。zkSync的账户模型与EIP 4337十分类似，具体表现在以下方面：

• 账户（智能合约钱包）接口也将validateTransaction和executeTransaction函数分开。

• 代付合约（Paymaster）接口也包括validateAndPayForPaymasterTransaction和postOp函数。前者定义了Paymaster代付交易的逻辑。后者可以确保在交易执行后，Paymaster能够抽取gas费补偿，尽管这部分功能尚未实现。

• 用户也通过填写交易中的paymaster地址和paymasterInput两个参数来调用Paymaster，类似于EIP 4337中的UserOperation。

然而，zkSync实现的账户抽象和以太坊也存在显著差异：

• zkSync允许validateTransaction函数调用已部署的外部合约，因为已部署的合约在zkSync中是不可更改的（immutable）。 以太坊禁止验证函数调用外部合约，以防止状态更改（state change）造成交易验证通过而交易执行失败。

• zkSync允许validateTransaction调用发出此交易合约账户的外部存储，例如合约账户在外部合约上的代币余额，理由同上。

• 在交易验证期间，Paymaster可以调用外部存储，理由同上。

b. 第三方基础设施提供商（非智能合约钱包）

如上所述，账户抽象基础设施包括可以发送UserOperations的客户端SDK、打包器（Bundlers）、代付合约（Paymasters）和签名聚合器（Signature Aggregator）。**这些基础设施通常由智能合约钱包自身实现，从而更好地整合产业上下游，但是大多数都不是为第三方使用而设计的。因此市场上需要第三方基础设施提供商来提供模块化和可定制的Bundler和Paymaster服务。**一些知名的基础设施玩家比如Alchemy也进入了这个市场。本节会深入探讨这些第三方基础设施提供商。

Stackup

Stackup是一个Bundler和Paymaster的提供商。其Bundler采用Go语言实现，通过了所有EIP 4377测试套件的要求，完全开源且免费使用。Stackup Bundler支持不同的模式：

• 私有模式（private mode）：UserOperations进入一个私有内存池（mempool），以更慢的交易执行速度换取更好的隐私。UserOperation不会显示在公共内存池中，从而避免了MEV攻击。

• 搜索模式（searcher mode）：由以太坊生态的机器人运营者（即bot operator，也称为searcher，例如DeFi套利机器人）使用，并与诸如Flashbot之类的区块构建者（block builder）集成，通过MEV-Boost发送UserOperations，允许searcher为特定的交易排序出价，以供block builder选取MEV最大的交易排序构建区块。

Stackup还支持两种类型的Paymaster：

• Verification Paymaster：提供需要链下交易（如法币出入金）的gas抽象。例如，用户可以选择使用信用卡订阅Paymaster服务来支付gas费。用户也可以定制gas代付的逻辑。Stackup将通过“按需付费”（pay as you go）模式向用户收费。

• Deposit Paymaster：允许用户用ERC20代币支付gas费。

图：Stackup的基础设施产品套件

Blocknative

Blocknative主要是一个内存池浏览器和可视化工具提供商。得益于其对于内存池较强的理解，Blocknative提供了具有独特功能的打包器（Bundler）服务，例如：

• 使用EIP 4337交易浏览器（EIP 4337 UserOps Explorer）可视化内存池中UserOperations的状态，方便钱包和dApp实时监控交易的状态

• Blocknative的核心产品内存池浏览器也可以监听入口点合约中待处理和已确认的Bundler交易

Alchemy

Alchemy目前正在开发其Bundler和Paymaster服务，潜在用户可以加入waitlist。

图：Alchemy的EIP 4337基础设施服务还在开发中

eth-infinitism

eth-infinitism是以太坊基金会的官方团队，目前已经实现了EIP 4337标准定义的Bundler和Paymaster。关于该团队的文档很少，但是根据Stackup的一篇文章，截至2023年2月，eth-infinitism是通过EIP 4337官方测试套件的唯一两个Bundler之一（另一个是Stackup）。

第三部分：账户抽象的未来之路

1. 归根结底，账户抽象市场的生死存亡取决于生态对EIP 4337的采用，而这个市场还非常早期

根据Web3Caff Research最近的一篇研报，以太坊中所有交易的发起地址（from参数）去重后的总数约为1.5亿。然而，智能合约钱包的总数，以Gnosis Safe和Argent账户的总和来估算（这两个产品的用户最多），仅为15万。

假设在终局，EOA和智能合约钱包的数量相等，我们可以预测智能合约钱包的市场规模有1000倍的潜力。 尽管如此，生态对智能合约钱包的采用并不会一帆风顺。像MetaMask这样的EOA钱包巨头仍未宣布采用EIP 4337的计划。尽管我们不知道他们的意图，但也不难推断，主流EOA钱包的巨大利润并不足以支持其团队内部采用一个基础设施都不完善的新标准。UserOperation仍然不是dApps广泛使用的主流交易类型。虽然如此，我依旧对智能合约钱包市场保持乐观态度，也可以预见到智能合约钱包对用户体验的大幅改善会为账户抽象市场带来的指数级的增长，尽管这种爆发可能还需要一两年才发生。

2. EIP 4337尚未完成，同志仍需努力

尽管EIP 4337定义了诸如打包器（Bundler）、代付合约（Paymaster）和签名聚合器（Signature Aggregator）等基础设施的合约接口，以太坊官方并没有给出很多重要技术问题的解决方案，而这些问题需要项目方反复尝试不同的技术实现，比如：

• 目前Bundler主要在私有内存池（private mempool）广播交易，UserOperation被直接发送给指定的区块构建者（block builder）。Bundler网络是否有可能使用公共内存池（public mempool）？

• Bundler能否通过对UserOperations进行排序来抽取MEV？区块构建者能否通过对捆绑交易（bundle）进行排序来抽取MEV？MEV将如何在Bundler和区块构建者之间分配？我们是否应该将Bundler和区块构建者分开？

• 考虑到Bundler需要完成大量的链下模拟和链上验证，它们能否同时作为可靠的区块构建者？

• UserOperation的内存池和常规交易的内存池应该如何协调以避免状态冲突？

3. L2采用EIP 4337的速度各异

尽管zkSync和Starknet已经原生地支持账户抽象，但它们仍未实现所有的EIP 4337接口，并且在技术实现上与以太坊存在差异。尽管许多项目团队正在为Optimism和Arbitrum构建智能合约钱包、打包器（Bundlers）和代付合约（Paymasters），但这些L2尚未宣布官方支持EIP 4337的计划，账户抽象也并非他们的开发重点。

从纯技术的角度来看，L2账户抽象基础设施的实现比L1更为复杂。例如，在验证步骤中，一个L2智能合约钱包需要同时估算L1和L2的gas费，并分摊给捆绑交易（bundle）里的每个UserOperation。

4. 抛开技术细节，一个优秀的智能合约钱包需要有哪些特点？

尽管钱包市场上有许多创新的功能（如gas抽象、社交恢复、MPC等），大多数智能合约钱包都支持所有上述功能，因为这些功能的技术实现并不困难。因此，智能合约钱包的商业层面与用户体验层面同样重要。重要的商业因素包括：

• 与dApps合作：与每个L1或L2链的流量入口级dApps合作，尤其是基础设施类的dApps（如稳定币或DeFi协议），是吸引用户的主要途径

• 实用功能：如钱包内部集成的NFT市场、launchpad或快速集合新的交易对

• 外部支持：如来自VC或以太坊基金会的官方支持，这些支持可以帮助钱包找到第一批用户

5. 一个优秀的打包器（Bundler）需要有哪些特点？

无需许可（permissionless）且模块化（modular）的Bundler服务是一种公共物品（public good）。绝大多数Bundler的开源性质决定它们是非排他性和非竞争性的。任何RPC端点都可以通过复制开源代码来运行一个Bundler。即使运行Bundler的RPC端点通过API密钥来收取服务使用费，Bundler服务也比其他基础设施（如代付合约Paymaster）更难盈利，因为后者可以通过与第三方出入金或DeFi协议聚合器提供商合作轻松赚取费用差价。虽然更难商业化，但是Bundler是一种重要的公共物品，因为UserOperation的验证和执行需要尽可能多的Bundler参与从而更好地去中心化。因为Stackup和eth-infinitism是目前唯二可用的第三方Bundler服务提供商，所以我们肯定需要更多这样的Bundler服务提供商。

Bundler服务提供商需要克服许多技术难点：

• 对链下和链上的多个验证步骤进行深入研究，从而确保UserOperation可以成功执行。技术难点包括理解多个UserOperations之间可能出现的状态冲突（state conflict）。

• 理解验证函数对某些OpCode的禁用：

  • 由于读取可变的外部状态（external state）可能导致交易验证成功但执行失败，因此EIP 4337禁止验证函数调用读取外部状态的OpCodes。

  • 不同的L2对读取外部状态的OpCode有略微不同的禁用，会对多链开发造成挑战。

  • 正在构建Bundler的项目方需要通过traceCall函数来获取每个函数调用的OpCodes。然而，大多数第三方RPC节点都不支持traceCall，因此Bundler项目方可能需要运行自己的节点，这也存在技术壁垒。

• 目前大多数Bundler项目方的开发重点都在L2，需要分别计算L1和L2的gas费。

• 实现私有和公共内存池的P2P network。私有内存池需要为searcher和dApps提供定制化的服务，例如白名单。公共UserOperation内存池的行业标准尚未完成。

Bundler服务提供商的差异化在于：

• Bundler服务是专为钱包构建的，还是第三方基础设施提供商构建的？

  • Bundler只是钱包项目方需要构建的众多事物之一，因此他们更可能专注于为钱包构建一个最基础的可用的Bundler。

  • 第三方基础设施提供商需要构建无需许可和模块化的Bundler，并为不同的场景提供优质的服务。

• 类似于以太坊节点，Bundler服务采用不同的语言实现。这种语言多样性可以防止单点故障，对以太坊生态有益。

• 对私有和公共内存池的支持以及对私有内存池进行定制的选项。

• 对L1和不同L2链的支持，每个链在接口实现上略有不同。

6. 让我们聊聊创新

本节将列举智能合约钱包和账户抽象基础设施中最需要的创新。

无需许可和模块化的EIP 4337基础设施

让我们首先设想一下EIP 4337基础设施的终局：

• 许多打包器（Bundler）、代付合约（Paymaster）和签名聚合器（Signature Aggregator）提供商会在一个开放市场上竞争。用户可以用最低费用获取高质量服务

• 市场上既存在无需许可的Bundler、Paymaster和Signature Aggregator公共端点，也存在专门为某个智能合约钱包或dApp部署的端点

• **智能合约钱包、dApp和个人用户可以以无需许可（permissionless）、模块化（modular）和用户友好的方式部署上述的基础设施。**换句话说，第三方基础设施提供商允许从任意地址快速且可定制地部署Bundler、Paymaster和Signature Aggregator

在当前市场状态下，许多智能合约钱包已经构建了自己的基础设施，但是这些基础设施并未针对第三方的不同使用场景。诸如Stackup之类的第三方基础设施提供商正在开发模块化的Bundler和Paymaster，但是它们的部署过程仍然远未达到无需许可。因为EIP 4337尚未完成，这些基础设施的模块化功能还没有被全部定义。此外，由于UserOperation交易量依旧较低，启用了签名聚合的钱包（如BLS Wallet）仍然不是主流。

EIP 4337下游基础设施

这些包括EIP 4337未定义但实现EIP 4337基础设施所需的下游基建，比如可以集成到Paymaster的法币出入金聚合器和DeFi聚合器。因为这些解决方案已经存在，所以创新最有可能在现有提供商内部发生，提供商只需重新配置它们公开的接口。

dApp SDK和脚手架

尽管现有的智能合约钱包都为了方便dApp集成而构建了自己的客户端SDK，但市场仍然缺少：

• 支持账户抽象功能的类似于ether.js的dApp开发标准库，比如对如下功能的封装：

  • 使用Web2社交媒体账户和电子邮件创建钱包和恢复钱包地址

  • UserOperations的创建、签名、发送以及的事件监听

  • 快速部署Paymaster和Signature Aggregator

• 聚合所有主要智能合约钱包的SDK和UI工具

• 用于快速前端部署的脚手架工具，以便dApp开发人员可以专注于他们产品的业务逻辑

• 由账户抽象赋能的新型dApp的模板，例如支持gas抽象的游戏

更激进的做法：将账户从智能合约钱包分离

EIP 4337的智能合约钱包接口只需要一个validateOp函数，将所有的核心业务逻辑，如用户注册、权限控制和社交恢复等，留给钱包开发者自由决定。虽然这提供了更多的灵活性，但不同的智能合约钱包会更加割裂以太坊生态，因为一个钱包中的数据不能轻易地转移到另一个钱包。dApp也可能通过支持某些智能合约钱包而不支持其他钱包加剧这种分裂。

此外，尽管用户可以通过邮箱或其他在Web2常见的流程登录智能合约钱包，他们仍需要通过“连接钱包”这类Web2用户不熟悉的操作流程来登录dApp。

解决这些问题的一个激进方案是通过创建新的账户标准，将账户与智能合约钱包分离，例如Hexlink倡导的EIP 6662。EIP 6662定义了一个IAccountMetadata的账号接口，使用户可以自定义自己账号的认证方法（如Web2社交媒体账号），从而将认证逻辑从钱包主合约转移到单独的账户接口。支持此接口的智能合约钱包可以允许用户将其账户数据转移到另一个钱包。支持此接口的dApp可以允许用户使用账户接口中定义的Web2认证方法登录他们的Web3账户。dApp可以验证来自Web2认证方法的签名，以此查询Web3账户地址，向Web2账户推送通知，并连接到Web3账户。用户不需要为不同的dApp创建其支持的不同的钱包。相反，dApp会自动连接到与用户Web2认证方式关联的Web3账户。用户账户和钱包不再是一体也不再受制于钱包，钱包本质上成为了用户可以登录账户来进行资产管理的dApp。

结论

• EIP 4337将智能合约钱包及其相关基础设施标准化为六个合约接口：智能合约钱包主合约、打包器（Bundler）、入口点合约（Entry Point Contract）、代付合约（Paymaster）、钱包工厂（Wallet Factory）和签名聚合器（Signature Aggregator）。UserOperation是EIP 4337支持的新交易类型。

• 账户抽象市场有两类参与者：

  • 具有社交登录、社交恢复、gas抽象、交易批处理，以及集成和聚合第三方服务（如法币出入金和DeFi协议）等功能的智能合约钱包。

  • 基础设施（如Bundler或Paymaster）的第三方提供商，专注于模块化设计。

• 我对账户抽象市场有如下预测：

  • 智能合约钱包市场竞争激烈，因为竞品的功能类似，技术壁垒也较低。

  • Bundler是一种盈利较难但是生态十分需要的公共物品。

  • 账户抽象仍然是一个非常早期的市场，因为采用率仍然很低，EIP 4337尚未完成，许多L2尚未实现对账户抽象的支持。

  • 账户抽象市场需要许多创新，如：无需许可的模块化基础设施、与现有法币和DeFi服务的集成、dApp SDK以及潜在的独立帐户层。

鸣谢与免责

在撰写本文时向几位行业专家和朋友进行了请教交流，特别在此感谢陈剑Jason、PlanckerDAO的王奕翔Aaron、独立研究员菠菜菠菜、Hexlink团队、AntAlpha Ventures的Circle Fang、Skyhigh等各位的交流探讨！

因本人认知有限，调研时间有限，可能会出现错误和疏忽。如有不同意见，欢迎交流指正，非常感谢！研究为个人兴趣，与文章里提到的所有项目都不存在经济利益关系，但也不作为投资建议。

欢迎大家关注我的推特@SteveIsEmployed，如果你想深入探讨交流，也可以添加微信clairvoyant_98。

参考文献

https://ethereum.org/en/roadmap/account-abstraction/

https://eips.ethereum.org/EIPS/eip-4337

https://antalphaventures.notion.site/2edc5e36f69a44fe9a27dad0ef6ac3fb?v=a0fad60e889a4b2f831a2349d92ca11b

https://www.stackup.sh/blog/a-guide-to-the-top-erc-4337-bundlers-features-performance-and-more

https://github.com/PaymagicXYZ/awesome-account-abstraction

https://camiinthisthang.substack.com/p/account-abstraction-for-everyone

https://research.web3caff.com/zh/archives/4660

https://research.web3caff.com/zh/archives/3212

https://www.alchemy.com/blog/account-abstraction

https://www.alchemy.com/blog/account-abstraction-paymasters

https://www.alchemy.com/blog/account-abstraction-wallet-creation

https://www.alchemy.com/blog/account-abstraction-aggregate-signatures

https://docs.starknet.io/documentation/architecture_and_concepts/Account_Abstraction/approach/

https://era.zksync.io/docs/dev/developer-guides/aa.html#example-of-using-the-library

https://www.alchemy.com/account-abstraction

https://docs.zerodev.app/

https://eips.ethereum.org/EIPS/eip-4361

https://beta-docs.0xpass.io/

https://braavos.notion.site/Public-Docs-d98f625edb2e4399acab2e30d060ef8e

https://github.com/proofofsoulprotocol/soul-wallet-contract

https://docs.wallet.unipass.id/introduction/intro

https://docs.blocknative.com/4337-tools/blocknative-bundler

https://docs.candidewallet.com/develop/getting-started

https://docs.stackup.sh/docs/packages/bundler/introduction

https://github.com/web3well/bls-wallet

https://docs.etherspot.dev/

Twitter: @SteveIsEmployed

Introduction

Account abstraction, as defined in Ethereum Improvement Proposal 4337 (EIP 4337), is a set of protocol interfaces that not only integrate web2-familiar user interactions such as multi factor authentication, but also address web3-specific user pain points such as gasless transactions. Alternatively termed as the protocol that onboards the next billion users, account abstraction focuses on smooth user experience at the forefront.

Although many existing articles explain account abstraction very well, they are either entirely introductory or too focused on the technicals. This article aims to provide both a high level understanding of account abstraction concepts and a deep dive into existing applications. In part 1, we will explore the origins of EIP 4337 and delve into its technical details, including UserOperation, Bundler, Paymaster, Wallet Factory, and Signature Aggregator. In part 2, we will profile and analyze existing market players in the space. In part 3, we will discuss the way forward for account abstraction, including innovations that are still lacking in the space.

Part 1: EIP 4337 and Technical Review

To very briefly go through the basics, there are two types of accounts in Ethereum: externally owned accounts (EOA) and contract accounts.

• EOAs are user controlled accounts that can send transactions. EOA defines the ownership of an account through its private key, which can sign and execute transactions to change the EOA’s internal state or external smart contracts’ states. Because private key (or its alternative form, seed phrases) is everything, EOA isn’t good for defining complex ownership or transaction logics such login with social media accounts and multi-party signed transactions. The limitations of EOA translate into poor user experience, where counterintuitive things like private key and seed phrase management deters Web2 users from entering Web3. The most popular wallets, such as MetaMask, are based on this model.

• Contract accounts host arbitrary Solidity codes and therefore can access all the Turing-complete functionalities of EVM. Because they cannot send transactions, their functions must be triggered by EOAs. Smart contract wallet is a contract account which is indirectly triggered by its user through the wallet provider’s EOA network, whether Relayers or Bundlers.

Figure: EOA vs contract accounts (credit to Bitcoin Insider)

Smart contract wallets exist before EIP 4337, which was only later proposed to codify the common functionalities of a smart contract wallet and its related infrastructures. EIP 4337 follows a few design principles:

• Overall, all implementations should be on a high level (smart contract level) and shouldn’t touch lower level infrastructures such as the consensus and execution engines, due to the constraint on developer resource, most of which had been focused on the Merge.

• The protocol design should be modular, so that users can customize options including transaction processing (Bundler), gas payment (Paymaster), signature scheme (Aggregator).

• Ideally, each service will become a competitive open market, where users select the best service based on providers’ price and reputation.

EIP 4337 defines six contract interfaces for standardized smart contract wallets:

• First, the smart contract wallet itself, which allows Bundler to validate a transaction off-chain and then process it on chain.

• Second, the Bundler, which validates and executes smart contract wallet transactions (called UserOperation) in batch.

• Third, the Entry Point contract, a global singleton contract which standardizes transaction execution and insulates the bundler from potentially malicious transactions.

• Fourth, the Paymaster, which handles gas payment on behalf of the wallet user.

• Fifth, the Wallet Factory, which standardizes wallet creation.

• Sixth, the signature Aggregator, which aggregates the signatures of multiple transactions to bytes for faster validation and execution.

Now, I will elaborate on UserOperation and the six contract interfaces defined above. I drew my inspiration from the official EIP 4337 doc and a series of technical reviews by David Philipson @Alchemy.

1. UserOperation

UserOperation is essentially a transaction with additional account abstraction specifications. Recall that a regular ethereum transaction, which can only be triggered by an EOA, has fields such as recipient address, ethereum amount, gas amount, and gas price.

Besides, given the highly customizable nature of account abstraction, UserOperation include the following important fields:

• calldata: defines the signature and input parameters of the function to call on the smart contract wallet (also in a regular transaction)

• signature: verifies that the transaction is indeed from the smart contract wallet (also in a regular transaction)

• nonce: prevents replay attacks (also in a regular transaction)

• sender: specifies which smart contract wallet should execute the UserOperation

• paymasterAndData: used for gas abstraction, containing Paymaster address and specifications for gas payment

• initCode: used for wallet creation, containing Wallet Factory address and parameters for the smart contract wallet

Other than the additional fields, UserOperation works similarly to a regular transaction, such that they are both broadcast to a mempool for validation, execution, and inclusion in a block. Validation and execution of UserOperation is handled by Bundlers, which we explain next.

Figure: UserOperation parameter definition by official EIP 4337 doc

2. Bundler

Bundler validates and executes UserOperation transactions on the smart contract wallet on behalf of its user and acts like an EOA, because all transactions must be triggered by an EOA on Ethereum. Bundler saves the user from creating and remembering the private key of an EOA in order to trigger smart contract wallet transactions, which defeats the very purpose of having a smart contract wallet.

Despite the public good they contribute to, Bundlers are economically self-interested, because:

• Bundlers can pocket the difference between the maximum priority fee and the actual gas spent after executing a UserOperation

• Same as relayers of regular transactions, Bundlers can extract MEV by ordering transactions in a bundle

Despite the cost, Bundlers are good for gas savings, because executing each transaction costs a fixed overhead of 21,000 gas, so that executing a bundled transaction spread the fixed cost over multiple transactions, thereby saving gas cost. Besides, modifying storage in the same transaction is incrementally cheaper for each additional operation.

Note that although transactions are executed linearly (non-parallel) on Ethereum to avoid state conflicts, UserOperations can be executed as a bundle, because Bundlers will try to include at most one transaction for each smart contract wallet address, so that UserOperations don’t clash with each other when modifying the state.

Apart from these differences, Bundlers are similar to block builders because both broadcast validated UserOperation transactions to a public or private mempool.

Next, we introduce the Entry Point Contract, which the Bundler has to interact with in order to execute a UserOperation.

3. Entry Point Contract

Entry Point Contract is a global singleton contract that all Bundlers need to call to execute a UserOperation. It acts as the middleman between Bundler and smart contract wallets:

• On one hand, Bundlers calls the Entry Point Contract’s handleOp function, which takes a UserOperation input. handleop is responsible for validating and executing a smart contract wallet function according to the calldata of the UserOperation

  • handleOp first validates the UserOperation on chain, by checking that it’s signed by the designated smart contract wallet and that the wallet has enough gas to pay the Bundler

  • If validation is successful, handleOp executes the smart contract wallet function according to the function’s signature and inputs defined in the calldata of UserOperation

• On the other hand, smart contract wallets are required to deposit tokens to the Entry Point Contract to pay gas to Bundlers. Gas is incurred when Bundler triggers handleOp function using an EOA.

  • Alternatively, smart contract wallet can pay gas to Bundler using its own balance, or ask a Paymaster to handle the payment, which we will elaborate later

  • A UserOperation without enough gas held by its destination smart contract wallet won’t pass the validation step, thereby failing before execution

  • Even with enough gas, a UserOperation can still fail at the execution step, for example, due to a runtime error

  • Whether the execution is successful or not, the Entry Point Contract will pay gas to the Bundler for triggering the handleOp function

  • The Entry Point Contract provides methods for smart contract wallets to add or withdraw stakes

Figure: Entry Point Contract workflow by official EIP 4337 doc

4. Smart Contract Wallet

The smart contract wallet separates the validation and execution steps of a UserOperation:

• Validation is defined in the validateOp function. It’s called twice: once off chain by the Bundler to validate the signature of the UserOperation and gas balance of the smart contract wallet as a simulation; then again on chain by the Entry Point Contract to validate the UserOperation before execution

• Execution is defined in the calldata of the UserOperation, which specifies the signature and inputs of a smart contract wallet function

Therefore, validation and execution are separated, so that the Bundler can validate UserOperation off chain and filter out malicious transactions without paying gas. The validateOp function is similar to an off chain debugging API.

5. Paymaster

Paymaster defines the gas abstraction logics of a smart contract wallet. Gas abstraction means gas payment in alternative ERC20 tokens or gasless transaction, which requires gas sponsorship from a Paymaster. The modular design of ERC-4337 means that a UserOperation can choose an arbitrary Paymaster by specifying its address and input parameters using the paymasterAndData field. Paymaster has the following features and requirements:

• It is essentially a smart contract deployed by a dApp to selectively pay gas for UserOperation using arbitrary logic defined an exposed validatePaymasterOp function that the Bundler triggers

• Paymaster is required to deposit ETH on the Entry Point Contract to pay gas for UserOperation

• In addition to the gas deposit, Paymaster also need to deposit an ETH stake on the Entry Point Contract; this stake won’t be slashed, but acts as a barrier to prevent Paymaster creation spam

The open market nature of Paymasters (anyone can implement the interface) encourages competition. There’s no centralized or on chain reputation system, but Paymasters are incentivized to reliably serve UserOperations, as Bundlers can keep a track record of their operations and stop using lower quality Paymasters.

Paymaster interface exposes two functions:

• validatePaymasterOp: defines the gas abstraction logic. For example, in a scenario where the smart contract wallet pays gas in a ERC20 token, this function will make sure that the wallet has enough balance. validatePaymasterOp is called before a UserOperation is executed. The same design logic that separates validation and execution applies here

• postOp: is called at the last step of a smart contract wallet function call, and will revert the function call if the wallet doesn’t have enough ERC20 balance to reimburse gas to the Paymaster. postOp double checks that gas is still sufficient after executing a function. Gas is still extracted if a function call fails at this step

Figure: workflow with Paymaster by official EIP 4337 doc

Figure: Paymaster interface by official EIP 4337 doc

6. Wallet Factory

Wallet Factory is a contract that creates smart contract wallets. Recall that UserOperation has an optional initCode field. When initCode is empty, the UserOperation simply triggers a smart contract wallet function. When initCode is filled with a Wallet Factory address and the parameters for the new smart contract wallet, the Bundler will trigger the corresponding Wallet Factory to create a smart contract with specified parameters.

Wallet Factory helps achieve account abstraction in the following aspects:

• User can ask a Bundler to create a smart contract wallet without ever owning an EOA, by submitting a UserOperation with initCode filled

• User can customize their smart contract wallet by selecting a specific Wallet Factory with predefined customization options and passing in their own parameters. Besides, because Wallet Factory contracts are public and well known ones are likely thoroughly audited, creating new wallets using factories is safe for users

• User can choose to have a Paymaster sponsor gasless wallet creation or pay gas in alternative ERC20 tokens, without even owning ETH. On the other hand, Paymasters can choose to pay gas for smart contract wallets deployed by approved Wallet Factories

• User can know their smart contract wallet address before creating the wallet by calling the CREATE2 function, which generates a smart contract address deterministically using the EOA address that triggered the smart contract creation, a salt, and the initCode. This delays gas payment for wallet creation until the user conducts their first transaction, thereby improving user experience.

Wallet Factories have additional responsibilities as well. Similar to Paymaster, they need to stake ETH on the Entry Point Contract and keep a good track record of serving UserOperations, in order to generate more traffic from Bundlers.

7. Signature Aggregator

Because different smart contract wallets use different signature schemes, it’s essential to aggregate UserOperations with the same scheme for separate validations. Besides, because on chain cryptographic arithmetic can be gas intensive, signature schemes that support aggregation such as BLS can help save gas during on chain validation. These considerations require another EIP 4337 interface called Signature Aggregator, which is essentially a smart contract that supports a specific signature scheme by implementing two functions:

• aggregateSignatures: takes an array of UserOperations and returns an aggregated signature using a specific scheme

• validateSignatures: takes an array of UserOperations and the aggregated signatures

Instead of validating one UserOperation at a time, Bundlers will first generate multiple aggregated signatures (one for each signature scheme) using multiple Aggregator contracts (one for each signature scheme). Then, the Bundler passes UserOperation arrays, aggregated signatures, and Aggregator addresses to the Entry Point Contract, which calls each Aggregator’s validateSignature function. Once validated, the Bundler executes UserOperations on smart contract wallets.

Similar to Paymasters and Wallet Factories, Aggregators need to stake on the Entry Point Contract as well and keep a good track record of serving UserOperations.

Figure: Signature Aggregator interface by official EIP 4337 doc

8. Overall Workflow Summary

The modular design of EIP 4337 splits the account abstraction features of smart contract wallets to multiple interfaces. However, they are simply moving pieces in one giant work flow summarized below:

• User sends a UserOperation to Bundler

• If UserOperation contains an initCode field, Bundler triggers Wallet Factory (through the Entry Point Contract) to create a new wallet deterministically

• If UserOperation contains a paymasterAndData field, Bundler collects gas payment from Paymaster’s stake on Entry Point Contract. If not, Bundler collects gas payment from smart contract wallet’s stake on Entry Point Contract

• Bundler can elect to aggregate signatures

• Bundler will simulate UserOperation off chain using a combination of validateOp, validatePaymasterOp, or validateSignatures functions

• If off chain simulation passes, Bundler validates UserOperation on chain using a combination of the functions above

• If on chain validation passes, Bundler executes UserOperation on chain, and collects gas payment whether execution succeeds or not

Figure: account abstraction workflow without Signature Aggregator (credit to Alchemy)

Figure: account abstraction workflow with Signature Aggregator (credit to Alchemy)

9. Other Considerations

Because UserOperation is validated both off chain and on chain, to prevent inconsistent validation results due to changing contexts, EIP 4337 restricts access to storage and OpCodes that read the global state such as the timestamp. This restriction applies to validateOp, validatePaymasterOp, and validateSignatures functions.

Part 2: Account Abstraction Market Players

1. Smart Contract Wallet with SDK

Smart contract wallets are the most obvious players in the account abstraction wallet. To be compatible with EIP 4337, they often implement their own Bundler, Paymaster, Wallet Factory, and Signature Aggregator. These wallets also come with SDKs for dApp integration. The market is relatively crowded, with existing players such as Gnosis Safe implementing additional account abstraction features, and new players such as Candide building a new smart contract wallet. This section will introduce the common features of these wallets and minor differentiating points within each feature.

a. Social Login and Social Recovery

Social login provides a very familiar Web2 feel for smart contract wallets, such as creating and logging in a wallet with an existing Google account. The same extends to social recovery as well, such as resetting the password of a smart contract wallet using a recovery email. Social login and social recovery logics are defined in the wallet’s main contract.

Here we introduce the concept of Guardian, which refers to the entities that grant access to or helps recover an account, whether a Web2 login or an email address. This concept was well developed in Web2 and now comes to smart contract wallets as well thanks to account abstraction.

There can be multiple Guardians for one smart contract wallet. User needs to set up the Guardians during or after wallet creation and reach a certain threshold of Guardian authentications, such as 2 out of 3 Guardians, in order to login or recover a wallet. This process is familiarly termed as multi factor authentication. Here are the common types of smart contract wallet Guardians:

• Web2 service provider: such as your social media account, usually achieved by implementing the OAuth (Open Authorization) standard, which allows the wallet to access login information hosted by another Web2 app on behalf of the user

• User device: such as browser storage and mobile storage

• Email: such as sending a signature by clicking an authorization email link

• Multisig: user can set up multiple EOA or smart contract wallet controlled by trusted individuals as Guardians

• MPC: user can split private key into shares, each controlled by a node in an MPC network without revealing the full key

• SWIE (Sign-In With Ethereum)

Let’s see a few market players’ implementations:

• Web3Auth is a social login and MPC service used by many notable smart contract wallets including Biconomy, Etherspot, and 0xPass. Web3Auth splits and secures user key shares under social login, user device, and their MPC node network. The implementation is entirely off-chain, and no party stores the full private key. (See figure below.)

• BLS Wallet and Argent allow social key recovery with nominated EOA addresses using Multisig.

• UniPass implemented an innovative approach that uses email for social recovery. Guardian’s email is submitted on-chain and its DKIM signature is verified on chain using a smart contract. DKIM, or Domain Keys Identified Mail, is an email authentication protocol that creates a digital signature that mailbox providers use to verify the identity of an email sender. UniPass also uses zk proofs to desensitize user information on chain. Other non-email social recovery methods are also supported.

• Soul Wallet verifies Guardian’s email on chain for social recovery.

Figure: social login and social recovery by Web3Auth with multiple guardians

b. Gas Abstraction

Gas abstraction refers to sponsored gasless transaction or gas payment in arbitrary ERC20 tokens. The logics can be implemented in a Paymaster contract or through Relayers.

Many smart contract wallets implement their own EIP 4337 compatible Paymaster contract and stake tokens on the Entry Point Contract to handle gas payments on behalf of users.

Relayer is another gas abstraction solution that exists before EIP 4337. Relayers are trusted forwarders that execute a special type of gasless transactions called “meta transactions”. A meta transaction is an Ethereum transaction that inserts another transaction in the original one. The user signs it using their private key and sends it to the Relayer, which verifies it, submits it to the blockchain, and handles the fee. The Relayer only executes the transaction without changing it. Relayers are economically incentivized, as they charge the transaction’s recipient contract the gas payment plus a small fee. For example, Relayer can charge a dApp which sponsors gas fees for its users. Relayers can be centralized trusted parties, or a decentralized network. Relayers are different from Paymasters in the following ways:

• Besides paying gas, Relayers also sign transactions, similar to what a Bundler does in EIP 4337

• Relayers don’t exclusively handle UserOperations

• Relayers don’t stake gas payments on Entry Point Contract

Let’s see a few market players’ implementations:

• Biconomy has not only its own EIP 4337 compatible Paymaster, but also a Relayer network that handles ERC20 gas payments.

• Argent uses third party Relayer to pay gas fees in the form of meta transactions.

• Candide has its own Paymaster implementation

• UniPass uses its own Relayer node to pay gas fees. It plans to add a “watch ad for free transaction” mode and to support gas payment using bridge in the future.

So far, most ERC20 gas abstraction solutions, such as Candide and Soul Wallet, only support very limited token types, mostly stablecoins, though I foresee that this will change in the future.

Figure: Biconomy supporting gasless transactions using Paymaster (EIP 4337 implementation)

Figure: Biconomy paying gas in ERC20 token using Relayer (non-EIP 4337 implementation)

c. Ramps and Bridges

Fiat on and off ramps and bridges are already natively integrated in many existing wallets such as MetaMask, through third party partnerships. Integrating these with gas abstraction into one click gas payment solutions is super exciting.

Let’s see a few market players’ implementations:

• Biconomy and 0xPass partner with Transak to provide fiat ramps. Biconomy also offers multi-chain bridge and messaging.

• Argent Vault partners with Moonpay, Transak, and Wyre for fiat ramps and also has a built-in DeFi protocol aggregator.

• Etherspot, UniPass, and Braavos support fiat ramps, swaps, and bridges.

d. Transaction Batching

Transaction batching is a feature uniquely enabled by smart contract wallets, allowing wallet user to perform multiple transactions in one single on-chain transaction. One implementation is by calling a multiCall function which takes an array of calldata and an array of contract addresses corresponding to multiple function calls. The multiCall function loops through the arrays and executes multiple function calls in one transaction. Transaction batching helps reduce the fixed gas cost per Ethereum transaction.

Note that transaction batching is different from signature aggregation, which takes an array of UserOperations and returns an aggregated signature for faster validation. Here, each UserOperation can perform a multiCall that performs transaction batching.

In the context of EIP 4337, the Entry Point Contract will call the handleOp function, which calls the multiCall function defined by a smart contract wallet.

Let’s see a few market players’ implementations:

• Biconomy sets up a multi-call contract which smart contract wallets will call and batch execute functions.

• Argent performs transaction batching through a smart contract module called Transaction Manager that enables multi-call and user sessions.

• Etherspot, Candide, Openfort, and 0xpass all support transaction batching.

Figure: example MultiCall contract (credit to Solidity by Example)

e. Modular Design of Smart Contract Wallet

One major advantage of smart contract wallet over EOA is its modular design. The wallet’s functionalities can be extended by pluggable contract modules developed by wallet provider. These modules offer features that are not defined in EIP 4337’s interfaces, and can be customized by users. The modular design makes smart contract wallets upgradeable, and is an industry standard practice before EIP 4337 came out, pioneered by products such as Gnosis Safe, a multisig wallet mainly targeting business users. Non EIP 4337 features offered by Gnosis Safe include:

• Spending policies: Limit the amount that a signing account can withdraw from a Safe.

• Scheduled transactions: Automatically execute transactions on a schedule.

• Roles and Permissions: Set fine grain rules on what types of actions specific accounts can perform.

• Hierarchies: Different permission sets based on roles within an organization.

• Allow and deny lists

The same modular design has been inherited by EIP 4337 compatible wallets, including Argent, Candide, Soul Wallet, and zeroDev.

Another way of extending a smart contract wallet’s functionality is by natively integrating dApps. For example, Gnosis Safe provides an SDK for dApps to directly appear in the wallet interface, essentially providing a built-in App store for the wallet. Other similar solutions include WalletConnect. These, however, are not protocol level designs, and are therefore out of our scope.

Figure: Candide Wallet’s modular design is similar to Safe’s (prev. Gnosis Safe)

2. Infrastructure Providers

I will talk about support for account abstraction on various Layer 2s and pure-play infrastructure providers of Bundlers and Paymasters.

a. Account Abstraction on Layer 2s

Given the recent explosion of L2, many smart contract wallets have pivoted development efforts towards L2, many of which have native support for account abstraction adapted from EIP 4337 that this section will explore.

Optimism

The first version of Optimism implemented account abstraction by introducing three OVM OpCodes that aren’t in EVM. In practice, the only type of account is a smart contract (no EOAs) and all user wallets are smart contract wallets. Smart contract wallets are also upgradeable by sending a transaction that calls an upgrade function.

Unfortunately, these features were removed in their second version in order to be identical to the EVM and due to security concerns.

Although a handful of smart contract wallets are building on Optimism, there’s no official announcement for account abstraction support yet.

Arbitrum

Although a handful of smart contract wallets are building on Arbitrum, there’s no official announcement for account abstraction support yet.

Starknet

Unlike Ethereum, Starknet doesn’t distinguish between EOA and contract account. Therefore, all Starknet accounts are smart contract accounts. Starknet’s account model is heavily influenced by EIP 4337 in the following ways:

• All Starknet accounts must include validate and execution functions. validate is required, so that only account owners can initiate transactions and that transaction executors are guaranteed gas payments. Users can implement arbitrary logics in validate and execute functions for full flexibility of their account. For example, different signature schemes can be implemented in the validate function.

• Starknet restricts validate from calling external contracts, to prevent scenarios where a transaction passes validation but not execution.

There are notable implementation differences from Ethereum, though:

• Starknet doesn’t distinguish between regular transactions and UserOperations, because all transactions are triggered by contract accounts. In Ethereum, Bundlers execute UserOperation transactions, whereas in Starknet, sequencers execute all transactions.

• Starknet has yet to implement a native gas abstraction protocol like Paymaster.

• Starknet requires an existing funded account to call a special deploy_account transaction in order to create a new contract account. In EIP 4337, contract account is deployed by executing a UserOperation transaction with the initCode field and the deployment doesn’t require a funded contract account, because gas payment can be sponsored by a Paymaster.

• If a validated transaction fails at the execution step, sequencer won’t be reimbursed for gas payment. Ethereum doesn’t have this problem.

Figure: Starknet doesn’t have EOA account type, only contract accounts

zkSync

zkSync also doesn’t distinguish between EOA and contract account and therefore natively supports account abstraction. zkSync’s account model is similar to EIP 4337 in the following ways:

• The Account (smart contract wallet) interface separates validateTransaction and executeTransaction functions.

• The Paymaster interface includes validateAndPayForPaymasterTransaction and postOp functions. The former defines a Paymaster’s arbitrary logic for sponsoring transactions. The latter will ensure that Paymaster is refunded with gas payment after transaction execution, though this is not implemented yet.

• A transaction invokes Paymaster by filling in the paymaster address field and the paymasterInput field, similar to EIP 4337’s UserOperation.

There are notable implementation differences, however:

• In validateTransaction, zkSync allows OpCodes for calling deployed contracts, which are immutable on zkSync. Ethereum restricts these to prevent changing contexts between transaction validation and execution

• validateTransaction is allowed to access external storage associated with the contract account that calls the transaction, such as the contract account’s token balance

• Paymaster has no external storage restriction during transaction validation

b. Pure Play Infrastructure Providers

As elaborated above, account abstraction infrastructures include client SDKs that can send UserOperations, Bundlers, Paymasters, and Signature Aggregators. These infrastructures are commonly implemented by smart contract wallets themselves to achieve vertical integration, but are mostly not designed for third party use. That’s why there exists pure play third party infrastructure providers of modular and customizable Bundler and Paymaster services, including notable infrastructure players such as Alchemy. This section lists a few of them.

Stackup

Stackup is a Bundler and Paymaster provider. Its Bundler is implemented in Go, passes all EIP 4377 test suite requirements, and is fully open-source and free to use. Stackup Bundler supports different modes:

• Private mode: UserOperations enter a private mempool, which trades off slower transaction execution for better privacy. UserOperation won’t be displayed in a public mempool, thereby avoiding MEV.

• Searcher mode: used by Ethereum bot operators (called searchers) and integrates with block builders like Flashbot to send UserOperations via MEV-Boost, which allows searchers to bid bundles of ordered transactions for block builder to include in a block.

Stackup also supports two types of Paymasters:

• Verification Paymaster: provides gas abstraction linked to an off-chain process such as fiat ramps. For example, a user can elect to pay gas fee using credit card or a subscription service. Users can define their own logics for gas sponsorship. Stackup will charge users based on a “pay as you go” model.

• Deposit Paymaster: allows user to pay gas in ERC20 token.

Figure: Stackup’s infrastructure product suite

Blocknative

Blocknative is primarily a provider of mempool explorer and visualization tools. Consistent with its mempool expertise, Blocknative offers a Bundler service with unique features such as:

• Visualize UserOperations moving through the mempool using a “EIP 4337 UserOps Explorer”

• Blocknative’s core product, the mempool explorer, can also monitor for pending and confirmed Bundler transactions going through the Entry Point Contract

Alchemy

Alchemy is currently developing its Bundler and Paymaster services, which are available for early sign ups.

Figure: Alchemy’s EIP 4337 infrastructure service open for early access

eth-infinitism

eth-infinitism, an official Ethereum Foundation team, provides Bundler and Paymaster implementations. There are little documentations about the team, but they provide one of the two Bundlers (the other one being Stackup) that passed EIP 4337’s official test suites as of February 2023 according to an article by Stackup.

Part 3: What’s the way forward for account abstraction?

1. At the End of the Day, It’s a Game of Adoption, an Incredibly Early One As Well

According to a recent research article by Web3Caff Research, the total number of unique from address in all Ethereum transaction is ~150 million. However, the total number of smart contract wallets, proxied as the sum of Gnosis Safe and Argent accounts, the two most famous products, is only 150 thousand.

Assuming that there will be an equal number of EOA and smart contract wallet at the end game, we see a 1000x market size potential for smart contract wallets. That said, the path to adoption won’t be a smooth one. Incumbent giants like MetaMask still haven’t announced plans to adopt EIP 4337. While we don’t know their intention, it’s not hard to deduce that profit from mainstream EOA wallets doesn’t justify adopting a new standard whose infrastructures are still budding. UserOperation** still isn’t a mainstream transaction type used by dApps, though I do foresee that smart contract wallets will grow exponentially due to great user experience improvement.

2. EIP 4337 Still Isn’t Finalized

Although EIP 4337 defined the high level interfaces of infrastructures like Bundler, Paymaster, and Signature Aggregator, there are still adjacent problems not covered by official interfaces and would require implementations to battle test different solutions, such as:

• Current Bundler implementations mostly work with private mempools, where UserOperation Bundlers are relayed directly to specific Block Builders. Will public or P2P mempool be possible for the Bundler network?

• Can Bundler extract MEV by ordering UserOperations? Can Block Builders extract MEV by ordering bundles? How will MEV be distributed between Bundler and Block Builders? Should we prefer separating Bundler and Block Builder?

• Can Bundlers be reliable Block Builders, given the vast amount of simulation and validation work they need to do?

• Will UserOperation succeed at validation but fail at execution due to state conflicts with regular transactions? How would UserOperation and regular transaction mempools coordinate to avoid conflicts?

3. L2s Are at Various Speed of EIP 4337 Adoption

Although zkSync and Starknet are already natively supporting account abstraction, they still haven’t finished implementing all EIP 4337 interfaces and have diverged from Ethereum’s implementation. While many project teams are building smart contract wallets, Bundlers, and Paymasters for Optimism and Arbitrum, these L2s haven’t announced official EIP 4337 integration roadmaps and account abstraction hasn’t been their development focus.

From a purely technical stand point, L2 account abstraction infrastructure can be more complicated to implement. For example, an L2 smart contract wallet will need to estimate and divide both L1 and L2 gas fees among a bundle of UserOperations during the validation step.

4. Technicalities Aside, What Makes a Great Smart Contract Wallet?

Despite the great number of innovative features (gas abstraction, social recovery, MPC, and etc.), most smart contract wallets support all of the features, because their implementation aren’t technically difficult. Therefore, the business side of smart contract wallets, or wallets in general, matter as much as the user experience side. Important business factors include:

• dApps partnership: partnering with the top dApps of each L1 or L2 chain, especially infrastructure-type ones such as stablecoin or DeFi protocols, is a major way to onboard users

• Utility features: such as integrated NFT market place, launchpad, or quick integration of new trading pairs

• External backing: such as VC or official support from Ethereum Foundation, which can help a wallet find its first batch of users

5. What Makes a Great Bundler Service Provider?

Permissionless and modular Bundler service is a public good. It’s non-excludable and non-rivalrous due to its open source nature. Any RPC end point can run the service by forking an implementation. Even if the RPC end point charges service usage using an API key, it’s harder to run a Bundler service as profitably as other infrastructures such as Paymaster, which can easily charge a fee spread by partnering with a third party fiat ramp or DeFi protocol provider. However, Bundler is an important public good that diversifies Ethereum’s UserOperation transaction entry points. Because Stackup and eth-infinitism are the only two functional third party non-wallet Bundler service providers, we definitely need more of them.

There are many technical barriers a Bundler service provider needs to overcome:

• Heavy research on multiple off chain and on chain validation steps, to make sure a UserOperation can get executed. One difficulty is understanding the potential state conflicts among multiple UserOperations.

• Understanding OpCode bans:

  • Because reading changing external states can cause successful validation but failed execution, some OpCodes that read external contexts are banned by EIP 4337.

  • Different L2s can implement slightly different bans, which is hard to navigate through.

  • Bundler builder needs to call the traceCall function to get the OpCodes that are called by each function. However, most third party RPC end points don’t support traceCall. Therefore, Bundler builders might need to set up their own nodes, a technically intensive step.

• Most Bundler services are focusing on L2, which requires the difficult step of estimating gas fee on both L1 and L2.

• Implementing a P2P gossiping network for private and public mempools. The private mempool requires customization for searchers and dApps, such as whitelisting. The public UserOperation mempool standard is still not completed.

What are the differentiating factors for Bundler service providers:

• Is the service built specifically for a wallet or by a pure play infrastructure provider

  • Bundler is only one out of many things a wallet provider needs to build, so they are more likely to focus on building a minimal viable Bundler that’s only used by the wallet.

  • Pure play infrastructure providers need to focus on building permissionless and modular Bundlers that provide stellar service in all contexts.

• Similar to Ethereum nodes, Bundler services are implemented in different languages, and Bundler diversity is good for the ecosystem by preventing single points of failure.

• Support for private and public mempools and level of customization allowed for private mempool.

• Support for L1 and L2 chains, each with slightly different interface implementation requirements.

6. Let’s Talk About Innovation

This session will list the most needed innovations in smart contract wallet and account abstraction infrastructure.

Permissionless and Modular EIP 4337 Infrastructure

To picture the end game of EIP 4337 infrastructure:

• Many providers of Bundlers, Paymaster, and Signature Aggregators compete for the lowest fees in an open market

• There will be a mixture of publicly exposed Bundler, Paymaster, and Signature Aggregators end points, as well as specialized ones deployed just for a single smart contract wallet or dApp

• Smart contract wallets, dApps, and individual users can deploy these infrastructures in a permissionless, modular, and user friendly way, i.e. there will be infrastructure providers that allow easy and customizable deployment of Bundler, Paymaster, and Signature Aggregator from arbitrary addresses

At the current market state, many smart contract wallets have already built out their own infrastructures that are not designed for third party use. Pure play infrastructure providers such as Stackup are working on modular Bundlers and Paymasters. However, the deployment process is still far from permissionless. With EIP 4337 still in the shift, the modular features of these infrastructures are not fully defined yet. Besides, given the low volume of UserOperation transactions, Signature Aggregator enabled wallets such as BLS Wallet are still not the mainstream.

Adjacent EIP 4337 Infrastructures

These include infrastructures not defined in EIP 4337 but are required by EIP 4337 infrastructures: for example, fiat ramp aggregators and DeFi aggregators that can be integrated to Paymasters. Because these solutions already exist, innovations will most likely happen within existing providers, by simply redefining their exposed end points.

dApp SDKs and Scaffolding

While existing smart contract wallets all built out their own client SDKs for dApp integration, there still lacks:

• Standard libraries such as ether.js for dApp development, except that account abstraction features are also enabled. For example:

  • Wallet creation and social recovery using Web2 social media account and email

  • Creating, signing, sending, as well as the event handling of UserOperations

  • Quick deployment of Paymaster and Signature Aggregator

• SDKs and UI tools that aggregate all major smart contract wallets

• Scaffolding tools for quick front end deployment, so that dApp developers can focus on the business logics of their products

• Templates for new types of dApps empowered by account abstraction, such as gas abstracted free-to-play games

Something More Radical: Decoupling Account from Smart Contract Wallet

EIP 4337’s smart contract wallet interface only requires a validateOp function, leaving all core logics, such as user registration, access control, and social recovery, to the wallet developer’s free will. While this grants more flexibility, different smart contract wallets can become walled gardens where one can’t easily port data from one to the other. dApps could also exacerbate this division by supporting some smart contract wallets but not others.

Besides, although users can log in smart contract wallets using familiar Web2 flow using credentials like their email, they still need to go through unfamiliar user flow like “connect wallet” to log in dApps.

One radical solution to these problems is to decouple user’s account from smart contract wallet, by creating a new account standard, such as EIP 6662 advocated by Hexlink. EIP 6662 defines an IAccountMetadata interface, where users can customize their own authentication methods, thereby moving authentication from wallet contract logics to a separate account interface. Smart contract wallets supporting this interface can allow users to easily port their account data to another wallet. dApps supporting this interface can allow users to log in their Web3 account using Web2 credentials defined in the account layer. dApp can verify a signature from a Web2 credential, look up the Web3 account address, push a notification to the account, and get connected to the Web3 account. Users don’t need to create different wallets for different dApps. Rather, dApps are automatically connected to users’ Web3 accounts linked to their Web2 credentials. Users are no longer tied to wallets. Rather, wallets become essentially dApps that users can log in for their asset management functionalities.

Conclusion

• EIP 4337 standardizes smart contract wallets and their related infrastructures into six standardized interfaces: the smart contract wallet itself, Bundler, Entry Point Contract, Paymaster, Wallet Factory, and Signature Aggregator. UserOperation is the new transaction type supported by EIP 4337.

• There are two types of players in the account abstraction market:

  • Smart contract wallets with features including social login, social recovery, gas abstraction, transaction batching, as well as integration and aggregation of third party services such as fiat ramps and DeFi protocols.

  • Pure play providers of infrastructures such as Bundler and Paymaster, focused on modular design.

• Given similar features offered and low technical barrier, smart contract wallet is a very competitive market. Bundlers are hard-to-profit but important public goods that we need more of to diversify the execution of UserOperation. With adoption still very low, EIP 4337 incomplete, and many L2s yet to announce any integration plans, account abstraction is still an early market, with many needed innovations such as: permissionless and modular infrastructures, integration with existing fiat and DeFi services, dApp SDKs, and a potential separate account layer.

References

https://ethereum.org/en/roadmap/account-abstraction/

https://eips.ethereum.org/EIPS/eip-4337

https://antalphaventures.notion.site/2edc5e36f69a44fe9a27dad0ef6ac3fb?v=a0fad60e889a4b2f831a2349d92ca11b

https://www.stackup.sh/blog/a-guide-to-the-top-erc-4337-bundlers-features-performance-and-more

https://github.com/PaymagicXYZ/awesome-account-abstraction

https://camiinthisthang.substack.com/p/account-abstraction-for-everyone

https://research.web3caff.com/zh/archives/4660

https://research.web3caff.com/zh/archives/3212

https://www.alchemy.com/blog/account-abstraction

https://www.alchemy.com/blog/account-abstraction-paymasters

https://www.alchemy.com/blog/account-abstraction-wallet-creation

https://www.alchemy.com/blog/account-abstraction-aggregate-signatures

https://docs.starknet.io/documentation/architecture_and_concepts/Account_Abstraction/approach/

https://era.zksync.io/docs/dev/developer-guides/aa.html#example-of-using-the-library

https://www.alchemy.com/account-abstraction

https://docs.zerodev.app/

https://eips.ethereum.org/EIPS/eip-4361

https://beta-docs.0xpass.io/

https://braavos.notion.site/Public-Docs-d98f625edb2e4399acab2e30d060ef8e

https://github.com/proofofsoulprotocol/soul-wallet-contract

https://docs.wallet.unipass.id/introduction/intro

https://docs.blocknative.com/4337-tools/blocknative-bundler

https://docs.candidewallet.com/develop/getting-started

https://docs.stackup.sh/docs/packages/bundler/introduction

https://github.com/web3well/bls-wallet

https://docs.etherspot.dev/