以太坊核心开发者会议152

以太坊核心开发者会议 #152

会议日期/时间：2023 年 1 月 5 日，UTC 时间 14:00-15:30

会议时长：1 小时 30 分钟

GitHub 议程

会议视频

主持人：Tim Bieko

笔记： Alen (Santhosh)

决策事项	描述
152.1	EIP-3860：将失败更改为 OOG EIPs#6249：Aragon 和 Geth 团队都批准了此 PR。 所以准备合并。 更新测试，下一步也应该包括此更改。
152.2	上海升级： 客户端团队已经同意 EOF 不应包含在上海升级中。 从上海升级中删除 EOF，同时保持范围的严格性。 所以，是的，这样我们就不会推迟提款。
152.3	EIP-4844 更新： 没有重大更新，接下来我们将举行另一次社区电话会议。
152.4	在 ExecutionPayloadHeader consensus-specs#3078 中为列表添加十六进制树根： EL 开发者需要线下讨论此事后再回来，无法通过本次通话做出决定。
152.5	EIP-5483： 作者未出席本次会议

Tim Beiko

• 早上好，各位。 欢迎参加第一次，所有核心开发者执行层会议。 这是第 152 次此类通话。 是的，今天的大部分内容都围绕上海升级展开。
• 因此，获取有关提款测试和 DevNet 状态的一些更新。 有一个关于限制计量器、代码 EIP 的规范变更提案，稍后我将进行介绍，然后，跟进 EOF，了解客户端的进展情况，基于上次通话的对话。 并且，还会回顾自那以来出现的不同提案。 然后我可以介绍一些测试方面的内容。
• 最后，还有 EIP 4044，一个关于 CL 规范的提案，以及两个新的 EIP 需要讨论。 如果我们能讨论到这些的话。
• 我想先从这里开始，来自测试或客户端团队的任何人是否愿意就提款测试的进展情况，不同实现的进展情况以及开发网络方面的进展情况发表快速更新。

提款测试与 Devnets 更新 3.30

Barnabas Busa

• 关于 DevNet，我可以提供最新信息。 是的。 因此我们目前正在运行一个 DevNet，我们在圣诞节前就开始了。
• 目前，我们有所有不同的客户端组合在上面运行。 有些组合运行良好，而另一些组合自然存在问题，我已将链接发布在聊天中。 在这里我们可以看到我们位于区块 94,000，并且大多数节点都能够继续前进。

Tim Beiko

• 好的。实现中包含了什么？ 因此我认为它包括提款和这些其他小的 EIP，但不包括 EOF，对吗？

Barnabas Busa

• 这是正确的。

Tim Beiko

• 好的。太棒了。 任何其他客户端团队，有人对此有想法或想分享其他内容吗？ 哦，好的。
• 然后，Perry，是的，发布了我们在聊天中定位的规范版本。 因此这是 CL 规范，13.0，alpha two，然后在 EL 方面，我们使用的提款 EIP 的 commit 是 0FA D E C，太棒了。 还有关于提款或上海升级的内容吗？

Barnabas Busa

• 我们希望开始一个新的版本，其中包含你，但这实际上取决于 EL 团队是否为此做好准备。

Tim Beiko

• 知道了。 是的。 好的，谢谢。 我想在我们开始讨论 EOF 之前，我想快速介绍一下 Powell 为 EIP 3860 提出的更改。
• 它更改了一种失败情况，而且似乎 Geth 的一些人已经批准了这一点。 有人想快速概述一下这是什么吗？
• Marius，我将点名你，因为你是第一个批准它的人，而且我在通话中找不到 Powell。

EIP-3860：将失败更改为 OOG EIPs#6249 5.58

MariusVanDerWijden

• 所以基本上，我们有不同的失败模式，要么是 gas 不足 (out of gas)，要么只是返回零。 因此，我们要么终止交易上下文，要么返回零地址。 如果你查看链接，如果你查看以太坊魔法师的帖子，你会看到这些检查就像是交织在一起的。
• 因此，我们之前进行了一些 gas 不足 检查，然后在零地址返回中进行了一些其他 gas 不足 检查，将其放在一个块中，然后再进行另一个块，这样更有意义。
• 而且，基本上现在指定的 代码初始化 大小限制检查将返回地址零。 但是，在概念上也更有意义的是在这里返回错误，因为这意味着你遇到了 代码初始化 大小限制。 对我而言，这显然是一个错误。 所以，是的。

Martin Holst Swende

• 是的，从语义上也可以这样理解，我的意思是，你可以部署部署和冷启动大小，但是如果这样做大于 C 0 0 0 管道，则会花费无限量的 gas。

Tim Beiko

• 好的。 还有其他人，我看到 Geth 的人也批准了这个 PR，Aragon 也是。 任何客户端团队不同意吗？ 好的，太完美了。 我想我们可以继续在接下来的一周左右合并这个，然后更新测试，下一步也应该包括这个更改。 好的。 哦，哦，是的。

Pawel Bylica

• 是的，很抱歉我迟到了。 我想知道另一方是否有任何评论，我的意思是，来自合约开发人员的评论，如果他们认为这是一个需要处理的问题。

Tim Beiko

• 通话中的人对此合约幻灯片有意见吗？ 你想阻止合并，直到我们弄清楚吗？ 或者，最好是

Pawel Bylica

• 我也稍微赞成提出的更改，因为我认为客户端同意。 但是我认为，主要原因是，我认为一月份最常见的系列是返回尽可能多的用户友好的错误。 是的，所以，我认为这是最初设计的原因，是的，我不确定这在多大程度上适用于这里。 但我不会阻止它，但确实存在一些担忧。 是的，我不知道。

Tim Beiko

• 是的，我想只是因为我们希望推进提款，而且所有事情都交织在一起，如果没有任何客户端团队反对，我将继续进行更改。
• 我想如果在接下来的几天或几周内，我们了解到合约开发者的大力反对，我们总是可以将其恢复。 这似乎不是一个巨大的变化。 但是，是的，我将尝试继续前进并立即合并它。 有人不同意吗？

Martin

• 我同意。

Tim Beiko

• 好的。 我会尽量呼吁合约开发者对此进行关注。 因此，也许我们可以等到周五晚些时候或周一再合并它，这样至少可以让人们有几天的时间，但假设它会进行。 太棒了。

EOF 状态更新和截止日期 11:13

Tim Beiko

