保障以太坊 EIP-7702 升级：一种安全 EOA 到智慧钱包过渡的代理模式

我们开发了 EIP7702Proxy，这是一个轻量级的 ERC-1967 proxy 合约，旨在用作 EOA 的 EIP-7702 委托代理基本逻辑转发….可解决 EIP-7702 委托帐户特有的一些挑战。本文源自 登链社区 所着文章，由 foresightnews 整理、编译及撰稿。 （前情提要： 以太坊Pectra升级「骇客爽翻」，Wintermute警告：EIP-7702使大量合约部署自动化攻击） （背景补充：以太坊基金会「一兆美元安全计划」发布首份报告：梳理智能合约、基础设施与云安全…六大生态挑战 ） EIP-7702 使简单的以太坊钱包（EOA）能够升级为智慧合约钱包，从而提供更高的安全性、高阶功能、Gas 赞助的机会和其他好处。从历史上看，智慧钱包必须从头开始建立，但随着 EIP-7702 的引入，传统的钱包可以升级，并保留其所有的资产和链上历史记录，且保持相同的钱包地址。这就像从座机切换到智慧手机而无需获得新号码一样。 EOA 通过设定 「委托指定（delegation designation）」，即指向委托智慧合约（delegate smart contract）的指标来进行升级，然后委托智慧合约的逻辑来管理 EOA。因此，升级后的 EOA 可以拥有函式、设定储存、发出事件以及执行智慧合约可以执行的所有其他操作。EOA 可以随时通过新的、已签名的 EIP-7702 授权来更改或删除此委托。虽然这解锁了许多新的可能性，但这个强大的功能也引入了新的安全挑战，需要仔细考虑和创新解决方案。 为了使 EOA 能够充当智慧合约钱包，我们开发了 EIP7702Proxy，这是一个轻量级的 ERC-1967 proxy 合约，旨在用作 EOA 的 EIP-7702 委托。除了代理执行的基本逻辑转发之外，EIP7702Proxy 还包含其他功能和设计选择，可以解决 EIP-7702 委托帐户特有的一些挑战。设计 EIP7702Proxy 的一个目标是使 「标准部署」 的 Coinbase 智慧钱包和 EIP-7702 委托的 Coinbase 智慧钱包之间尽可能地保持对等性，这意味着将 EIP-7702 机制所需的额外复杂性抽象到专用代理中，并继续依赖 CoinbaseSmartWallet 的原始实现。这种挑战的解决方案可以有效地应用于任何实现逻辑，而不仅仅是 CoinbaseSmartWallet 实现，同时还有助于 EOA 在启用 7702 的环境中保持安全。 下面我们将介绍具体的挑战和相应的设计解决方案，这些解决方案使我们能够安全地调整任何现有的智慧合约钱包实现，以用于 EIP-7702 升级。 挑战 #1：强制执行安全初始化 实现 EIP-7702 的第一个主要障碍来自其初始化约束。传统的智慧合约钱包（包括 CoinbaseSmartWallet）通常通过单独的工厂合约在其部署期间原子地处理安全初始化（建立帐户所有权）。这种原子性意味着许多此类实现都具有未受保护的 initializer 函式，这些函式只能被呼叫一次。但是，EIP-7702 的设计不允许在程式码委托过程（与 「部署」 相当的步骤）期间执行初始化 calldata，因此无法原子地完成此操作。 这种步骤分离会产生一个关键的漏洞视窗。当通过 EIP-7702 将实现合约 「部署」 到 EOA 时，无法保证此 7702 升级和初始化钱包的标准 EVM 交易将原子地执行。从技术上讲，即使同时提交，设定授权的程式码也可以独立于初始化交易应用，这可能允许攻击者抢先执行初始化交易并宣告智慧帐户的所有权。 解决方案：需要 EOA 签名以原子地设定 implementation 并初始化 请注意，现有的 Coinbase 智慧钱包部署在带有 UUPSUpgradeable 实现（实际的 CoinbaseSmartWallet 逻辑）的 ERC-1967 proxy 之后。实际帐户地址中的程式码是一个代理，该代理使用 ERC-1967 定义的常规储存位置来储存指向其实现逻辑的指标。我们针对 7702 上下文中的初始化漏洞的解决方案包括认识到任何实现逻辑只有在代理实际建立与其的连线时才会变为活动状态（因此才有危险）。因此，如果我们不能强制执行原子性的部署和初始化，我们可以强制执行原子性的实现设定和初始化。 EIP-7702CoinbaseSmartWallet合约架构和逻辑委托流程 在 EIP-7702 的上下文中，EOA 本身是对其帐户进行任何更改的初始许可权，并且必须提供签名以授权初始化并建立新智慧帐户的任何所有者。我们的 EIP7702Proxy 合约实现了一个 setImplementation 函式，该函式可以原子地设定新的逻辑实现并初始化帐户。setImplementation 函式： 验证来自 EOA 的签名，其中包括关键资料，例如新 implementation 合约的地址、初始化 calldata、将评估最终帐户状态的安全性的验证器合约的地址，以及基本的签名可重放保护，例如 nonce 和过期时间。 将 ERC-1967 指标的值设定为新的 implementation，并针对新的逻辑 implementation 执行提供的 calldata。 呼叫 validateAccountState 函式，该函式必须由签名中包含的验证器实现。 验证器是一个特定于 implementation 的合约，其中包含用于评估其是否认为最终帐户状态安全的逻辑。例如，对于 CoinbaseSmartWallet，CoinbaseSmartWalletValidator 将检查帐户的所有权状态是否为非空，因此不再容易受到任意初始化的影响。 挑战 #2：跨 EIP-7702 委托的共享储存 EIP-7702 最复杂挑战可能与储存管理有关。EOA 可以随时自由地将其逻辑重新委托给不同的合约，或完全删除委托。所有委托共享 EOA 地址上的...