Account Abstraction账号抽象——EIP-4337提案

1. 引言

账号抽象这些年的衍化路径可参看：Account Abstraction Link Tree

账号抽象（Account Abstraction，AA）是以太坊开发者社区长期以来的梦想。不仅可使用EVM code来实现应用逻辑，还可使用EVM code来实现个人用户钱包的验证逻辑（nonces、签名等待）。这将为钱包设计的创意打开大门，钱包设计可以提供一些重要功能：

• 多签和社交恢复
• 更高效、简单的签名算法（如Schnorr、BLS）
• 抗量子安全的签名算法（如Lamport、Winternitz）
• 可升级性

在当今智能合约钱包中可实现以上所有功能，但是以太坊协议自身需要打包由EOA（externally-owned account）账号发起的交易内的所有信息 使得实现以上功能是困难的。由EOA将每个用户操作打包进交易，额外需要21000 gas开销。用户要么需要在不同的EOA账号中有ETH来支付gas，并管理2个账号的余额；要么需要依赖中心化的relay系统。

2020年提出的EIP-2938: Account Abstraction 为一种解决方案，需对以太坊协议进行调整，以执行层从合约发起交易，而不是仅支持从EOA发起交易。矿工可检查合约自身的验证和手续费支付逻辑，但是该方案需要对协议做大幅调整，且当时协议开发者在专注于merge和扩容。为此，2021年提出了新的提案EIP-4337：Account Abstraction via Entry Point Contract specification，实现相同目的的同时，无需在共识层进行调整。

开源代码实现见：

• https://github.com/eth-infinitism/account-abstraction（Solidity + TypeScript）

Entry Point合约已于2023年2月审计完成，具体见审计报告，当前已在以太坊主网、Goerli、Gnosis chain（以太坊侧链）上部署。

• https://etherscan.io/address/0x0576a174D229E3cFA37253523E645A78A0C91B57（老版本Entry Point合约，2个月前）
• https://etherscan.io/address/0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789（新版本，合约代码有小调整，2周前）

2. EIP-4337提案原理

EIP4337被视为智能合约钱包的一种演变。在高水平上，通过将所需的一些链上和链下基础设施交互，使在以太坊上编写和操作智能合约钱包变得更加简单。
使用EIP4337，用户不再制作交易。相反，用户将UserOperations发送到更高级别的mempool。Miner或bundler可以将一组UserOperation打包为一个bundle交易，该bundle交易被发送到EntryPoint合约以供执行。EntryPoint合约会编排这些UserOperation的正确执行，并确保Miner/Bundler获得适当的交易费用补偿。
使用EIP4337，任何开发者都可以用几行代码编写定制的智能合约钱包，而不必关心如何补贴交易费用。
与智能合约钱包一样，EIP4337旨在模拟AA，而无需对协议进行任何更改。但与智能合约钱包一样，EIP4337并没有摆脱EOA，基于EIP4337的钱包在以太坊上仍然是二等公民——很多Dapp不兼容智能合约钱包。

EntryPoint合约需实现的接口函数有：【EntryPoint合约必须被每个人信任。】

account合约需实现的接口有：

在EIP-4337：Account Abstraction via Entry Point Contract specification中，不修改共识层逻辑，而是在更高层系统中复制交易mempool功能——即实现“UserOperation mempool”。用户发送UserOperation对象，在UserOperation对象中打包了：

• 用户意图
• 签名
• 其它验证所需数据

当前UserOperation mempool通过独立的bundling client来实现，而不是在现有的以太坊节点之上做的实现，如：

• https://github.com/NethermindEth/AA_bundler（Go语言）
• https://github.com/eth-infinitism/bundler（TypeScript语言）
• https://github.com/stackup-wallet/stackup-bundler（Go语言）
• https://github.com/etherspot/skandha（TypeScript语言）

• miners或bundlers可使用服务（如Falshbot）来将一组UserOperation对象 打包进 单个“bundle transaction”中，这些“bundle transaction”会被包含在某个以太坊区块中。【注意：bundlers 为(either miners running special-purpose code, or users that can relay transactions to miners eg. through a bundle marketplace such as Flashbots) 】
• bundlers以ETH来支付“bundle transaction”的手续费，并从所有个人UserOperation支付的手续费中获得补偿。与矿工类似，bundlers可基于手续费优先逻辑，来选UserOperation对象。

UserOperation对象与交易类似，为ABI编码结构，包含的字段有：

