EIP-3074是个好主意吗？

作者：Alex Connolly，Immutable联合创始人兼CTO，翻译：0xjs@

最近宣布，EIP-3074将包含在下一个以太坊硬分叉中，作为以太坊钱包用户体验的协议级改进。以太坊社区出现了各种奇怪的反应：

庆祝活动：“……以太坊用户体验的重大升级”（Uniswap 创始人）

担忧：“……问题很大”（Gnosis 创始人）

困惑：“心情复杂……不确定这是正确的策略”（EIP-3074 作者之一）

那么EIP-3074到底是什么？用户的资产安全吗？这与智能合约钱包、账户抽象或 ERC-4337 有什么不同？为什么以太坊社区用令人困惑的数字来命名一切？

如果你是 EVM 的常规用户或开发人员，那么有必要了解钱包的下一步发展方向。但首先，让我们从头开始。

EOA与智能合约钱包

EVM 的基本账户原语是外部拥有账户 (EOA)。

账户：以太坊地址（例如0xabcdef）

外部拥有：该地址的控制者是加密私钥

另一种类型的以太坊“账户”是智能合约，它也有一个地址，但包含代码并且没有原生控制密钥：如果你想通过智能合约账户发送交易，你需要将该功能构建到其代码中！

以太坊上的所有交易都必须由 EOA 发起，因此它们是迄今为止用户最常见的以太坊账户类型。然而，EOA 有许多主要的用户体验和安全缺点：

他们必须有足够的 ETH 在交易中用作 Gas（如果用户拥有其他有价值的资产，例如 NFT，但没有 ETH，则会出现问题）

他们无法以原子方式发送捆绑交易或者与 >1 个智能合约交互

他们不能有链上恢复机制（例如社交恢复）

它们很容易被泄露，如果它们被泄露，你的所有资产都将被盗

为了解决这些挑战，区块链研究社区的一个长期目标是“账户抽象”（AA）：将用户从EOA切换到由链上代码控制的“智能合约钱包”。用户通常仍然需要设备上的一些密钥材料，但我们可以将任意逻辑编写到智能合约代码中来控制用户资产并解决上述问题。

一些链已经引入账户抽象作为原生原语（例如Starknet），而以太坊则满足于让钱包提供商创建自己的智能合约钱包实现。现在有数十种智能合约钱包，它们为不同的目的提供不同的功能（例如 Gnosis Safe、Argent、Coinbase 智能钱包、Immutable Passport）。

然而，数字不言而喻：不到 0.1% 的以太坊用户使用智能合约钱包，但仍有数千万活跃的以太坊 EOA。让这些用户进行切换是一项艰巨的任务，也是一场安全噩梦。

EIP-3074有什么帮助？

EIP-3074于 2020 年底提出，旨在帮助 EOA 用户立即获得账户抽象的一些好处，而无需将其账户完全转换为智能合约钱包。

EIP-3074 引入了两个新的操作码：AUTH 和 AUTHCALL。这些操作码允许用户通过签署消息来临时将对 EOA 帐户的控制权委托给另一个帐户（“invoker调用者”，通常是智能合约）。然后，另一个帐户（“sponsor/bundler”）发送一个交易，该交易使用该消息和 AUTH 操作码来使委托正式上链。然后，“调用者”帐户可以使用 AUTHCALL 作为用户进行交易。

可能会有一些标准调用者合约（例如处理批处理的合约），并且这些调用者将复制帐户抽象的一些关键用户体验优势！

批量交易

考虑 ERC20 批准 + 转账的常见流程，目前 EOA 需要两个单独的以太坊交易。通过委托给批处理调用程序，这可以减少为一笔交易（尽管钱包仍然需要显示两次确认）。此外，许多应用程序试图通过在用户第一次交互期间请求无限制的花费批准来避免后续交互中的这种“双重请求”。这会让用户致命地暴露于这些协议中未来的任何错误中，因此通过避免它，我们将免费获得巨大的安全改进！

Gas赞助

假设我们的用户钱包里有 20 美元的 USDC，但没有 ETH 用来支付 Gas 费（例如swap费）。 dapp 可以通过调用者请求代表用户行事的权限，自行支付 Gas 费，然后从用户的 USDC 余额中寻求补偿。调用者合约必须包含逻辑，限制其发送的交易仅发送给用户通过显式签名批准的交易。

