「AAStar: RIP7560 分析」内容回顾

背景

ERC、EIP 和 RIP：

ERC 是应用层的 proposal，EIP 是核心层的 proposal，RIP 是专指 Rollup 的 proposal。

Account Abstraction（简称 AA） 相关的知识是本文要了解的基础，例如 ERC4337 和一些最近的 AA 的文章。

在建设基于 ERC4337 构建 AA 的过程中，发现了许多的问题，不是一个 account 应该或者能够解决的问题，例如 layer1 和 layer2 的同步机制变化和改进，目前同步并不是双向和稳定可依赖的（在高层应用层面）；不同 layer2 上的一些合约层面的标准一致性，最明显的就是 factory 合约的支持和计算一致性；在一些算法甚至 EVM 层面的支持，例如对特定加密算法的 verify 支持等；在23年4月和 Vitalik 就一些 AA 问题沟通时，这个感觉就非常明显：我们在做钱包，为啥这么多依赖都要搞，感觉在搞 Layer1，Layer2 的核心共识改进了，这对一个钱包团队来说，难度太大了；而 RIP7560 是可能解决这些问题，提供更稳定，更低成本，更高效的 AA 支持，Native AA 可能是一个合适的解决方案，是 consensus-layer protocol changes。

关于 EIP2938:

EIP-2938^[1] 提出的账户抽象化（Account Abstraction, AA）是一个可以让合约账户成为和外部账户一样的「顶层」账户的提案。具体来说，这个方案要求对以太坊协议进行修改，并允许从合约（每个智能合约都有一个合约账户），而不仅仅是外部账户来发起以太坊交易。合约本身将具备验证和矿工需验证的 gas 费用支付逻辑。那么也就是说，实现了账户抽象化之后，合约账户也可以发起交互请求并支付交易费。

本文假设你有 ERC4337 的基础知识背景，可以看这里学习：https://www.erc4337.io/resources 。

7560 Proposal 核心

提议的人是 Alex Forshtat，4337 团队的作者之一，上来就是合并 2938（顶层账户）和 4337^[2] 为 7560。

最核心的一句话：

We propose splitting the Ethereum transaction scope into multiple steps: validations, execution,and post-transaction logic.
我们建议将以太坊交易范围分为多个步骤：验证、执行、和交易后逻辑。

Transaction validity is determined by the result of the validation steps of a transaction.
事务有效性由事务的验证步骤的结果决定。

这些带来的是整体事务复杂度的降低（后面有讨论）

相关变化：

1. 新增原生的 Transaction Type(AA_TX_TYPE)

• TransactionType4，简单说，这个交易类型是个原来多个交易记录的数组，也会增加一些原生字段（例如时间、触发条件？），这个最初是在 EIP2718^[3]，改进了交易数据结构，例如 AA_BASE_GAS_COST，整合了复杂计算？需要跟进；
• 添加了 tx counter header，类似于 utxo 里面的输入输出，对交易进行计数，分别跟踪和处理，提升了对批量事务的处理能力（内置了批量，原来做批量那些应用，发现可以直接使用 AA 能力，不用 dapp了）；
• 二维随机数，这个估计所有开发 AA 钱包的都有同感，都设计了这个机制，现在不用了，使用默认交易类型就支持；
• 独立给出了 builder fee，这个和 1599 里面记得也说过有 builder 的小费啊（不是 burn 那部分），check 下，据说这个可以更好的激励出块效率。

合约账户成为 Native 功能（2938 的核心）

• 参考上面

Paymaster 直接支付

1. 废除在 entrypoint pre-fund 方式存 gas，不用维护那个 mapping 了
2. 原来 4337 的需要自行升级，validatePaymasterUserOp 要变更（因为 tx 升级等）

Create

1. 兼容原理 4337 的 initcode 和 factory 模式
2. native 也会原生支持

更紧密的 Bundler

1. 出块节点为 bundler 提供专属的 api 访问权限（其实不如出块节点自己 run？）
2. 打包的直接沟通，nonce 改进（二维 nonce）

其他

