以太坊的账户抽象以创建单一账户类型为目标，这种账户将包含所有相关方面，而且没有任何无关的方面，让开发人员的工作更加轻松。

原文标题：《以太坊区块链账户抽象概览》（An overview of Account Abstraction in Ethereum blockchain）

撰文：Yash Kamal Chaturvedi

编译：ETH 中文

译者注：账户抽象 (Account Abstraction, AA) 自 2015 年以来就一直被讨论，并提出了几个不同版本的 EIP (EIP-101、EIP-86、EIP-859、EIP-2938、EIP-4337)。最近，账户抽象的研发似乎又成为了社区的讨论热点，应用层面上也陆续推出账户抽象的解决方案。那么账户抽象究竟是什么？大家想要通过 AA 来解决什么？本文讲述了以太坊账户类型、账户抽象的 EIP、以及账户抽象的潜在用例。

推荐阅读下列文章，更好地理解账户抽象：

• 《账户抽象的动机、历史和分析》by 沙漏:
• 《引介 | 概述以太坊账户抽象化》by EthFans:
• 《引介 | 账户抽象化（EIP-2938）：为什么 & 做了什么》by EthFans:
• 《论账户抽象 (2022)》by 沙漏:
• 《EIP-4337》by Plancker DAO:

此外，普朗克社区和 ECN 社区合办的首期「他的名字叫小 V」活动对 EIP4337 合约钱包进行了分享。分享视频：EIP4337 合约钱包分享

计算机编程中的抽象和数据抽象指的是隐藏除了「对象」相关数据以外的所有数据的过程，目的是减少复杂性并提高有效性。它通过省略不必要细节的方式来表示对象。抽象是面向对象编程（object-oriented programming）的三大原理之一，它与封装和数据隐藏有关。这篇文章将为以下方面提供概览：

以太坊账户抽象

• 外部账户 / 用户账户
• 合约

为账户抽象提议的 EIP

• EIP-86：事务来源和签名的抽象
• EIP-2938：账户抽象
• EIP-4337：通过入口点合约 (Entry Point Contract) 实现的账户抽象

用例

• 钱包
• 赞助交易
• 混币
• DeFi 协议

账户抽象

以太坊的账户抽象以创建单一账户类型为目标，这种账户将包含所有相关方面，而且没有任何无关的方面，让开发人员的工作更加轻松。

以太坊账户类型

目前，在以太坊区块链上有两种类型的账户：

用户账户（EOA）

用户账户是给一般人使用的（人类）。

• 这些账户由对应公共地址的私钥所控制，比如用户的钱包账户。
• 这些账户又称为外部账户 (EOA)，不需要 ETH 余额就可以在区块链上创建一个外部账户。但是，两个外部账户之间可以用 ETH 进行交易，也可以用 ERC 支持的其他代币。
• 外部账户 ( 钱包 ) 用于加密货币的发送和接受功能存在于以太坊虚拟机（EVM）的外部。

合约

合约是一组由代码控制的指令。

• 因为使用了网络储存，所以创建一份合约通常会产生相关成本。
• 用户可以操作多种功能，比如接收来自外部账户和合约账户的事务，以及向它们发送事务。
• 它还可以启动一个执行多种活动的代码，包括兑换代币或是创建一个新合约。
• 合约账户是存在于 EVM 的「智能合约」。

如果你发送 1 个 ETH 到由代码合约控制的账户，那就没有人可以再控制这个 ETH 了。唯一可以转移这个 ETH 的是合约的执行，即代码本身。

两种账户类型都具有接收、保留和发送 ETH 和代币的潜能，还有与部署在网络上的其他智能合约进行通信的潜能。

账户抽象提案

以太坊账户抽象 (AA) 是对这两种账户形式的加强，让它们更具有可比性，还使外部账户的管理逻辑像合约账户一样通用。

它的目的是将合约账户的两种形式减为一种形式。单个账户形式的用途包括铸币和合约转账。开发者和用户将不再需要区别账户类型，因为事务将完全转移到 EVM 上并脱离区块链协议。

