比特币:以太坊核心开发者会议更新：上海升级、提款机制、坎昆升级_TALI

原文标题：《以太坊核心开发者会议更新014》

原文来源：AllCoreDevsUpdate

原文作者：TimBeiko

原文编译：Ethereum.cn

欢迎阅读新一期的AllCoreDevs(以太坊核心开发者会议)更新——2022年的最后一期。

尽管这些更新最初是每月系列，但节奏逐渐趋于每季度一更。读者可以把这些更新视为围绕AllCoreDevs发生的重大事件摘要。如果你想要了解更多细节，我推荐阅读ChristineKim?的记录、BenEdginton?的共识层会议记录和我的ACD长推文，这些更新更频繁。

话不多说，让我们开始吧！

概要

上海/Capella升级的内容已经敲定了：提款、EOF和一些小型修改......前提是它们不延迟提款

Blob空间要来了：EIP-4844将成为以太坊下一次升级的中心，它的召唤仪式很快就要开始

在技术方面使得执行层和共识层的升级流程能互相协调的努力正在进行中。我们还看到关于在这个过程中更好地融入社区意见的积极讨论

ProtocolGuild(协议公会)发布了一份中期试点报告，以及一份在2023年扩大一层维护者的规模并更好地给他们提供支持的大概计划

上海/Capella升级

在最近的一次AllCoreDevs?上，客户端团队就上海/Capella升级的最终范围达成了共识。尽管升级的名字可能还有待商榷，但团队对它的范围已经明晰了。升级的主要功能是为质押者引入信标链提款。尽快推出这个功能是客户端团队不想妥协的事情，所以升级中的其他功能需要同时准备好，否则可能会被放弃。

上海执行层规范列出了所有被纳入的EIP：

EIP-3540:EVM对象格式(EOF)v1

EIP-3651:降低访问COINBASE地址的gas开销

EIP-3670:EOF-代码验证

EIP-3855:新增操作码PUSH0

EIP-3860:对initcode的大小设限并引入gas计量

EIP-4200:EOF-静态的相对跳转

EIP-4750:EOF-引入函数

EIP-4895:信标链推式提款作为系统操作

EIP-5450:EOF-堆栈验证

尽管列表很长，它可以被分成三个不同部分：小型改良、EVM对象格式和提款。接下来将逐一介绍：

小型改良?

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

这个EIP修复了在EIP-2929?里的一个疏忽，即对某些数据字段访问的gas开销修改是根据这些数据是已在客户端内存中(WARM)还是需要从磁盘中检索它们(COLD)来判断。

EIP-2929在每笔交易开始时将客户端内存中的两个数据设为?WARM?：发送地址和接收地址。EIP-3651给这个列表添加第三个地址，COINBASE?地址(即?feeRecipient)，因为它也是客户端在处理区块交易时在内存中的地址。

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

顾名思义，EIP-3855引入了一个把0值压入堆栈的操作码。压入0通常用于填充EVM中的值，此操作码将提供一种更高效、更便宜的方法来执行此操作。

EIP-3860:Limitandmeterinitcode(对initcode的大小设限并引入gas计量)

这个EIP添加了?initcode?的大小上限，并基于其长度引入gas计量。其大小上限为EVM添加了一个不变量，这使得它更易于理解和提议修改。

为?initcode?引入每32字节2gas的开销，这是用于支付客户端在执行前必须进行的jumpdest分析，jumpdest分析之前没有列入gas收费表。

对象格式

上海升级纳入的大多数EIP其实都是这单一功能的一部分：EVM对象格式(EVMObjectFormat,EOF)。这项工作被分解为5个不同的EIP，以帮助客户端开发者理解每个单独的修改，但为了提供一个更高层级的概述，开发者发布了一份统合的规范。这5个EOF的EIP分别是：

EIP-3540:EVM对象格式版本1

EIP-3670:EOF-代码验证

EIP-4200:EOF-静态相对跳转

EIP-4750:EOF-引入函数

EIP-5450:EOF-堆栈验证

值得注意的是，EOF的第一步是发生在伦敦升级的EIP-3541，它为EOF合约保留了?0xEF00?的前缀。在过去的几个月里，上海升级的EOF范围也发生了变化。

