全球区块链监管查询平台

简体中文
下载WikiBit

最新以太坊执行层会议总结:EIP-7514 将成为 Dencun 升级的一部分

最新以太坊执行层会议总结:EIP-7514 将成为 Dencun 升级的一部分 WikiBit 2023-09-16 23:00

本文总结了关于以太坊开发网络Devnet-8状态更新、EIP-7514、EVM与Blob、EIP-4788、Gas优化等多个方面的讨论和进展。

  本文总结了关于以太坊开发网络Devnet-8状态更新、EIP-7514、EVM与Blob、EIP-4788、Gas优化等多个方面的讨论和进展。

  作者:@TimBeiko / 来源:https://twitter.com/TimBeiko/status/1702424793805684902

  翻译:火火/白话区块链

  9月15日又结束了一次 @ethereum #AllCoreDevs 会议:会议讨论了开发网络的更新,对 Dencun 的增加,还全面概述了 Reth !

  议程:https://github.com/ethereum/pm/issues/857直播链接:https://youtube.com/live/aobFWu7NANc?feature=share

  以下是由@TimBeiko 做出的会议总结 。

  1、Devnet-8 的状态更新

  首先,关于 devnet-8 的状态更新:该网络正在进行最后的开发,许多客户端已经向其推送了新的更新。与此同时,我们已经开始使用 @KurtosisTech 进行 MEV/block 构建流程的测试。@NethermindEth 表示他们的 blob 事务池现在已经就绪,在单个节点上进行了几天的测试后,他们已经将其部署到了所有的 Dencun 测试节点上。

  Geth 的 blob 事务池也快要完成了。Besu 正在对其交易池进行广泛的改进(限制 blob 和非-blob 交易的总大小),预计将在其下一个版本中发布。Erigon 仍在继续改进其交易池,希望能在 devnet-9 上准备就绪。Prysm 也指出在接收 blob sidecars 方面存在一些延迟,他们表示这些 sidecars 通常在区块后大约延迟约500毫秒到达(而区块处理需要约15毫秒)。

  他们正在调查这个问题,以确定是否可能是 blob 和区块导入之间的竞态条件引起的。关于在硬分叉之前是否允许在内存池中支持 blob 事务的问题,团队们一致同意不这样做。

  2、EIP-7514

  接下来,我们继续了上周 ACDC 电话会议上的讨论,讨论是否要向验证器激活队列添加一个常数上限。此提案已经正式形成为 EIP-7514。简而言之,这将减缓在最坏情况下 ETH 投注的百分比增长速度。Dankrad 在通话中表达了对该提案的支持,他表示这会为我们争取时间,以进行潜在更复杂的验证器奖励方面的变更。

  所有 CL 团队都赞成这项变更,但有一个附加条件,即这只适用于存款队列,不适用于提款队列。经过更多讨论,我们决定将限制设置为 8。因此,EIP-7514 将成为 Dencun 升级的一部分!预计在接下来的几天内,EIP 和相关的 CL 规范 PR 将会更新以反映这一变更。

  3、EVM 与 Blob

  接下来,我们讨论了另一个临时提案:在以太坊虚拟机(EVM)中添加一个操作码来公开 blob 基础费用。这个提案是由来自 Arbitrum 的 @PlasmaPower0 提出的,他在本周早些时候在 R&D Discord 上表示这对他们(以及其他 Layer 2 解决方案)会很有用。我们已经有一个类似的操作码,可以公开 EIP-1559 中的 BASEFEE,这个操作码是在 EIP 激活的同时引入的。这使得 Layer 2 解决方案更容易根据 L1 数据成本来确定向用户收取的正确的gas价格。

  来自 Optimism 的 @protolambda 也参加了会议,并提出这不是获得 L2 的 blob 基础费用的唯一方式,因为他们可以查看区块头(其中包含用于计算 blob 基础费用的值),并提供针对这些值的 Merkle 证明。尽管如此,他也同意这是一个不错的功能。Arbitrum 目前不执行区块头解析,而依赖这一点对于不可变的 Layer 2 解决方案来说可能会有问题,因为如果区块头格式最终发生变化,会带来麻烦。

  其中一位 EIP-4844 的作者 @adietrichs 提到,这个操作码没有包括在原始规范中,因为当时有希望开发一种更通用的方式来访问区块头信息(而不是添加一次性的操作码)。尽管如此,与引入这个操作码相比,采取这种更为宏大的改变将是一项更加雄心勃勃的任务。

  这个操作码暴露的信息已经是 EL 客户端需要计算的信息,从语义上讲,它几乎与 BASEFEE 操作码相同。客户端团队一致同意,因此我们应该添加这个操作码,即使只是为了与 BASEFEE 保持一致。如果将来我们提出了一个“更巧妙”的机制,那么这个新操作码中的任何冗余功能也会成为使用区块头信息的其他操作码的问题。此外,值得强调的是这是很小的一个改变:@vdWijden 在 EIP 存在之前在 Geth 中实现了它,大约只用了约20分钟,而 Reth 团队在 ACD 电话会议期间提交了一项关于这个变更的 PR.

  4、EIP-4788

  接下来,我们讨论了对 EIP-4788 的一些更新,该提案将 beacon 根存储在以太坊主链上的合约中。在过去的几周里,我们对该合约进行了多次审计和模糊测试,这导致了在这个 PR 中描述的一些小的变更。尽管还没有完成所有的审计工作,而且报告也还没有出来,但 @lightclients 给出了迄今为止考虑的变更的概述。第一个变更是对0时间戳的明确处理,使其导致回滚(就像其他无效的时间戳一样),而不是返回0。第二个变更是关于缓冲区大小的。假设时隙时间发生了变化,原始合约将会导致存储浪费,因为模运算的工作方式。

  5、Gas 优化

  最后,还有一个减少加载 CALLDATA 次数的gas优化。审计员将审查这些变更,我们预计在下一个 ACDE 会议之前将获得他们的最终报告。为了保持模糊测试和实施工作的进展,我们同意现在合并提出的变更。

  @shemnon 还提到这些变更应该在实际的 EIP 中进行文档记录 - 我们正在处理!接下来,我们讨论了如果系统合约地址是状态的一部分,但在执行结束时为空,客户端应该如何处理。虽然这在主网上实际上不太可能发生(按我理解的情况!),但这是一种在测试中出现的边缘情况,通过在创世区块中设置地址来测试。

  鉴于这是一个相当特殊的边缘情况,并且没有明确的规范行为,我们同意花更多时间来思考这个问题,并在下周的测试会议上继续讨论。这就是有关规范变更的全部内容!以上所有内容都已计划包含在 devnet-9 中。客户端团队一致认为,应该可以在下周的 ACDC 之前实施和测试所有内容。在那次电话会议上,我们将达成 devnet-9 的启动日期协议。

  下一次 ACDE 计划于 9 月 28 日,UTC 时间 14:00 举行。在那之前,可以关注 @terencechain 获取测试会议总结,关注 @benjaminion_xyz 获取 ACDC 会议信息,以及关注 @christine_dkim 获取更详细的整个事件报道。

  以太坊 坎昆升级

免责声明:

本文观点仅代表作者个人观点,不构成本平台的投资建议,本平台不对文章信息准确性、完整性和及时性作出任何保证,亦不对因使用或信赖文章信息引发的任何损失承担责任

  • 通证换算
  • 汇率换算
  • 购汇计算
/
当前汇率
可兑换金额

0.00