以太坊开发者一直在寻找实现的方法，但一直没有达到 Final 状态的提案。在以下部分，我们将概述迄今为止提议账户抽象的三个以太坊改进提案 (EIP)。

账户抽象提案的时间线

2016：

• Vitalik Buterin 为 Metropolis 提出最初的抽象变化想法。
• 其目的是准备一种账户安全抽象。在传统的模型中，ECDSA（椭圆曲线数字算法签名） 和默认的 nonce 方案是保护账户的唯一途径。在此模型中，所有账户都是合约账户，它可以支付 gas，且用户可以自由定义他们的安全模型。

2017：

• Vitalik Buterin 提出了用于事务来源和签名的抽象的 EIP-86。
• 其目的是抽象出签名验证和 nonce 检查机制，允许用户建立账户合约来执行任意所需签名或 nonce 检查，而不是依赖于传统的方法。

2020：

• Vitalik Buterin、Ansgar Dietrichs、Matt Garnett、Will Villanueva 和 Sam Wilson 提议了用于账户抽象的 EIP-2938。
• 目的在于允许合约成为可以支付费用和执行事务的「顶级」账户类型。

2021：

• Vitalik Buterin、Yoav Weiss、Kristof Gazso、 Namra Patel 以及 Dror Tirosh 提议了通过入口点合约规范进行账户抽象的 EIP-4337。
• 其目的在于避免共识层协议变更，而是依靠更高层次基础设施。

EIP-86：事务来源和签名的抽象

根据其「摘要」，EIP-86 提议实现一系列改变，这些改变服务于「抽象出」签名验证和 nonce 检查的综合目的，允许用户创建用于执行任意所需签名 /nonce 检查的「账户合约」，而不是依赖于使用目前这种硬编码到事务处理的机制。

传统模型：ECDSA 和默认的 nonce 方案是保护账户的唯一方式。

新模型：所有账户都是合约账户，它可以支付 gas，且用户可以自由定义他们的安全模型。

以 forwarding contract 为例，作者 Vitalik Buterin 解释道，这种合约会验证签名，如果签名是有效，它开始向矿工发起付款，然后使用给定的值和数据向指定地址发送调用指令。

优势

这个提案的主要优势如下：

多签钱包

• 传统方法：多签钱包中的每一笔交易都必须由所有的参与者进行同意。我们可以通过将所有参与者签名结合为单一批准事务对此进行简化，但这种方法还是会增加复杂性，因为所有参与者的账户都必须持有 ETH。
• 新方法：在这个 EIP 的帮助下，现在的合约可以持有 ETH，直接提交包含所有签名的事务至合约上，合约将会支付这笔费用。

自定义密码学

• 传统方法：用户必须遵循 ECDSA，这是一种使用椭圆曲线的密码学。
• 新方法：用户可以升级至 ed25519 签名或用户自己希望升级的任何方案；不要求用户采用 ECDSA。

EIP-2938：账户抽象

根据 EIP-2938 的摘要，账户抽象 (AA) 允许合约成为可以支付费用和执行事务的「顶级」账户。

传统模型：事务的有效性直接由 ECDSA 签名、一个简单的 nonce 值以及账户余额进行定义。

新模型：

1. 账户抽象通过执行随机的 EVM 字节码来扩展事务的有效性条件。
2. 为了表示有效性，引入了新的 EVM 操作码 PAYGAS，还设置了合约的 gas 价格和 gas 使用上限。
3. 账户抽象现已分为两类：
4. 单租户 AA：这种类型旨在支持钱包或其他参与者很少的用例。
5. 多租户 AA：这种类型旨在赋能像 Uniswap 这种有很多用户的应用。

共识变更

• NONCE 操作码：添加一个 NONCE 操作码，推送事务的 nonce 字段。
• PAYGAS 操作码：添加一个 PAYGAS 操作码，创建一个不可逆的检查点，确保 PAYGAS 之前的状态变更无法被逆转。

Sam Wilson 是这个提案的作者之一，它在这里解释了 AA 事务与其他传统事务的不同之处。