1. 给出了一个 penalty，如果你「恶意」给出大量 gas，多处部分作为 builderfee，这个其实实际都会计算不准，换句话说，可能很多 paymaster 服务方会多支付，以前退款到预付款帐号，现在罚没给 builderfee，感觉有点问题。
2. 出发点是大家可以加价，但别乱加价？效果是都默认 +10%?每个块如果 full，记得下一个默认试试 10%。
3. RIP-7560 supports multiple execution frames within a single transaction，这句话讨论下，这个 frame 是说啥？一个交易可以有多个中间状态？因为复杂事务需要重试和回滚，所以就设置了多个frame来支持这个？这个和交易也密切相关，是一个交易的核心能力，需要深入看看。对于内置了事务能力，不用自己通过其他方式控制事务了？
4. validation 因为交易类型新增，包括验证也需要匹配交易的自定义签名（可能是非椭圆曲线签名？）？，适配 4337 之前的特性。
5. 聚合签名是 4337 的一个可选项，为的是提升批量交易的性能，降低 gas 和签名体积，提升验证效率，类似 BLS（validator 用的聚合签名）或者其他的聚合签名，目前预留了这部分接口，7560 提了但是没有深入。

解读

ERC-4337 Smart Accounts:
https://dune.com/niftytable/account-abstraction

1. 账户合约可以发起交易，代表获得了和 EOA 同样的「地位」，原来很多的绕远的实现方式，都可以避免，提升了 4337 的效率（兼容 4337）
2. 新 TX 类型实际是一个综合的 native 化，包括原来的一些问题，通过增加和支持新交易类型，来削减了原来基于 4337 的很多复杂交互，例如多笔交易的排序，并发交易的 nonce 支持；也降低了 gas，对于新交易类型，会和传统交易一样，进入 mempool 中。
3. 基本上主要是 4337 协议小组的人：Yoav，Dror，Vitalik，也有不认识的加入
4. 如果说逻辑上来看，4337 是尽力不改动核心层，加了一层外挂，那 7560 是把必要的（能大幅降低复杂度和成本，提升安全性的）功能，转移到了 ETH 的客户端（会影响 Layer1，Layer2）来支持和实现。
5. Native 肯定比 Hack 要更闭环、高效、丝滑、低成本和安全，简单说是 2938+4337—>native 化。
6. Bundler 看完个人理解是还会继续存在，但必要性我依然存疑，感觉长期看依然是合并到出块节点内，这个可以讨论和继续跟进，看 7560 是给了 bundler 一些 Builderfee（可以分析下如果上线，bundler 还值得做么？多少钱？是比原来降低还是高？这个态度感觉是为了照顾 4337 原来的面子，不一下子推翻，说兼容、无缝过度啥的，单实际上根本没有应用，只是在测试，99.999 的还是在 EOA，个人感觉（对比那点 AA4337 交易量就知道，308 万 AA 账户，比年度 5000 万 EOA 增量少太多，还是个孩子）。

Raw RIP read

源文^[4]这个是 RIP github 版本

略读一下，写下读后感

1. author Kristof 木有了（Pimlico 作者），其他看起来都是 4337 作者。
2. 03 年 9 月，其实还是 zuzalu 之后不久，就开始了这个协议，看起来那次会议还是有可能有点触动和帮助，也可能 Vitalik 也在想，但是没那么坚决，所以造成 4337 run 了一段时间的局面。

相关讨论

1. 4337 的关键之一，bundler 作为 relay 并且有权选择出块节点（可以自己获取 MEV），不可避免的中心化，预计会在几个大的 Web3 RPC 提供商或者他们支持的钱包、SDK 上集中，而他们使用的大多数是 AWS（估计有的是自建？）等，中心化和面临 cesorship 的概率几乎是 99%。

2. 7560 的改进可能会让独立的 bundler？或者更多其他方式的 bundler 涌现？

3. Gas fee 优化上如果 native 后，许多操作 gas 成本转换为节点的计算成本，大幅降低 4337 的 gas fee，不过这个需要每个环节对比看看。

