确定性部署，第三部分：其他方法

这是关于确定性部署系列的第三篇也是最后一篇文章。在前两篇文章（1，2）中，我们涵盖了大量内容：托管私钥、Nick 的方法、预签名交易、CREATE2 factories 和 CREATE3。在本文中，我们将探讨一些额外的方法，其中包括几个相对较新且非常有趣的方法。

Preinstalls

我们目前讨论的所有方法都可供任何想要使用它们的人使用。然而，为了完整起见，我们应该提及在给定地址获取合约的另一种方式：在协议层面包含它。也就是说，合约存在于该地址仅仅是因为链的规则规定如此。以这种方式包含的合约通常被称为 preinstalls。1

这正是 OP Stack 链所做的：我们在上一篇文章中讨论的四个 CREATE2 factories，以及许多其他合约，无需通过交易部署即可使用。

Preinstalls 使链更具“开箱即用”的特性，但它们也可以作为有用的最后手段。考虑一个使用 Nick 的方法部署了多次的合约，但由于交易的 gas 限制过于严格而无法在某些新链中部署。在这种情况下，链可以决定在网络升级中将该合约作为 preinstall 添加。这并不是你会首先选择的方法，但了解此选项的存在是件好事。

RIP-7740

RIPs 是 Rollup Improvement Proposals，一种用于标准化不同 rollup 行为的机制。RIP-7740 简单地提议所有 rollup 在其常用地址 preinstall 一组 CREATE2 factories，以便任何人都可以指望它们的可用性。指定的集合正是我们上一篇文章中的四个合约：Arachnid's Deterministic Deployment Proxy, create2deployer, Safe Singleton Factory, 和 CreateX。

EIP-7997

EIP-7997 提议将一个 CREATE2 factory 作为一个 predeploy2 添加到以太坊 L1，并延伸到任何希望与协议保持同步的 EVM 兼容链。这将是一个行为类似于 Arachnid's Deterministic Deployment Proxy 的最小工厂。3

这种方法的一个有趣的特性是 predeploy 没有关联的 ECDSA private key，使其具有抗量子性。我们之前讨论的 CREATE2 factories 不提供这种保证：如果 ECDSA 被攻破，未来的攻击者可能会推导出 deployer key，并可能在部署到新链上的任何部署之前，使用其他代码进行 front-run。这是否是一个现实的担忧值得商榷（它需要 ECDSA 被攻破 并且 仍在创建新的 EVM 链），但无论如何，拥有这样一个清晰的属性是件好事。

ERC-7955

顾名思义，ERC-7955 是一个 ERC 而不是 EIP 4，这意味着它不需要对协议进行任何更改。相反，它提出了一种标准化的机制来执行确定性部署，并用它来引导一个 CREATE2 factory。

所提出的机制假设目标链中存在 EIP-7702 (Set EOA Account Code)。我们在这里不解释 EIP-7702，但让我们快速回顾一下对 ERC 很重要的两个方面：

• EIP-7702 允许 EOA 将自身“转换”为合约。更精确地说：发送到经过 EIP-7702 转换的 EOA 的任何交易都会导致对某个指定地址的 delegate call。

• 对于 EOA 来说，要委托其执行，它不需要自己发送交易。它只需要签署一个 authorization，并且该 authorization 需要包含在 EIP-7702 交易中，而该交易又可以从任何地址发送。

考虑到这一点，ERC-7955 的工作原理如下：

ERC-7955

一个众所周知的 private key（在图中对应 ERC7955EOA）用于签署一个 authorization，该 authorization 委托给 SomeCreate2Factory。该 factory 的地址或 code 都不重要，只要它能用于通过 CREATE2 部署合约即可。

一旦 EOA 被委托，一个交易就会发送到它（从任何账户）以部署另一个 factory：ERC7955Factory，这是我们真正希望在确定性地址拥有的 factory。关键的洞察是：当被委托的 EOA 被调用并它 delegate-calls SomeCreate2Factory 时，用于计算部署地址的“sender”参数是 ERC7955EOA，而不是来自 SomeCreate2Factory 的（就像在非 delegate call 中会发生的那样）。这就是为什么 factory 的身份不重要：最终的地址由众所周知的 EOA 地址、salt 和 init code 决定，所有这些都预先固定。

我喜欢将这种方法视为我们正在从 EOA 执行 CREATE2 opcode，这在 EIP-7702 之前是不可能的。这结合了 managed key 的地址稳定性与 CREATE2 的 nonce-independence。

ERC-7955 的一个巨大优点是无需保护 private key；事实上，该 key 是故意公开的。任何想要在新链中部署 factory 的人都可以使用它来签署所需的 EIP-7702 authorization。主要缺点是此方法需要 EIP-7702（一个相对较新的功能）可用。

还有一个更微妙的缺点。由于 private key 是众所周知的，任何人都可以使用相同的 nonce 签署不同的 authorization 并 front-run5 委托，暂时阻止部署。话虽如此，这并非致命缺陷：总是可以签署一个具有更高 nonce 的新 authorization，我们可以继续尝试直到一个成功。而且，面对顽固的攻击者，我们总可以使用 private mempool 来保证 authorization 被包含。

总结

我们涵盖了广泛的技术，从最简单的到最新的：

• Managed private keys、pre-signed transactions 和 Nick's method，它们基于正常的部署交易，在 key custody、replay protection 和 permissionlessness 方面具有不同的权衡。

• 基于 CREATE2 的方法，例如 CREATE2 factories 和 CREATE3。鉴于 CREATE2 factories 的广泛可用性，对于任何想要以确定性方式部署合约的人来说，这些应该是首要考虑的选项。

• 本文讨论的方法：基于 preinstall 的思路或巧妙的 ERC-7955。

值得指出的是，ERC-7955 和 EIP-7997 都是在不到一年前提出的。如果新方法不断涌现，这并不令人惊讶。

感谢阅读！如果你想在新文章发布时收到通知，可以订阅本博客。

订阅

1. 有关 precompiles、preinstalls、predeploys 和 system contracts 之间区别的详细解释，请查看我此处的回答。 ↩
2. 在此上下文中，preinstall 和 predeploy 之间没有太大区别。有关更多详细信息，请参阅上一个脚注中的链接。 ↩
3. 两者都使用 calldata 的前 32 字节作为 CREATE2 salt，其余作为 init code。但它们（至少）有两个小区别：1) EIP-7997 factory 返回 32 字节，而 Arachnid 的返回 20 字节；2) 如果合约创建失败，EIP-7997 code 会转发 revert reason，而 Arachnid 的则不会。 ↩

4. EIP 代表 Ethereum Improvement Proposal，而 ERC 代表 Ethereum Request for Comments。

   ↩

5. 由于 mempool 的内容是公开的，攻击者可能会看到包含由众所周知 private key 签名的 authorization 的交易，然后使用该 key 签署一个具有相同 nonce 的不同 authorization，并支付更高的 gas price 来激励 block builder 首先将其包含。一旦被包含，原始交易就会变得无效，因为它包含一个已被使用过的 nonce 的 authorization。

   ↩

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