Paradigm CTO：解读以太坊坎昆升级之后的布拉格硬分叉

Foresight News ｜2024-01-19 8:00

我们认为布拉格硬分叉可能会于 2024 年第三季度在以太坊测试网上实现，并于年底在主网上完成。

撰文：Georgios Konstantopoulos，Paradigm CTO

编译：Luffy，Foresight News

本文的目的是概述 Paradigm Reth 团队对于布拉格硬分叉（坎昆硬分叉后以太坊的下一次重要升级）应包含哪些 EIP 的看法，以及我们 2024 年「EL Core Dev」的总体计划（译者注：EL 指执行层，CL 指共识层）。以下观点还在不断演变，仅代表 Reth 团队当前的观点，并不一定代表整个 Paradigm 团队。

我们认为布拉格硬分叉可能会于 2024 年第三季度在以太坊测试网上实现，并于年底在主网上完成。它应包括：

与质押相关的 EIP，例如支持重新质押和无需信任质押池的 EIP-7002。
单独的 EVM 变化。
我们愿意与任何想要进一步研究布拉格或其他未来 EL 硬分叉的团队合作，并乐意在修改 Reth 代码库的地方提供指导和帮助。

要做什么：

我们认为必须优先考虑以下 EIP：7002、6110，2537。
我们支持规范中描述的 EOF，希望尽快最终确定范围并创建元 EIP。
我们愿意增加 EIP-4844 Max Blob Gas。我们对具体的数字没有看法，但我们邀请数据人员与我们合作研究该主题。
我们愿意发布 EIP-7547 的版本：它包含一个帮助基础层抗审查的列表。

不要做什么：

我们不支持布拉格硬分叉中加入 Verkle Tries，但支持客户端团队在 2024 年第 2 季度开始为此努力，并承诺将于 2025 年的大阪升级中发布。
我们认为不应该增加 L1 执行 Gas 限制或合约规模，但我们邀请数据人员与我们合作调查它对网络的影响。我们愿意改变我们的看法，因为过去的测试表明 Reth 节点可以毫无问题地处理增加的负载。
我们认为钱包 / 账户抽象 EIP 需要进行更多彼此之间的对抗测试，以更好地了解权衡空间。如果它们不相互排斥，那么我们将愿意在未来部署多个与 AA 相关的 EIP。
如果社区同意谣传的 NSA 后门，我们可以越过 EIP-7212 (secp256r1) 上的线路。
其他路线图主题：我们对 CL EIP 或 CL/EL 分叉的耦合没有实际了解，但 EIP 7549 和 7251 看起来很有希望。我们还希望尽可能从 EL 方面为 PeerDAS 的工作做出贡献。目前我们希望避免引入 SSZ 根（EIP 6404、6465、6466）。最后，我们发现有机会针对过期的 blob、历史记录和状态提供长期数据归档解决方案，因为 EIP-4844 和 EIP-4444 都明确说明了这一点，以太坊是否愿意提供这样的解决方案还有待确定。

下面详细展开。

要做的事

抽象地说，我们支持 1) 进一步缩小 CL 和 EL 之间的差距，2) EVM 修改可以作为单人工作执行，并且可以单独和并行测试。

EIP-7002

该 EIP 通过使 EL 侧的智能合约能够控制 CL 侧的 1 个或多个验证器来解锁无需信任的重新质押和质押池。在我们看来，它至少将使现有的质押池能够从实现提款的智能合约中消除一层中心化。

将有状态预编译引入 EVM 是我们需要在 EVM 实现中获得的新抽象，但除此之外，我们认为这是一个可以直接执行的 EIP。

EIP-6110

该 EIP 引入了 EL 状态中的存款，简化了需要在 CL 上完成的状态管理。在实施方面，这类似于跟踪 CL 提款，因此总的来说，我们认为这也是一个简单且独立的 EIP。

EIP-2537

目前 BLS12-381 有多种实现，它是许多 SNARK、BLS 签名算法和 EIP-4844 中经常使用的曲线。我们认为它实现复杂度很低，因为它只是通过预编译接口公开曲线的验证算法。我们可能还需要 BLS12-381 曲线预编译的哈希值。

EOF

译者注：EOF 全称 EVM Object Format，译为以太坊对象格式，包含一系列 EIP，承诺使以太坊执行更高效、更一致且更可升级。早期计划在上海升级中实施，后被删除。

EOF 将同时支持 Solidity 和 Vyper。毫无疑问，代码格式和验证调整将使字节码分析变得更加简单，我们建议仔细考虑除此之外的事情。我们在下面推荐了一些 EIP，但我们愿意进一步调整。

好的方面：

仅限 EVM 的更改，可以使用以太坊 / 测试网进行测试并由单人实施。
Vyper 和 Solidity 想要的 EVM 改变
有助于提高性能和增加合约规模限制。
消除了 EVM 在运行时进行字节码分析的需求。在不涉及缓存的情况下，分析的时间可能高达 50%，并且随着合约大小的增加而增加。
启用部分代码加载，有助于执行大型智能合约。
Devex：将允许通过 dupN/swapN 和其他工具改进来修复「堆栈太深」的问题。
面向未来：可以安全地跨 L2 引入新功能，并且工具会知道什么是兼容的。

不好的方面：