4. 因为 4337 还没有大规模或者稍大点规模的应用，7560 还有机会改进

5. 关于 penalty gas 超额的部分，需要讨论

   Because of the separate validation and execution stages for AA transactions, it’s harder for the block builders to account for an unused gas discrepancy.
   由于 AA 交易的验证和执行阶段是分开的，因此区块构建者更难解释未使用的 gas 差异。
   
   It’s described here https://github.com/ethereum/RIPs/blob/e3bead34f1bcf1aa37fd51923ad99a77b801775c/RIPS/rip-7560.md#unused-gas-penalty-charge 48
   这里描述 https://github.com/ethereum/RIPs/blob/e3bead34f1bcf1aa37fd51923ad99a77b801775c/RIPS/rip-7560.md#unused-gas-penalty-charge48
   
   

6. 说 7560 不好的一个是升级和添加函数 _v 符合的选择，一个是认为会总结 core 的复杂度，一个认为 AA 现在应用不广泛，硬分叉会拖慢整体，一个说 core 协议边复杂了，而 AA 在发展中，例如意图 AA（intent based AA like UniswapX, ERC-7521^[5]），7560 lock 了 4337+2938 方案，另外删除了 aggregation，他认为是为 OP Rollup 节省大量 gas 的亮点；一个说 unused gas 的模糊；两个（包括 jaydon）关注 EIP 9999 是啥？啥时间释放？啥内容），作者回复 EIP 9999 是 ERC-7562：帐户抽象验证范围规则的占位符，就是上面说道到剥离验证 rule 部分。作者挨个回复了论坛的几个问题（这部分我们看论坛讨论一下）；yoav 也回复了关于增加复杂度问题；alex 关于 DDos 和新版 EP 回复；讨论到了SLOAD，这个我很迷惑：I think making accounts upgradable offers security and usability benefits, well worth the SLOAD. But we’re also looking for ways to make it cheaper. For example, EIP-7557^[6]，聊几句；cejay 问 none manager问题，这个是全局的；而 internal nonce is left for CREATE operation only. 删除请求的这个上下文有点晕。Yoav 说正在基于 GETH 实现 7560，进度不确定。

7. 4337 的 bundler 现状：304.8万，比另外一个数字少点，gas fee 用了 158 万 U？

BundleBear:
https://www.bundlebear.com/overview/all

对 AAStar 和 ETHPaymater 影响

1. 可以部分跳过 4337，直接基于 7560 构建例如 Application Account 等模块
2. Paymaster 可以自行支付，不用预付到 Entrypoint，但当下感觉先实现 4337 的，届时拉新分支改进是个稳妥思路，可以设计具体流程的时候评估，甚至两个都兼容。
3. 这句话就是 EOA gas sponsor

A notable feature of RIP-7560 is the introduction of gas abstraction for 
Externally Owned Accounts (EOAs), ensuring that transactions under this new 
system are as cost-efficient as traditional ones

