以太坊共识层调用 #99 Writeup

https://www.galaxy.com/research/insights/ethereum-consensus-layer-call-99-writeup/

2022 年 12 月 1 日，以太坊开发者齐聚一堂第 99 共识层 (CL) 称呼。由以太坊基金会的 Danny Ryan 主持的 CL 电话会议是以太坊开发人员讨论和协调以太坊协议变更的两个双周会议系列之一。本周，开发人员重申了在上周的所有核心开发人员 (ACD) 电话会议上做出的决定。也就是说，开发人员同意为以太坊的下一次升级上海启用质押的 ETH 取款，这与他们在 proto-danksharding (EIP 4844) 上的工作分开进行，proto-danksharding 可能会在上海之后的单独升级中激活。开发人员还讨论了一系列与以太坊共识层规范相关的正在进行的研究主题和计划。最后，在电话接近尾声时，开发人员庆祝了 2020 年 12 月 1 日推出的以太坊信标链成立 2 周年。

质押的 ETH 取款和 EIP 4844

在开始电话会议时，Danny Ryan 重申了 ACD Call #150 中的讨论，在该讨论中，CL 客户团队就完全专注于上海的质押 ETH 提款达成共识。 “我认为至关重要的是，共识层团队明确表示，他们认为 EIP 4844 与 [抵押的 ETH] 提款几乎没有准备好，将它们结合起来会大大延迟提款。我们不会耦合它们。我们将以目前的形式全力推进 Capella，”瑞安在电话中说。 Capella 是专用测试网络的名称，核心开发人员正在其中测试用于质押 ETH 提款的代码更改。

以太坊基金会的 DevOps 工程师 Barnabas Busa 提供了有关启用质押 ETH 提款的最新进展。 Busa 提到有两个多客户端开发者网络测试取款，一个模拟合并前环境，另一个模拟合并后环境。这些开发网络目前都不支持所有 EL 和 CL 客户端。合并后环境中较新的测试提款支持 Prysm、Lighthouse 和 Teku CL 客户端，以及 Geth 和 Nethermind EL 客户端。一旦 Nethermind (EL) 和 Besu (EL) 等其他客户端的实施准备就绪，开发人员将启动一个寿命更长的多客户端测试网用于提款。

然后，以太坊基金会的研究员亚历克斯·斯托克斯 (Alex Stokes) 对他实施有界扫描的拉取请求进行了简短更新。简而言之，这是一种防止边缘情况的机制，在这种情况下，协议需要扫描整个验证器集以进行部分和全部提款。斯托克斯提案将扫描限制为最多 1,024 个验证者 .没有人反对 Stokes 的提议，开发人员同意在下周末之前围绕有界扫描推进更多的取款测试用例。

尽管 EIP 4844 的开发将与进入上海的开发工作和质押的 ETH 提取分开进行，开发人员仍然讨论了一些与实施 proto-danksharding 相关的公开讨论项目。构建 Lighthouse (CL) 客户端的 Sigma Prime 软件工程师 Sean Anderson 提到，关于网络将如何处理同步 blob 存在一个悬而未决的问题。 Blob 是将在 EIP 4844 中引入的一种新型交易，它专门将交易数据从第 2 层汇总提交到以太坊的基础层。 Ryan 建议进一步讨论 blob 同步的边缘情况开放的 GitHub 问题。

以太坊基金会的生态系统负责人 Trent Van Epps 更新了 EIP 4844 实施所需的可信设置仪式的进展情况。该仪式旨在生成一段将在 EIP 4844 中使用的安全代码，即将为公共贡献期做好准备。 Van Epps 表示，他希望该仪式将成为加密领域有史以来规模最大的仪式之一，收集 8,000 至 10,000 份捐款。仪式的公众贡献期将持续大约 2 个月，并于 12 月的某个时候开始。有关更多信息，请阅读这个网站 并加入这个 Twitter Spaces 会话 2022 年 12 月 2 日。

研究讨论

开发人员讨论了几个与以太坊 CL 规范的潜在优化和更改相关的讨论项目。首先，Sigma Prime 的联合创始人 Adrian Manning 强调了两项提案，这两项提案都是向后兼容的，这意味着它们不需要全系统的硬分叉升级即可实施。第一个详细这里 旨在改善以太坊上质押节点之间的对等发现。第二个支持运行称为 IPv6 的最新互联网通信协议的 CL 节点。后一个讨论项目是由 Sigma Prime 团队在 5 月份提出的。可以找到之前 CL 通话的通话记录这里 .

检查点同步是指通过从可信节点获取最新的区块状态，让连接到信标链的新节点快速同步到链头的操作。 Checkpointz 是 Ethereum Foundation DevOps 团队构建的一种工具，可让受信任的节点轻松公开检查点同步端点。在电话会议上，ConsenSys 的首席研究员 Mikhail Kalinin 解释说，有人担心 Checkpointz 会成为节点的中心故障点，并指出一些建议 帮助将依赖从 Checkpointz 转移到其他工具。

然后，Obol Technologies 的联合创始人 Oisin Kyne 强调了验证器分配聚合职责的问题，Obol Technologies 是一家构建分布式验证器技术 (DVT) 解决方案的公司。 Kyne 解释说，这些职责不是为分布式验证器集执行而设计的。因此，他为 CL 客户端提出了两个新的端点，以更好地支持分布式验证器的操作。有关凯恩斯提议的更多信息这里 和深静脉血栓形成的高级背景这里 .

最后，Kalinin 围绕以太坊引擎 API 规范提出了两个问题。第一个是内务处理项目，通过删除一种过时的方法来帮助简化引擎 API 规范，该方法用于检索 EL 客户端支持的功能，称为“engine_getCapabilities ”开发者同意在 GitHub 上异步反馈这个建议。 Kalinin 提出的第二个问题是围绕引擎 API 规范文档使用哪种结构。其中一种方法记录了通过分叉对引擎 API 进行的更改，这意味着通过系统级硬分叉升级。其他结构文档因引擎 API 功能而异。更详细地解释了每种方法的优缺点这里 .电话会议上没有开发人员对这两者有强烈的偏见，但 Ryan 确实提到他更喜欢分叉方法，而 Kalinin 提到他认为采用功能方法的优点很强大。

杂件

开发人员同意审查 GitHub 上的讨论engine_getCapabilities 并更多地考虑在上海之前记录引擎 API 更改的结构。在结束通话之前，独立的以太坊开发人员 Micah Zoltu 就网站背后的数据提出了一个简短的问题客户多样性.org . Zoltu 解释说，该网站从两个不同的来源获取数据，这导致了截然不同的结果。 Ryan 回应说，其中一种方法是通过质押的 ETH 计算客户的分布。另一个通过使用识别节点及其对等点的爬虫来记录有关客户端分布的数据。据 Ryan 所知，节点爬虫收集的数据是不准确的，依靠区块打印和质押 ETH 分配的方法虽然不完美，但可靠得多。

Jacek Sieka，也被称为“Arnetheduck”，是正在构建 Nimbus (CL) 客户端的 Status 研究开发主管，他提到他的团队已经推出了一个新的客户端版本。该版本正式将 Nimbus 客户端从测试版升级到生产就绪状态。可以找到有关此版本中改进的更多详细信息这里 .在结束电话会议之前，Ryan 指出，2022 年 12 月 15 日的下一次 CL 电话会议将是今年的最后一次电话会议。开发人员将在新的一年的 1 月某个时候恢复通话。