在二月，客户端团队同意考虑在上海升级纳入两个最小的EOFEIP：EIPs3540&3670。它们都将作为构件，但在不引入EIP4200、4750和5450的前提下，不会提供全部功能。尽管有可能延展EOF，但向后不兼容可能需要新增一个版本。因为EOF前的或有一个特定版本的EOF合约必须一直可执行，因此每个新的EOF版本都意味着客户端开发者必须维护一组与旧规则并行的新EVM执行规则。

在EOF之前，客户端一次只维护一组EVM规则。代码库也支持之前的EVM规则，这些规则在每次网络升级里都会修改，但一旦它们到了区块链的链头，就必须只应用最新的规则。部署了EOF后，客户端将维护两套平行的EVM规则，因此它们可以执行在EOF和非EOF合约里的代码。换句话说，EOF的版本增加所增加的是必须维护的平行的而不是连续的EVM规则集数。

为此，在过去几个月，客户端团队开始偏向于「大EOF"的方法。这样，尽管他们必须实现更大型的修改集，但EOF版本将维持更长时间，并减少需要维护的「平行EVM"数。因此，开发者们考虑的是「大EOF」，并最终纳入到了上海升级。

也就是说，更大型的功能显然更难以实现和测试，且团队也不希望看到EOF严重延迟信标链提款。因此，如果到1月，EOF的实现还没完成，且彼此间无法快速互操作，客户端团队同意把EOF移出上海升级。

有了这些脉络后，现在让我们简要介绍各个EOFEIP：

EIP-3540:EVMObjectFormat(EOF)v1(EVM对象格式版本1)

这个EIP为EOF合约引入了「container」。它增加了区分合约里的代码和数据部分的标记，并防止不符合格式的EOF合约被部署。这就保证了任何链上的EOF合约都会遵循有效的格式，这就简化了与这些合约的交互，以及对它们的静态分析。

EIP-3670:EOF-CodeValidation(EOF-代码验证)

在由3540引入的container基础上，EIP-3670确保EOF合约中的代码是有效的，或者防止它被部署。

这意味着未定义的操作码不能被部署在EOF合约中，这有一个额外的好处，即减少所需增加的EOF版本数量。如果添加了一个新的操作码，可以简单地改变验证规则来启用它，并且保证没有已部署的EOF合约在其代码部分引用它。

EIP-4200:EOF-Staticrelativejumps(EOF-静态相对跳转)

EIP-4200引入了首批EOF专用的操作码：RJUMP、?RJUMPI?和?RJUMPV，它们将目的地编码为有符号的即时值。这些新的JUMP操作码可以被编译器用来优化gas开销，因为它们免去了运行时jumpdest分析的需要，而现有的?JUMP?&?JUMPI操作码都是需要的。

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

EIP-4750在4200的基础上再进一步：它不允许使用?JUMP?&?JUMPI?操作码，并为不能复制?RJUMP、RJUMPI?和?RJUMPV功能添加替代方案。它通过在EOF字节码里引入特定函数section来实现，这些函数可以分别从新的?JUMPF、CALLF?和?RETF?操作码跳转到，并使用它们来调用和返回。

EIP-5450:EOF-StackValidation(EOF-堆栈验证)

最后，EIP-5450为EOF合约添加了另一个验证检查，这次是围绕堆栈的。这个EIP防止EOF合约部署可能导致堆栈下溢，以及某些情况上溢的代码。有了这个EIP，客户端可以减少在执行EOF合约时验证检查的次数，因为它们有了围绕堆栈相关异常的更好保证。

作为一个非常关注EIP本身的非EVM专家，我可以介绍的就这么多了！如果读者想要更加深入了解EOF，我推荐Geth团队的lightclients?和Solidity团队的Leo?发的相关推文。

信标链提款

最后但同样重要的是，「Shapella」?(译者注：Shanghai/Capella的合称)的主要部分是信标链提款。这部分变更在共识层规范和EIP-4895?都有说明。现在有一份稍微过时的元规范把这些变更联系在一起。

从高层级来看，提款的机制如下：

当提议区块时，验证者线性扫描验证者索引，找出前16个有0x01凭证的验证者，它们需要符合以下其中一个条件：

Haveabalanceabove32ETH(i.e.haveaccruedvalidatorrewards)

