一文了解以太坊即将上线的上海/卡佩拉升级

欢迎来到 2022 年 AllCoreDevs 的最后一次更新。

长话短说：

上海/嘉佩乐升级

在最近的 AllCoreDevs 电话会议上，客户团队就上海/嘉佩乐升级的最终范围达成了共识。 虽然升级的名称可能仍有争议，但该团队已经明确了升级的范围，这将为质押者引入信标链提款。 尽快修复此问题是客户团队的目标，因此升级中的其他功能需要同时准备好，或者可能会被删除。

上海 EL 规范列出了所有包含的 EIP：

虽然列表很长，但我们可以将它们分为三个不同的部分：小改进、EVM 对象格式和取款。 让我们一一分析：

小改进⚙️

EIP-3651：温暖的COINBASE

这个 EIP 修复了 EIP-2929 中的一个疏忽，该疏忽根据客户端是将它们存储在内存中（WARM）还是需要从磁盘中检索它们（COLD）来改变访问某些数据字段的 gas 成本。

EIP-2929 在每个事务开始时将客户端内存中的两条数据设置为 WARM：发送地址和接收地址。 EIP-3651 在这个列表中添加了第三个地址，即 COINBASE 地址（又名 feeRecipient），因为它也是客户端在处理区块交易时在内存中的地址。

EIP-3855：PUSH0指令

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

EIP-3860：节流和计量初始化代码

该 EIP 增加了 initcode 的最大大小，并引入了基于其长度的 gas 计量。 大小限制为 EVM 添加了一个不变量，这应该更容易推理和提出更改。

引入了 2 gas/32 字节的 initcode 开销来说明客户端在执行之前必须执行的 jumpdest 分析，这在之前的 gas 计划中没有考虑到。

EVM 对象格式

上海升级中包含的大多数 EIP 都是单一功能的一部分：EVM 对象格式 (EOF)。 此升级工作分为 5 个不同的 EIP，以帮助客户开发人员分别解释每个更改，但为了提供更高级别的概述，本周发布了统一规范。 五个 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 版本颠簸增加了并行的数量，而不是顺序的，必须维护的 EVM 规则集。

出于这个原因，在过去的几个月里，客户团队开始更喜欢“大 EOF”方法。 这样，虽然他们必须实施更大的变更集，但 EOF 版本将保留更长时间，从而减少要维护的“并行 EVM”的数量。 因此，考虑了“大EOF”，并最终将其纳入了下一次的上海升级。

也就是说，更大的功能显然更难实施和测试，客户团队不希望看到 EOF 显着延迟信标链的撤回。 因此，客户团队同意，如果 EOF 实施不完整并且不能在明年 1 月之前快速相互操作，则将 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 - 静态相对跳转

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（即验证者奖励已累计）

Withdrawable（即已经完全退出验证人集）

根据这些，验证者将创建一个提款列表以包含在他们的 ExecutionPayload 中。 此列表中的每个项目都包含以下内容：

EL 客户端将在构建或处理区块时执行交易后应用这些取款。 换句话说，取款的处理方式与工作量证明奖励的记入方式类似，并且不会与用户交易争夺区块空间。

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

处理提款时，“全部”和“部分”提款之间的优先级/顺序没有区别。 一旦验证者离开退出队列，就会发生完全撤回，当验证者集的线性扫描到达验证者的索引时，会定期发生部分撤回。

为了处理取款，验证者必须使用 0x01 令牌以太坊合并时间，它代表一个 ETH 地址。 信标链启动时只允许 BLS 密钥对的 0x00 凭据。 为了启用提款，具有 0x00 凭证的验证器将需要签署 BLSToExecutionChange 消息。 这些将作为 Capella 升级的一部分启用。 验证者可以期待多种工具的支持和教程来签署此消息。

验证器集的扫描以每个块为界。 如果在扫描验证者集合的一个子集后，没有 16 个提款需要处理，验证者将停止扫描，下一个将从上次扫描的验证者索引中提取。

与往常一样，将有多个开发人员测试网 (devnets) 和测试网（甚至可能是一些新的！）供验证者运行整个过程并在主网上线之前解决所有问题。

不过，上海/卡佩拉升级并不是唯一取得进展的升级！ 开发团队也一直期待着下一次的更新。

坎昆升级️

上海升级的内容已经确定，但很多CFI EIP还没有纳入。 客户端团队开始讨论下一次Cancun升级应该考虑什么️

在 CL 方面，EIP-4844 被指定为 capella 之后的第一个升级。 EL 尚不支持此布局规范，但 EL 团队同意遵循类似的路径并将下一次升级集中在 EIP-4844 周围。

按照使用 devcon 城市名称进行升级的惯例，开发人员创建了 cancun.md 并在此次升级中正式包含了 EIP-4844。

这个决定是在 2022 年 AllCoreDevs 电话会议的最后几分钟做出的，因此没有时间讨论其他提案。 那些在上海晋升为CFI但未被选中的EIP已经被转移到坎昆的CFI名单中，以太坊魔术师论坛已经创建了讨论坎昆EIP候选人的话题。 关于坎昆范围的讨论将于明年初正式开始。

KZG仪式️

与坎昆升级相关的另一件事是 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)，焦点已经转移到即将发生的事情上。

随着一月假期的结束，您可以期待：

谢谢阅读！ 感谢过去一年努力改进以太坊的每一个人——我们做了很多。 希望你们都度过了一个当之无愧的假期。

2023 年见！