• 好的。 接下来是 EOF。 因此，我认为这里有两件事要做。 首先是 EOF 1 实现的当前状态，最好先回顾一下，然后我们可以讨论自那以来出现的不同提案。
• 因此，具体而言，Vitalik 在 ETH 魔法师上提出了关于禁止代码自省的提案。 然后，今天早上 Alex 分享了这种观点，即所有这些如何适应更广泛的 EOF 路线图。 但是，也许，是的，首先，任何客户端团队是否愿意分享他们 EOF 实现的进展情况？

lightclient

• 也许我可以快速更新一下在假期期间的各个分会场的情况。 是的，我们在假期期间开设了两个分会场，主要有两个规范结果，主要是第一次会议的结果。 首先是我们删除了 jump F 操作码。
• 我们觉得我们需要花费更多的时间，让 solidity 完成他们的实现，并确保这是我们正在寻找的完美指令类型。 因此，我们暂时将其删除，从而稍微缩小了 EOF 的范围。 然后我们还使数据部分成为强制性的。
• 以前它是可选的，但使其强制性使解析变得稍微简单一些。 这些是两个主要的规范更改，也讨论了一些其他事情。 但是，这些最终进入了规范。 Epson 团队花费了大量时间，我也帮助了一下，使规范进入了更加最终确定的位置。
• 我认为我们已经合并了所有未完成的 PR 至 EOF EIP。 仍然有一些小事情，例如规范中的小错误，四个或五个 EIP 之间存在一些冲突，但总的来说，EIP 在实现和测试方面都处于良好状态。
• 我认为大约一周半前，一周前，Martin 开始在所有客户端上进行差异模糊测试。 这揭示了很多东西。 最初，我认为每个客户端至少有三个、四个错误，其中很多东西都已得到解决。 如果 Martin 想更多地谈谈那里的发现，他会，是的，那会很棒。
• 但我们也有两组参考测试。 我认为它们都没有正式发布，但 Epsilon 团队一直在 Ethereum slash tests 中开发一组测试，而 Mario 和我一直在 execution spec tests 中开发一些测试。 Mario 和我决定在能够集成上海升级时间逻辑之前不发布它们，但这些测试在我会前发布的一个 PR 中。 * 我认为参考测试不如我们最终希望的那么全面，但它们处于我们可以开始了解客户端位置的状态。 不幸的是。
• 我认为除了你之外，没有任何客户端运行了所有测试，你知道，Geth 客户端。 我几天抢跑了 Epsilon 测试，通过了除两三个之外的所有测试，显然我填写了 execution spec 测试。 因此我们正在通过所有这些测试，因此仍然需要让一些客户端运行这些测试。 是的，我认为这主要是更新。 我很想听听其他客户端团队对他们的实现进度的看法。

Tim Beiko

• 也许 Dan

Danno Ferrin

• 在 Besu，我们已经开始随机参考测试。 我们还没有，最初有规范更改。 你可以随意从 EOF 1 转到旧版，因此我需要更新它。
• 因此，你只能从 EOF1 创建 EOF1。 这些是大多数失败的测试。 尽量避免，我正在做太多的合并，直到我们减少进入实际主线的 PR 数量。
• 因此我将大多数这些合并到我拥有的 EOF 5 分支中。 但是，是的，我们基本上处于检查所有框的阶段，确保一切都已准备就绪。 因此我们已经完成了所有主要工作。

Tim Beiko

• 知道了。 谢谢。 Nethermind 或 Aragon 的人呢？

Ahmad Bitar

• 因此，我们已经有了 EOF 的完整实现，测试尚未最终确定。 我们不确定要提取哪个 PR 并针对它运行。 我们已经针对其中的几个运行过，因为它们尚未准备好并且不符合规范。
• 因此，我们只是想要测试最终确定。 因此，在我们开始使用开发网络之前，因为如果我们不运行测试和解决问题就开始使用开发网络，可能会发生的是，在开发网络期间，我们将遇到很多共识问题，并且需要花费大量时间来调试这些问题。 是的，基本上就是这种情况。 但是从实现方面来说，我们已经完成了所有 EIP 的所有实现，并且我们已经通过了客户端正在谈论的模糊器。

Tim Beiko

• 知道了。 非常感谢。 任何来自 Argon 的人？

Andrew

• 是的，对于 Argon 来说，这很简单。 我们将借助 Lightclient 的 Geth 实现。

Tim Beiko

• 知道了。 谢谢，Powell。 我看到你举起了手。 这与此有关吗？

Pawel Bylica

• 是的，所以实际上我想提供有关测试的更新，更具体地说。 因此，测试用例，我的意思是状态测试，执行测试，来自 Ethereum slash tests。 因此，测试用例仍然分为来自原始 EIP 的五个组，因为我们之前已经定义了其中大部分。 但是，实际的实现启用了所有 EIP。 因此，测试用例有点像关注 EOF 的特定方面，但你应该期望所有其他功能也已启用。
• 目前的状态是，这是最近的，我们更新了其中的第一个包，并且这已经在测试的主分支中。 这是 EIP 3540，是的。 因此我们认为这已经完成，虽然 EVM 1 和 Geth 实现，我认为对其中一项测试有异议。 因此，这是我们需要查看的第一件事。 但是，
• 我想，这部分几乎完成了，下一部分，因此第二组测试已准备就绪但尚未合并，还有另外两个正在进行中。 最后一个尚未开始。 因此，是的，这是状态的总结。 这也试图回答一分钟前的一个评论，我认为截至今天，你可以查看已经在主分支中的第一包测试。

Tim Beiko

• 知道了。 谢谢。 任何人对当前状态或实现或测试有其他想法吗？ 我不知道 Martin，你想快速更新一下你所做的模糊测试工作吗？

Martin Holst Swende

• 嗯，不，我现在正尝试使其更像一次性完成，但本质上是有四个不同的客户端正在接受测试。 不，五个不同的客户端，四个，对不起。 我们有一个非常好的，只是，你知道，事实证明，容器格式和验证的实现显然非常复杂，从所犯的不同类型的实现缺陷的数量来看。 但验证也证明非常容易测试。 我们定义了这种测试格式，我们可以显示字节作为输入，我们可以比较输出。
• 因此，我们对它进行了非常好的覆盖。 我相当有信心，这种类型的测试从长远来看将被证明非常有效。 我们尚未测试的是运行代码的实际语义。 因此，我的传递完成了代码的验证，但没有完成代码的实际执行。 这是以后的阶段。 是的，状态测试之类的。 是的，这对我来说无关紧要。

Tim Beiko

• 知道了。 谢谢。 任何，好吧。 有关当前测试和实施的任何其他内容吗？

Mario Vega