其他自定义调用程序可能会随之而来，用户可以访问此 UX，而无需离开现有的、熟悉的钱包（假设这些钱包添加了 EIP-3074 支持）。

这与 ERC-4337 有什么不同？

等等，我以为我们已经有了一个带有奇怪号码的帐户抽象提案？ERC-4337发生了什么？

ERC-4337是智能合约钱包的标准，旨在整合目前分散的智能合约钱包生态系统。 ERC-4337账户是完整的智能合约钱包：用户资产存储在智能合约中而不是EOA中。有很多不同的实现，但 ERC-4337 交易的总体流程如下（请注意 alex.eth 是智能合约）：

ERC4337 的目标是在不对核心 EVM 进行任何更改的情况下引领智能合约钱包的广泛采用。最终，账户抽象很可能会原生融入到链中：已经有计划通过RIP-7560将原生账户抽象引入以太坊 L2，并且这可能在未来扩展到以太坊本身（通过EIP-2938或后续版本） 。

如今，ERC-4337 仍处于起步阶段。该标准尚未最终确定，上周所有 EVM 链上仅有约 200,000 笔 ERC-4337 交易（Polygon 上的交易量超过 90%）。EIP-3074 和 ERC-4337 是对钱包用户体验的并行改进，目前大多数以太坊用户都是 EOA 用户。两者的支持者都认为，改进以太坊用户体验的最快方法是在两个方面尽快推进！

那么为什么有些人反对 EIP-3074？

EIP-3074 是一个潜在的主要安全攻击媒介

你在 Twitter 上看到的最常见的抱怨是，在 EIP-3074 之后，“一个签名就可以耗尽我账户中的所有 ETH、ERC20 和 NFT”。这是事实：委托给恶意调用者，用户的所有资产都将丢失。当然，带有 EOA 钱包的恶意“导出私钥”，用户的资产也会丢失。但签名在 web3 应用程序的标准流程中更为常见，许多用户只是尽快确认。

然而，这里有一些重要的警告。 EIP-3074 签名非常容易识别——它们必须有一个“魔法前缀”（字面就是“0x04”）。如今，大多数钱包仅支持使用ERC-191中定义的不同前缀进行签名，因此任何当前签名被用来欺骗 EIP-3074 委托的可能性很低（但不是零！ ）。随着钱包实现对 EIP-3074 的支持，它们可能会引入非常可怕的屏幕，让用户在签署此消息之前仔细检查他们的操作——想想“导出你的私钥”的安全级别。这限制了 EIP-3074 的 UX 优势：如果你每次想要使用不同的调用程序时都需要批准大红色警告屏幕，那么我们还没有取得任何进展。

为了解决这个问题，许多钱包可能会选择实施经过批准的调用程序列表（例如标准交易批处理程序），并且仅在用户超出这些范围时才显示可怕的屏幕。然而，这是一个明显的中心化问题，在不同的钱包之间会有所不同，并且依赖于 dapp 和钱包之间的协调（例如，两者都选择相同的 Gas 赞助调用者）。

假设用户的钱包明智地部署了 EIP-3074，则没有理由相信 EIP-3074 将成为一场安全灾难。但这是无数个以太坊钱包的一个重大假设。无论如何，这都将是一个重要的新攻击媒介，毫无疑问会导致一些引人注目的事件——我实际上想知道伪装的批量交易（适用于所有 AA 钱包）实际上是否是最大的长期风险领域。

EIP-3074不会永久“抽象”你的钱包

有人将 EIP-3074 描述为“将你的 EOA 升级为智能合约钱包”。这是一种误导——更准确地说，用户是“暂时允许智能合约代表你行事”，它有一些主要限制：

委托给调用者是暂时的，可以随时撤销。这意味着，如果有人泄露你的私钥，或诱骗你签署恶意交易，你的资产仍将被盗。你可以获得帐户抽象的一些用户体验优势，但没有任何安全优势。事实上，EIP-3074 可能会大大降低钱包和用户升级到完整智能合约钱包的动力——这与我们的长期目标相矛盾。

每当你发送实际的 EOA 交易时，你都将清除任何现有的调用者授权。这对于快速撤销来说非常棒，但如果你出于任何原因需要发送非 EIP-3074 交易，你将必须重新经历钱包的“可怕的屏幕”过程，以获取所有现有的授权。这不好玩。

