以太坊目前的发展重点

来源 | mirror.xyz/luozhu.eth

作者| @洛竹张

翻译 |

译者注：本文写于2022年12月31日，文章基于第151次ACD会议确定的工作计划，因此与现行路线图不同。 需要说明的是，在2023年1月5日的第152次ACD会议上，确定将EOF相关的EIP搬出上海进行升级。 更多关于#152 ACD会议的中文笔记，请看ECN的整理：。 请在此处查看上海升级规范：#eips-considered-for-inclusion。

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

目录

➤ 背景

➤ 升级主要内容

➤ 路线图和时间表

➤ 总结

背景

受 CC 和 Vitalik 的启发写了这篇文章。

他们一致认为，了解以太坊最好的方式是观看 All Core Devs 会议，阅读相关会议纪要，查看 hackmd 文档、问题、PR 和 EIP，直到弄清楚以太坊当前的路线图状态、关注点和关注点核心开发人员以及每次升级/EIP 的作用......

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

以太坊拥有伟大的开源文化，您可以在 EF YouTube 上观看所有会议视频，以及在 ethereum/pm 上的未来讨论议程（另请参阅 Tim 和 Kim 的笔记）。 以太坊开发人员正在尽最大努力让社区了解以太坊当前的升级及其提议的改进。

所以我觉得写这样的文章对社区是非常有价值的！

升级的主要内容

2022年9月15日，以太坊合并成功后，将目光转向后续的改进建议：执行层上海升级； 共识层上的 Capella 升级。

他们扮演着不同的角色。 信标链提现是上海升级的核心，EOF只有在提现不受影响延迟的情况下才会被纳入上海升级。 （译者注：最新的ACD确认上海升级去掉了EOF）

另外，EIP-4844已经从上海升级范围中移除，因为它可能会影响提现时间。 但是我们都知道EIP-4844是以太坊的一个重要改进提案，所以它会是下一次升级（坎昆升级）的重点。

如果读者对上海升级不熟悉，我将在本文中分别解释相关术语和EIP。

信标链提现

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

信标链尚未推出

在信标链推出之前，以太坊是一个完整的单体型区块链，其共识引擎（PoW）和执行引擎（EVM）没有耦合和分离地协同工作。

单链

阶段 0

信标链在第 0 阶段（2020 年 12 月）启动。

此后，以太坊从单一区块链转变为两条平行链（即信标链和执行链）的组合。

他们之间唯一的沟通方式就是存币合约，存币并锁定32个ETH成为验证者（这个角色类似于PoW机制下的矿工）。

合并前

牵牛星升级

很快，信标链迎来了上线两周内的第一次硬分叉，也就是Altair的升级。 本次升级做了一些简单的修复（共识层升级以星号命名）。

贝拉特里克斯升级

第二次硬分叉升级是Bellatrix，在这次升级中进行了合并：信标链与执行链合并。

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

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

合并后

卡佩拉升级

这是信标链（以二星命名）的第三次硬分叉升级，将与上海升级（执行层）同步进行。 通过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 在运行时验证的内容（例如堆栈下溢、溢出）转移到部署时。 这使得 EVM 的开销更低，并使合约代码更安全（潜在的错误不会部署在以太坊上）。

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

另外，EOF主要由5个EIP组成，我简单介绍一下各个EIP的作用。 如果读者想了解更多关于EOF的知识，建议大家去往往的讨论，比如《EVM封装格式》和《关于EVM的一切》，还有这5个EIP（这里有统一的规范）。 这些材料非常有用！ ？？？

➤ EIP-3540：EVM对象格式（EOF）v1（EVM对象格式，EOF v1）

此 EIP 引入了 EOF“容器”并指定了 EOF 合约中包含的所有字段（请参阅此处的完整字段）。 此外，它依赖于 EIP-3541，确保在上海升级之前拒绝 EOF 格式的合约部署。

➤ EIP-3670：EOF - 代码验证（EOF - 代码验证）

本EIP在EIP-3540的基础上，增加了更多EOF合约的验证规则。 无法部署无效的 EOF 代码，请在此处查看所有代码验证规则。

➤ EIP-4200：EOF - 静态相对跳转（EOF - Static relative jumps）

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

➤ EIP-4750：EOF - 导入函数（EOF - 函数）

这个EIP在4200的基础上更进了一步，引入了“EVM函数”（一个独立的子程序）的概念，引入了CALLF和RETF来调用&返回EVM函数。 有了EIP-4750和EIP-4200，我们就可以完全放弃JUMPDEST分析（动态跳转JUMP和JUMPI）。

➤ EIP-5450：EOF - 堆栈验证（EOF - 堆栈验证）

该 EIP 添加了更多验证规则，并将堆栈下溢/溢出、低效 gas 等从运行时检查转移到部署时检查。 这可以进一步减少 EVM 的开销（目前下溢/上溢由 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（type 1 zkEVM）时，每次EVM升级也会考虑zkEVM，同时升级（ EVM + zkEVM）是可能的。 所以我认为保持 zkEVM 更新没什么大不了的。

至于 EOF。 未来还有很多改进，比如考虑禁止CODECOPY、CODESIZE、EXTCODECOPY、EXTCODESIZE和EXTCODEHASH直接读取EOF代码，实现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-4844 正在进行中

虽然 EIP-4844 的进展非常快，但仍有许多工作要做（包括客户端实现和广泛的测试）。 为防止 4844 的推进会延迟退出过程，在 ACD#151 中，开发人员决定将 EIP-4844 从上海升级中移除（但 Péter Szilágyi 和 Dankrad Feist 对此表示反对）。

EIP-4844 是以太坊的下一个关键改进，我们都知道它的重要性。 这也是为什么上海升级后的下一次升级（坎昆升级）会重点关注EIP-4844。

其他 EIP

除了withdraw和EOF，上海升级还会部署三个独立的EIP？？？？

➤ EIP-3651：Warm COINBASE（减少访问 COINBASE 地址的 gas 开销）

该 EIP 通过为交易执行的开始添加一个 COINBASE 地址来补充 EIP-2929。

➤ EIP-3855：PUSH0 指令（添加操作码 `PUSH0）

该EIP引入了一条新指令PUSH0，用于将常量值0压入堆栈。

➤ EIP-3860: Limit and meter initcode（限制initcode大小，引入gas计量）

该 EIP 扩展了 EIP-170。 它将 initcode 的大小限制为 49152 的上限，并且每 32 字节的 initcode 引入了 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 on mainnet！）？？？？

升级时间表

上海+嘉佩乐升级

此次升级的核心是信标链提款。 为避免阻止提款的任何可能性，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的很多发展。

我很高兴见证这一年。 我也对以太坊协议的这些潜在改进感到兴奋。

明年，我们有更多的关键升级：它们是上海 + 卡佩拉（退出和 EOF）、坎昆 + 天津四 (EIP-4844) 和布拉格 + 伊莱克特拉 (TBD)。

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