• sender：执行该操作的钱包
• nonce和签名：传入到钱包验证函数的参数，这样钱包可验证该操作。
• initCode：若钱包不存在，为创建该钱包的初始代码。
• callData：实际执行时调用该钱包的数据。
• 剩下的字段与gas和fee管理有关。

额外增加了1个RPC方法：

• eth_sendUserOperation：eth_sendUserOperation submits a User Operation object to the User Operation pool of the client. The client MUST validate the UserOperation, and return a result accordingly.
  The result SHOULD be set to the userOpHash if and only if the request passed simulation and was accepted in the client’s User Operation pool. If the validation, simulation, or User Operation pool inclusion fails, result SHOULD NOT be returned. Rather, the client SHOULD return the failure reason.
  Parameters:

  1. UserOperation a full user-operation struct. All fields MUST be set as hex values. empty bytes block (e.g. empty initCode) MUST be set to "0x"
  2. EntryPoint the entrypoint address the request should be sent through. this MUST be one of the entry points returned by the supportedEntryPoints rpc call.

  Return value:

  • If the UserOperation is valid, the client MUST return the calculated userOpHash for it
  • in case of failure, MUST return an error result object, with code and message. The error code and message SHOULD be set as follows:
    • code: -32602 - invalid UserOperation struct/fields
    • code: -32500 - transaction rejected by entryPoint’s simulateValidation, during wallet creation or validation
      • The message field MUST be set to the FailedOp’s “AAxx” error message from the EntryPoint
    • code: -32501 - transaction rejected by paymaster’s validatePaymasterUserOp
      • The message field SHOULD be set to the revert message from the paymaster
      • The data field MUST contain a paymaster value
    • code: -32502 - transaction rejected because of opcode validation
    • code: -32503 - UserOperation out of time-range: either wallet or paymaster returned a time-range, and it is already expired (or will expire soon)
      • The data field SHOULD contain the validUntil and validAfter values
      • The data field SHOULD contain a paymaster value, if this error was triggered by the paymaster
    • code: -32504 - transaction rejected because paymaster (or signature aggregator) is throttled/banned
      • The data field SHOULD contain a paymaster or aggregator value, depending on the failed entity
    • code: -32505 - transaction rejected because paymaster (or signature aggregator) stake or unstake-delay is too low
      • The data field SHOULD contain a paymaster or aggregator value, depending on the failed entity
      • The data field SHOULD contain a minimumStake and minimumUnstakeDelay
    • code: -32506 - transaction rejected because wallet specified unsupported signature aggregator
      • The data field SHOULD contain an aggregator value
    • code: -32507 - transaction rejected because of wallet signature check failed (or paymaster signature, if the paymaster uses its data as signature)

如Request:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_sendUserOperation",
  "params": [
    {
      sender, // address
      nonce, // uint256
      initCode, // bytes
      callData, // bytes
      callGasLimit, // uint256
      verificationGasLimit, // uint256
      preVerificationGas, // uint256
      maxFeePerGas, // uint256
      maxPriorityFeePerGas, // uint256
      paymasterAndData, // bytes
      signature // bytes
    },
    entryPoint // address
  ]
}

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x1234...5678"
}

钱包是一个智能合约，需有2个函数：

• validateUserOp()函数：以UserOperation为输入。该函数会验证UserOperation中的签名和nonce，若验证通过，支付手续费并递增nonce；若验证失败则抛出异常。
• UserOperation执行函数：将UserOperation中的callData解析为某指令供钱包行动。该函数如何解析Calldata，并对解析结果采取哪种行动是完全开放式的。最常用的情况是将Calldata解析为某指令，钱包据此来发起一次或多次call。

为简化钱包逻辑，确保许多复杂的智能合约安全所需的技巧不是在钱包自身中完成的，而是在一个称为entry point的全局合约中完成的。validateUserOp()函数 和 执行函数 需满足require(msg.sender == ENTRY_POINT)调用条件。即，仅trusted entry point可调用钱包执行某种action或支付手续费。entry point仅在UserOperation中的callData已执行成功时才调用钱包的validateUserOp()函数的，因此这样足以避免钱包遭受攻击。若钱包还不存在，entry point也会使用所提供的initCode来创建钱包。

entry point的控制流程为：

mempool nodes和bundlers需限制validateUserOp()函数的功能：