Are?withdrawable?(i.e.havefullyexitedthevalidatorset)

余额大于32个ETH(即已经获得验证者奖励)

是?withdrawable?的（可提款的，即已经完全退出验证者集)

Fromthese,thevalidatorwillcreatealistofwithdrawalstobeincludedintheir?ExecutionPayload.Eachiteminthatlistcontainsthefollowing:

验证者将从这些验证者里创建一个提款列表打包进他们的ExecutionPayload。列表里的每一项都包含以下内容：

WithdrawalIndex：所有进行过的提款交易索引——这有助于区分来自相同地址、相同验证者的相同数额提款

ValidatorIndex：余额被提出的验证者索引

ExecutionAddress：执行层的ETH地址，即提款应该发送到的地方

Amount：被发送到?ExecutionAddress?的数量，这个数量以?gwei(而不是wei)计量

在构建或处理区块时，执行层客户端将在交易执行后进行这些提款操作。换句话说，处理提款与工作量证明奖励的入账方式相似，它并不与用户交易竞争区块空间。

还有一些值得注意的细节：

在处理提款时，提出「全款」对比「部分资金」在优先级/排序上并没有区别。当验证者离开退出队伍时即提出全款，而部分提款是周期性发生的，即当对验证者集进行线性扫描并扫到某个验证者的索引号时。

为了提款得以被处理，验证者必须使用?0x01?凭证，它用ETH地址表示。信标链上线时只允许使用BLS密钥对?0x00?凭证。为了启动提款，有?0x00?凭证的验证者将需要对一条?BLSToExecutionChange?消息签名。这些将在Capella升级中被激活。会有多种工具用以签署这条消息，验证者可以期待对这些工具的支持和教程。

对验证者的扫描是以每个区块为界限的。如果在扫描完一个验证者集的子集后没有16笔提款需要处理，验证者将停止扫描，而下一个验证者将从最后一个被扫描的验证者索引开始。

像往常一样，在主网上线前，会有几个开发者测试网和测试网(甚至可能有一些新的测试网！)给验证者运行整个过程，并解决所有问题。

上海/Capella并不是唯一取得进展的升级！开发者团队还在展望下一个升级。

坎昆升级

由于上海升级的内容已经满了，但很多纳入考虑升级的EIP(CFI)都没能进入上海升级。客户端团队开始讨论哪些EIP应该考虑进入下一次升级：坎昆升级(共识层名称有待确定)

在共识层方面，EIP-4844已经成为Capella升级后第一个写进规范的的EIP。执行层(还)没有一个可以实现这种布局的规范，但执行层团队同意遵循相似的路径，并在下一个升级里以EIP-4844为中心。

按照升级使用举办过Devcon城市名称的惯例，cancun.md?已经被创建，其中EIP-4844被正式纳入升级。

这个决定发生在2022年最后一次AllCoreDevs会议的最后一分钟，所以没有时间处理其他提案。进入上海升级CFI但最终没有被纳入的EIP被移到坎昆升级的CFI清单，在EthereumMagicians?论坛也开了一个帖子用来讨论坎昆的候选EIP。明年年初，坎昆升级范围的讨论工作应该会开始正式进行。

KZG仪式

另一件与坎昆升级相关且可以期待的事情是KZG仪式，这是EIP-4844的要求。

这个仪式将生成验证blob数据有效性所需的随机性。要使得它被认为是安全的，只需要有一个参与者是诚实的。换句话说，如果除了一个参与者外其他所有参与者都合谋了，这样整个过程在密码学上都是安全的。

这个仪式从1月开始，它将向所有人开放几个月。我们的目标是有10,000个参与者，计划会是这类仪式迄今为止规模最大的！如果你想要确保不错过，请在推特关注TrentVanEpps！

合并后升级流程

正如在之前的更新里提到的，合并后，在执行层和共识层协调以太坊的升级流程是一个重要的待办事项。从高层级来看，执行层使用黄皮书&EIP来说明修改，而共识层使用可执行的Python规范。

执行层流程的好处是EIP被社区所熟知，并且其格式化的方式可以清楚地展示提案背后的原因。有大量数学内容的黄皮书搭配EIP，以及需要把规范放回各个EIP的脉络里使得执行层规范难以理解和扩展。

