抽象帐户（Account Abstraction ）：EIP-3074 与EIP-4337 简介

免责声明：本文旨在传递更多市场信息，不构成任何投资建议。文章仅代表作者观点，不代表MarsBit官方立场。

小编：记得关注哦

来源：Mirror

原文标题：抽象帐户（Account Abstraction ）：EIP-3074 与EIP-4337 简介

以太坊的社群其实讨论了好一阵子究竟要如何设计新一代的帐户，不同的思路也对应了不同的提案，本文主要介绍AA 在以下这两种方向的相关内容：

本文主要继承自前篇：Account Abstraction 抽象帐户：EIP-2938 简介，因此会希望读者已经阅读完前篇，以及具备相关的背景知识。

EIP-3074: AUTH and AUTHCALL opcodes打算在EVM 中加入两个新的OpCodes，分别是 AUTH 和AUTHCALL，让EOA 能透过这两个opcode 授权合约代替EOA 的身份去呼叫其他合约。

EIP-3074 的主要目的并非设计一个崭新的protocol 来扩展EOA 的functionality，因为随着protocol 与相关的介面标准越来越复杂，能被攻击的地方也会越来越多。

它倾向让User（EOA）可以以合约（Invoker Contract）代理自己执行各种动作，同时让开发者能以一个更具弹性的框架来设计交易物件和验证机制（签章演算法），使任何的EOA 可以像一个合约帐户（Contract Account）一样运作，却不用自己布署任何合约。

Image Source: Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337

概括来说一个EOA 能将一则已签的讯息（交易）送至自己信任的合约（称作Invoker）上，合约可以利用 AUTH 和 AUTHCALL 代替这个EOA 送出这笔交易。

由于EOA / User 提交给Invoker 的形式是合约自订的，搭配新的OpCodes 之后能让各种需求变得很好实现，例如批次交易、包装交易、手续费缴交方式、多签、签章验证方式等。EOA 也能透过他喜欢的方式（ERC-20、法币等）给予Invoker 手续费。

此外，commit可以利用平行的call 和在其之中的nonce，达到multi-call 的「包装交易」效果。例如我们在面对ERC-20 的交易时，就可以把approve-transfer包在一个动作里面。

关于这个部分每一个call frame 里面的角色及运作，可以见下文。

AUTH（0xf6）：会基于ECDSA 签章演算法去设定 authorized 的值

AUTHCALL（0xf7）：会代理 authorized 这个帐户发送call

在EIP-3074 中还有 dynamic_gas 的设计，这个部份因为比较琐碎我就先略过，如果有兴趣或是想知道其他参数的Spec. 可以详阅此处。

EIP-4337: Account Abstraction via Entry Point Contract specification则希望可以把原本交易在底层运作的逻辑拉到合约中：

在这里我们有许多名词是第一次碰到，下文我会慢慢解释！

Source: ERC 4337: account abstraction without Ethereum protocol changes

首先，这个提案最大的特点就如同上图来源， Vitalik 文章的标题叙述一样，不用去更改Ethereum 底层的Protocol 就能完成AA 的实作。

EIP-4337 可以达到以下目标，某些点可能与我们之前介绍过的EIP-2938 和EIP-3074 稍微不同：

我们可以把EIP-4337 的AA 实作当成是一个Contract 的Spec.，它的目的是要把底层的交易与帐户运作拉到合约层面执行。这边我会边解释名词，边顺过整个交易在AA 被执行的过程。

在合约里面，用户送上来的交易物件是一个在合约中名为 UserOperation 的struct。这个 struct 的members 和我们认识的交易很像，包含sender、nonce、callData、callGas、signature等，细节可见原提案。

Bundler 有可能是矿工，或是能作为User 和Miner 之间的中介人。会去聆听UserOperation mempool 中新加入的UserOperation，并且将从这些交易中挑选一部分捆绑成Bundle Transactions。

首先Bundler 会在Local 使用RPC Call 呼叫Entry Point Smart Contract 中的simulateValidation，以此先确保这些UserOperation 的签章没问题和Gas Fee 被正常支付。关于模拟交易结果的部分可见此处。

最后Bundle Transactions 会呼叫Entry Point Smart Contract 中的函式handleOps。

Entry Point Smart Contract（EntryPoint）是一个早就被布署的合约，将在未来被相关的AA Transaction 呼叫使用，例如某一个Dapp 有它想要的AA 交易模式，它就需要布署一个它的EntryPoint。

EntryPoint会处理UserOperations 的内容和替Bundle Trandactions 布署一个Wallets Contract（使用标准EIP-2470: Singleton Factory以及CREATE2，initCode来自于UserOperation.initCode，salt来自于UserOperation.nonce）。

Wallet Contract 会用来处理nonce 与signature 的验证并且执行交易。

在进到 EntryPoint 与 handleOps 的解释之前，我们先回忆一下之前在EIP-2938 提到的，节点需要负责验证一笔AA 交易是否合法的两个阶段：PAYGAS以前的验证阶段（verification phase），与 PAYGAS 以后的执行阶段（execution phase）。

Source: Implementing account abstraction as part of eth1.x

在 handleOps 中有很类似的举动，面对每一个UserOperation，handleOps会用两个For Loop 来实作上述两个phases，一个是verification loop，另一个是execution loop。

handleOps中的第二个步骤（回圈）会以 UserOperation 作为calldata，去呼叫Verification Loop 布署的Wallet Contract。并且执行交易本身该执行的内容。（可想而知Wallet Contract 要有办法去parse 这个calldata。）

执行完以后，会将剩余的gas fee 给予Wallet Contract。

在EIP-4337 还有特别重要的一个Features 叫做Paymasters。

大家还记得在之前的文章中有介绍过的其他支付手续费的方式，以及Tornado Cash 的AA Example 吗。Paymasters 可以做到第三方代替别人支付一笔交易的手续费的行为，此时就可以去接收其他种的Fee（eg 信用卡、ERC-20 等）。

要如何判断这笔交易的手续费是Wallet Contract 还是Paymasters 支付，得看 validateUserOp 中的参数 requiredPrefund 是否为0。如果我们已经确定要用Paymaster 支付的话，可以对应着看上方示意图。

EntryPoint中要特别去实做一些属于Paymaster 的函式，例如：

在以上的示意图中，对应的步骤如下：

Image Source: Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337

上面这张图也蛮漂亮的，大家可以参考一下：

整个系统的安全假设有一个前提是Node（miner / bundler）必须在包装这笔UserOperation 时就先利用上文提到的模拟行为确保交易会成功、手续费会被支付（细节可见 此处）。如果这件事情没有做到，那我们可以假设有恶意人士会提交很多个operations，并且被包装抵达 EntryPoint 但在最后一刻（执行了很久之后），才被revert。但如果有在每次提交到EntryPoint 前确实模拟，那系统就可以预设是DoS Safe 的。

虽然无论是使用Wallet Contract 还是Paymaster 支付手续费，都可以利用模拟行为避免交易在最后一步才被revert，但Paymaster 是被第三方制造出来的，因此我们可以想像有一种恶意情况是模拟行为中 paymaster.validatePaymasterUserOp 会成功，但之后的 postOp 等真正要执行时会失败。

和前一篇介绍AA 的文章相同，由于是简介所以非常多设计细节还有实作的设计想法我都没有提到，如果想要了解的话可以细细品尝该EIP 本身还有下方Reference 提到的资料。

由于以上介绍的两个提案都还不是定案，在研究时也会找到许多旧版提案的内容，因此如果大家发现认知与资料不一的情况，可以先去确认EIP 内文，那里肯定是最准确的！

本文要感谢

责编：Lynn