• 是的，我想分享？ 是的。 执行测试的观点。 因此，我一直在与 line 一起工作，与其他参考测试套件一起工作。 我真正发现的一件事是，为 EOF 创建有效的最佳用例并不容易。 因此，问题是存在很多陷阱。
• 例如，如果你希望 EOF 中的某些内容以某种方式失败，则必须非常具体，并且必须确保该测试在到达你真正要测试的内容之前不会在其他地方失败。 因此，我认为如果我们以某种方式标准化错误，我们将能够验证我们的测试是否正在实际测试我们期望的测试，这非常有价值。 类似地，有错误的草案，但我不确定你现在是否想分享，或者稍后再分享。 但是，是的，我并没有真正认为在反馈中改进的所有客户端都可以标准化这一点将非常有价值。

Tim Beiko

• 知道了。 谢谢。 好的。 然而，我的客户端刚刚在所有测试中分享了他的笔记，好的。 有所有不同的错误代码。 还有什么要补充的吗？

Danno Ferrin

• 我更希望错误是可读的字符串，这样你就可以弄清楚出了什么问题，而不是必须交叉引用一个表。 这将是一个请求，但我认为标准化字符串是可以的。

Tim Beiko

• 知道了。 好的。 而且，我认为，所以还有两件事要谈。 其中之一是，在上一次通话中，我们说如果 EOF 今天没有完全准备好，我们可能会将其删除。 下一次通话也是如此。
• 我认为在我们进行对话之前，值得讨论一下新出现的 EOF 新提案，这样我们在做出决定时就可以将其纳入考虑范围。 因此，我不知道，也许这有意义。 Vitalik，你首先在以太坊魔法师上发布了关于代码自省的信息，然后 Alex，你今天早上发布了基于此计划的信息。
• 但是，也许 Vitalik 你想先来，然后我们可以让 Alex 来。

Vitalik Buterin

• 当然。 你们能听清楚我的声音吗？

Tim Beiko

• 是的，非常好。

Vitalik Buterin

• 好的，太棒了。 因此，我认为我想要从一些哲学背景开始，说明我所说的一些话来自哪里，对吗？ 因此，是的，我担心以太坊的发展以及对 EVM 的持续改进，至少就目前为止所做的那样，与对以太坊协议其余部分的持续改进之间的区别在于，在 EVM 中，删除东西比删除其他未来要困难得多，对不对？
• 因此，例如去年，我们成功地删除了一个巨大的模块，即整个工作量证明共识系统。 这只导致了对用户和应用程序的非常有限的向后兼容性问题。 但另一方面，对于 EVM 来说，我们添加了几个 OP 代码，但是，当我们尝试实际更改东西甚至删除东西时，通常，是的，这种情况发生过几次，但成本非常高，对吗？
• 因此，例如，删除自毁操作码正在进行中，但这绝对是需要花费五到十倍于 EVM 之外的类似变更所需的时间。 甚至两三年前的 Gas 成本增加最终都需要花费相当长的一段时间，对吧？ 因此，这样做的原因基本上很明显，对吧？
• 它是用 EVM 代码编写的应用程序，如果 EVM 发生变化，那么这些应用程序就无法更改。 而如果你触及系统的一部分，该部分与外部的东西交互，例如，如果我们最终摆脱了我们的 LP 交易格式，那么这与外部的东西有关，并且可以更改，对吧？ 我认为这将是，或者我对 VM 的改进特别大的担忧之一是，基本上，由于很难弃用和实际删除东西 A，因此 VM 开发理念允许大量的持续改进，并且不会很快地提交到接近僵化的状态，这将使我们面临创建 V2，然后创建 V3，然后创建 V4 的风险，从而需要继续将 V1、V2 和 V3 作为共识代码的一部分，因为我们没有很好的方法来删除它们。 而且因为有一些应用程序依赖于它们，对吧？
• 我认为我们已经通过调用代码看到了这一点，这可能是一个很好的例子。 我们添加了委托调用，这显然更好，但是调用代码仍然存在，而且我通常想提出的解决此问题的方法，以及让我们随着时间的推移对 EVM 进行一些改进的方法，但同时实现使 EVM 更简单、使 EVM 更清晰的目标，并实际使协议随着时间的推移变得更简单、更美观，而不是仅仅拥有我们可以摆脱的这种不断增加的技术债务，而是如果我们要创建 EVM 版本，那么新的 VM 版本应该设计为牢记，它非常向前兼容我们将来想要进行的所有类型的升级，对吧？ 而且当前的 EVM 在很多方面完全不是这样，基本上是因为当前的 EVM 对事物进行了太多的自省，对吧？ 因此，例如你有代码读取操作码和代码读取操作码，类似于你读取代码的特定字节。 你有 jump 操作码，而且 jump 操作码可以将字节值作为参数。 然后由 EVM 执行创建。 因此，跳转目标，类似于实际上无法重新排列它们。 你必须将相同的字节精确地保留在相同的字节中。 你没有东西。
• 这类似于合同创建，而且，你知道，与代码哈希密切相关的所有内容都类似于整堆 EVM 属性，即状态 Gas 也是另一个属性，对吗？ 凡是所有这些 EVM 内部结构都暴露在外，这意味着我无论如何尝试更改很多东西，最终都会变得非常向后不兼容，对吧？
• 因此，这里的想法是，如果我们创建 EVM 的 V2，其中 V2 具有这种属性，即它具有的自省能力要少得多，那么我们获得的能力就是强制升级旧合同的能力，对吧？ 因此，如果我们升级，假设 EV m 从 V2 在未来的某个时候升级到 V3，那么我们可以制定一个协议规则，表明当仍然是 V2 的合同被触及时，你可以应用一个转换，将 V2 代码转换为具有等效行为的 V3 代码。
• 而且由于不存在所有这些疯狂的自省，因此实际上可以实现这一点，对吧？ 因此，为了给出一个快速具体的例子。 假设在 V3 中，我们决定拥有一种具有一个字节的代码（例如 shot three 或 Kak）是一种从第一天起就犯的错误。 因此，让我们摆脱现金支票酸度代码，并将其移过来并使其成为简报堆。 好吧，这样做的主要问题在于，你已经用具有 10 到 20 字节代码的代码替换了具有一个字节的代码。 而且，你知道，你还需要一个内存片。
• 而且你正在用一个更复杂的字节序列替换单个字节。 因此，最终改变了代码复制输出，并且最终改变了所有代码的位置。 而且你可以编写出转换代码并执行它，但前提是所有这些自省都不存在，对吧？ 但是，如果自省不存在，那么你可以执行的操作是，实际上编写转换代码，甚至可以正式证明转换后的代码在新版本的预执行代码下具有与旧版本完全相同的行为。 然后在 V 之后，你将有一段过渡期，其中 EV M V2 和 E V M V3 都可用，并且最终类似于 V2，确保所有 V2 合同都被探测到并移到 V3 中。
• 然后，一旦发生这种情况，最终就可以再次升级并执行 V4 或类似的操作，对吧？ 因此，这意味着客户端在任何时间点都实际需要支持的 EVM 版本的数量都限于两个，对吧？ 类似于一旦你超过三个，那么第三个最旧的版本就可以完全弃用。 而且 EOF 本身的一个优点是，它具有朝着这个方向发展的特性，对吧？
• 因此，特别是摆脱动态跳转，摆脱动态跳转是朝着这个方向迈出的重要一步，因为它能够实现这些代码转换，对吧？ 类似于如果你必须进行代码转换以通过五个字节来避免一个字节，那么你可以这样做，并且你可以转换所有坐标。 而且你知道，之所以可以转换坐标，是因为不再有任何方法可以跳转到你将要跳转的 V 坐标作为 EOF 生成变量传递的地方，对吧？
• 而且无法实现这一点，这使得这种代码转换实际上成为可能。 因此，我的建议基本上是，好吧，我们可能可以采用 e ev EOF 路线，但稍微扩展一下，禁止自省，并且基本上将其推到 EOF 本身达到这种程度。 但是你知道，另一条路径可能是具有当前提议的 EOF v2，然后具有 v3。 并且我认为 V2 仍然可以转换为 V3，尽管你需要支付一些成本，例如代码大小翻倍，但这很好。 而且，你知道，也许可能还有一些其他路径。 因此，你知道，我们走吧。