• validateUserOp()函数执行期间不能读写其它合约的storage；
• 不能使用如TIMESTAMP这样的环境opcodes。
• 不能调用其它合约，除非其它合约已证明不能sefl-destructing。

bundlers和UserOperation mempool nodes需要对validateUserOp()函数做仿真执行，确保指定的UserOperation可以包含或forward，即若未来实际包含在某区块内，具有相同的效果。

若某UserOperation验证已仿真成功，则在sender账号有某些其它内部状态变化之前，可UserOperation都可被打包。sender账号的内部状态变化可源自：

• 同一sender的另一UserOperation，
• 或者 其它合约调用该sender。

无论是哪种情况，为一个合约触发该情况需要在链上花费7500+ gas。此外，UserOperation中定义了validateUserOp() step的gas上限。除非该上限值很小（如低于20万），否则mempool nodes和bundlers可拒绝该UserOperation。这些限制赋值了现有以太坊交易的关键属性，以保证mempool的对DOS攻击的安全性。bundlers和mempool nodes可使用当今以太坊交易处理逻辑类似的逻辑来决定是否将某UserOperation包含或forward。

3. EIP-4337提案的优缺点

与常规以太坊交易mempool相比， EIP-4337提案的“UserOperation mempool”维护的属性有：

• 无中心化角色：所有都是通过peer-to-peer mempool来实现的。
• DoS safe：除非sender发生了状态变化，每个通过了模拟检查的UserOperation都可确保被打包。若要改变sender状态，攻击者需为每个sender支付7500+的gas。
• 无用户端的设置钱包的复杂性：用户无需关心其钱包是否已发布，钱包存在于确定性的CREATE2地址，若在首次UserOperation时钱包不存在，则会自动创建。
• 完全支持EIP-1559：包括简化手续费设置（用户可设置一个固定手续附加费 和 一个高的最大总手续费，并希望被快速打包并合理收费）
• 支持replace-by-fee：以比老UserOperation更高的手续附加费来发送新的UserOperation，可替换老的UserOperation或以更快的速度被打包。

与常规以太坊交易mempool相比， EIP-4337提案的“UserOperation mempool”具有的新优势：

• 验证逻辑灵活：validateUserOp()函数可增加任意的签名和nonce验证逻辑（新的签名方案、多签等等）
• 足以让执行层quantum-safe：若EIP-4337提案被广泛采用，则在执行层无需做任何操作来实现quantum-safe。用户可将其钱包独立升级为quantum-safe。甚至miner可为每个bundle交易使用新创建的哈希保护的EOA，且在该bundle交易添加到区块内之前不发布该交易，这样wrapper交易是安全的，
• 钱包可升级性：钱包验证逻辑是stateful（有状态的），因此钱包可修改公钥或（若已DELEGATECALL发布）总体升级code。
• 执行逻辑灵活：钱包可在执行层添加自定义逻辑，如做原子式多个操作 （为EIP-3074: AUTH and AUTHCALL opcodes的目标）

与常规以太坊交易mempool相比， EIP-4337提案的“UserOperation mempool”的弱点有：

• 稍微增加了DoS脆弱性：因验证逻辑比现有的单个ECDSA验签更复杂。
• gas开销：比常规交易的gas开销更高（在支持多操作方面能有所弥补）
• 一次一笔交易：账号无法排序并将多笔交易发送到mempool。但是其支持原子式多操作，这个特性也就没那么必要了。

4. 通过paymaster来赞助交易

赞助交易有一些关键用户场景，最常见的为：

• 1）支持应用开发者为其用户支付手续费。
• 2）支持用户以ERC20 token来支付手续费，借助某个作为中间商的合约来收集ECR20并以ETH支付手续费。

EIP-4337提案通过内置的paymaster机制来支持赞助交易。UserOperation可设置另一地址作为其paymaster，若已设置了paymaster（即为非零值），则在验证环节时，entry point还会调用paymaster来验证paymaster愿意为该UserOperation支付手续费。若愿意，则将从paymaster质押 entry point（为安全，取款有延迟）内的ETH 支出手续费，而不是从钱包中支出手续费。在执行环境，会正常以UserOperation中的callData来调用钱包，但之后，会以postOp来调用paymaster。

以上2个用户场景的示例流程为：

