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

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

作者：Toni, Francesco, Jochem 和 Ignacio.

这份简短的说明遵循了 @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 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～