Alex Beregszaszi

• 是的，我知道。 是的，我不确定我是否应该实际深入研究该提案。 可能不会，因为它也很冗长。 但我想从说我们实际上通常想要拥有很多这些优点，提到这些优点Micah Zoltu
• 当然。因此，倒退绝对比两个版本更糟糕，但我认为一个版本和两个版本之间的差异是巨大的，两个版本和三个版本之间的差异非常小，而三个版本和 20 个版本之间的差异比边际略大，但仍然远不及从一到二的第一个巨大飞跃。 所以问题就变成了，好的，如果我们没有获得那么大的收益，我们只获得了一系列中间的边际收益，那么也许它们确实累加到了一定的程度。 值得付出所有的努力吗？ 比如，这需要付出大量的努力。
• 就像每次我们想要升级，升级 EVM 时，我们都必须考虑，好的，我们如何转换一切？ 就像我们必须为每个 EVM 更改实际解决那个转换问题，这并非易事。 然而，如果我们只是接受，你知道，我们拥有所有这些 EVM，那么我们就不必处理这个问题了。
• 所以我只是在质疑这是否值得付出努力，如果我们无法从二变一获得那么大的收益，那这努力就相当重要了，但我认为我们做不到。

Tim Beiko

• Dankrad，哦，不确定你是否有麦克风。

Dankrad Feist

• 哦，是的。 我，所以我有一个非常，我的意思是，比如，我认为这非常不同。 我认为，比如，我们应该，比如，很明显，从必须支持两种版本到必须支持三种版本，工作量增加了 50%，对吗？
• 所以我会说，是的，我的意思是，我可以看到，act six 的论点不像一次性做出如此大的版本飞跃非常困难。 所以我同意这绝对是一个值得思考的问题，但真正值得思考的是，如果我们现在实施你的消息，支持 EVM 的额外版本的持续努力会增加 50%。

Tim Beiko

• 所以，哦，Vitalik。 是的。

Vitalik Buterin

• 是的。 我只是想再次重申，比如我，这件事是一个很大的决定，整个事情都包含不可逆转的决定，我认为，比如，我们都应该记住，为 20 年或 40 年的长期做出正确的决定，远比不推迟六个月甚至一两年重要得多，对吗？
• 所以，你看，这绝对是我认为，无论哪个决定是正确的，都应该仔细考虑的事情。 而且，如果我们能做出任何形式的不可逆转的承诺，比如，我认为该承诺应该考虑到，从那里开始的实际路径将会是什么，我明白了。
• 是的。 就像我在消息中说的那样，对吧？ 20 到 40 年的决定就是僵化。 我认为，你知道，如果这是真的，那么这甚至可能是一个暗示今天正确的决定实际上是僵化的论点，并且基本上说 EVM 不会改变，就像甚至从明天开始一样，对吧？ 但无论决定是什么，长期都应该是。
• 是的，我认为真正地，被认为是主要问题，对吧？

Andrew Ashikhmin

• 我想，我只是担心如果我们推迟 EOF，直到它完美，那么我们就会失去机会，无法获得实际的反馈，因为试图制造，我们无法在实际投入测试和实际使用之前，获得理论上可能的完美的东西，在我看来，EOF v1 在一方面足够大，另一方面，它提供了很好的改进，特别是在消除动态跳转方面。
• 所以，是的，如果我们，如果我们试图使它完美，那么它将像一个永无止境的超级项目，特别是在没有来自真实合约的反馈的情况下，我，我会逐步交付它。

Tim Beiko

• 谢谢。 Ansgar。

Ansgar Dietrichs

• 是的，所以，在我看来，这里可能有一条很好的路径，考虑到我们正在瞄准一个，在上海之后的三四个月的时间线上的八个或四个分叉，我不知道，也许这里有足够多的人担心做出一个好的决定，从而在如此仓促的时间线上将我们锁定在未来 20 年。
• 比如，对于上海，我们基本上今天就必须做出决定，也许最好的行动方案是从上海撤出它，
• 但基本上承诺在接下来的几周内积极讨论这个问题。 然后基本上决定我们是否要按原样继续进行 V1，基本上将其与 4444 捆绑在一起，基本上尽快做出决定，以便我们可以将其与该版本捆绑在一起，这意味着在接下来的三个月左右做出决定。
• 如果我们在该时间线内基本上不确定是否要继续推进，那么我们可以进一步推迟它。 但是，基本上要瞄准，4、4、4 捆绑包，因为否则它可能会滑落，然后很容易我认为，所有的赌注都将失效。 是的。

Tim Beiko

• 是的，我会强调这一点。 我认为，如果我们不想因此而推迟提款，就像我们决定是否将 V1 纳入上海一样，这是一个我们基本上必须在今天做出的决定。 我认为如果我们不承诺这一点，那么它就不会发生。 然后我们可以弄清楚，如果我们不这样做，下一步是什么。 但是，是的。
• 我想我很好奇想听听其他客户端团队对此有何看法。 我想，Geth，我不确定 get，Mary 你在聊天室里发表了一些评论，但 Matt 也是如此，我已经停止关注了，但是，是的。

