让智能账户为EIP-7702做好准备

EIP-7702 计划包含在 Pectra 中，可能在 2025 年第一季度。它允许 EOA 继承智能账户的功能，而不是提供永久的迁移路径。总的来说，EIP-7702 非常有利于智能账户的采用，并且符合以太坊的账户抽象路线图。为了使现有的智能账户能够安全地与 EIP-7702 一起使用，必须进行一些小的更改。我们一直在 ERC-7579 参考实现 中原型化这些更改，以作为所有智能账户构建者的指南。

EIP-7702 解释

EIP-7702 的要点是，它允许 EOA 签署一个委托交易，该交易将在 EOA 的地址设置代码。具体来说，这段代码是指向合约地址的指针。当未来调用这个 EOA 时，例如通过 ERC-4337 EntryPoint，EVM 会将 EOA 视为具有部署在指针地址的代码。这允许现有用户将其现有的 EOA 转换为智能账户。

EIP-7702 有一些缺点和注意事项。其中之一是 EOA 私钥仍然可用，既可以用于签署新的委托（包括完全删除代码的委托），也可以用于并行于智能账户交易进行 EOA 交易。这意味着一些（主要是安全相关的）功能对于 EIP-7702 账户是不可行的。例如，将 EOA 转换为多重签名提供的安全保证低于实际迁移到多重签名，因为私钥始终可以用于绕过多重签名逻辑。此外，由于同样的原因，账户内的资源锁定也是不可行的。

需要的更改

如上所述，EIP-7702 对现有的智能账户非常友好，这也是社区 предпочтительно 它的原因，而不是类似的提案。但是，智能账户需要进行两项更改。

其中第一项是确保存储是命名空间的。需要这样做的原因是用户可能会在不同的账户之间移动，并且重新委托不会清除存储。这意味着如果两个账户实现使用相同的存储槽，则账户可能配置不正确、损坏或容易受到攻击。附带说明的是，此更改还使普通的智能账户用户更容易升级其智能账户代理并迁移到新的实现，这将有助于减少智能账户的供应商锁定。

所需的第二个更改与 EIP-7702 的简单性有关。具体来说，EIP-7702 委托仅对委托地址（和一些“元数据”）进行签名。这意味着 EIP-7702 没有初始化的概念，而是将负担推给了智能账户层。但是，当前的智能账户实现期望以原子方式部署和初始化，这意味着初始化函数不受访问控制，因为它不能被抢先交易。当委托给这些合约时，这会打开一个攻击向量，其中恶意行为者可以相对容易地抢先初始化并接管用户账户。

在下面的章节中，我们将详细介绍我们对 ERC-7579 参考实现所做的确切更改，以便我们可以安全地将其与 EIP-7702 一起使用。

存储命名空间

当我们最初编写 ERC-7579 参考实现时，实际上我们已经构建了具有命名空间存储的实现，主要是为了让用户更容易通过升级其代理在智能账户之间切换。因此，虽然我们从技术上讲没有进行任何更改，但我将介绍参考实现中的存储布局是如何工作的。

命名空间存储的想法是，与其使用基于连续的存储槽（例如 Soldity 用于静态和动态类型的存储槽，尽管后者通常是连续索引和其他参数的混合），不如从名称派生存储槽。ERC-7201 提出了一种方法，参考实现大致遵循该方法。要使用此模式，开发人员需要提出一个名称根，例如“modulemanager.storage.msa”，然后使用基于此根的哈希的存储槽（ERC-7201 对此有一个特定的公式）。然后，通过手动将结构体的槽设置为等于此根存储槽来访问存储，之后可以正常使用。

为了在用户重新委托其账户时不会产生任何问题，需要在账户上使用此模式进行所有存储访问。

初始化抢先交易保护

在这些更改之前，ERC-7579 参考实现的构建方式是特定的，即通过为用户创建并指向单例实现的代理。在与创建代理相同的调用中，代理也将由工厂原子地初始化。此外，代理的地址（因此也是用户账户）将取决于代理初始化参数，这意味着无法使用不同的参数抢先初始化账户，因为这将产生不同的账户地址。因此，到目前为止，初始化函数没有访问控制。

但是，当使用 EIP-7702 时，此过程有所不同。在此流程中，用户委托给单例参考实现，这大致相当于将代理部署到用户的 EOA 地址，该代理指向单例。核心区别在于 EIP-7702 本质上是一个代理，并且代理的“delegatecalling”由 EVM 本身处理。但是，就我们的目的而言，核心区别在于没有代理工厂，而是“创建代理”（即使用 EIP-7702 交易类型进行委托）不包含原子地初始化账户的方法。这意味着，如果我们使用现有的参考实现，则恶意行为者可能会在 mempool 中发现新的委托，从用户那里获取签名，并在抢先交易中提交它，攻击者可以在其中设置自己的初始化参数。

抢先交易保护的设计约束