• paymaster验证paymasterData包含源自sponsor的签名，验证该sponsor愿意为该UserOperation支付手续费。若签名有效，则paymaster接受且UserOperation的手续费由sponsor的质押支付。
• paymaster验证sender钱包又足够的ERC20余额来支付UserOperation。若有，则paymaster接受且支付ETH手扶箱，然后在postOp中claims the ERC20 tokens作为补偿（若因UserOperation耗尽了该ERC20余额导致postOp失败，则执行将revert并再次调用postOp，使得paymaster总是能get paid）。注意迄今为止，仅当ERC20为paymaster所管理的wrapper token时，才可实现该功能。

特别要注意的是，在第二种情况下，paymaster可以是纯粹被动的，也许偶尔会进行rebalancing和参数重新设置。与现有的赞助尝试相比，这是一个巨大的改进，后者要求paymaster始终在线，以积极wrap个人交易。

5. L2的原生抽象账号实现

当前StarkNet和zkSync等L2扩容方案，都宣称将上线原生抽象账号实现。

账号抽象，将当前的one-account-fits-all（某人一旦有小错误，将失去一切），转换为，可根据需要定制账号。从而可构建自我监管的安全网，并提供更流畅的用户体验。
使得自我监管称为主流工作的一个可行选项，而替代seed phrase或中心化交易所的可怕世界。

以太坊有2类账号：

• 1）Externally Owned Accounts（EOA）： controlled by anyone with the private keys
• 2）Contract Accounts（CA）：a smart contract deployed to the network, controlled by code

EOA账号有3大属性：

• 1）账号可用的ETH余额
• 2）确保每笔交易唯一的nonce
• 3）在网络唯一表示该账号身份的地址

区块链的状态，也就是账户的状态，只能通过交易来修改。需由区块链外部的东西触发，因此在以太坊上，每笔交易都必须从EOA发起。这意味着，当以太坊虚拟机（EVM）执行交易时，第一个touched账号必须是EOA，相应的账号必须向矿工支付执行整笔交易的手续费。
以太坊上的每个账号都关联一个名为signer的密码学对象。sIgner，又名keypair，对应有2个密钥：

• 一个私钥：为秘密，用于签署数字消息。
• 一个公钥：用于验证相应私钥签署的签名。

以太坊采用基于Secp256k1曲线的ECDSA签名方案。EOA地址派生自signer的公钥，为公钥Keccak-256哈希值的后20个字节。
用户以私钥对其发起的交易进行签名，EVM收到交易和签名之后：

• 验证签名为目标账号的有效签名
• 验证交易nonce与账号nonce匹配
• 执行交易
• 从账号余额中扣除手续费

由此可知，以太坊账号有3个组件：

• 1）state状态：包含了余额和nonce
• 2）在EVM中应编码的逻辑：用于验证和执行账号发起的交易。明确定义了何为来自目标账号的有效签名。
• 3）address地址：账号通过地址与signer（keypair）紧耦合。

以太坊区块链设计的一个很重要的选择在于：

• 将 （the object holding your tokens）Account概念 与 （the object authorized to move these tokens）Signer概念 二者等同。

也就是说现有的以太坊账号设计是原罪：

若拥有某私钥，则自动就有用了相应地址的账号，为拥有某指定地址的账号，需拥有相应的私钥。整个逻辑已硬编码在EVM核心。

这种方案的优势在于易于理解且更易于实现，且更容易入门。从而对应有“Not your keys, not your coins!”这样的口号。

但是account与signer的这种耦合性，也会引入大量问题：

• 由于私钥即账号，丢失私钥即意味着丢失账号，以及账号内所有的token。

当前因私钥丢失或被盗，已损失数亿甚至数十亿美金。
当然，可通过硬件钱包、将私钥写在金属上并安全保存，这些早期方案，但是不具备扩展给数十亿用户使用。

而且若想使用不同于ECDSA的签名方案，或使用不同的椭圆曲线，如何来应对呢？量子计算机即将破解ECDSA。

相应的解决方案就是：

• 解耦 （the object holding your tokens）Account 与 （the object authorized to move these tokens）Signer
  

具体思路为：

• 将account以智能合约表示，在合约内实现何为有效交易的逻辑。仅需要遵循特定的接口方法来验证和执行交易。
  在计算机科学行话中，称该account已被抽象。因此有“account abstraction账号抽象”术语。

它不再是一one-account-fits-all-use-cases。相反，每个用户都可以拥有一个适合其需求的帐号：

