来源 | mirror.xyz/luozhu.eth

作者 | @LuozhuZhang

翻译 | Franci, ECN

译者注：本文撰写于 2022 年 12 月 31 日，文章基于第 151次 ACD 会议确定的工作计划展开，因此与目前的路线图有出入。需要注意的是，在 2023 年 1 月 5 日进行的第 152 次 ACD 会议中确定，EOF 相关的 EIP 被移出上海升级。更多关于 #152 ACD 会议的中文笔记请看 ECN 的整理：#152 以太坊核心开发者会议笔记。上海升级的规范请看此处：https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md#eips-considered-for-inclusion。

特别感谢 proto.eth 的帮助和宝贵意见。

目录

➤ 背景

➤ 升级的主要内容

• 信标链提款

• EOF

• EIP-4844

• 其他 EIPs

➤ 路线图和时间线

• 时间线

• Shanghai + Capella 升级

• 下一个升级：坎昆升级

➤ 总结

背景

我受到 CC 和 Vitalik 的启发而撰写了此文。

他们一致认为，学习以太坊的最好方法是观看核心开发者会议 (All Core Devs)，阅读相关的会议记录，查看 hackmd 文档、issue、PR 以及 EIP，直到你弄清楚以太坊当前的路线图状态、核心开发者的关注点和担忧点以及每个升级/EIP 的作用是什么…

除此之外，我还受到了社区的启发。

以太坊有着优秀的开源文化，你可以在 EF YouTube 上看到所有的会议视频，以及在 ethereum/pm 查看未来讨论的议程 (还可以看 Tim 和 Kim 的笔记)。以太坊的开发者们正在尽最大的努力让社区了解以太坊目前的升级和其改进提案。

所以我认为撰写这类文章对社区是非常有价值的！

升级的主要内容

2022 年 9 月 15 日，以太坊成功合并后便将其注意力转到后续的改进提案中：执行层上的上海升级；共识层上的 Capella 升级。

主要有以下几点👇

• 信标链提款

• EOF

• EIP-4844

• 其他 EIP

他们扮演着不同的角色。信标链提款是上海升级的核心，而 EOF 只有在提款不会受到影响而延迟的情况下才会被纳入到上海升级中。(译者注：最新的 ACD 中确定 EOF 从上海升级中移除)

此外，由于 EIP-4844 可能会影响提款的推进时间，它已经被移出了上海升级的范围 (译者注：EOF 也是这个原因而被移出上海升级)。但是我们都知道 EIP-4844 是以太坊的一个重要改进提案，所以它将是下一次升级 (坎昆升级) 的重心。

以防读者们是首次了解上海升级，我将在本文中单独解释相关的术语和 EIP。

信标链提款

理解 “提款” 需要对信标链的历史和演变有一些基本的认知。

信标链还没推出

在信标链推出之前，以太坊是一条完整的单一型区块链，它的共识引擎 (PoW) 和执行引擎 (EVM) 在一起工作，没有耦合和分离。

单一型的链

阶段0

信标链在阶段 0 (2020 年 12 月) 推出。

自此，以太坊由单一型区块链转变为两条平行链的结合 (即信标链和执行链)。

在它们之间通信的唯一方式就是存款合约，存入并锁定 32 个 ETH 以成为一名验证者 (这个角色类似于 PoW 机制下的矿工)。

合并前

Altair 升级

很快，信标链在上线两周内迎来了首次硬分叉，也就是 Altair 升级。这次升级做了一些简单的修复(共识层升级以星星的名字命名)。

Bellatrix 升级

第二次硬分叉升级是 Bellatrix，合并就是在此次升级进行的：信标链与执行链合并。

合并后，以太坊从两条平行链变成一条链，但还是由两层组成，即共识层和执行层。这两层通过引擎 API 通信。