共识层方面的问题则相反：它有一个清晰易懂的规范，在一个单一的仓库里，但修改并不具体可辨，而且提案淹没在仓库里的其他公开PR里。

随着以太坊执行层规范的引入，我们有希望从执行层方面缩短这一差距。而且，通过一些流程争论，我们可能能够让EIP引入到共识层流程！

也就是说，随着上海升级的范围被讨论和最终敲定，很明显，这个过程可能缺乏另一部分：让社区去表达他们对变更的相对偏好，并参与到关于整个升级范围(而不是个别EIP)讨论里的地方，并将其作为AllCoreDevs和共识层会议决策的一部分。

现在还不清楚它会是什么样的——我很乐意收到建议！——但随着积极参与协议变更的利益相关者的数量以及一层变更影响的领域数量都在增加，我们显然需要某些东西。

幸运的是，我们不需要从头开始。EthereumMagicians?已经存在多年了，它的线下聚会、专门的小组会议或社区会议可能是很好的扩展起点。

期待在2023年初在这方面有更多进展！

协议公会更新

随着协议公会(ProtocolGuild,PG)试点已经完成了一半，他们发布了一份报告，检视事情的进展情况，以及思考项目的下一步计划是什么。

提醒一下，PG是针对以太坊Layer1客户端开发者、协议研究员和支持贡献者(如你们）的一个无需许可的资助机制。

这个机制以个人为中心，而不是组织。简而言之，每个成员都有资格获得公会的Token份额，根据他们对以太坊的贡献时长来进行加权计算。成员的增删是以真正以太坊的方式来进行——基于一套标准，在PG内部达成大致的共识。这个列表随后会被放到链上，使用0xSplit?的分割合约。然后，捐献者可以将资金直接发送到接收者的地址，或发送到给接收者地址发放资金的锁仓合约(vestingcontract)。

试点中期报告在这篇推文里有总结。以下是一些重点

这次试点筹得了970万美元，这些款项来自很多的组织，例如Lido、Uniswap、ENS、NounsDAO和MolochDAO，以及一些经常进行捐助的个人(感谢Tetranode！)——感谢大家使这项计划成为可能??！

PG在发布时有90名成员，到现在有128名，在他们之间已经分发了500万美元

平均来说，每个成员收到39,000美元，其中最低的是1.3万美元，最高的达到7.9万美元

PG的架构正在变化，将会支持L2，并删除对多签的需求，以更新权重

这些早期的结果显示PG正在按计划运作：一个将一篮子Token分配给一组自我孵化、不断增长的协议贡献者的机制。如果没有试点捐赠者的慷慨支持，这个项目不会有今天的成果。

展望未来，现在是时候扩大PG的影响范围，充分发挥它的潜能：为以太坊的维护者提供有竞争力的、具有风险调节能力的补偿。这里最简单的做法是项目从一开始就给PG捐款，就像DannyRyan在启动PG的推文里所说的。

试点里的捐款大多来自拥有大量资金的大型项目。如果协议公会可以说服这些项目从第一天就给PG捐款，即他们的Token仍然是真正「不值钱」的时候，之后，以太坊的维护者就可以从这些成功项目的整个上升轨迹中获益。

当有足够多的项目参与时，激励可以让最优秀的人才保持维护协议，而不是把他们拉走。

为了支持这一点，以及其他许多捐献类型，PG将需要进行一次技术革新。下一个版本将支持L1和L2，并进一步减少其链上治理的足迹。

如果你是希望给协议公会捐款的项目，请联系我——我的DM是开放的!

后续工作

这就是2022年的最后总结了......多么不平凡的一年！三个月前，我们甚至还没合并！现在，以太坊已经在后台默默运行着权益证明，焦点已经转移到未来的事务。

随着大家在1月份回归，大家可以预期：

上海/Capella升级的开发者测试网和影子分叉

KZG仪式上线

围绕Cancun的讨论，以及网络升级流程应如果发展，以更好地捕捉社区的偏好

协议公会的试点将结束，我们将公布试点后的架构

感谢你们的阅读！以及感谢在过去一年中花时间努力改善以太坊的每一位——我们实现了很多。

2023年见！

标签：比特币ALIVITATALI闪电比特币局Decentralized Hash MiningVita InuItalian Lira

FIL币热门资讯