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