在终结总难度值 (TTD)58750000000000000000000中，Bellatrix 升级 (在共识层发生) 和 Paris 升级(在执行层发生) 同时推出。通过 EIP-3675 和 EIP-4399，以太坊成功从 PoW 共识过渡至 PoS 共识！

合并后

Capella 升级

这是信标链的第三次硬分叉升级 (以 Capella 星星 命名)，它会与上海升级 (执行层) 同时进行。通过 EIP-4895，实现从信标链提款至 EVM 的功能。

这也是目前共识层和各个客户端团队的主要工作。升级完成后，所有验证者都可以提出他们的 ETH。信标链的总存款已经超过了 15,741,431 ETH，验证者能够动态变化对于以太坊经济层来说非常重要。

总存款

EVM 对象格式 (EOF)

作为 EVM 的超级爱好者，我相信很多人对 EOF 期待已久。几年前，就有关于 "以太坊账户版本化" 的讨论和改进提案。直到现在，EOF 就要成为现实，确定纳入到上海升级的范围内 (实际上，EVM 自创世区块以来就没有改变多少)。

(译者注：最新的 ACD 中确定 EOF 从上海升级中移除)

简单地说，目前的 EVM 只有一套解释和验证规则来处理所有现有的合约 (我们将它们称为 “旧式合约”)。

EOF (包含 5 个 EIP) 引入了一种新的智能合约格式，即 “EOF 合约”。而客户端/EVM 解释器也有相应的更新。

所以我们现在有两套 EVM 解释和验证规则，并且它们是平行存在的。EVM 将能够同时处理旧式合约和 EOF 合约 (在更长远的未来，我们可能会用 EOF 合约取代所有的旧式合约)。

为什么需要 EOF，它有什么好处？👇

➤ EVM 版本化。这使得引入或移除功能变得更容易，防止 EVM 变得越来越复杂和不优雅。现在移除 EVM 的功能非常困难，因为庞大的生态系统/应用层依赖某个特定的 EVM 行为，所以移除可能会导致应用层的不兼容性问题。所以如果向 EVM 添加某个功能，我们需要默认它可能会永远存在。

➤ 增加新的控制流操作，完全放弃动态跳转和运行时的 JUMPDEST 分析，性价比更高。(并使代码转换更容易，等等。)

➤将 EVM 在运行时验证的内容 (e.g. 堆栈underflow,overflow) 转移到部署时间。这使得 EVM 的开销降低，并使合约代码更加安全 (潜在的错误不会被部署在以太坊上)。

➤ 代码和数据分离。我们将有一个可执行但不可读的代码部分，以及一个可读但不可执行的数据部分。

此外，EOF 主要由 5 个 EIP 组成，我将简单介绍每个 EIP 的作用。如果读者想了解更多关于 EOF 的信息，我建议大家去看过去的讨论，比如 "EVM 封装格式" 和 "关于 EVM 的一切"，以及这五个 EIP (这里有一个统一的规范)。这些资料都非常有帮助！👇

➤ EIP-3540: EVM 对象格式 (EOF) v1 (EVM Object Format, EOF v1)

这个 EIP 引入了 EOF “container” 并规定了所有包含在 EOF 合约中的字段 (在这里可以查看完整的字段)。此外，它依赖于 EIP-3541，这个 EIP 确保 EOF 格式的合约部署在上海升级前会被拒绝。

➤ EIP-3670: EOF - 代码验证 (EOF - Code Validation)

这个 EIP 在 EIP-3540 的基础上，为 EOF 合约添加更多的验证规则。无效的 EOF 代码无法被部署，在这里查看所有代码验证规则。

➤ EIP-4200: EOF - 静态相对跳转 (EOF - Static relative jumps)

这个 EIP引入了一些新的跳转指令 -RJUMP、RJUMPI和RJUMV，它们被用来指向已执行代码的相对位置。通过这个 EIP，我们可以初步删除 JUMPDEST 分析 (动态跳转JUMP和JUMPI)。

➤ EIP-4750: EOF - 引入函数 (EOF - Functions)

