以太坊 - 探索EIP-7702 - Rhinestone

保护EOA超级能力和实现无需许可的创新，面向未来

在过去的几周里，EIP-3074 在账户抽象生态系统中受到了认真和广泛的讨论。该 EIP 被标记为包含在 Pectra 中，开始了 devnets, dev 工具支持, 原型设计 以及围绕该标准的辩论的开发。其中一个核心辩论集中在其对账户抽象路线图和现有账户抽象设计的影响上，最值得注意的是 ERC-4337。

昨天，Vitalik 提出了 EIP-7702，其目标与 EIP-3074 类似，但实现方式不同。值得注意的是，它似乎更符合账户抽象路线图、现有基础设施以及提案，包括 RIP-7560。

EIP 概述

EIP-7702 从 EIP-5806 中汲取灵感，并提出了一种新的交易类型，在该交易类型中，可以设置一系列 EOA 的合约，并提供与每个 EOA 相关的代码。实际上，这意味着在 tx 的现有字段之上，提供了一个数组，其中包括每个元素的合约代码和签名。当执行此 tx 类型时，客户端将循环遍历此数组，恢复每个签名的 EOA 地址，并将此 EOA 的代码设置为提供的合约代码。在此交易结束时，将删除提供的所有 EOA 的代码。该提案不要求提供的任何 EOA 成为交易发起者，使其与中继器兼容，包括 ERC-4337 bundler。

它与 EIP-3074 有何不同

EIP-3074 引入了两个新的操作码，AUTH 和 AUTHCALL。从高层次上讲，AUTH 恢复 EOA 的签名，如果成功，则设置一个上下文变量，允许发生 AUTHCALL。AUTHCALL 执行一个调用，该调用在大多数方面与普通的 CALL 操作码类似，但使用恢复的 EOA 地址作为消息发送者。这意味着 EOA 可以授予所谓的 invoker 合约权限来执行源自该 EOA 的调用。

这两个提案的目标相同：赋予 EOA 执行代码的能力。EIP-3074 通过允许合约以 EOA 地址作为消息发送者来执行调用来实现这一点。EIP-7702 通过在交易上下文中设置 EOA 的代码来实现这一点。因此，后者几乎完全与现有的智能账户兼容，因为用户只需使用其 EOA 签名其代码，并使该代码在交易范围内存在于 EOA 地址下。相比之下，EIP-3074 需要重建现有的智能账户以使用所提出的操作码（如 之前的一篇博文 中所讨论的）。

为什么它更符合账户抽象路线图

目前，以太坊上的账户抽象路线图取决于 ERC-4337 和（未来）RIP-7560。这两个提案的核心重点是抗审查和去中心化中继。实现这一目标的一个关键因素是将验证与执行分离。然而，使用 EIP-3074，验证（使用 AUTH）与执行（使用 AUTHCALL）紧密耦合，使得将它们彼此分离变得更加困难，但并非不可能。相比之下，EIP-7702 没有这样的限制，并且对智能账户的设计完全没有倾向性。

从长远来看，账户抽象路线图的目标是将所有用户转移到智能账户上，其中一些需要通过从 EOA 到智能账户的永久迁移来实现。在 EIP-3074 的世界中，这种情况可能会通过 EIP-5003 发生。此扩展添加了另一个操作码 AUTHUSURP，允许将合约代码永久部署到没有代码的 EOA 地址。在 EIP-7702 中，迁移的实现方式会简单得多，可能会像在签名数据中添加一个标志一样容易。

实现无需许可的创新的清晰路径

在我们的 之前的一篇博文 中，我们讨论了钱包供应商对 invoker 的白名单作为 EIP-3074 设计空间中最具限制性的因素。简而言之，如果一个 dapp 希望构建需要新的 invoker 合约的新产品功能，他们必须让所有相关的钱包供应商将该合约列入白名单。

我们提出的解决此问题的方法是一个模块化 invoker，它借鉴了围绕 ERC-7579 和/或 ERC-6900 的研究和开发。这将允许一个或几个高度安全和受信任的模块化 invoker 实现，这些实现被普遍列入白名单，并由任何开发人员通过模块进行扩展。然后，从模块化账户抽象空间借用的许可和安全系统将允许无需许可地开发 invoker 功能。

EIP-7702 创建了一种简单的方法，可以直接采用现有的模块化账户抽象解决方案，以解锁 EOA 的无需许可的 UX 创新。它确保与现有模块化智能账户实现以及围绕模块化智能账户标准构建的所有工具和基础设施的向后兼容性。

EIP-7702 的另一个优点是，它可以更容易地构建一个应用程序，该应用程序对 EOA 和智能账户用户都使用智能账户功能，如批量处理、赞助、会话密钥等。虽然这在某种程度上也适用于 EIP-3074，但应用程序可能需要付出更多的努力才能与两者兼容。在最坏的情况下，这意味着 dapp 开发人员可能会选择只支持其中一个，从而为用户造成碎片化，本质上是强迫他们同时拥有 EOA 和智能账户，并且需要根据应用程序使用。

开放性问题

协议内撤销

EIP-3074 最初不包括在协议中撤销 AUTH 签名的方法。在协议中包含此功能意味着即使 invoker 变得恶意或存在某种错误，也可以撤销签名。在收到社区的反馈后，该提案进行了修改，以便 EOA nonce 和 chainid 也将被签名。尽管如此，此更改仍然引发了很多争论。

EIP-7702 目前不包括协议内撤销机制，但有一些建议要包含它。但是，这样做的一个缺点是需要为此选择一个特定的机制，例如，帐户 nonce、最大 nonce、nonce 管理器或其他机制。这样做的一个问题是，它本质上要求选择并坚持其中一个提案，而不是允许帐户开发人员选择如何完成此操作。因此，我们认为该提案应保持非倾向性并保持灵活性。

存储

EIP-5806 禁止在 EOA 地址的上下文中，使用 SSTORE 操作码。其中一个原因是，如果 EOA 最终可以升级，则可能存在已设置的存储，这可能会导致意外行为。因此，我们认为类似的限制对于 EIP-7702 也是有意义的。这将需要重写智能账户，以便它们的存储位于外部合约中。但是，这不会非常复杂，并且我们已经 为此原型设计了一个示例。

永久升级

Vitalik 提出的另一个想法是在交易数据中添加一个标志，以将 EOA 永久升级为智能账户。实际上，客户端可以只检查是否设置了此标志，如果设置了，则在交易结束时不删除代码。另一个想法是，即使 Pectra 硬分叉中未包含此标志，由于在客户端中包含该标志的工作量很小，因此汇总客户端可能会尝试使用此功能并在其添加到以太坊之前添加它。

结论

EIP-7702 与账户抽象路线图更加一致，并且不太可能导致以太坊客户端和构建在其之上的协议产生技术债务。因此，我们认为它是 EIP-3074 的一个更好的版本，因为它以更优雅和面向未来的方式实现了相同的目标。该标准仍然存在一些开放性问题，因此继续探索其影响是有意义的，但它似乎仍然是 EOA UX 更好的前进方向，并且与智能账户生态系统保持一致。这意味着 EIP-7702 也更有可能带领我们走向一个未来，在这个未来中，EOA 和智能账户都可以实现无需许可的创新，而不仅仅是后者。

• 原文链接： blog.rhinestone.wtf/expl...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～