MariusVanDerWijden

• 是的，所以我认为 Geth 团队对此存在分歧。 我只能谈谈我个人的看法。 我感到有点仓促。 我想，我觉得现在在 EOF 上做出决定有点压力，而且，我不认为这很好。 所以从我所看到的，我也没有像我应该做的那样密切地关注这个过程。
• 但从我所看到和听到的来看，规范仍在更改或仍在更改中。 而且，测试还没有达到我们希望的水平。 而且，特别是，fuzzing 在多个不同的客户端中发现了问题，通常我们只在一个或两个客户端中发现问题，然后，是的，问题的数量和问题的严重性，通常让我感到担忧。 我认为，将 EOF 分为 EOF one 和 EOF v2 是一种好主意。
• 但是，我不觉得现在将 EOF one 放入上海很舒服。 这只是我个人的看法，我认为 Geth 团队中的一些人可能不同意。

Tim Beiko

• Geth 中有人想提出相反的观点吗？

lightclient

• 我认为我并不完全反对那种观点。 我认为现实情况是，我们为上海设定的时间表必须延长一点，以支持将 EOF 测试放到人们可以安心进行升级的地方。
• 多长时间，我不知道，我认为不会超过一个月的时间，但这仍然掩盖了我们对代码内省和，你知道，其他不可逆的小问题的疑问，人们普遍感到仓促。
• 我觉得大约一个半月前，我们在上海进行 EOF，我们有点像一个开发团队一样推动自己，但这是我们能力范围内的。 现在我觉得我们有点达到我们能做的极限了。 所以如果上海的时间表不延长，那么我认为 EOF，我们无法负责任地发布此 EOF 升级。
• 是的，问题是我们是否足够重视讨论延长上海截止日期几周一个月。
• 但如果我们试图在 2 月初进行主网测试网升级，我不认为我们会在那时准备好。

Tim Beiko

• 明白了。 谢谢。 Nethermind 或 Besu 中有人想分享吗？ 哦，Daniel。

Danno Ferrin

• 所以对我来说，我认为可能会推迟的部分是当我们与 Solidity 合作并讨论他们需要将建设性参数附加到区块时。 EOF 旨在密封，它并非旨在在部署时扩展。 因此需要进行设计更改以支持这一点。
• 我们可以做一个 hack 并说它可以仅针对针织代码进行扩展。 也许我们可以巩固这一点，但我认为这会需要更多的测试，并且，这个发现是在 12 月份才发现的。 所以，你知道，整个内省问题可能是在后期才出现的。
• 我不确定，你知道，使整个初始部署区块成为其数据区块有什么危害？ 我认为有一些方法可以解决这个问题，而不一定需要对其进行内省并关闭副本。
• 但就实际的可用性而言，无法附加建设性参数，尤其是阵列类型，我认为，对我来说，Warren 正在将其推迟到坎昆。

Tim Beiko

• 明白了。 谢谢你。 Andrew？

Andrew Ashikhmin

• 是的，我认为，这验证了我最初的担忧，我们需要一个可用于生产的 Solidity 编译器进入 EOF，以便我们实际上确保它可以与 Solidity 配合使用。 所以我目前认为推迟 EOF v2 Cancun 是一个好主意，并且，使适当的 Solidity 编译成为一项要求。

Tim Beiko

• 好的。 然后谢谢你。 然后，来自 Nethermind 的 Amen 也说，我宁愿现在不包含 EOF，而宁愿将其推迟到坎昆。
• Lucas 竖起了大拇指。 所以我认为很明显，是的，不，不包括在上海的 EOF 似乎是共识。 有人强烈反对吗？
• 好的。 所以我认为这似乎是因为所有这些提案都在浮动，现在就决定如果和什么包含在坎昆中可能还为时过早。
• 我宁愿我们至少等待一个或两个电话再做出决定。
• 而且，我认为部分与 EOF 产生的问题是，我们很早就决定将它部分包含在上海中，在合并工作中超级早期，然后人们有点措手不及。Sort of 包含在很早的时候。 所以我认为最好不要在这里犯同样的错误。
• 所以，是的，你知道，也许在下次通话中我们可以决定将其放入坎昆，但我认为最好至少给人们两周的时间来讨论所有这些。 以及它们是否应该与 4844 耦合，或者，是的。 或一个单独的分叉。 我看到你取消了静音。

lightclient

• 是的，我的意思是，我只是想说，如果我们已经达成了相当好的协议来尝试为上海做 EOF，我认为最好还是尝试，你知道，仍然达成相当好的协议，我们将尝试为坎昆做这件事。
• 当然，就像我们可以稍后在情况变得更加明朗时再进行一次评估。 但我想知道是否有人强烈反对我们承诺尝试为坎昆做 EOF。
• 因为我不想进入我们之前与 EOF 相同的情况，我认为如果我们没有让所有客户端团队实施这些东西并围绕 EOF 拥有尽可能多的势头，Solidity 正在进行此实现。 如果我们将来不再承诺，
• 那么我们将再次进入只有 Epsilon 团队负责，客户端团队在想要最终确定前两个月才开始关注，然后我们意识到这些事情，并且 Solidity 在两个月前开始工作，然后我们意识到这些事情。

Tim Beiko

• 对。 Maris，你举起了手。

MariusVanDerWijden

• 是的。 我真的不喜欢这样做，因为我认为，一直在大力推动这个 EIP。 但是，随着 U F 退出上海，我认为我们应该考虑将 1153 移至上海。 这是一个小的更改，并且，将其添加到上海可能是可以的。

Tim Beiko

• 让我们等等。 好的。 我们可以在 5、10 分钟内讨论这个问题。 我只是想确保我们在之前正确地结束 EOF，但，好的。 我们可以随便讨论。 是的，让我们在那之后立即讨论。 我认为只是回到 Matt 所说的，我认为我同意这种势头和客户关注非常宝贵，而且，我们应该尽可能多地继续努力。 我只是不想，我只是不想现在就将其提交到分叉计划中。 但是，如果我不知道是否所有客户端团队都强烈认为我们应该这样做，我们可以继续进行。 是的，我不知道是否还有其他想法。

lightclient

• 我强烈认为我们应该做出承诺，但是，我不知道其他人是否持相反的意见。

Andrew Ashikhmin