这个 EIP在 4200 的基础上更进一步，它引入了 “EVM 函数” 的概念 (这是一个独立的子程序)，并且引入了CALLF和RETF来调用 & 返回 EVM 函数。通过 EIP-4750和 EIP-4200, 我们可以完全抛弃 JUMPDEST 分析 (动态跳转 JUMP和JUMPI)。

➤ EIP-5450: EOF - 堆栈验证 (EOF - Stack Validation)

这个 EIP添加了更多验证规则，并将堆栈underflow/overflow、inefficient gas 等从运行时检查转移到部署时检查。这可以进一步减少 EVM 的开销 (目前的underflow/overflow是由 EVM 解释器在运行合约代码时检查)。

我个人认为，EOF 对 EVM 来说是一个重大的改进，所以我希望在上海升级中能部署 EOF (在不影响提款推进的前提下)。

至于 EOF 路线图，我们将在初期同时保留旧式合约和 EOF 合约，然后将现有的旧式合约转换成 EOF 合约 (显然后者不会是我们优先考虑的)。但这可能会对 zkEVM 产生一些影响。👇

➤ 取决于 EOF 合约的数量。如果大部分合约是旧格式的，现有的 zkEVM 不需要做太多修改就可以与 EOF 兼容。

➤ 如果所有现有的合约都转换为 EOF 合约，我们需要在所有电路中增加与 EOF 相关的约束条件 (比如数据和代码的分离，这可能会改变现有的字节码电路)。

➤ 对于操作码来说，JUMP和JUMPI可能会被废弃，因为 EOF 禁用了动态跳转。而根据 Vitalik 的提案，CODECOPY和CODESIZE也可能在未来被抛弃。另外，我们需要为新的操作码编写约束 (例如RJUMP、RJUMI、RJUMV、CALLF、RETF 等等)。

但总的来说，zkEVM 总是需要随着 EVM 的变化而变化 (zkEVM 服务于 EVM)，而当 zkEVM 用于 Layer1 (类型一 zkEVM)，每次 EVM 升级也会把 zkEVM 考虑在内，并且同时升级 (EVM + zkEVM) 是有可能的。所以我认为保持 zkEVM 更新不是什么大问题。

至于 EOF。未来还有许多改进，比如考虑禁止 EOF 代码被CODECOPY、CODESIZE、EXTCODECOPY、EXTCODESIZE和EXTCODEHASH直接读取，并实现 EVM 版本的自动-强制转换 (版本 n 的代码可以自动转换为版本 n+1)。EVM 代码甚至可以转换为其他 VM 代码的等价物。

如果我们将来决定从 EVM 转变为其他 VM (例如 WASM、Cairo 等)，就有可能自动将 EVM 的代码转变为具有同等功能的新虚拟机的代码。

EIP-4844

EIP-4844 完全是为 Rollup 设计的，以进一步降低数据提交和验证的开销 (根据 L2fee，L2 的交易费已经比 L1 便宜 4-20 倍)。

Proto-danksharding 来自 proto.eth 在 ETH Denver 中对 完整版 Danksharding 的简单实现。它比完整版的 Danksharding 更容易实现，这对以太坊扩容来说非常重要。

虽然 EIP-4844 已经足够简单了，但是它的实现仍广泛涉及以下几个方面。👇

• EIP 本身(已完成)

• 共识规范(正在进行, 大概完成)

• 引擎 API 规范(已完成)

• 客户端实现(正在进行，参考Geth和Prysm)

• KZG 仪式(已完成，在这里参加)

• 工具、开发者测试网 (正在进行, 大概完成)

• 测试(正在进行)

EIP-4844 的工作进展

虽然 EIP-4844 的进展非常快，但仍有许多工作要做 (包括客户端实现和大量测试)。以防 4844 的推进会使得提款的进程延迟，在 ACD#151 中开发者们决定将 EIP-4844 移除出上海升级 (但 Péter Szilágyi 和 Dankrad Feist 对此表示反对)。

