以太坊核心开发者大会更新：上海升级、提款机制、坎昆升级……

日期：2023年04月15日 12:06 浏览量：1

原文标题：《以太坊核心开发者会议更新 014》原文来源： AllCoreDevs Update原文作者： Tim Beiko原文编译： Ethereum.cn尽管这些更新最初是每月系列

但是，节奏正在一个季度一个季度地改变。读者可以将这些更新视为以AllCoreDevs为中心发生的重大事件的摘要。如果你想了解更多

，Christine Kim的记录，Ben Edginton的共识层会议记录，我建议你阅读我的ACD长推文。这些更新更频繁。概要

上海/Capella升级的内容已经确定。提款、EOF和一些小修改……前提是它们不会延迟提款Blob空间的到来。 EIP-4844将成为以太坊下一次升级的中心

，其呼吁仪式很快在技术方面协调执行层和共识层升级进程的努力正在进行中。在这个过程中还可以看到关于更好地纳入社区意见的积极讨论

协议指南(Protocol Guild )公布了中期试验报告，以及在2023年进一步扩大维护规模、更好地支持他们的大致计划上海/Capella升级

在最近的AllCoreDevs中，客户团队就上海/Capella升级的最终范围达成了一致。升级的名称可能值得商榷，但小组明确了其范围

。升级的主要功能是在当铺引入信标链提款。尽快发布此功能是客户团队不愿意妥协的事情，因此升级中的其他功能需要同时准备。不这样做的话，有可能被放弃。上海管理层的规范包括了所有的EIP。

EIP-3540: EVM对象格式(EOF ) v1EIP-3651:减少了访问COINBASE地址的gas开销

EIP-3670: EOF -代码验证EIP-3855:新操作码推送0 EIP-3860:限制init代码大小，引入gas计量

以EIP-4200: EOF -静态相对跳EIP-4750: EOF -引入函数EIP-4895:信标链推送式提款为系统操作

EIP-5450: EOF -堆栈验证尽管列表很长，但可以分为小型改进、EVM对象格式和提款三个不同的部分。接下来逐一介绍。小型改良

EIP-36513360 warmcoinbase (减少用于访问coin base地址的gas开销)此EIP修复了EIP-2929中的忽略问题

这意味着，访问特定数据字段的gas开销的更改取决于这些数据是否已经在客户端内存中，或者是否必须从磁盘中获取。

EIP-2929在每个事务开始时将客户端内存中的两个数据设置为WARM。发送地址和接收地址。 EIP-3651在此列表中添加第三个地址

、COINBASE地址，即feeRecipient。这也是因为它是客户端处理块事务时内存中的地址。

