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

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

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

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

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

在最近的一次 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: Warm COINBASE (降低访问 COINBASE 地址的 gas 开销)

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

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

EIp-3855: pUSH0 instruction (新增操作码 `pUSH0)

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

EIp-3860: Limit and meter initcode (对 initcode 的大小设限并引入 gas 计量)

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

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

对象格式

上海升级纳入的大多数 EIp 其实都是这单一功能的一部分：EVM 对象格式 (EVM Object Format, 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 范围也发生了变化。

在二月，客户端团队同意考虑在上海升级纳入两个最小的 EOF EIp：EIps 35403670。它们都将作为构件，但在不引入 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-3540: EVM Object Format (EOF) v1 (EVM 对象格式版本 1)

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

EIp-3670: EOF – Code Validation (EOF – 代码验证)

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

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

EIp-4200: EOF – Static relative jumps (EOF – 静态相对跳转)

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

EIp-4750: EOF – Functions (EOF-引入函数)

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

EIp-5450: EOF – Stack Validation (EOF-堆栈验证)

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

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

信标链提款

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

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

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

Have a balance above 32 ETH (i.e. have accrued validator rewards)

Arewithdrawable(i.e. have fully exited the validator set)

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

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

From these, the validator will create a list of withdrawals to be included in theirExecutionpayload. Each item in that list contains the following:

验证者将从这些验证者里创建一个提款列表打包进他们的 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 清单，在 Ethereum Magicians论坛也开了一个帖子用来讨论坎昆的候选 EIp。明年年初，坎昆升级范围的讨论工作应该会开始正式进行。

KZG 仪式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 的讨论，以及网络升级流程应如果发展，以更好地捕捉社区的偏好

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

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

2023 年见！

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