对于以太坊社区的许多人来说，这感觉像是工作完成了一半。如果我们要花 2-3 年的时间来让 dapp 和钱包支持 EIP-3074 交互，为什么不实现使这些委托永久化的能力，并完全替换帐户的代码（将其完全转换为智能合约）钱包）？EIP-5003将引入另一个新的操作码 AUTHUSURP，它可以做到这一点，并且现在正在大力推动将 EIP-5003 包含在下一个以太坊硬分叉中以“完成工作”。

Safe创始人对AA全面替代EOA之路的看法

尽管该提案得到了许多主要以太坊社区成员的支持，但这并不是灵丹妙药：

与完整的智能合约钱包相比，EIP-5003 账户仍然存在一些限制

没有简单的方法可以使 EOA 私钥中的现有或新签名无效，并且许多合约将这些签名视为权威签名

跨链支持存在各种各样的挑战，尽管其中许多挑战也存在于ERC-4337 钱包中

EIP-3074 将需要广泛的钱包基础设施改变

为了启用上述赞助和批量交易流程，我们需要一个大致如下图所示的流程：

dapp 必须确定这些交易应该批量处理在一起

dapp 必须知道我们的钱包是否支持批量交易，并且可能需要在交易成本估算中包括钱包使用的特定调用程序的成本（以了解他们是否想要赞助）

钱包必须知道 dapp 是否打算赞助交易

钱包必须检查用户是否已经批准了必要的批量交易和赞助调用者

钱包必须能够将 dapp 的“批准和转移”请求转换为正确调用者的 EIP-3074 授权以及后续请求 - 或者也许我们要求 dapp 这样做？

钱包必须使用其自定义 EIP-3074 逻辑向创作批量交易调用程序的用户请求 EIP-3074 签名

钱包必须向用户显示 UI 以确认批次中包含的每笔交易。这必须由每个钱包单独构建。

Dapp 需要为批处理/非批处理用户实现单独的流程，并针对任何差异进行自定义错误处理。正如你所看到的，让所有用户/钱包/dapps 支持此流程将是一项艰巨的任务 - 我们甚至还没有开始跨 L2 UX！

这与 ERC-4337/智能合约钱包当前面临的挑战非常相似，并且已经有新的钱包 RPC 方法的提案，例如EIP-5792（批量交易）、标准化 paymaster API（EIP-7677）、与帐户无关的用户操作包（ERC-7679）和更多人类可读的钱包权限。在某些/所有情况下，EIP-3074 批处理可能能够搭载这项工作，但我们也完全有可能最终得到 3 个独立的流程（EOA、EIP-3074、ERC-4337）！

这种巨大的实施提升会带来巨大的现实世界成本：我们使以太坊越复杂（在 EVM 层和钱包 RPC 层），我们就越分散开发者的注意力，让他们无法完成以太坊成功所需的其他一切工作。

总结

对于采用EIP-3074 的用户/dapps/钱包来说，毫无疑问，EIP-3074 将能够提供有意义且立即的用户体验提升。

然而，存在一个很大的风险，即该功能的使用将非常有限：新的用户体验将令人困惑、复杂且跨钱包不同。当 dapp 和钱包为 EIP-3074 提供广泛支持时，完整的智能合约钱包标准将有望拥有工具和成熟度，成为对用户更具吸引力的目的地。我最希望 EIP-3074 作为用户通往完整智能合约钱包的中间工具，并且我同意这样的论点，即如果不快速包含 EIP-5003，这将受到很大的限制。

以太坊社区面临的最大风险是支持 EIP-3074 所需的努力将削弱开发人员试图将用户转移到完全账户抽象钱包的努力。 ERC-4337仍然不是最终版本，钱包 <>dapp 层的关键 EIP 仍然悬而未决，并且通过RIP-7560 在 L2 上进行原生帐户抽象的尝试吸引力相对较低。进一步划分开发者关注点不太可能产生更好的结果！

最终，EIP-3074 是否是一个好主意将取决于它成为其他帐户抽象路径（ERC-4337 和原生）的特洛伊木马的程度。在成功案例中，EIP-3074 是一次出色的即时升级，并激励 dapp 开发人员集成启动 ERC-4337 采用所需的工具。在失败的情况下，我们最终会发现 dapp 开发人员需要为 8 种不同类型的以太坊账户维护自定义流程！