EIP-3855: PUSH0 instruction (新操作码` PUSH0) )顾名思义，EIP-3855引入了将0值推入堆栈的操作码

。压入0通常用于填充EVM的值。使用此操作码可以更高效、更便宜地完成此操作。

EIP-38603360有限元码(引入有限的初始码大小gas测量)此EIP增加了初始码大小上限

根据其长度引入gas计量。其大小上限是在EVM中添加了不变量，从而使理解和修正的提案变得容易。在initcode中引入每32字节2 gas的开销

，它用于支付客户端在执行前必须进行的jumpdest分析，在jumpdest分析之前，它不在gas费用表中。对象格式

上海升级中包含的大多数EIP实际上是这一单一功能的一部分。 EVM对象格式(EVM Object Format，EOF )。这项工作被分解成五个不同的EIP

，使客户端开发人员了解各个更改，但为了提供更高级的概述，开发人员发布了集成的规范。这五个EOF的EIP分别是EIP-3540: EVM对象格式版本1

EIP-3670: EOF -代码验证EIP-4200: EOF -静态相对跳跃EIP-4750: EOF -引入函数

EIP-5450: EOF -堆栈验证值得注意的是，EOF的第一步是在伦敦升级的EIP-3541，并且在EOF合同中保留了0xEF00的前缀。在过去的几个月里

上海升级的EOF范围也发生了变化。 2月，客户团队同意考虑将上海升级纳入eips35403670这两个最小的eofEIP。所有这些都是组成部分

但是，除非部署了EIP 4200、4750和5450，否则不会提供所有功能。可以扩展EOF，但如果不向后兼容，则需要添加新版本

。由于EOF之前或特定版本的EOF合同必须始终可执行，因此每个新的EOF版本意味着客户端开发人员必须与旧规则并行维护一组新的EVM执行规则。在EOF之前

，客户端一次只维护一组EVM规则。代码库也支持以前的EVM规则。这些规则在每次网络升级时都会发生变化，但一旦成为区块链的链头，就应该只应用最新的规则。引进EOF后

，客户端维护两个并行的EVM规则，因此可以在EOF和非EOF合同中执行代码。这意味着，随着EOF版本的增加，需要维护的并行数将增加，而不是EVM规则集的连续数。

因此，在过去的几个月里，客户端团队开始偏向于“大EOF”方法。这要求他们实现更大的修改集，但EOF版本可以保持更长的时间，并减少需要维护的“并行EVM”的数量。于是，我决定

开发者们想到了“大EOF”，最终被纳入上海的升级。这意味着更大规模的功能显然很难实现和测试，团队不希望看到EOF大幅延迟信标链提款。因此，如果到了1月

，由于EOF的实现尚未完成，彼此无法迅速互通，客户团队同意将EOF移出上海进行升级。有了这些上下文之后，现在让我简单介绍一下每个EOF EIP :

EIP-35403360 evmobjectformat (EOF ) v1 ) EVM对象格式版本1 )此EIP在eof合同中引入了“容器”

。添加标记以区分合同中的代码和数据部分，从而避免引入不合格的EOF合同。这将确保所有链上的EOF合同遵循有效格式，简化与这些合同的交互和静态分析。

EIP-36703360密码验证(eof -代码验证)基于3540中引入的容器

，EIP-3670确保EOF合同的代码有效或不引入。这意味着不能将未定义的操作码引入到EOF合同中。这有一个额外的好处，就是减少了需要添加的EOF版本的数量

。如果添加了新的操作码，则可以轻松修改和启用验证规则，以确保代码部分中没有引用已部署的EOF合同。

EIP-42003360静态相对跳跃(eof -静态相对跳跃) )。

EIP-4200引入了第一个EOF专用操作码RJUMP、RJUMPI和RJUMPV，将目标编码为带符号的即时值。这些新的JUMP操作码可由编译器用于优化gas开销

中选择所需的族。因为不再需要运行时jumpdest分析，而是需要现有的JUMP JUMPI操作码。 EIP-47503360eof-functions(eof-部署函数) ) ) ) )。

除了4200之外，EIP-4750还添加了备用方案，以禁止使用JUMP JUMPI操作码，并且无法复制RJUMP、RJUMPI和RJUMPV功能

。这是通过在EOF字节码中引入特定函数section来实现的。这些函数分别从新的JUMPF、CALLF和RETF操作码跳转到，并使用它们调用和返回。

EIP-54503360堆栈验证(堆栈验证)最后，EIP-5450为EOF合同添加了另一个验证检查。这次以堆栈为中心

。此EIP可以防止因引入EOF合同而导致堆栈溢出，或者在某些情况下可能溢出的代码。此EIP增强了客户端以堆栈相关异常为中心的保证，从而减少了执行EOF合同时的验证检查次数。

作为非常关注EIP本身的EVM以外的专家，我能介绍的只有这个！如果读者想了解更多关于EOF的信息

推荐来自Geth团队的lightclients和Solidity团队的Leo的相关推文。信标链提款是最后一次，但同样重要的是

，“Shapella”(译者注： Shanghai/Capella的总称)的主要部分是信标链的提款。这一部分的变更在共识层的规范和EIP-4895中有说明

。现在有一个有点旧的元规范将这些改变联系起来。从较高级别来看，提款机制如下。提出块时，验证者对验证者索引进行线性扫描，找到前16个拥有0x01证书的验证者

必须满足以下条件之一： haveabalanceabove 32 eth (I.e.haveaccruedvalidatorrewards )

arewithdrawable (I.e.havefullyexitedthevalidatorset ) )余额大于32ETH )，即已经从验证方获得报酬)。

是withdrawable的。 (可提款的东西，也就是说完全结束了验证者集) )。

From these，thevalidatorwillcreatealistofwithdrawalstobeincludedintheirexecutionpayload.eachiteminthatlistcontainsthefolllowinsthefollololllloreforeflodetinstated

验证者从这些验证者创建提款列表并将其打包到ExecutionPayload中。清单中的每个项目都包括：

WithdrawalIndex :所有提款交易索引——这有助于区分来自相同地址、相同验证者的相同金额的提款ValidatorIndex :提交余额的验证者索引

执行地址：运行层的ETH地址，即发送到提款的位置amount :执行地址的数量

，该数量是在gwei而不是wei上测量的，在构建或处理块时，执行层客户端会在交易执行后进行这些提款操作。换言之，提款处理与工作量证明奖励的收款方式相似

，在与用户的交易中不竞争块空间。另外，还有几个值得注意的细节。在处理提款时，提交“全额”和“部分资金”对优先级/顺序没有区别。验证者退出队伍时提交全额

另一方面，部分提款是周期性发生的。也就是说，是直线扫描验证者集，扫描到某个验证者的索引号时。验证者必须使用0x01证书才能处理提款。这用ETH地址表示

。当信标链在线时，只允许对0x00证书使用BLS密钥。要开始提款，具有0x00证书的验证者必须在BLSToExecutionChange消息上签名

。它们将通过Capella升级激活。签名此消息有多种工具，验证者可以期待这些工具的支持和教程。验证者的扫描以各块为边界

。在扫描验证者集的子集后，如果没有16笔提款需要处理，验证者将停止扫描，下一个验证者从最后一次扫描的验证者索引开始。像往常一样，在主网前

有几个开发者测试网和测试网()可能有新的测试网！ )让验证者执行整个过程，解决所有问题。上海/Capella并不是唯一有进展的升级！开发人员团队还在展望下一次升级。

坎昆升级虽然上海升级内容已满，但很多考虑升级的EIP (CFI )无法进入上海升级

。客户团队开始考虑哪个EIP应该进行下一次升级。坎昆升级(协议层名称需要确定) )协议层中，EIP-4844成为Capella升级后第一个写入规范的EIP

。执行层没有实现这种布局的规范，但执行层团队同意遵循类似的路径，在下一次升级中以EIP-4844为主。遵循升级和使用举办Devcon的城市名称的惯例

，cancun.md已创建，其中EIP-4844已正式纳入升级。这个决定发生在2022年最后一次AllCoreDevs会议的最后一分钟，所以没有时间处理其他提案

。进入上海升级了CFI，但最终没有被纳入的EIP被移动到坎昆升级的CFI列表中，在Ethereum Magicians论坛上也发表了讨论坎昆候选EIP的帖子。明年年初

坎昆升级范围的讨论应该会正式进行。 KZG仪式的另一个与坎昆升级相关的值得期待的是KZG仪式，这是EIP-4844的要求。

该仪式生成验证blob数据有效性所需的随机性。为了被认为是安全的，参加者必须只有一个人诚实。也就是说，如果除了一个参加者以外所有其他参加者共谋，则整个过程在密码学上是安全的。

这个仪式从1月开始，对所有人开放几个月。我们的目标是有10，000名参与者，这样的仪式将是迄今为止规模最大的如果你想确保美好的生活

请在推特上关注Trent Van Epps！合并后升级流程如以前更新中所述，合并后在执行层和协议层协调以太网升级流程是一个重要的待办事项。从上层来看

执行层使用黄皮书EIP解释修改，共识层使用可执行的Python规范。运行层过程的优点是，明确地说明了EIP在社区中是众所周知的，其格式化方法是提案背后的理由

。具有大量数学内容的黄皮书和EIP的组合，以及需要将规范返回到每个EIP的上下文中，使得对执行层规范的理解和扩展变得困难。共识层的问题恰恰相反。它有明确易懂的规范，在一个仓库里

但是，修改不具体知道。此外，提案被埋没在仓库的其他公开宣传中。随着以太坊执行规格的出台，执行方希望缩短这一差距。然后，在几个过程中进行争论

也许可以将EIP引入共识层流程中！也就是说，随着上海升级的范围得到讨论和最终确定，很明显，这个过程可能缺少了另一部分，即让社区表达对变更的相对偏好

参与整个升级范围的讨论，而不是个别的EIP，作为AllCoreDevs和共识层会议决策的一部分。因为现在不知道会变成什么样的——，所以我很乐意接受建议

！ ——但是，随着积极参与协议变更的利益攸关方数量和一级变更所影响的领域数量的增加，我们显然需要一些东西。幸运的是，我们没有必要从头开始。 Ethereum Magicians已经存在多年了

在线聚会、专门的小组会议、社区会议可能是很好的扩张起点。我们期待着2023年初在这方面取得更多进展！协商会议的更新

随着协商委员会(Protocol Guild，PG )的试点工作完成一半，他们发表了报告，确认了事情的进展情况，思考了项目下一步是什么。注意一下

、PG是不需要以太网第1层客户端开发者、协议研究者以及像你们这样的支持贡献者许可的资助机制。这个机制以个人而不是组织为中心。简而言之

，各成员有资格获得公会Token份额，根据对以太网的贡献时间进行加权计算。成员的追加、删除，以真正的以太方式进行——，根据一系列的标准，在PG内部大致达成了共识。这个清单会被放在链条上

使用0xSplit的分割合同。然后，捐助者可以将资金直接发送到受益人地址，或发送到向受益人地址发放资金的锁定协议(vesting contract )。

中期报告被总结在这个推文中。以下是几个重点：在这次试点中筹集了970万美元。这些资金来自许多组织

例如，Lido、Uniswap、ENS、NounsDAO和MolochDAO，以及经常捐款的个人() ——感谢您使这个计划成为可能！

PG在发布时有90名成员，现在有128名，他们之间分发了500万美元。平均而言，每个成员将收到39，000美元，其中最低的是1.3万美元

，高达7.9万美元的PG的框架正在变化，支持L2、删除多签名需求和更新权重的初始结果表明PG正在按计划运行。一个变成一个篮子

Token是被分配给一群自我孵化、不断成长的共识贡献者的机制。没有试点捐赠者的慷慨支持，这个项目不可能取得今天的成果。展望未来，现在正是扩大PG影响范围的时候

充分发挥其潜能：为以太坊维护者提供有竞争力的风险调节能力的补偿。这里最简单的是项目从一开始就捐赠给PG。正如Danny Ryan在创办PG的推文中所说。

许多试验性捐款来自拥有大量资金的大型项目。如果协议会能说服这些项目从第一天开始就捐赠给PG，也就是说他们的Token还是真正的“没有价值”的时候，之后

以太坊的维护者可以从这些成功项目的整个上升轨迹中受益。在有足够数量的项目参与的情况下，激励不是离间他们，而是让最优秀的人才能够维持维护合同。为了支持它，以及许多其他捐赠类型

PG需要进行技术革新。下一个版本支持L1和L2，以进一步减少链上的治理足迹。如果你是希望向协议会捐款的项目，请联系我——我的DM是开放的！

之后的工作在2022年的最后总结出来了……多么不平凡的一年啊！三个月前，我们还没有合并！目前，以太坊已经在后台默默执行权益证明，焦点已经转移到未来事务上。

随着大家在1月回归，上海/Capella升级开发者测试网和影子分支KZG仪式将在线参与以Cancun为中心的讨论

、以及网络升级过程的发展，将需要更好地捕捉社区的优先协议协会试点项目结束，并公开试点后的体系结构

以太坊核心开发者大会更新：上海升级、提款机制、坎昆升级……

推荐阅读