ERC-4337 概述

ERC-4337，或称为“账户抽象”，是以太坊的一项提案，介绍了“账户”智能合约。账户抽象简化了以太坊账户的处理，为传统的外部拥有账户 (EOA) 和智能合约账户提供了一个通用接口。社交恢复、支付Gas费和交易安全是其中一些提议的改进。在这种新的方法中，用户不再被迫处理他们的私钥，并享有设置附加账户规则的灵活性，这提高了他们的安全态势。

在本文章中，我们将详细说明账户抽象相对于当前钱包解决方案的主要优势，以及对用户和开发者的安全考虑。

当前钱包管理解决方案

外部拥有账户 (EOA) 是以太坊区块链上的基本账户类型。只要拥有私钥，就可以完全控制与之关联的 EOA 的操作。虽然这允许与网络进行简单的交互，但也带来了管理私钥的固有挑战。一个简单的错误可能意味着资金的永久损失，而在链上，永久确实意味着永久。除此之外，还有Gas费的概念。这对大多数 Web2 用户来说是反直觉的，因为在现代 Web 或移动应用中，很少有按动作付费的情况。

鉴于这些挑战，已经实施了几种对基本 EOA 结构的替代方案和增强：

• Web 浏览器钱包: 直接集成到 Web 浏览器中，作为扩展或插件。例如 MetaMask 和 Coinbase 浏览器扩展。它们提供用户友好的界面，用于查看余额、执行交易以及直接从浏览器与 dApp 进行交互。在浏览器内运行使它们易受各种攻击的影响，包括网络钓鱼、XSS、社会工程等。
• 多签名 (multi-sig) 钱包: 这些是基于智能合约的钱包，需要多个私钥来授权交易。因此，即使一个密钥被破解，攻击者仍然需要访问其他密钥才能转移资金或执行关键操作。这里的例子包括 Safe、Argent 和 Armory 多签名钱包。
• 多方计算 (MPC) 钱包: 类似于多签名钱包，这种类型的钱包通过把单个私钥分割给多个参与者来分配交易授权。一些例子包括 ZenGo 和 Fireblocks。一些 MPC 实现使用新颖的阈值签名，其中只需要 n 个总签名中的 m 个。与多签名钱包不同，这种阈值属性是加密原语本身的内在属性，而不是编程中的智能合约约束。
• 硬件钱包: 像 Ledger 或 Trezor 这样的设备提供了物理安全层。它们将私钥离线存储，并要求在设备上进行物理确认以签署交易。妥善设计的硬件钱包中的密钥永远不应该离开设备。这使它们在面对在线黑客攻击时更加可靠。

虽然这些解决方案在一定程度上解决了与传统 EOA 相关的挑战，但它们也引入了自己的复杂性和权衡。例如，没有一种提供有效账户恢复机制的解决方案。有些使用的恢复密码也可能丢失或被盗， thus 仍然将所有责任留给用户。

首先，让我们开始讨论 ERC-4337 提案背后的理由，并讨论其一些好处。

账户抽象概述

账户抽象的核心是简化用户与以太坊网络的互动。它让新用户的学习曲线更平缓，否则他们可能会被以太坊的技术方面所吓倒。他们不再需要处理私钥，而交易批准程序可以委托给其他受信任的方。

与此同时，开发者在设计和实现 dApp 时的灵活性也得到了提高。账户抽象提供了改善用户体验的新方式。这些包括赞助Gas费、通过白名单特定地址进行交易合法性检查、通过社交登录进行身份验证（例如，“使用 Google 登录”）等。可以设置交易支出限额等账户规则，以消除在协议受到损害时剩余批准被滥用的可能性。

尽管开发功能丰富的账户抽象钱包涉及复杂性，但一般架构是透明的。实际上，只有一个“链下”组件，即新的内存池。其他所有操作均在智能合约中处理。与以往解决方案中所具备的所有外部组件相比，攻击面显著减少。

我们看到账户抽象带来了用户体验的重大改进，但当事情听起来过于乐观时，通常会有一些问题。让我们探讨一些开发者和用户需要了解的内容，包括潜在的安全隐患。

账户抽象交易的工作原理

在后台，典型用户交互中的以下步骤进行：

步骤 0: 用户将 UserOperation 发送到专为 ERC-4337 定制的特殊内存池。这个新的内存池是为了让用户不需要提前支付Gas费。捆绑者（本质上是 EOA）将从内存池中拾取新添加的 UserOperation 并将其添加到捆绑交易中。

步骤 1: 然后捆绑交易被转发到一个名为“Entry Point”的单例合约。

步骤 2: Entry Point 然后逐个调用每个用户账户合约（即继承自 IAccount 的钱包智能合约）上的 validateUserOP，验证捆绑中的每个交易。（为了简化，我们假设捆绑中只包含一个 UserOperation。）

步骤 3: 用户的账户合约根据其在 validateUserOp 函数中设置的规则，返回所请求验证的 UserOperation 是否有效。

步骤 4: 如果有效，Entry Point 验证用户账户是否已支付足够的Gas费，然后再调用 execute 返回用户账户合约。

→ 如果无效，终止执行并将适当的响应返回到 Entry Point 合约。

步骤 5: 用户账户合约然后使用实际的 UserOperation 中提供的 calldata 和目标执行低级调用，完成执行链。