• Andrew，我认为，我们应该，好，我的偏好仍然是拆分，而不是试图达到 EOF 的完美状态。 我们可以尝试它，但是，我只是担心太大的变化会导致，所以在我看来，最好采取较小的步骤，但是，我会将 EOF 提交到坎昆，但要求我们有一个完全正常运行的，Solidity 编译器进入 EOF，并且 Solidity 团队对此感到满意，并且一切都很好，如果坎昆之前还没有准备好，那么我们将推迟它更多

Ansgar Dietrichs

• 是的，只是为了说，基本上我确实认为重要的是，我们仍然要对整个 B one 拆分以及我们是否真的想这样做保持开放的态度。
• 我认为，我不知道，我认为实际上对为什么这可能是一个好主意有很好的看法，但是，我认为我们应该承诺的只是我们应该确保坎昆的 UF 不会因为我们再次没有准备好而进入，就像我们应该，至少如果我们，如果我们最终不包含它，那应该只是因为我们决定实际上将所有内容捆绑到一个组合的 b2 中，这是明智的做法。 我认为现在到坎昆之间有足够的时间，我们应该能够充分探索并做出该决定。 所以我认为这是我们应该做出的承诺。

Tim Beiko

• 好的。 Moody，我看到你也在举手。

moody

• 是的，我只是想，我认为最好对 EOf 进行一些真实世界的 gas 测试，只是为了在强制实施 v1 之前实际测量这些好处，以确保有实际的理由使用 v1，并且人们不会只是继续使用旧代码。 我实际上正在与 Solidity 的 Daniel 合作，为 v3 做这件事。 所以希望我们有一些数字。

Tim Beiko

• 明白了。

Alex Beregszaszi

• 是的，Alex，是的，我的意思是来自 Solidity 的 Daniel 实际上已经实现了所有 EOF EIP 和关于 gas 的 Grand Benchmark，即使没有优化步骤，这意味着，你知道，重复数据删除和优化所有内容。 即使没有这些，我也在使用更少的 gas。

Tim Beiko

• 好的。 我觉得，好吧，只是为了不把剩下的时间都花在这个上面。 我认为，如果在这里我们想从上海移除 UF，我认为等待额外的两个星期来为坎昆做出具体的决定不会改变任何事情或大大减慢进度。
• 我认为，你知道，很明显，客户端团队现在正在从事这项工作，我们应该继续这样做。 因此，我觉得我们应该在下次通话中继续讨论关于坎昆和 V1 与 V2 的讨论，但在今天就此打住，除非有人觉得我们还有其他重要的事情没有在今天讲到。
• 好的。 所以我也会这样做。我会在这次通话结束后立即对规范进行更改。 下一件事。 好的，所以 Marius，你提出了这个问题，如果我们从上海移除 EOF，我们是否有带宽添加其他东西？ *如果是这样，我们应该添加什么？ 因此，在你的评论 MIRIs 之后，聊天中有很多关于我们现在可能应该只删除东西的评论。 是的，所以我想我只是想听听客户端团队的意见，他们觉得我们应该添加东西吗？ 还是大家都更喜欢只删除东西，以使范围保持在控制之下？

Danno Ferrin

• Daniel，所以削减它的原因是这样我们就不会因为退出而推迟事情。 我担心的是，如果我们添加任何东西，那可能会延迟退出。 提取是上海的驱动因素，因此无论我们做出什么决定，都应该尽快提取。 因此，基于此，添加事物只会增加风险。

Tim Beiko

• 好吧。 因此，如果有更多对仅削减的支持，仅对削减的支持，我不知道，另一个小的走了，任何强烈的意见？ 这是关于添加 1153 还是有可能添加 1153，但总体来说是添加所有东西。

tukasz Rozmej

• 是的，因此如果我们想要添加一些东西，我们应该产生相当小的影响。 1153 可能会产生相当小的影响。 如果每个团队都审查了代码和测试，那么它可能是一个影响最小的东西。 但否则我们可能不会，如果不是的话，我们不想添加它。 因此，这取决于每个团队是否可以花一些时间来审查它。

Tim Beiko

• 明白了。 和 argon 对 1153 没有强烈的意见。 无论是哪种方式。 好的。 因此，1153 似乎是唯一可以考虑的。
• 这是我们需要在今天做出决定的事情，还是人们更愿意在接下来的两周内考虑这个问题，并可能在那时做出决定？

lightclient

• 我觉得如果我们的目标是 2 月初的公共测试说明，我们现在就应该做出决定。

Tim Beiko

• 好的。

Danno Ferrin

• 2 月初的测试集具有侵略性。 任何新的广告，我的意思是，接受 EOF 已经是足够的风险了，有保证的风险，但在我看来，添加其他没有参与之前测试匹配或结构的东西，即使像 1153 这样好的东西，也是不必要的风险，愿意被推翻，但我仍然认为这是不必要的风险。

Tim Beiko

• 好的。 聊天中也有来自其他 Nethermind 的更多评论，因此我认为，好的。 然后只关注从上海移除 EOF，保持范围紧凑。 因此，是的，所以我们不会延迟提款。 好的.
• 我认为，我认为这就是上海的全部内容。 还有人想讨论分叉的其他内容吗？ 好的。 如果没有，还有其他一些议程项目。 EIP-4844 更新。 我知道已经举行过几次社区电话会议。
• 我不知道是否有任何更新，人们想要讨论。 好的。 没有提前转发任何消息。 下周还会举行一次电话会议，我们可以在其中讨论这个问题。 Eaton 在状态团队中有一项提案，在 ExecutionPayloadHeader 中添加列表的十六进制特里根。 Heather，我不知道 Ethan 是否在通话中。

Etan (Nimbus)

• 是的，我在。

Tim Beiko

• 好的，太棒了。

Etan (Nimbus)

• 所以那里有一个问题，有点类似于上海，因为它也影响提款，但严格来说也没有必要用那份工作来解决它 。 所以，它是关于轻客户端的。 他们目前可以关注小道消息主题，以了解共识层的最新信标块头。

• 我们希望扩展到包括 EL 块头，以便你可以关注该被动流。 然后，当你检测到某个区块包含例如与你的钱包相关的某些锁时，你可以请求证明，嘿，给我与该区块相关的Token转移。 我在这里准备了一个小图形，我在聊天中分享了这个 PDF 文件。 目前的问题是，要获取该 EL 块头，CL 块不包含所有数据。

• EL 块头中有两个字段，即事务路由和提款路由，它们是 EL 块头中的十六进制，抱歉，特里路由。 但在 CL 执行有效负载中，那些十六进制三特里路由，由于在 CL 块中，它们只是缺失。