1. 对 bundler 来说，还需要深入看看，目前不需要（暂时不做 bundler），因为新的交易类型其实就等于合约账户可以直接向节点客户端发起交易，那对于 bundler 来说，就没有存在必要了？而新的交易类型，也会加入去中心的 mempool（这个估计还在开发中，matis？）。
2. 对于 Layer2 的影响，需要再深入分析和持续跟进，我还没有感受到太多，这个 RIP 改进了哪些 rollup 和之上的 AA 特性（说是 enhance rollup）？而实际上 Layer2 更是需要提供更多 native 的变化的，todo，补充：目前看 rollup 需要做一些协议层的改进，来配合实现 native AA；
3. 7560 保持 4337 兼容性之一是让已经 follow 这个标准（4337）的 ZkSync^[7]，StarkWare^[8]，scroll^[9]  等等可以平滑过度，不至于频繁升级，造成生态损失。刚在 roadmap 看到是无限期共存？有点疑惑，边走边看
4. 迁移路径级别就是上面说道的，最好是统一行动，否则真的头大，所有应用面对两种解决方案，如果要做全链支持所有 Layer2 的话。猜测会有类似于 Thirdweb 之类的 sdk，把变化封装住或者做隔离，这样复杂度会降低些。讨论下
5. 一些变更（相对于 4337）：
1. EntryPoint 地址设置为系统范围的常量值，每个链会不同
2. validateUserOp 重命名，因为 UserOp 消失了
3. 合约账户不必 prefund gas 到 EntryPoint，会直接被扣除 gas；或者用 Paymaster
4. Paymaster 自己需要合约和代码的升级（validatePaymasterUserOp 重命名等，上面也重复说过），这个估计要追下，做兼容
5. Validation Code Rules 、 Entity Staking 和 Entity Reputation ，ERC-4337 继续保持（这个和提交老失败的交易有关系？），但原生 AA EIP/RIP 不包含。我估计这个会类似 Aggregation，有独立方式^[10]。
6. mempool 其实没有太清晰，原来 4337 可以提交给指定 pool，现在新结构上文我猜测是 7560 后 4337 的 UserOperation 直接提交客户端，标记为 TransactionType4？还是略作结构修改后提交？这个直接结果就是 bundler 的 mempool 收益没有了，不过 TransactionType4 会返回给 bundler 一些 fee（上面说过）
7. bundler 通过 eth_sendTransactionConditional 访问客户端，这个特权 api 特在哪里？

References

[1]

EIP-2938: https://eips.ethereum.org/EIPS/eip-2938

[2]

4337: https://github.com/ethereum/ercs/blob/master/ERCS/erc-4337.md

[3]

EIP2718: https://eips.ethereum.org/EIPS/eip-2718

[4]

源文: https://github.com/ethereum/RIPs/blob/e3bead34f1bcf1aa37fd51923ad99a77b801775c/RIPS/rip-7560.md#accepting-eoa-account-as-sender-to-achieve-native-gas-abstraction

[5]

ERC-7521: https://ethereum-magicians.org/t/erc-7521-generalized-intents-for-smart-contract-wallets/15840/8

[6]

EIP-7557: https://github.com/ethereum/EIPs/pull/7968/files

[7]

ZkSync: https://era.zksync.io/docs/reference/concepts/account-abstraction.html

[8]

StarkWare: https://starkware.co/resource/native-account-abstraction-opening-blockchain-to-new-possibilities/

[9]

scroll: https://github.com/scroll-tech/contribute-to-scroll/issues/1613,https://blog.particle.network/introducing-social-logins-modular-account-abstraction-on-scroll/,https://etherspot.io/case-studies/scroll/

[10]

独立方式: https://github.com/eth-infinitism/account-abstraction/pull/342/files#diff-bcee933283b40cf03dcf7913aad7c6437f25dcf4ffe2365dcc09d00e3e6512f3

[11]

RIP-7560: Native Account Abstraction: https://ethereum-magicians.org/t/rip-7560-native-account-abstraction/16664

[12]

What is Native Account Abstraction? RIP-7560 Explained: https://blog.thirdweb.com/native-account-abstraction-rip-7560/

[13]

What is Native Account Abstraction? RIP-7560 Explained: https://blog.ambire.com/native-account-abstraction-rip-7560-explained/

[14]

RIP-7560：共识层变更的原生账户抽象，账户抽象的最终形态？- 深潮TechFlow: https://www.techflowpost.com/article/detail_14974.html

[15]

Native Account Abstraction on Ethereum?! RIP-7560 Explained: https://www.youtube.com/watch?v=BEO1WQE-dw4

[16]

Roadmap for Native Account Abstraction Introduction: https://hackmd.io/@alexforshtat/native-account-abstraction-roadmap?ref=blog.thirdweb.com

推荐阅读

---

/ About  Plancker

PlanckerDAO 是一个专注建设以太坊生态的社区，我们为开发者、产品经理和研究员提供多方面支持，致力于与以太坊共建人类的数字化美好未来。

Website：https://plancker.org/

Forum：http://forum.plancker.org/

Telegram：https://t.me/PlanckerDAO

Notion：https://planckerdao.notion.site/

Twitter：https://twitter.com/PlanckerDAO