在 AA 事务中，不会有 gas 价格或是 gas 上限、没有发送的值和签名字段，并用 target 代替 to 。在多签合约中，这些字段在 calldata 中进行传递，并用合约进行处理。

如果一笔事务到达节点，事务的有效性会被检查。但是传统事务和 AA 事务进行检查的方式不同。

• 在传统事务中：节点检查：他们的 nonce 与账户的下一个 nonce 匹配、账户余额足以支付他们的价值以及最高的 gas 费用，并且他们的签名与账户的地址匹配。
• 在 AA 事务中：节点检查：他们的 nonce 与合约的下一个 nonce 完全匹配、合约的字节码以标准的前缀开始、验证逻辑在达到验证 gas 上限之前调用 PAYGAS 、没有禁止的操作码在  PAYGAS 之前被调用，以及合约余额足够支付 PAYGAS 设定的 gas 费。

区块广播时间是一个新区块到达网络大多数节点所需平均时间。

当具有 AA 事务的区块到来时，同一账户的所有待处理事务都将被删除。另一方面，传统事务会被重新验证并可能在收到新区块时发布。

EIP-4337：通过入口点合约实现的账户抽象

这是 Vitalik Buterin 和社区提出的最新议案。它作为一项 ERC 提议出来，而这个提案包括了避免共识层协议的变更，而依靠于更高层的基础设施。

它旨在完成下列目标：

• 账户抽象：允许用户使用包含随机验证逻辑的智能合约钱包作为他们的主要账户，而不是 EOA。
• 去中心化：允许打包交易捆的人参与包含账户抽象用户活动的过程。用户不需要知道任意活动者的直接通信地址，就可以处理发生在整个公共内存池中的任意活动。
• 无共识变更：为了更快的采用，这个提案避免了共识变更。
• 交易费支付：用 ERC-20 标准的代币支付交易费，使得开发者为其用户支付费用，以及类似于 EIP-3074 这样的赞助的交易提案所支持的用例。

这项提案怎么运作？

图片来源：Infinitism

Vitalik Buterin 在这里很好地解释了这项提案的运作。

这是账户抽象最新的提案，现在还是 draft（起草）状态，等待被合并成为一项 EIP。对比常规的以太坊事务内存池，这项设计增添、维护以及牺牲了一些功能。

关键亮点

没有中心化的活动者、移除了用户端钱包设置复杂性，完全支持 EIP-1559、具有代替交费的能力，发送一个比旧 UserOperation 具有更高溢价的新 UserOperation 来替换操作或保留了让它更快被打包的功能。

有一些增添的新优势：

• 验证逻辑的灵活性
• 足以让执行层达到量子安全
• 钱包可升级性
• 执行逻辑灵活性

然而，尽管协议已经尽了最大的努力，它还是会略微增加 DoS 攻击的可能性，它还会增加 gas 开销，并且一次只执行一个事务。

账户抽象用例

钱包

EOA 和合约钱包

• EOA 钱包：由私钥保护的钱包。
• 合约钱包：使用智能合约在链上实现的钱包。
• 安全考虑：如果智能合约代码中存在 bug，合约钱包将面临来自易受攻击的智能合约的安全风险。这种风险可以通过由钱包提供商完成的安全测试和审查进行最小化。然而，在 EOA 钱包中，风险会完全由钱包用户承担，就像用户不小心丢失了私钥也由他们自己承担。

Argent, Dapper, Gnosis Safe 和 Monolith 都是智能合约钱包的案例。

EOA 的元交易

以太坊区块链用户需要一个持有 gas 的 EOA 与区块链网络进行连接，或依赖钱包供应商通过他们的中继或第三方中继网络（例如 Gas Station 网络）促进元交易。前者依赖于 ( 需要做 KYC 的 ) 中心化交易所购买的 ETH，试图通过将消费者的责任转移给中继者来尽量减少用户体验摩擦，费用由链上 / 链下钱包供应商和 / 或链下用户支付。

元交易是一种包含了带有执行交易意愿者所签署的数据信息的交易。

