原文：CurrentEthereum
作者：@LuozhuZhang
翻译：Franci,ECN
文章概述了以太坊目前开发工作的重心，并整理出了关键升级的路线图和时间线。
译者注：本文撰写于2022年12月31日，文章基于第151?次ACD会议确定的工作计划展开，因此与目前的路线图有出入。
需要注意的是，在2023年1月5日进行的第152次ACD会议中确定，EOF相关的EIP被移出上海升级。更多关于#152ACD会议的中文笔记请看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的启发而撰写了此文。
他们一致认为，学习以太坊的最好方法是观看核心开发者会议(AllCoreDevs)，阅读相关的会议记录，查看hackmd文档、issue、PR以及EIP，直到你弄清楚以太坊当前的路线图状态、核心开发者的关注点和担忧点以及每个升级/EIP的作用是什么…
除此之外，我还受到了社区的启发。
以太坊有着优秀的开源文化，你可以在EFYouTube上看到所有的会议视频，以及在?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,431ETH，验证者能够动态变化对于以太坊经济层来说非常重要。
EVM对象格式(EOF)
作为EVM的超级爱好者，我相信很多人对EOF期待已久。几年前，就有关于“以太坊账户版本化”的讨论和改进提案。直到现在，EOF就要成为现实，确定纳入到上海升级的范围内(实际上，EVM自创世区块以来就没有改变多少)。
(译者注：最新的ACD中确定EOF从上海升级中移除)
简单地说，目前的EVM只有一套解释和验证规则来处理所有现有的合约(我们将它们称为“旧式合约”)。
EOF(包含5个EIP)引入了一种新的智能合约格式，即“EOF合约”。而客户端/EVM解释器也有相应的更新。
所以我们现在有两套EVM解释和验证规则，并且它们是平行存在的。EVM将能够同时处理旧式合约和EOF合约(在更长远的未来，我们可能会用EOF合约取代所有的旧式合约)。
以太坊区块浏览器Etherscan启动监视功能:金色财经报道，以太坊区块浏览器Etherscan启动了一项监视功能，可扫描非法活动。ETHProtect将使用户能够检查转入的资金，以查看它们是否源自非法收益，例如黑客攻击、网络钓鱼计划或其他欺诈。Etherscan希望该功能将使社区能够从流通中去除污染的硬币。[2020/4/15]
为什么需要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(EVMObjectFormat,EOFv1)
这个EIP引入了EOF“container123rong”并规定了所有包含在EOF合约中的字段(在这里可以查看完整的字段)。此外，它依赖于EIP-3541，这个EIP确保EOF格式的合约部署在上海升级前会被拒绝。
?EIP-3670:EOF–代码验证(EOF–CodeValidation)
这个EIP在EIP-3540的基础上，为EOF合约添加更多的验证规则。无效的EOF代码无法被部署，在这里查看所有代码验证规则。
?EIP-4200:EOF–静态相对跳转(EOF–Staticrelativejumps)
分析 | ONT/ETH交易对逆势上扬 注意风险:金色盘面综合分析：ONT/ETH逆势上扬，24小时涨幅10%，ETH/USDT在24小时内跌幅7.7%，ONT/USDT涨幅只有1.7%，这样的涨幅是不正常的，注意交易风险的控制，上方阻力关注0.0062，下方支撑关注0.0057[2018/8/8]
这个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–StackValidation)
这个EIP?添加了更多验证规则，并将堆栈underflow/overflow、inefficientgas等从运行时检查转移到部署时检查。这可以进一步减少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?等等)。
以太社区再闹分裂？原Myetherwallet推特宣布新身份Mycrypto:\t周四起，Myetherwallet在推特发布消息宣布新身份为Mycrypto，并更改账号名称，推特中还称，Myetherwallet被分裂成了两个部分。媒体报道显示，对此，Myetherwallet团队的一半人感到意外，他们声称“Twitter的处理是在没有MEW创始人的支持或许可的情况下改变的”，其创始人Taylor Monahan似乎没有告诉她的联合创始人Kosala。Taylor称，无论什么原因，Myetherwallet都将继续正常运行，并暗示这一事实可能并非所有人都一致同意。Kosala在新注册的推特账号中写到：目前，我们正在处理一些非法的、社交媒体账户的切换，我们正在解决目前的情况。两者之间的矛盾似乎由来已久，去年12月，Kosala在加州提起诉讼，原因是Taylor拒绝让他查看MEW的相关文件。MyEtherWallet（MEW）是一个免费的开源客户端界面，用于生成以太坊钱包等。[2018/2/10]
但总的来说，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在ETHDenver中对完整版Danksharding的简单实现。它比完整版的Danksharding更容易实现，这对以太坊扩容来说非常重要。
虽然EIP-4844已经足够简单了，但是它的实现仍广泛涉及以下几个方面。
????EIP本身?(已完成)
????共识规范?(正在进行,大概完成)
????引擎API规范?(已完成)
????客户端实现?(正在进行，参考?Geth和?Prysm)
????KZG仪式?(已完成，在这里参加)
????工具、开发者测试网(正在进行,大概完成)
????测试?(正在进行)
虽然EIP-4844的进展非常快，但仍有许多工作要做(包括客户端实现和大量测试)。以防4844的推进会使得提款的进程延迟，在ACD#151中开发者们决定将EIP-4844移除出上海升级(但PéterSzilágyi和DankradFeist对此表示反对)。
EIP-4844是以太坊的下一个关键改进，我们都知道它的重要性。这也是为什么上海升级之后的下一次升级中(坎昆升级)将以EIP-4844为重心。
其他EIP
除了提款和EOF，上海升级还会部署三个独立的EIP
?EIP-3651:WarmCOINBASE(降低访问?COINBASE?地址的gas开销)
这个EIP?作为EIP-2929?的补充，为交易执行的开始增加了一个COINBASE?地址。
?EIP-3855:PUSH0instruction(新增操作码?``PUSH0`)
这个EIP引入了一个新的指令PUSH0?，用来把常量?0?值压入堆栈中。
?EIP-3860:Limitandmeterinitcode(对initcode的大小设限并引入gas计量)
这个EIP扩展了EIP-170。它限制了initcode的大小上限在49152?的位置，并为initcode引入每32字节2gas的开销。
三、路线图和时间线
作者LuoZhu对路线图和时间线的最新补充：
?EOF从上海升级中移除，会不会在坎昆升级部署需要看1月19日的ACD会议
?EOF可能不会推进的这么快，比如配合EOFv2和一个比较完整的路线图
时间线
基于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年是非常合适的。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。