EIP-4844 是以太坊的下一个关键改进，我们都知道它的重要性。这也是为什么上海升级之后的下一次升级中 (坎昆升级) 将以 EIP-4844 为重心。

其他 EIP

除了提款和 EOF，上海升级还会部署三个独立的 EIP👇

➤ EIP-3651: Warm COINBASE (降低访问COINBASE 地址的 gas 开销)

这个 EIP作为EIP-2929的补充，为交易执行的开始增加了一个COINBASE地址。

➤ EIP-3855: PUSH0 instruction (新增操作码 `PUSH0)

这个 EIP 引入了一个新的指令PUSH0，用来把常量0值压入堆栈中。

➤ EIP-3860: Limit and meter initcode (对 initcode 的大小设限并引入 gas 计量)

这个 EIP 扩展了 EIP-170。它限制了 initcode 的大小上限在49152的位置，并为 initcode 引入每 32 字节 2 gas 的开销。

路线图和时间线

作者 LuoZhu 对路线图和时间线的最新补充：

➤ EOF 从上海升级中移除，会不会在坎昆升级部署需要看 1 月 19 日的 ACD 会议

➤ EOF 可能不会推进的这么快，比如配合 EOF v2 和一个比较完整的路线图

时间线

基于 12 月 8 日 ACD #151 会议，确定的以太坊升级时间表大致是这样的👇

一月

在 1 月 5 日 (下一次 ACD 会议#152) 前完成 EOF 的客户端实现和测试，在 1 月 12 日为上海升级进行影子分叉，在 1 月 19 日 (第 153 次 ACD 会议) 前完成 EOF 的跨客户端互操作。

二月

2 月份将进行更多的测试，以确保 EOF 和提款足够稳定。并在公共测试网 (Sepolia、Goerli 等) 上部署提款功能。

三月

发布上海升级 (主网上的信标链提款！)。🎉

四月

重点转移到下一次的坎昆升级 (以 EIP-4844 为中心)，全面测试 EIP-4844。如多个主网影子分叉，并使 EIP-4844 进入公共测试网。

五月

发布坎昆升级 (EIP-4844 上主网! )🎉

升级时间线

Shanghai + Capella 升级

这次升级的核心是信标链提款。为了避免任何阻碍提款的可能性，EIP-4844 从上海升级中移除 (你可以在这里看到完整的上海升级规范)。

而 EOF 的开发进展需要严格遵守上述时间线，否则将被移除。两个比较重要的时间点是：2023 年 1 月 5 日 (ACD #152，EOF 需要完成客户端的实现和测试) 和 2023 年 1 月 19 日 (ACD #153，完成 EOF 跨客户端的互操作)。

上海升级预计将在 3 月发生 (共识层和执行层同时升级)。如果一切顺利，我们将很快在主网上看到 EOF 和提款!

下一次升级：坎昆升级

由于 EIP-4844 被移除出上海升级，我们把它作为下一次升级的重心 (你可以在这里看到坎昆升级的规范)。

预计 EIP-4844 的实现和测试将在 2023 年 4 月完成，并部署在公共测试网上。然后坎昆升级可以在 5-6 月启动，将 EIP-4844 部署到主网上。

总结

今天是 2022 年的最后一天，在这一年里我们看到了许多重大的技术进步。例如：成功合并、完成 EIP-4844 的规范、rollup 崛起、zkp 涌现了许多创新，以及 zkevm 也有许多进展。

我很高兴能见证这一年。也为以太坊协议出现这些底层的改进感到兴奋。

明年，我们会有更加关键的升级：它们是上海+Capella (提款和EOF)，坎昆+Deneb (EIP-4844)，以及 Prague + Electra (待定)。

明年仍然会是很值得期待的一年，有很多工作等着我们去做。我们将看到更多的基础性想法和研究，所以我认为用这篇文章来开启 2023 年是非常合适的。新年快乐!