• 是否要使用与ECDSA不同的签名方案？没问题，你可以为此写一个账号。
• 是否要使用多个密钥来授权交易？没问题，你可以为此写一个账号。
• 是否要每周更改帐号的signer？没问题，你可以为此写一个账号。

可能性是无限的，期待看到在支持账户抽象的链上（如StarkNet和zkSync 2.0）会出现什么新的用例。

当今很多自我监管的问题都源自EVM核心中硬编码的authorisation授权逻辑，（the object holding your tokens）Account 与 （the object authorized to move these tokens）Signer 二者存在紧耦合。当前以太坊的签名机制为ECDSA，椭圆曲线为Secp256k1。没有办法引入新的签名方案或者椭圆曲线。

而Account Abstraction账号抽象（AA）将 the object holding your tokens）Account 与 （the object authorized to move these tokens）Signer 二者解耦，通过将account实现为智能合约，使得authorisation授权逻辑可编程。借助AA，每个用户可部署和使用根据其需求定制的自定义授权逻辑的account。

原因有：

• 1）多个signer，从而可支持欺诈监控：检查每一笔交易，以确保其符合定义的安全规则，并防止用户将资产发送到欺诈地址或错误的合同。
  
  
  

• 2）具有不同椭圆曲线的不同签名方案：将签名方案更改为更简单、更gas高效的签名方案或抗量子的签名方案。甚至可以使用iOS和Android设备的安全飞地，将每部手机都变成硬件钱包。
  
  

• 3）社交恢复：在用户的私钥丢失或泄露的情况下，AA允许钱包添加机制来安全地替换控制帐号的密钥。再也不用担心seed phrases了！
  

• 4）游戏中的session key：无需反复多次调用钱包。
  
  

可能性是无限的.

在以太坊上实现完整的账户抽象并非易事，因为它需要对协议的核心进行多次更改。随着以太坊价值的增加，越来越难以协调和实施的变化。
这就是为什么尽管在2016年进行了讨论，并在2017年首次提出了以太坊改进提案（EIP），但AA至今仍未在以太坊上实施。这产生了我们不得不接受的所有戏剧性后果：以太坊上糟糕的用户体验，seed phrases继续困扰着每个人。
自2016年以来，已经提出了几种方法来引入AA的一些功能，同时要求对协议进行可接受的更改。可接受的意义是，更改足够小，可以在协议的下一个分叉时升级。
每一种较弱的AA形式都有其自身的局限性，值得注意的是，它们还没有被广泛采用。这就是推动在L2上广泛采用AA的原因之一。

5.1 StarkNet 抽象账号实现

其中：

• validate()函数：Sequencer会调用该函数来验证某交易。
• execute()函数：Sequencer会调用该函数来执行某交易。仔细看execute函数的参数可知，其支持Multicalls。
• is_valid_signature()函数：用于验证链下签名。

对于抽象账号开发者来说：

所谓multicalls是指：

• 用户仅需要签名一次
• 更好的用户体验（不需要多次approve然后call）
• 可节约大量gas（仅state diffs会推送到L1）

multicalls可用于：

• approve and call
• multi-send
• 游戏中的batch transactions

5.2 zkSync 抽象账号实现

zkSync 抽象账号示例见：

• https://github.com/matter-labs/custom-aa-tutorial【account合约需实现IAccount接口和（或）IPaymaster接口。】

IAccount接口有5个函数：

• 1）validateTransaction：是强制性的，系统将使用它来确定AA逻辑是否同意继续进行该交易。如果交易不被接受（例如签名错误），则应revert该方法。如果对此方法的调用成功，则认为实现的帐号逻辑接受了交易，系统将继续进行交易流。
• 2）executeTransaction：是强制性的，在向用户收取费用后，系统将调用它。此函数将进行交易的执行。
• 3）payForTransaction：是可选的，如果交易没有paymaster账户愿意为交易付费，则系统将调用它。该方法用于通过account支付费用。请注意，若你的帐户永远不会支付任何费用，并且始终依赖paymaster功能，则不必实现此方法。此方法必须至少bootloader系统合约地址发送tx.gasprice*tx.gasLimit个 ETH。
• 4）prepareForPaymaster是可选的，如果交易有paymaster，即有一个不同的地址为用户支付交易费用，则系统会调用它。该方法应该用于准备与paymaster的交互。其中一个值得注意的例子是approval paymaster的ERC-20代币。
• 5）executeTransactionFromOutside：从技术上讲，executeTransactionFromOutside不是强制性的，但强烈鼓励这样做，因在priority模式的情况下（例如，如果operator没有响应），需要有某种方式才能从“外部”从你的账户开始交易（基本上这是标准以太坊方法的fallback，EOA从你的智能合约开始交易）。

