原文来自：以太坊核心开发者TimBeiko
编译：DeFi之道
欢迎阅读有关AllCoreDevs在2022年的最后一次更新。
长话短说：
上海/Capella升级的内容已经敲定：提款，EOF，还有一些小改动……只要不耽误提款即可?
Blobspace即将到来:EIP-4844将成为以太坊下一次升级的中心，其召唤仪式即将开始
开发者们正在努力协调执行客户端和共识客户端升级过程的技术方面。我们还看到了关于更好地将社区的意见纳入流程的积极讨论
上海/Capella升级?
在最近一次AllCoreDevs电话会议上，客户端团队就上海/Capella升级的最终范围达成了共识。虽然升级的名称可能仍有争议，但团队们已经清楚了升级的范围，这次升级的主要任务是为质押者引入信标链提款。尽快解决这个问题是客户端团队的目标，因此升级中的其他功能需要同时准备好，或者有可能会被移除。
上海EL规范列出了所有包含的EIP：
EIP-3540：EVM对象格式(EOF)v1
EIP-3651：WarmCOINBASE?
EIP-3670：EOF-代码验证?
EIP-3855：PUSH0指令?
EIP-3860：限制和计量initcode?
EIP-4200：EOF-静态相对jumps?
EIP-4750：EOF-函数?
EIP-4895：信标链推送提款操作?
EIP-5450:EOF-堆栈验证?
Coinbase将针对USDC提供4%的奖励:6月16日消息，Coinbase宣布将针对USDC提供4%的奖励，奖励率可能会发生变化，并且可能会有所不同。6月9日时Coinbase网站显示，该奖励率为2%。[2023/6/16 21:41:44]
虽然列表很长，但我们可以将它们分为三个不同的部分：小改进、EVM对象格式以及提款。让我们来逐一分析：
小改进
EIP-3651：WarmCOINBASE
该EIP修复了EIP-2929中的一个疏忽，该疏忽根据客户端是否已将数据字段存储在内存中或需要从磁盘中检索它们来更改访问某些数据字段的gas成本。
EIP-2929在每个事务开始时，将客户端内存中的两段数据设置为WARM：发送地址和接收地址。EIP-3651在这个列表中添加了第三个地址，即COINBASE地址，因为它也是客户端在处理区块交易时在内存中的地址。
EIP-3855：PUSH0指令
顾名思义，EIP-3855引入了一个将值0推入堆栈的操作码。Pushing0经常用于填充EVM中的值，此操作码将提供一种更有效、更便宜的方法来实现这一点。
EIP-3860：限制和计量initcode
该EIP增加了initcode的最大大小，并引入了基于其长度的gas计量。大小限制为EVM添加了一个不变量，这将使推理和提出更改变得更容易。
引入了一个2gas/32字节的initcode开销，以说明客户端在执行之前必须执行的jumpdest分析，这在以前的gas计划中并没有被考虑到。
EVM对象格式?
上海升级包括的大多数EIP都是单一功能的一部分:EVM对象格式(EOF)。这项升级工作被分解为5个不同的EIP，以帮助客户端开发人员单独地解释每个更改，但为了提供更高层次的概述，本周发布了一个统一的规范。这5个EOFEIP分别是:
1、EIP-3540:EVM对象格式(EOF)v1
2、EIP-3670:EOF-代码验证
3、EIP-4200:EOF-静态相对跳转
4、EIP-4750:EOF-函数
5、EIP-5450:EOF-堆栈验证
值得注意的是，EOF的第一步是在伦敦升级中使用EIP-3541，它为EOF合约保留了0xEF00前缀。在过去的几个月里，上海EOF升级的范围也发生了变化。
2月份，客户端团队同意为上海升级考虑两个最小的EOFEIP：EIP3540和EIP3670。它们将充当构建块，但如果不引入EIP4200、EIP4750以及EIP5450将无法提供全部功能。虽然有可能扩展EOF，但向后不兼容的扩展可能需要一次版本升级。由于具有特定版本的前EOF或EOF合约必须始终可执行，因此每个新的EOF版本都意味着客户端开发人员必须维护一组与旧规则并行的新EVM执行规则。
在EOF之前，客户端一次只维护一组EVM规则。代码库还支持历史EVM规则，这些规则可以改变每次网络升级，但一旦它们到达链的顶端，就只能应用最新的规则。而使用EOF，客户端将维护两个并行的EVM规则集，因此它们可以在EOF和非EOF合约中执行代码。换句话说，EOF版本bumps增加了并行的数量，而不是顺序的，必须维护的EVM规则集。
出于这个原因，在过去的几个月里，客户端团队开始更喜欢一种“大EOF”方法。这样，虽然他们必须实施更大的变更集，但EOF版本将保持更长时间，从而减少要维护的“并行EVM”的数量。因此，“大EOF”被考虑并最终纳入到接下来的上海升级中。
也就是说，更大的功能显然更难以实施和测试，而客户端团队们并不希望看到EOF显着延迟信标链提款。因此，客户端团队们同意，如果到明年1月，EOF实施不完整且相互之间无法快速互操作，则将EOF从上海移除。
在这个背景下，现在让我们简单地介绍一下各种EOFEIP：
EIP-3540：EVM对象格式(EOF)v1
该EIP为EOF合约引入了“容器”。它在合约中添加了区分代码和数据部分的标记，并防止部署不符合格式的EOF合约。这保证了任何链上EOF合约都将遵循有效的布局，从而简化了与这些合约的交互以及对它们的静态分析。
EIP-3670：EOF-代码验证
EIP-3670建立在EIP-3540引入的容器之上，确保合约EOF中的代码有效，或阻止其部署。
这意味着未定义的操作码无法在EOF合约中部署，这具有减少所需的EOF版本更新数量的额外好处。如果添加了新的操作码，只需更改验证规则即可启用它，并且可以保证没有EOF部署的合约在其代码部分引用它。
EIP-4200：EOF-静态相对JUMPs
EIP-4200引入了第一个EOF专用操作码：RJUMP、RJUMPI和RJUMPV，它们将目标编码为带符号的即时值。编译器可以使用这些新的JUMP操作码来优化gas成本，因为它们消除了对现有JUMP和JUMPI操作码所需的运行时jumpdest分析的需要。
EIP-4750：EOF-函数
EIP-4750比EIP-4200的功能更进一步：它不允许JUMP和JUMPI操作码，并为RJUMP、RJUMPI和RJUMPV无法复制的函数添加了替代方案。它通过在EOF字节码中引入特定的函数部分来实现这一点，这些函数部分可以分别使用新的JUMPF、CALLF和RETF操作码跳转到、调用以及返回。
EIP-5450：EOF-堆栈验证
最后，EIP-5450为EOF合约添加了另一个验证检查，这次是围绕堆栈进行的。该EIP可防止EOF合约部署可能导致堆栈下溢，以及某些溢出情况的代码。有了这个，客户端可以减少它们在执行EOF合约期间进行的验证检查的数量，因为它们可以更好地保证与堆栈相关的异常。
作为一名非EVM专家，以上就是我能带你走的最远的地方！如果你想深入了解EOF，我推荐你们阅读Geth的lightclients或Solidity的Leo的帖子。
信标链提款?
最后但同样重要的是，“Shapella”的主要组成部分是信标链提款。这一变化在共识层规范以及EIP-4895中都有规定。现在稍微有点过时的元规范将这些联系在了一起。
下面简单说说提款的工作原理:
当提出一个区块时，验证器通过验证器索引线性扫描，找到前16个具有0x01凭据的验证器，这些验证器要么:
余额超过32ETH
可提款
根据这些，验证器将创建一个提款列表，以包含在他们的ExecutionPayload中。该列表中的每一项都包含以下内容：
WithdrawalIndex：所有提款中的索引——这有助于区分从同一验证器到同一地址的相同金额的提款；
ValidatorIndex：余额被提取的验证器的索引；
ExecutionAddress:需要发送提款的执行层ETH地址；
Amount:要发送到ExecutionAddress的金额，以gwei为单位；
在构建或处理区块时，EL客户端将在交易执行后应用这些提款。换句话说，处理提款类似于工作量证明奖励的记入方式，并且不会与用户交易争夺区块空间。
还有一些值得注意的细节：
在处理提款时，“全部”和“部分”提款在优先级/顺序方面没有区别。一旦验证器离开退出队列，就会发生完全提款，当对验证器集的线性扫描到达验证器的索引时，部分提款会定期发生。
为了处理提款，验证器必须使用0x01凭证，它代表一个ETH地址。在信标链启动时，只允许使用BLS密钥对的0x00凭据。为了启用提款，具有0x00凭证的验证器将需要签署BLSToExecutionChange消息。这些将作为Capella升级的一部分启用。验证者可以期待多种工具的支持和教程来签署此消息。
对验证器集的扫描以每个区块为界。如果在扫描验证器集的一个子集后，没有16个提款需要处理，验证器将停止扫描，下一个将从上次扫描的验证器索引中提取。
与往常一样，将有几个开发者测试网和测试网供验证者运行整个过程，并在主网上线之前解决所有问题。
不过，上海/Capella升级并不是唯一取得进展的升级！开发团队们也一直在期待下一个升级。
Cancun升级??
上海升级的内容已定，但很多CFI的EIP没有被纳入，客户端团队开始讨论下一次Cancun升级应该考虑纳入什么??
在CL方面，EIP-4844已被指定为capella后的第一个升级?。EL尚未支持这种布局规范，但EL团队同意遵循类似的路径，并将下一次升级围绕EIP-4844进行。
按照使用devcon城市名称进行升级的惯例，开发者创建了cancun.md，并正式将EIP-4844包含在这次升级当中。
这个决定是在2022AllCoreDevs电话会议的最后几分钟做出的，所以没有时间讨论其他提案。那些在上海升级获得CFI，但没有入选的EIP，已被转移到Cancun的CFI名单上，以太坊魔术师论坛已创建了帖子?来讨论Cancun候选EIP。明年初，关于Cancun范围的讨论将正式开始。
KZG仪式
另一件与Cancun升级相关的事情是KZG仪式???，这是EIP-4844的一项要求。
仪式将生成验证blob数据有效性所需的随机性。要使它被认为是安全的，必须只有一个参与者诚实地参与。
从明年1月开始，这个仪式将向所有人开放几个月。目标是获得10,000名贡献者，这计划成为迄今为止规模最大的此类仪式！如果你想确保自己不错过它，请关注TrentVanEpps?！
合并后升级过程
正如之前的更新中提到的，合并后的一个大的待办事项是在EL和CL中协调以太坊的升级过程。EL使用黄皮书和EIP来指定更改，而CL使用可执行的Python规范。
EL流程的优势在于EIP被社区所熟知，并且其格式能够清楚地呈现提案背后的原因。大量数学的黄皮书与EIP相结合，并且需要将规范置于EIP的上下文中，这使得执行层规范既难以理解又难以扩展。
CL方面有相反的问题：它有一个清晰易懂的规范，存在于一个单一的存储库中，但是更改不能明确地识别，并且提案被隐藏在存储库中的其他开放PR中。
随着以太坊执行层规范的引入，我们有望弥合EL方面的差距。而且，通过一些流程争论，我们也许能够将EIP作为CL流程的一部分引入……！
也就是说，随着上海升级范围的讨论和最终确定，很明显这个过程中可能会缺少另一个“部分”：让社区表达他们对更改的相对偏好，参与关于升级整体范围的讨论(而不是单个EIP)，并将其纳入AllCoreDevs和CL电话会议的决策中。
目前还不太清楚这是什么样子的——我很乐意提供建议！-但随着积极参与协议更改的利益相关者数量以及L1变更对两者影响的领域数量的增长，显然需要一些东西。
幸运的是，我们并不是从头开始：以太坊魔术师论坛已经存在多年，其IRL聚会以及临时分组讨论室或社区电话会议可能是扩展的良好起点。
期待2023年初，有关于这方面的更多更新！
下一步
2022年就这样结束了，多棒的一年啊!三个月前，我们甚至还没有合并!而现在，以太坊正在后台默默地运行权益证明，重点已经转移到即将发生的事情上。
随着一月份假期的结束，你可以期待:
上海/Capella开发者测试网和影子分叉
KZG仪式正在进行
围绕Cancun升级的讨论，以及网络升级过程应该如何演进以更好地捕捉社区的偏好
谢谢阅读！感谢在过去一年中花时间努力改进以太坊的每个人-我们做了很多工作。希望你们都有一个应得的假期。
2023年见
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。