Alchemy [这篇博客](https://www.alchemy.com/blog/account-abstraction)关于账户抽象的实现写得清晰易懂，阅读的过程中顺便做了一些摘录和翻译（不一定准确）。
## Part 1: You Could Have Invented Account Abstraction
> 实际中存在的需求将一步步导向现在的 ERC-4337。账户抽象合约（钱包）实现了
创建一个保护资产的钱包：对于大多数资产，我们使用一个私钥签名；对于宝贵资产，希望使用第二个私钥签名。然而 EOA 始终允许使用一个私钥转移帐下资产，因此必须使用智能合约达到我们的目的，这种智能合约被称为钱包。
需要方法对这个智能合约发送命令，以便执行原本从 EOA 发出的任何转账和调用。所以这个钱包需要执行我们的 UserOperation。除了那些要传给 eth_sendTransaction 的参数，需要钱包来检查这些请求是否被授权，以决定是否执行这些操作。对于珍贵资产，需要传递每一个私钥进行签名的用户操作；此外，添加随机数来防止重播攻击。
*谁来调用这些钱包合约？* 尽管钱包合约可以安全地执行这些用户操作（因为需要用户的签名），但仍然需要一个角色去真正调用这个合约。Ethereum 中的所有交易都是由 EOA 发起的，并且需要支付 gas。我们只需要一个 EOA 支付 gas 并调用合约就好了。这个合约其实就是 ERC-4337 中的抽象账户。
*但我不想自己使用 EOA 来调用。* 为满足这点，钱包合约的执行方法应当允许任何人调用。这些执行者可能会获得一些 gas 费用的补偿。
*钱包未必真正退还执行者费用。* 执行者可能需要模拟，以观察自己是否真正得到偿还。然而模拟与实际仍然存在不同：俩个场景下的 storage 可能变化，且模拟无法读取 timestamp，blockhash，basefee 等操作码，这些是无法预测的。另一方面，我们不应该限制用户操作能够做什么。
*引入 EntryPoint 从受信任的合约运行代码。* 执行者在获得某些保证的情况下，运行不可信任的代码。EntryPoint 是经过审计的代码，其能保证：1）钱包有足够的资金支付最大 Gas 量；2）调用钱包的执行操作方法，跟踪其 gas 使用量；3）将钱包的 ETH 发送给执行者。为保证第三点，EntryPoint 需要持有 ETH 进行支付，因为未必能从钱包中提取 ETH；EntryPoint 还需要方法允许钱包存放和提取 ETH；
*执行与验证的分开。* 钱包执行时用户操作时，需要对操作进行验证。目前的实现中，钱包无论验证失败与否都向执行者付款；更合理的是，在钱包执行失败但验证成功时，向执行者支付 Gas。然而不诚实的钱包可以在验证阶段执行一切代码，而让执行过程直接失败：也就是说，它无需为执行付出 gas 费用。这里的危险在于，钱包无需为 validate 过程支付 gas，这容易产生作恶的机会。
*模拟再现。* 执行者在本地只需要模拟 validate 的部分，它更加严格，因为它只需要有限的操作：1）validate 的操作码不应该包含禁止列表中的操作码；2）访问的唯一存储是钱包的关联存储；更新钱包存储的成本足够组织破坏者。
*支付的改进。* 对 EOA 而言，用户使用 EOA 的储蓄来支付 gas，而不是存入到 EntryPoint；所以 validateOp 的方法应该引入付款参数，在验证时才提出支付 gas 的请求；这时 gas 应该设置为最大区块所允许的值，因为我们不知道这次调用消耗的具体数量。**但是将 ETH 发向任何合约会调用该合约中的代码。** 于是，我们使用拉动支付方式：1）优先使用 EntryPoint 中存入的 ETH；2）仅在存入 ETH 不足时，再请求从钱包中提取不足的 ETH。如此，我们始终不需要向钱包退回多余的 ETH。
*捆绑者。* 批量的这些操作，被捆绑在一起，由所谓的执行者执行——现在他们有了新名字：捆绑器。这些捆绑在一起的用户操作之间必须互不影响。它们执行模拟验证，并将这些捆绑交易提交给区块生成者。
## Part 2: Sponsoring Transactions Using Paymasters
> 账户抽象完全复制了 EOA 的功能，帮助用户实现转账等基础功能，并引入自定义的验证逻辑；但钱包合约仍然需要支付 Gas 费用，这意味着用户需要持有 ETH。
实际上，希望钱包所有者以外的人代替支付 Gas 费用，理由如下：
1. 对新手而言，获取 ETH 是一个门槛
2. Dapp 可能愿意为其潜在用户支付 Gas，而不是吓跑他们
3. 赞助人可能使用 ETH 以外的代币支付 Gas
4. 用户可能使用混币器提取资产，并将 Gas 费支付给与他们无关的账户
作为代付人，只想为特定的用户进行代付，这意味着我们需要一套逻辑进行验证。这类代付合约是 paymasater。
用户操作在 wallet 上执行时，且包含了 paymaster 地址时，将调用 paymaster 的 validatePaymasterOp，通过验证则在 paymaster 合约上执行操作。类似于 wallet，paymaster也需要向 EntryPoint 存入 ETH。
一个问题是，对于 paymaster 无法仅仅只是通过验证时的限制钱包存储，来达到防止验证失败的效果。因为同一个捆绑包中的不同的用户操作，可能要访问同一个 paymaster 的钱包存储。一个失败的 validatePaymasterOp 可以干扰其他所有使用同样 paymaster 的用户操作。
恶意的 Paymaster 可以使用 DoS 攻击系统。所以信誉系统在这里被引入并解决这个问题。跟踪 paymaster 的验证失败频率，限制或禁止用户操作使用该 paymaster。但如果恶意 paymaster 创建多个自身实例，则信用系统无法发挥作用。因此，paymaster 必须质押 ETH。
## Part3: Wallet Creation
传统方法中，EOA 发送包含合约部署代码但没有接受者的交易，以部署一个合约。但这显然不应该出现在账户抽象中，迄今为止的努力都是为了消除 EOA 存在的必要性。我们需要明确这点：用户想在没有 EOA 的情况下，通过支付 ETH 或者让 paymaster 代付来创建一个钱包（也就是账户抽象）。另一个隐藏的需求，对于 EOA，用户可以在不进行交易前就在本地得到自己的地址，因此希望钱包合约也拥有相同的属性。
通过 CREATE2 创建决定性合约地址，用户可以提交字节码到 EntryPoint 进行部署。但对于 Paymaster 而言（如果用户选择代付）它无法轻易验证字节码是否符合要求。因此，让用户直接调用 CREATE2 是不必要的，通过公开一种成为工厂的合约，以便用户创建不同类型的钱包合约。
对部署代码的验证类似于Paymaster遇到的问题，可以设置质押环节。
## Part4: Aggregate Signatures
目前而言的实现，验证捆绑中每个用户操作，这使得在检查签名方面会非常昂贵（需要许多加密算法）。如果只需要一个签名，而非多个签名验证这些操作，这会非常经济。聚合签名提供了这样一种能力：由多个不同密钥签名的消息生成一个组合签名，对组合签名的验证即可确保所有签名的有效性。
然而，并非同一个包中的所有用户操作都可以将签名聚合到一起，因为验证逻辑各异，所以可能有各种签名方案。
因此，一个捆绑包中最后会有多组操作，每组使用相同的聚合方案，或者根本不用聚合。每种聚合方案的合约称作 aggregator。钱包将决定其与哪些聚合器兼容。
## Difference from ERC-4337
ERC-4337 利用时戳可以预防 Bundler 将对某个操作停留很久后才将其打包。
Wallet 实际上没有执行方法，而仅仅实在用户操作里包含一个 callData，钱包可以定义其他方法；同样，工厂合约没有部署合约的方法，而是接受用户操作中的 iniitCode 字段的数据。
.
.