EIP-7928:区块级访问列表:Glamsterdam案例 - EIP

该文档提议在Glamsterdam硬分叉中引入区块级访问列表(BALs),旨在通过显式映射每个交易到其访问或修改的状态(存储键、余额、nonce),使客户端能够并行执行交易,从而加速区块处理、提高吞吐量,并为节点运营者、应用、用户和基础设施提供商带来性能优势。

区块级访问列表:Glamsterdam 的案例

作者:Toni, Francesco, JochemIgnacio.

这份简短的说明遵循了 @timbeiko 设计的模板,旨在为分叉包含提出一个标题功能。

在本文档中,我们建议将 区块级访问列表 (BALs) 纳入 Glamsterdam 硬分叉。

概要

EIP-7928 引入了区块级访问列表 (BALs),这是一种启用事务并行执行的机制。通过强制执行每个事务到它接触或修改的状态(存储键、余额、nonce)的显式映射,客户端可以并行化磁盘 I/O 和 EVM 执行(包括状态根计算)。这加速了区块处理并提高了吞吐量。主要的受益者是节点运营商(由于减少了验证延迟)和所有从扩展 Ethereum L1 中获利的人(应用程序、用户和基础设施提供商)。

详细理由

由于未知的访问模式,客户端按顺序执行事务,限制了并行性并增加了区块处理延迟。虽然存在乐观的并行执行,但它依赖于推测性假设并产生开销,尤其是在具有许多依赖关系的 最坏情况 区块中效率低下。

BALs 通过使事务访问和状态更改显式化来解决这个问题。有了这些信息,客户端可以确定性地并行化 EVM 执行和磁盘 I/O,而无需进行推测。这减少了 最坏情况 的区块处理时间,并实现了更可预测的性能。

除了并行化之外,显式的状态差异还支持无执行验证(例如,对于 zk 客户端)、预执行分析(例如,包含列表、预热)以及改进的数据索引和同步方法。这些好处证明了 BALs 引入的适度大小开销是合理的。

主要好处

并行化:减少最大区块处理时间。

通过在区块中包含存储位置和事务级状态差异,可以并行化事务。大多数客户端已经支持乐观并行化(全区块预加载),这对于平均区块效果很好,但对于具有长依赖链的区块来说效果不佳。BALs 实现了 完全并行 验证,解开了依赖关系,并允许以任意顺序处理事务——彼此独立。

次要好处

没有执行的状态转换:BALs 是完整状态差异。这允许客户端从前一个状态和 BAL 中推导出后一个状态 (apply_bal(pre_state, bal) -> post_state)。这有几个含义:

  • 在 zkEVM 上下文中,节点可以验证一个证明并跳过执行,同时仍保持完整状态。
  • 可用于在同步或重组期间更新状态。
  • 部分无状态 优势,因为 BALs 帮助部分无状态节点仅维护他们关心的状态子集。
  • 协助像 FOCIL(包含列表)这样的提案,这些提案需要执行后的有效性检查。通过将 BAL 应用于前一个状态,通常只能在事务执行后完成的检查可以在事务执行前执行。

    • 同样适用于具有公平成本分配的区块级预热。今天,这只能在执行每个事务后完成,但是,有了 BALs,就可以更早地在执行前完成。

更简单的 RPC 方法替代方案

  • 长期以来,帐户余额索引一直是许多应用程序开发人员的痛点。BALs 通过允许开发人员跟踪余额而无需依赖大量的 RPC 调用来帮助解决这个问题。用户和应用程序可以直接从区块访问和维护余额信息——使该过程更加高效和直接。

为什么是现在?

社区已经表达了明确的愿望:Ethereum L1 必须扩展以满足用户和开发人员的需求。BALs 释放了对于更高吞吐量和/或更短插槽时间至关重要的性能提升。它们还为基于 zkEVM 的轻节点(无执行 + 无状态)、全节点(无执行 + 有状态)和部分无状态执行铺平了道路。

在 Fusaka 中,EIP-7825 通过限制单个事务的 gas 上限迈出了第一步,从而强制执行了基本级别的并行执行。

与替代方案相比

乐观并行执行已经在大多数客户端中实现。它在许多事务独立的平均区块中表现良好(参见 dependency.pics),但它无法并行化每个事务都依赖于前一个事务写入的 最坏情况 区块。BALs 不仅在平均情况下提高了性能,尤其是在 最坏情况 下提高了性能,这对于可预测和可扩展的执行至关重要。

利益相关者影响

积极方面:

  • 用户 从更便宜的 L1 事务中受益。
  • 验证者和节点运营商 体验到更低的计算开销(消除了对有效地执行两次区块的乐观并行化机制的需求)。
  • 执行客户端 获得更可预测的事务独立性模型,从而实现更深入的优化。
  • 用户和应用程序受益于更简单的数据索引。

负面或权衡:

  • 区块构建者 负责生成准确的 BALs。这项任务很简单,与构建者的讨论表明,增加的复杂性可以忽略不计。对于构建者来说,这是一项额外的努力,可以大大简化验证者的工作。
  • 区块大小开销:在 36m gas 上限下,BALs 平均每个区块增加约 45 KiB。这是由于包含 (1) 存储位置和 (2) 状态差异(大小约为 50:50)。虽然与 最坏情况 的 calldata 区块相比,这很小,但这是一个持久的成本,必须在不同的工作负载和 gas 上限下进行基准测试。重要的是,大的 BAL 区块和大的 calldata 区块是互斥的,因此 最坏情况 的区块大小与今天相同。

技术准备情况

该规范包含在 EIP-7928 中,并且 SSZ 数据结构已明确定义。与多个执行客户端团队的实施讨论正在进行中,并且初步原型正在制作中。有使用 ethereum/execution-specs 实现的初始规范。共识层不需要更改。

通过以 2026 年的硬分叉为目标,研究人员和客户端团队有充足的时间进行进一步的分析、实施、测试和模拟。

安全性和未决问题

未决问题:

BAL 中到底应该包含什么?

→ 此处讨论了设计空间 here

从正在进行的讨论中得出的两个关键见解:

  1. 事务级状态差异不仅仅对并行化有价值,如上所述,还有其他好处。
  2. BAL 大小的主要贡献者是 读取。读取比写入便宜,因此可以在单个区块中更频繁地完成,从而导致更大的 BAL。从 BAL 中删除存储位置(仅保留用于写入的 tx 级状态差异)可以显着减少其平均大小和 最坏情况 的大小。

从 BAL 中删除存储位置会使其大小减半,但也会消除在区块处理开始时执行批量 I/O 的能力。所以关键问题是:

我们应该在 BAL 中保留存储位置以提高实用性,还是为了更小的尺寸而删除它们?

  • 原文链接: ethereum-magicians.org/t...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
以太坊中文
以太坊中文
以太坊中文, 用中文传播以太坊的最新进展