在深入研究我们在参考实现中选择的特定解决方案之前，我将简要概述我们做出决策的要求，以及如果我们删除任何这些要求，结果可能会有何不同：

1. EIP-7702 和已建立的智能账户流程的一种实现

这减少了运营开销，更高的开销可能导致更多人为错误，例如委托给错误的（不安全的）实现，并增加了复合安全性的潜力。如果我们选择放宽此要求，我们甚至可能会为 EIP-7702 构建一个特殊用途的实现，例如，一个不需要初始化的实现。一些团队，例如 Safe，正在探索这一点，但由于上述原因，这低于标准。

2. 账户上的最小代码更改

我们希望现有账户从以前的版本中继承尽可能多的安全属性。

3. 受委托地址应为单例

这取决于钱包如何选择使用 EIP-7702。似乎极有可能的是，大多数钱包会手动选择使用某些实现，原因有两个：首先，由于委托是一种可能将整个账户的控制权交给恶意行为者的行为，因此需要审查委托目标。其次，钱包需要知道如何为委托的实现正确编码 calldata，因此它们需要手动允许具有不同 calldata 构建机制的实现。因此，钱包很可能会有一个简单的允许列表，供他们允许用户委托给这些实现。如果我们放宽此要求，则可以将略有修改的代理部署到用户的账户，该代理在其 字节码中包含初始化数据的哈希，它可以检查初始化是否被抢先交易并阻止它。

4. 委托和使用的最小 gas 开销

我们希望用户在创建委托和使用他们的账户时尽可能少的 gas 开销。这排除了使用代理，因为这会花费用户部署 gas 和运行时 gas，以及其他成本更高的解决方案。

5. 及时初始化

最后，我们希望保留已建立的智能账户流程中反事实地址的良好属性，即用户在第一次交易之前不需要进行链上交互。放宽此要求可能会使代码更改方面的初始化更容易，因为它不需要在第一个 UserOperation 中发生，但对于用户来说，当没有必要时需要立即进行交易感觉是一个相当大的缺点。

详细解决方案

该实现有两个核心组件：使用 EIP-7702 时的初始化逻辑和初始化函数的访问保护。基于上述要求，我们在 validateUserOp 函数中实现初始化逻辑。这意味着用户可以签署他们的委托交易，然后在他们的第一个 UserOperation 中，账户将被初始化。但是，我们的实现还允许用户继续仅使用他们的 EOA 私钥来签署交易，直到他们想要正确初始化他们的模块化账户并开始使用模块。虽然我们希望用户和应用程序能够相对较快地利用智能账户模块，例如会话密钥、Passkey或自动化，但这意味着用户最初可以使用他们的 ERC-7579 账户仅用于批量处理和 gas 抽象，然后再将其初始化为完整的模块化账户。

在验证 UserOperation 的逻辑中，账户需要检查用户尝试使用的验证器是否已安装。由于无论如何都会执行此检查，因此我们可以使用此条件来添加我们的初始化逻辑，从而在使用已初始化的账户时不会增加额外的开销。当未初始化时，用户只需使用其 EOA 签署 UserOperationHash。要初始化账户，用户可以对 initializeAccount 函数进行单个或批处理调用，并使用他们所需的配置进行设置。总的来说，此初始化逻辑大约有 8 行代码，并且不会为使用已初始化账户的基本流程增加开销。

我们更改的第二个组件涉及对 initializeAccount 函数的访问控制。以前，此函数不受访问控制保护，因为在已建立的智能账户流程中，它是在账户创建期间由工厂原子地调用的。基于第一个要求，即在已建立的智能账户流程和 EIP-7702 中使用一种实现，我们决定默认情况下访问控制此函数（除了允许账户调用该函数）。但是，当使用已建立的智能账户流程时，工厂会将一个值 tstore 到工厂中的某个槽中，这使其可以在此调用中仅调用 initializeAccount 函数。这意味着工厂可以在账户创建期间调用该函数，但否则该函数仍然受到访问控制，仅允许账户作为调用者。

结论

在本博客中，我们概述了我们对 ERC-7579 参考实现所做的更改，以使其能够安全地与 EIP-7702 一起使用。此方法的核心优势如下：

• 智能账户实现既符合 EIP-7702 标准，又与标准智能账户流程兼容，从而减少了运营开销、人为错误的潜在性并提高了安全性。
• 将委托地址维护为单例可确保与钱包供应商（例如 MetaMask）的预期合约白名单兼容。确保最大的互操作性和可组合性。
• 及时初始化允许钱包供应商继承基线 AA 功能，例如批量处理和 gas 抽象，而无需完全初始化智能账户模块化。这为希望逐步访问智能账户功能的供应商提供了更高的安全性。

我们希望这对计划进行类似更改的其他账户构建者有所帮助。如果你正在构建 ERC-7579 账户或升级现有账户，请联系我们 - 我们很乐意提供帮助！

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