IAccount接口用于支持由他人代为支付手续费，有2个函数：

• 1）validateAndPayForPaymasterTransaction：是强制的，由系统用于判断该paymaster是否同意为该交易支付手续费。若paymaster愿意，则该方法会将tx.gasprice*tx.gasLimit个 ETH发送给operator。其返回的context中对应为调用postTransaction方法的一个参数。
• 2）postTransaction：是可选的。在交易执行之后被调用。不过zkSync中的实现不同于EIP4337，不保证该函数会被调用。特别是当交易失败原因为out of gas时，不会调用该函数。
  postTransaction函数具有4个参数：
  • validateAndPayForPaymasterTransaction返回的context参数
  • 交易自身
  • 交易执行是否成功的标记位
  • 返还给paymaster的最大gas量

每个区块链的一个重要的不变量在于每笔交易具有唯一的哈希值。任何抽象账号实现都应满足该潜在属性。尽管账号可接收多笔完全相同的交易，甚至这些交易根据区块链规则角度来看是有效的，若违背了交易哈希唯一性原则，则很难被indexers和其它工具处理。
任何抽象账号实现都应满足2个原则：

• 对用户来说是cheap的。
• 在存在malicious operator的情况下是强健的。

为让交易哈希不重复，要求交易中的（sender, nonce） pair具有唯一性。为此：

• 1）在开始处理交易时，系统查询NonceHolder系统合约，检查交易中所提供的nonce是否已使用。
• 2）若nonce暂未使用，运行交易验证，此时将交易所提供的nonce标记为“used”。
• 3）交易验证之后，系统检查该nonce是否已标记为used。

每笔交易需经过如下流程：

• 1）validation step：在Validation step时，account应决定是否接受该交易，若接受，则支付手续费。若验证的某个环节失败，则account不付费，该交易也不包含在某区块内。
  验证环节中包含以下步骤：
  • 1.1）Step 1：系统检查交易的nonce之前未使用。
  • 1.2）Step 2：系统调用account的validateTransaction函数，若未revert，则进入下一环节。
  • 1.3）Step 3：系统检查已将交易的该nonce已被标记为used。
  • 1.4）Step 4（no paymaster）：系统调用account的payForTransaction函数，若未被revert，则进入下一步。
  • 1.5）Step 4（paymaster）：系统调用sender的prepareForPaymaster函数，若该调用未被revert，然后调用paymaster的validateAndPayForPaymasterTransaction，若也未被revert，则进入下一步。
  • 1.6）Step 5：系统验证bootloader合约接收到了至少tx.gasPrice * tx.gasLimit个ETH。若该验证成功，则进入execution环节。
• 2）execution step：负责交易的实际执行并将未使用的gas返还给用户。若该环节有任何revert，该交易仍认为是有效的，且将包含在区块内。
  • 2.1）Step 6：系统调用account的executeTransaction函数。
  • 2.2）Step 7（仅当交易中有paymaster时）：调用paymaster的postTransaction函数。通常用于当以ERC-20 token支付手续费时，将未使用的gas返还给sender。

参考资料

[1] V神2021年9月博客 ERC 4337: account abstraction without Ethereum protocol changes
[2] 2023年 Unified ERC-4337 mempool
[3] 2022年3月Argent博客 Part I: WTF is Account Abstraction——Learn why it’s a game changer for crypto’s adoption
[4] 2022年9月Argent博客 Part 2: WTF is Account Abstraction——The challenges of bringing Account Abstraction to Ethereum
[5] 2022年10月Argent博客 Part 3I: WTF is Account Abstraction——Scaling the UX and security of crypto by 10X
[6] 2022年视频 Julien Niset Why account abstraction on L2 is critical for mass adoption
[7] zkSync Account abstraction multisig
[8] zkSync Account abstraction support
[9] 2022年博客 Random thoughts on Account Abstraction
[10] github Awesome Account Abstraction
[12] 2023年1月Stackup视频 What is EIP-4337?
[13] Eden Network 2023年4月28日博客 ERC-4337: Exploring the Technical Components of Account Abstraction — Part 2
[14] Lomads 2023年6月博客 Exploring the Use Cases of Account Abstraction