以太坊:以太坊核心开发者如何解读上海升级？

本文作者为Tim Beiko，是以太坊核心开发者，这篇文章是他对于接下去上海升级的解读。

欢迎阅读有关 AllCoreDevs 在 2022 年的最后一次更新。

长话短说：

上海/ Capella 升级的内容已经敲定：提款，EOF，还有一些小改动……只要不耽误提款即可 ?

Blobspace 即将到来: EIP-4844 将成为以太坊下一次升级的中心，其召唤仪式即将开始??

开发者们正在努力协调执行客户端和共识客户端升级过程的技术方面。我们还看到了关于更好地将社区的意见纳入流程的积极讨论?

在最近一次 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 对象格式以及提款。让我们来逐一分析：

Cymbal推出“人类可读”的以太坊区块链浏览器:金色财经报道，Cymbal宣布推出“人类可读”的以太坊区块链浏览器，并于今日发布了测试版，Cymbal标榜自己是第一个“人类可读”的以太坊区块浏览器，它采用与标准浏览器相同类型的公共区块链数据，并将其转化为不仅可视化、一目了然且易于理解的摘要，而且还具有社交性。Cymbal通过人工智能工具运行这些数据，生成交易和趋势的对话摘要，使普通用户更容易理解。Cymbal首席执行官兼联合创始人Eric Feng表示，Cymbal正在通过OpenAI的GPT大语言模型运行该工具。[2023/7/20 11:05:49]

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

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

顾名思义，EIP-3855 引入了一个将值 0 推入堆栈的操作码。Pushing 0 经常用于填充 EVM 中的值，此操作码将提供一种更有效、更便宜的方法来实现这一点。

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

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

Chainlink：协议及服务将继续在以太坊上运行，不支持PoW等分叉:据官方消息，Chainlink发文表示，在以太坊合并期间和合并之后，Chainlink协议及其服务将继续在以太坊上运行，不支持以太坊网络的分叉，包括PoW分叉，这与以太坊社区将链升级为PoS的决定一致。对于不确定其围绕合并的迁移策略的以太坊开发人员和DApp团队，建议暂停智能合约操作，以避免不可预见的事件并帮助保护用户。[2022/8/8 12:08:54]

上海升级包括的大多数 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 执行规则。

以太坊未确认交易为167,207笔:金色财经消息，据OKLink数据显示，以太坊未确认交易167,207笔，当前全网算力为427.76TH/s，全网难度为5.69P，当前持币地址为56,566,831个，同比增加187,278个，24h链上交易量为1,872,305.6ETH，当前平均出块时间为13s。[2021/3/21 19:04:09]

在 EOF 之前，客户端一次只维护一组 EVM 规则。代码库还支持历史 EVM 规则，这些规则可以改变每次网络升级，但一旦它们到达链的顶端，就只能应用最新的规则。而使用 EOF，客户端将维护两个并行的 EVM 规则集，因此它们可以在 EOF 和非 EOF 合约中执行代码。换句话说，EOF 版本bumps 增加了并行的数量，而不是顺序的，必须维护的 EVM 规则集。

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

也就是说，更大的功能显然更难以实施和测试，而客户端团队们并不希望看到 EOF 显着延迟信标链提款。 因此，客户端团队们同意，如果到明年 1 月， EOF 实施不完整且相互之间无法快速互操作，则将 EOF 从上海移除。

在这个背景下，现在让我们简单地介绍一下各种 EOF EIP：

该 EIP 为 EOF 合约引入了“容器”。 它在合约中添加了区分代码和数据部分的标记，并防止部署不符合格式的 EOF 合约。 这保证了任何链上 EOF 合约都将遵循有效的布局，从而简化了与这些合约的交互以及对它们的静态分析。

EIP-3670 建立在 EIP-3540 引入的容器之上，确保合约 EOF 中的代码有效，或阻止其部署。

动态 | Fuel Labs推出基于Optimistic Rollups的以太坊侧链:Fuel Labs 宣布推出首个基于Optimistic Rollups开发的无需信任的以太坊侧链 Fuel ，Fuel侧链专门针对以太坊大额支款设计，在伊斯坦布尔升级之前，保守估计能将以太坊 ERC-20 代币交易成本降低 5 倍。[2019/10/23]

这意味着未定义的操作码无法在 EOF 合约中部署，这具有减少所需的 EOF 版本更新数量的额外好处。 如果添加了新的操作码，只需更改验证规则即可启用它，并且可以保证没有 EOF 部署的合约在其代码部分引用它。

EIP-4200 引入了第一个 EOF 专用操作码：RJUMP、RJUMPI 和 RJUMPV，它们将目标编码为带符号的即时值。编译器可以使用这些新的 JUMP 操作码来优化 gas 成本，因为它们消除了对现有 JUMP 和 JUMPI 操作码所需的运行时 jumpdest 分析的需要。

EIP-4750 比 EIP-4200 的功能更进一步：它不允许 JUMP 和 JUMPI 操作码，并为 RJUMP、RJUMPI 和 RJUMPV 无法复制的函数添加了替代方案。它通过在 EOF 字节码中引入特定的函数部分来实现这一点，这些函数部分可以分别使用新的 JUMPF、CALLF 和 RETF 操作码跳转到、调用以及返回。

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

作为一名非 EVM 专家，以上就是我能带你走的最远的地方！ 如果你想深入了解 EOF，我推荐你们阅读 Geth 的 lightclients 或 Solidity 的 Leo 的帖子。

声音 | 以太坊联合创始人Gavin Wood：加密分权只是一个神话 以太坊并非去中心化:据LongHash消息，以太坊联合创始人兼Polkadot创始人Gavin Wood在接受采访时表示，大部分加密社区均已经背叛“加密货币应该打破边界并将人们聚集在一起”的理想。其认为加密分权只是一个神话，以太坊也不是去中心化的。“比特币基本上由少数人控制。比特币至少在理论上是由比特币核心决定的，比特币核心是一个GitHub存储库。” 此外，其表示对区块链在跨境贸易、跨境互动等方面的应用更感兴趣，区块链有可能增加互连性，并保持最大化。因此尽管Gavin Wood对加密社区的分歧感到沮丧，但其总体基调是乐观的。在介绍Polkadot时，其承认至少在项目上线之前，Polkadot依然受到“仁慈的独裁者”的统治。[2019/5/12]

最后但同样重要的是，“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 升级并不是唯一取得进展的升级！ 开发团队们也一直在期待下一个升级。

上海升级的内容已定，但很多 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 范围的讨论将正式开始。

另一件与 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 升级的讨论，以及网络升级过程应该如何演进以更好地捕捉社区的偏好??

谢谢阅读！感谢在过去一年中花时间努力改进以太坊的每个人-我们做了很多工作。

DeFi之道

个人专栏

阅读更多

金色财经 子木

金色早8点

去中心化金融社区

CertiK中文社区

虎嗅科技

区块律动BlockBeats

深潮TechFlow

念青

Odaily星球日报

腾讯研究院

标签：以太坊BSPNBSDEV以太坊价格今日行情分析BSPAY币NBS价格devt币为什么会大跌

中币热门资讯