这一简单架构有几个增强。其中之一是 Paymasters 的使用，它负责任务交易的费用赞助。在这种情况下，在步骤 4 中，Entry Point 将验证 Paymaster 是否提供了足够的Gas费用，以覆盖正在验证的特定 UserOperation。这对关注用户采用的项目来说可能至关重要，因为以太坊区块链上的交互将更加无缝，类似于当前的 Web 和移动应用。或者，用户也可以被允许使用稳定币支付Gas费用，以获得更熟悉和方便的定价方案。

将交易执行逻辑移入智能合约增加了开发者的安全责任。在开发账户抽象钱包时，我们提出了几项安全考虑。

开发者需要知道的事项

正如我们在上一部分中看到的，为了支持 ERC-4337（即账户抽象）标准，钱包合约必须实现 validateUserOp 函数。

interface IAccount {
  function validateUserOp
      (UserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds)
      external returns (uint256 validationData);
}

validateUserOP 函数应确保所有以下事项：

• 确保↗ 函数调用来自单例 EntryPoint（即 require(msg.sender == EntryPoint);），以防止伪造调用。
• 确保用户操作根据 userOpHash 是有效的。↗ 主要是为了防止恶意的 UserOperations 代表用户账户钱包执行。此外，在签名不匹配时返回 SIG_VALIDATION_FAILED（勿 还原），根据标准↗。在任何其他类型的错误中还原。
• (如果不支持 Paymaster) 至少向 EntryPoint（msg.sender）支付 missingAccountFunds，确保费用已支付给特定的↗ userOp 交易。
• 返回值应为（authorizer，validUntil，validAfter）的打包编码。
  • authorizer - 有效签名为 0，标记签名失败为 1。否则，是 authorizer 合约的地址。ERC 定义“签名聚合器”为授权者。有关签名聚合器的更多细节可以在这里找到↗。
  • validAfter 和 validUntil 是六字节时间戳。UserOp 只有在 validUntil 之前或在 validAfter 之后，或者在 validAfter ... validUntil 范围内有效。

供参考，ERC-4337 核心团队已实现 SimpleAccount.sol↗ 示例账户合约，并在其中设置了所有必要检查。随着时间的推移，开发者将开始为默认的 ERC-4337 原型开发不同的改进，我们预计以下安全考虑将派上用场：

• 可升级性: 由于账户抽象的多数组件是智能合约，因此可以安全地假设项目将使它们 可升级。 需要注意的错误包括在存储变量与重写之间的管理不善和业务逻辑上的迁移函数处理不当。在这条 Twitter 线程↗ 中，我们描述了导致超过 6,000,000 美元资金丧失的存储碰撞漏洞。最近，我们还发现了一个问题，这会在合约升级后永久锁定合约。
• 重入攻击: 赞助Gas费的实现是安全地实施的棘手问题。会有一个 Vault 拾取 UserOperations、支付煤气，并转发交易吗？还是会有某种基于许可的交易？无论如何，我们预计协议将选择自定义 Paymasters，或许允许 ERC-20 转账、交换等。考虑到这一点，这里最可能的攻击面是重入，因为 Paymasters 将通过对外部合约的调用和回调转发某种Token，可能是原生或 ERC-20。
• 抢跑: 由于交易将在特殊内存池中公开可用，因此抢跑攻击将是普遍存在的，无论交易最终如何被捆绑和执行。
• （对于第三方合约）对 tx.origin 的依赖: 用户将通过合约而不是实际的 EOA 交易；因此，tx.origin 将不再与 msg.sender 匹配。任何仅针对 EOA 的检查将因此变得过时，所有希望提供账户抽象钱包支持的协议都必须支持必要的修改。所有智能合约开发者，即便是不直接参与 ERC-4337 的人，也应该意识到这一点。

用户需要知道的事项

就其本身而言，账户抽象不会给用户带来更多的安全风险。作为一项 ERC，标准代码将受到严格审计，出错的空间最小。然而，默认实现并没有涵盖我们在本文中讨论的所有功能。因此，在实现交易支出限额、社交恢复↗ 或身份验证等功能之前，仍需大量的开发和定制。正如我们所知，智能合约往往被证明是不安全的。选择一个关注安全的账户抽象钱包解决方案仍然需要仔细的审查。

总结

账户抽象的目标是简化实现账户抽象般用户体验的过程。无需集中组件便可以为默认 EOA 提供有效替代。这是开发者将更多用户引导到以太坊的一次机会，因为操作账户所需的技术知识将减少。这种简化并不直接转化为无错误的代码。然而，通过减少可能的外部攻击面，开发者现在需要处理的沙盒更小，安全不变性更容易定义。我们认为账户抽象是迈向更安全和抗风险以太坊生态系统的重要一步，为额外的用例和用户体验铺平了道路。

关于我们

Zellic 专注于保护新兴技术。我们的安全研究人员在最有价值的目标中发现了漏洞，从财富 500 强企业到 DeFi 巨头。

开发者、创始人和投资者信任我们的安全评估，以快速、自信地交付，而不产生关键漏洞。凭借我们在现实世界中的攻击性安全研究背景，我们能够发现他人所遗漏的东西。

‍ 联系我们↗，获取优于其他审计的审计，真实审计，而非走过场。

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