基于中继者的架构有一些缺点：

1. 可以将他们视作拥有抑制交易能力的中心化中介
2. 由于中继交易需要额外的 21,000 基本 gas 收费，及其公司在 gas 费基础上盈利的需要，他们在技术上 / 经济上的效率低下。
3. 对中继者专用协议权力的使用。

账户抽象允许智能合约钱包在不依赖中继网络的情况下，接受用户的无 gas 费的元交易并为他们支付 gas 费。在不失去以太坊去中心化保证的情况下，这种基础层的能力还会大大提升这种钱包的 UX（用户体验）。

赞助交易 (Sponsored Transactions)

Sponsored Transactions 囊括在 EIP-2711 ( 状态为已撤销 ) 中，这个 EIP 提议了一种机制：通过允许其他人代付 gas 费，可以让人们无需拥有任何 ETH 就可以进行交易。

一些用例：

• 允许应用开发者代表用户支付费用。
• 允许用户用 ERC-20 代币支付费用，合约则像中介收集 ERC-20 代币并以 ETH 的方式支付网络费用。

运作

这项提案可以通过出纳机制 (paymaster mechanism) 来支持这些用例。

• 对于用例 1：Paymaster 会验证赞助者的签名被纳入在 paymasterData 中，表明赞助已做好为 UserOperation 进行支付的准备。如果签名有效，Paymaster 就会接受这项指令，并从赞助者的份额中扣除 UserOperation 的费用。
• 对于用例 2：Paymaster 会检查 sender 的钱包是否有足够的 ERC-20 余额来支付这项 UserOperation。如果足够，Paymaster 会接受这项指令，并在索要 postOp 里的 ERC-20 代币之前支付 ETH 费用。

混币

一起探讨 Tornado Cash 混币机制的例子，以此理解我们如何在 DeFi 协议中使用 AA。

传统的 Tornado Cash 合约中的隐私问题

• 当用户进行提款时，Tornado Cash 为其提供隐私保护。他们可以证明这笔款来自一笔独一无二的存款，但除了用户之外没人知道这笔存款来自哪里。
• 用户通常不会在自己的提款地址里持有 ETH，如果用户使用他们的存款地址来支付 gas，这就会在存款地址和提款地址之间生成一条链上链接。

这个问题可以由第三方中继者解决，他们会验证 ZK-Snark 和 nullifier 仍然有效的状态，发布使用其 ETH 支付 gas 的交易，并从 Tornado Cash 合约中收集用户的返款。

账户抽象提供的解决方案：用户可以提交一个针对 TC 合约的 AA 事务，在这之后执行 ZK-SNARK 验证和 nullifier 检查，并直接快速地调用 PAYGAS。这可以让提款者直接用发送到他们提款地址的代币中支付 gas，无需中继者或连接其存款地址的链上链接。

DeFi 协议

一起探讨 DeFi 协议 Uniswap 的案例，了解我们可以在 DeFi 协议中如何使用 AA。

可以创建一种 Uniswap 的新版本，它允许直接进行针对 Uniswap 合约的交易。

目前，用户可以将代币提前存进 Uniswap；Uniswap 可以储存用户的余额和公钥，以便验证花费这些余额的事务。

AA 的目标在于通过禁止不符合高级标准的事务被打包到链上（例如，匹配订单的存在），从而提高 DeFi 协议的 gas 效率。

在传统模型中：正常的交易员会将他们的代币储存在 Uniswap 的合约之外。

在新模型中：套利交易员会将他们的代币存在 Uniswap 上，在外部市场发生变化的情况下，他们还可以转移执行套利的交易。最终，另一个套利交易员如果首先执行这笔交易时，这些没有获利的交易不会被打包上链。这让套利交易员避免了支付 gas 并减少了打包上链的垃圾交易数量。这将会增加区块链的可扩展性和市场效率，因为套利交易者更能做到纠正跨链交易在价格上的差异。

套利交易员指的是利用两个或更多市场之间的差价，由此同时低价购入并高价卖出的交易员。