• 啊，谢谢。 是的。 对于分享这一点。 所以是的，在 CL 中，有完整的交易列表和完整的提款列表。 单个交易仍然是 R LP，而在提款中，实际的提款对象实际上也是 ssc。

• 这也意味着它们以小端存储，整数和以千兆字节存储，而在 EL 提款路由中。 名称相同，但完全不同。 它是信标并以某种方式编码，它是 A R L P N 对天线十六进制特里根进行编码。

• 因此，我们在这里拥有的数据并不相同。 当我们想要进行交易或提款证明时，这会导致这样的问题，即像客户端，它只能从该小道消息流中获取 CL 执行有效负载头。 但是当它想要从 EL 请求交易证明时，EL 无法提供该证明。 所以是的。 另一个问题是，没有办法验证执行有效负载中区块中的现金是否具有风险。 正确。 目前按原样使用并不是真正的问题，因为我们有点信任同步委员会只会签署有效的执行有效负载头。

• 但比尔，如果你只有头部想要验证，我觉得这是一个 bug。 是的。 如果可以在上海修复该问题。 当然。 对于交易，像这是第一种方法，我们可以这样做吗？ 以便我们在任何地方都使用相同的格式？ 因此对于当前也存储在 CL 上的交易和提款，我们是否可以使用 EL 端的相同路由？ 这意味着向 EL 添加对 SSE 格式的支持。

• 我不确定发生了什么问题。 目前的风险是，风险墙上 EL 端的所有内容都是 R L P 以及 Tax，CL 端则是 ssc。 但是，是的，就像我们是否可以做到将此 SSC 库添加到 EL，那么从本质上讲，这将消除所有针对于相同数据的单一格式。

• 如果我们这样做，那么我们本质上需要找到一种方法将这些额外的十六进制路由从 CL 服务器获取到 CL 实时客户端。 我在这里使用的方法本质上是 CL 可以从 CL 块重新计算它们，因为它知道所有交易和提款，但这将意味着为 R L P 十六进制尝试和 kza 现金将所有遗留代码添加到 cls，这有点像我们想要去的方向的反面。 据我所知，S S C 格式被认为更现代化。 如果有一个绝对不能这样做的实现，它也可以请求 EL 块，可以是 VR 引擎 API 或执行 api。

• 这是一样的，嗡嗡声，但它会与也用于验证器职责的总线竞争。 因此，它可能会干扰实际的关键操作。 我不确定这将获得多好的支持。 下一个幻灯片，基本上通过仅扩展从引擎 api 获取的执行支柱来避免在 CL 上计算这些，以包括这些十六进制路由，作为交易路由的理由只是一个简单的二叉树。

• 是的，它只是一个简单的二叉树。 而且据我所知，这些十六进制特里路由，它们没有暴露给 E V M。 因此，E V M 中没有任何东西，除非有人重新实现它，否则就像有他们自己的交易证明系统一样。 但我认为现在没有办法从智能合约中提取交易路径。 但是无论如何，是的，这个，这个 light 这里基本上扩展了，扩展了执行有效负载，执行有效负载，Heather，每年增加 160 兆字节的额外存储空间。 拥有 4 4 44 历史记录修剪功能可能不再是那么大的问题。

• 避免将库添加到 CL。 最后一个幻灯片表明我们完全忽略了这两个值。 就像不是试图获取那些交易十六进制和提款十六进制，我们只有这四个最小的项目，父哈希状态根块号和块哈希。 我们将其提供给 EL，然后 EL 发出另一个网络请求，以获取基于它的 EL 块头（如果需要）。 这解决了存在这种不匹配的问题，但也意味着要对交易和提款进行操作，你需要再次主动从服务器请求这些其他字段。

• 因此，它增加了服务器的负载。 而且这也意味着你不能再被动地关注小道消息以跟踪最新的文本和 El 块头。

• 所以，是的，我的意思是，这可能是最快的方法，而且实际上没有太多的变化，根本没有变化。 但这也是最不灵活的，并且存在 EIP 4788，它将共识层保持对 EL 块字母的真实性。

• 因此，理论上可以只是基于那一个的交易和提款证明，但它们需要由 CL 提供服务，而不是由 EL 提供服务。 因此，你会遇到这样一种情况，即对于某些数据，你需要向 EL 寻求证据，而对于其他一些数据，你需要向 CL 寻求证据，因为 EL 不知道整个信标状态，无法为交易创建此类证据。 可能还存在拆分块存储，其中交易根本不在 cl 上。

• 是的。 而且，每次我们添加新数组时，都会再次出现同样的问题，因此交易和提款是目前存在此问题的两个数组，但是每次我们添加新数组时，我们都会再次遇到同样的问题。 所以是的，这就是我想提出的。 我的意思是，主要问题是，我们是否可以只是将这些数组转换为 el 中的 A S S C 路由，这是否存在风险或倒退，或者

Micah Zoltu

• 是的，我认为你将从那里得到的风险和倒退是外部工具可能依赖于此。 因此，任何实际尝试验证块的工具（例如，不是客户端）都需要修复并更改以处理它。 这包括执行块验证的链上合约。 我们打破了，是的。

Etan (Nimbus)

• 我的意思是，这对于交易来说是正确的，但我的意思是交易，它们可以通过将其也添加到有效负载中来作为一次性的解决方法来解决。 但我的意思是，这更多地是关于新东西，提款，将来可能成为收据路由的任何东西。 实际上，它是双关语，就像在 CL 和 dl 中都是十六进制尝试一样。 因此，已经一致了。
• 接收到的路由仍然值得更改为街道路由。任何想要从一层访问消息的二层。 如果证明很容易验证，那么使其更易于验证将是一个巨大的胜利。 同样，不同二层之间的消息传递。 任何 IFM 链都会发出一个事件，这些事件可以被另一个 e m 链吸收，如果证明很容易验证。

Etan (Nimbus)

• 是的。 因此，存在这样一种范围，即仅更改新东西，例如仅提款和新数组，或者还更改交易路由，因为这样我们就可以涵盖所有存在不一致的字段，甚至比这更多，或者根本不涵盖任何字段。 因此，存在这个完整的范围，我不确定我们应该遵循哪种方法。

Tim Beiko

• 只是因为我们快没时间了，我们还有其他事情要做，是否可以将对话转移到问题上更有意义？ Maruis，我们可以满足你，然后是的。 完成了。

MariusVanDen

• 是的，所以我认为我们需要一些时间与 EL 开发人员进行讨论。 好的。 但是，是的，因此我认为我们现在无法做出决定。 我认为现在做出决定也不是那么重要。 我们可能会在未来两周内更改它。 是的。