范围和动态目标。
没有支持者大力推动将其纳入其中。
仍然需要支持遗留代码
在采用之前，以太坊主网和其他 EVM 链之间存在暂时分歧。

我们认为以下 EOF 功能应在 2024 年部署。我们建议尽快确定范围并承诺实施。后续部署应该考虑其他任何事情。我们的建议是：

EIP-3540（EOF - EVM 对象格式 v1）：引入代码和数据容器，并向以太坊字节码添加结构和版本控制。
EIP-3670（EOF - 代码验证）：拒绝部署时不遵循 EOF 格式的任何合约。执行更结构化的代码并禁用无效和未定义的指令。
EIP-663（无限的 SWAP 和 DUP 指令）：这解决了 solidity 中的「堆栈太深」问题，并且通过 JUMPDEST 分析作为即时值有副作用。evm 语言非常想要的功能。
EIP-4200（EOF - 静态相对跳转）：更好的静态分析，没有不确定的跳转。更好的 aot 编译。相对跳转更有利于代码重用。
EIP-4750（EOF - 函数）：需要解决可以使用动态跳转但不能使用静态跳转的子程序。它还允许部分代码加载，这与 Verkle 完美配合，提升合约规模限制。
EIP-5450（EOF - 堆栈验证）：验证代码和堆栈要求。删除除 CALLF 之外的所有指令的运行时堆栈下溢和溢出检查 (EIP-4750)
EIP-7480（EOF - 数据部分访问指令）：允许访问字节码的数据部分。
EIP-7069（改进的 CALL 指令）：能够从 CALL 中删除 Gas 的可观测性，从而使将来能够更轻松地重新定价 Gas。虽然独立于 EOF，但我们认为这是引入它的好机会。

我们不太确定 EIP-6206（EOF - JUMPF 和非返回函数）。虽然它允许在 EOF 函数中进行尾部调用优化，但我们仍然需要看到语言分析它的作用。如果我们没有，我们认为可以将其从范围中删除并包含在后续 EOF 更新中。

我们估算上述工作量为 1 人全职工作 1-2 个月。我们愿意进一步缩小上述范围。

关于遗留字节码的注释：

虽然我们可以禁止新的遗留 / 非 EOF 字节码，但无法弃用现有的遗留字节码，它实际上充当 EOF「v0」。遗留字节码仍然需要 EOF 后的 JUMPDEST 分析，并且仍然需要特殊的代码处理以将其分段为 Verkle Tries 中的块。
据我们所知，如果不访问源代码，就无法验证从非 EOF 字节码到 EOF 的转换，但我们愿意研究促进这种转换的机制。
或者，我们愿意探索强制状态迁移到 EOF 的方法。

增加 EIP-4844 Blob 数量

我们对这一更改持开放态度，这将对应于 MAX_BLOB_GAS_PER_BLOCK 和 TARGET_BLOB_GAS_PER_BLOCK 的增加。 EIP-4844 中的相关内容为：

选择 TARGET_BLOB_GAS_PER_BLOCK 和 MAX_BLOB_GAS_PER_BLOCK 的值以对应于每个块 3 个 blob (0.375 MB) 的目标（最多 6 个 blob）。这些小的初始限制旨在最大限度地减少该 EIP 对网络造成的压力，并且随着网络在较大区块下展现出可靠性，预计 blob 数量会在未来的升级中增加。

实际上，这是一个小的代码更改，我们需要调查它在交易池中的实际影响，但我们认为我们可以为此重新使用 EIP-4844 压力测试基础设施。 CL 可能很难传播更多的 blob，我们尊重 CL 队伍的意见。

不要做的事

Verkle Tries

TL;DR：我们看不到 2024 年底 /2025 年初部署 Verkle 的尝试。我们建议团队在 2024 年第二季度为此分配资源，并承诺在 2025 年第二季度至第三季度在大阪硬分叉中部署。

好的方面：

通过更小的存储证明实现更便宜的轻客户端。
通过在区块头中包含读取预状态来进行无状态执行，这也可能由于静态状态访问而导致性能提高。
通过对字节码进行分块并启用部分代码加载来提高合约大小限制。
由于「恢复」状态的成本较低，状态到期变得更容易接受。

不好的地方：

变化的影响以及实施和测试的努力。
Gas 计算变化：Verkle Tries 将见证者的大小引入到 Gas 计算功能中。我们担心存储定价的变化尚未被探索（例如，Verkle 之后顶级 Gas 消耗者的成本是多少）？
应用程序集成：当 Overlay 过渡运行时，具有 Merkle Patricia Trie 验证者的应用程序应该做什么？ eth_getProof 应该如何表现？

虽然我们了解 Verkle Tries 的好处，但我们认为需要更多地考虑第三方工具 / 合约需要如何适应，以及过渡期间会对 Layer 2 等产生什么影响。最初我们对迁移策略有疑问，因为它规定当从预先存在的 MPT 读取状态时应该更新 Verkle trie，但情况似乎不再如此了。因此，我们支持 Overlay 方法作为可行的迁移路径。

Verkle 迁移策略的文档似乎已经过时，因为大多数资源仍然指出从 MPT 读取状态时应该更新 Verkle trie，。我们希望看到采用最新方法的过渡文档，例如这篇优秀的文档。我们还希望看到有关过渡策略的 EIP 草案。

因此，我们仍然支持其在 2025 年推出，而不是布拉格硬分叉中部署。