Tim Beiko

• 好的。 是的，让我们这样做。 哦，Micah。 是的。

Micah Zoltu

• 这难道不是有点违背了我们之前发表的声明吗？我们今天需要为上海的内容做出决定，因为到下周，我们为上海做出决定已经太晚了吗？

Marius

• 是的。 但是该更改实际上并没有太大更改，它只会更改块格式。 它不会更改 e VM 或任何内容中的任何内容。

Micah Zoltu

• 不是，不是所有客户端。 如果我说错了，请纠正我。 并非所有的执行客户端都具有 SSC 功能，对吗？

Marius

• 我们没有。

Micah Zoltu

• 所以，是的。 是的。 因此，这感觉可能是一个重大延迟的迹象。

Lukasz

• 对于 Nethermind，我们没有，因此我们没有 s z 实现，但 Alex 正在研究 EIP 4844 的某些东西。 因此，这可能是合理的。

Andrew

• 我觉得这是一个重要的问题，我们不应该推迟它。 我们，我的意思是我们可以离线讨论它，但是因为它与上海有关，而且，它是一个设计决策。 在我看来，这非常紧急。

Tim Beiko

• 你觉得怎么样，是的，我认为客户端团队离线思考这个问题是有意义的。 我们可以使用该问题进行讨论，我们可以将其列入下周 CL 电话会议的议程。 因为它也对他们有点相关。 并且最晚也要在下次所有核心开发者的会仪之前做出决定。 这样做有意义吗？

Andrew

• 是的。 是的。 但是，在我看来，因为这是一个设计问题，所以我首先会优先考虑它并尝试正确修复它，而不是留下一些技术债务。 当然。

Loin

• 是的。 对于害怕执行层实验室的一个说明，如果你仅针对这些类型实施，则你真的不需要实施通用的 s a z，这会容易得多。

Tim Beiko

• 明白了。

Etan (Nimbus)

• 好的。 是的。 就像你，你需要撤回对象，然后你需要那些，基本列表的数据，这是你需要提供的支持。 交易，它们仍然是 L P，只是交易的实际三点和完整提款以及他们的三个需要是的。 这，这，需要改变。

Loin

• 而且，EIP 4444 无论如何早已包含手动 s e 操作。

https://ethereum-magicians.org/t/eip-5483-evm-modular-arithmetic-extensions/12425 1:24:29

Tim Beiko

• 好的。 因此，是的，让我们讨论，让我们像 EL 团队一样，如果你们可以尽快查看此内容，那么我们将确保将其添加到下周 CL 电话会议的议程中，并希望在下次所有核心开发人员放置之前做出决定，最晚也要做出决定。 好的。 我们还剩六分钟，还有两个人们想简要介绍的 EIP。 因此，让我们尝试在每个 EIP 上花费三到四分钟，然后我们将总结一下。 首先，Jared，你有 EIP P 5 8 43，你想聊聊，你在这里吗，Jared？ 好的，如果没有，那么 Abdel ，你遇到了 N e I p e i p 5 9 88。 你还在这里吗？

https://eips.ethereum.org/EIPS/eip-5988 1:24:44

Abdel

• 所以基本上，它与素数域上的一组置换一起工作，并且它使在 ZK 上下文中非常高效。 而且，它基本上会实现一堆有趣的用例，显然，对于二层，特别是 ZK 和 rollup。 但不仅限于此，它可以实现哪种用例？
• 因此，首先，你可以使用它作为使用 Poseidon 哈希承诺进行某种数据可用性解决方案的有效且廉价的方法。 因此，显然，它不如 4844 和未来的数据可用性采样解决方案有效，但对于使用此新功能更便宜的数据可用性来说，它仍然是一种替代解决方案。 此外，它可以将其用作其rollup状态承诺的主要函数。 它也可以用于逃生舱口。 基本上，每次我们想要证明存储证明（如 Merkel 证明）时。 在以太坊上非常昂贵，因为我们没有任何 zk 友好的哈希函数。
• 因此，假设你想要实现一个 SK 修补系统，如果系统被冻结并且你想要让用户能够在第一层上恢复他们的手机，那么你可以使用该系统来实现一个逃生舱口系统。 这是我们计划为启动网做的事情，score 也计划将其用于他们的退出游戏机制。 而且，也许从长远来看，我们可以将它用于以太坊本身，比如，能够在以太坊内部证明以太坊的历史。 因此，这将对于存储证明和精简客户端以及许多其他用例特别有用。 因此，这对于潜在的用例来说也是如此，在层面上，在顶层也有一些有趣的用例。 但主要来说，这对于 rollup 运营商来说非常有趣。 一个重要的设计问题是它可以有多通用。 这是预帝国的主要问题，因为使用 paramunt，你可以将其与多个参数一起使用，并且许多不同的参与者正在使用不同的参数。
• 因此，我们有多种选择，我们可以只实现一组已知的实例，并使用硬分叉添加新实例，或者我们可以尝试创建一个通用的东西。 无论如何，这是需要考虑的一件事。 另一个重要的方面是安全性，因为那些 amatic 哈希函数都相当新。 因此，这也是需要考虑的事情。
• 因此，Vitalik 一个月前或更早的时候，在PCG 替代文章奖励中描述了一下这件事。 在实现方面，我们已经有了适用于 x, 86 架构的 c 汇编实现。 我们也开始了紧急实施。 因此，已经有一些实现存在，例如，Fcon one 和其他实现，但是，它们不够通用，无法适应所有可能的实例。 因此，是的，存在通用城市方面、安全方面，是的，简而言之，这就是全部内容。 因此，我们只剩下一分钟，所以我将在那里停止。Tim Beiko
• 谢谢。好的，Dankrad举手了。我想我们可以先听听你的评论，然后结束。

Dankrad

• 好的，只是一个非常短的评论。所以总的来说，我认为现在在VM中确定任何算术哈希函数还为时过早，因为你提到了安全问题，而且我们对它们了解还不够。是的。所以我通常认为现在确定它还为时过早。

Tim Beiko

• 明白了。然后以太坊魔法师（Eth magician）的帖子链接到了EIP，供人们进一步讨论。
• 好的。在结束之前还有什么吗？好的。我想，是的，如果有人想看看 Jared 的 EIP Async，它与EVM监视器或指标有关，这是很久以前作为VM 384提出的。所以我刚刚也在聊天中发布了链接。好的，我想就这样了。感谢大家的参与，我们这周的CL会议上见。谢谢你们。

• 原文链接： github.com/ethereum/pm/b...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～