EIP-7928 引入区块级访问列表（BAL），包含每个交易访问的账户和存储槽以及交易后的状态差异。这使得 EVM 可以并行执行交易、批量预取状态、并行计算后状态根，并改进同步（Snap Sync v2）。初步测试显示，在 6 核机器上区块验证速度提升 5 倍，有望将 gas 上限提升至 3 亿甚至更高，实现以太坊扩展的 10 倍提升，同时不影响硬件要求。
概述
以太坊即将从根本上改变区块的执行方式。随着即将到来的 Glamsterdam 硬分叉，它将推出 EIP-7928：区块级访问列表，这是一项将并行化引入 EVM 的提案。以下是对其内容、工作原理及其对扩展重要性的简要说明。
让我们从头开始。EIP-7928 与 EIP-7732（ePBS）一同，是 Glamsterdam 分叉中执行层（EL）的重磅提案。与 ePBS 一样，主要关注点是以太坊的扩展，不过这两个提案还附带了一系列其他同样重要的特性——例如消除 PBS 流水线中的信任需求或改进同步。
什么是区块访问列表？
EIP-7928 为每个以太坊区块添加了一个区块访问列表（BAL）。BAL 是区块触及的账户和存储槽的列表，但这并非全部：它还包含交易后的状态差异（这部分至关重要！）。交易后的状态差异告诉你每个交易之后的状态是什么样的。
快速示例：用户 A 在去中心化交易所 B 上用 1 ETH 兑换 DAI。BAL 告诉你，用户 A 的 ETH 余额减少了 1 ETH 加上交易费用，其 nonce 增加了 1；去中心化交易所 B 的 ETH 余额增加了 1 ETH；在 DAI 合约内部，用户 A 的 DAI 余额增加，而去中心化交易所 B 的余额减少。换句话说，所有这些信息都可以静态获取，而此前需要追踪交易才能得知。
关键优势
客户端软件（Geth、Nethermind、Besu、Erigon、Reth、Ethrex、Nimbus）可以利用这一点实现一些非常强大的功能：
-
并行化交易执行。 了解每笔交易后的状态可以解决它们之间的依赖关系。不再需要等待前一笔交易，因此执行可以完美并行化。区块验证的大部分时间不再闲置等待顺序执行，客户端最终可以更好地利用现代硬件。
-
批量预取。 节点最繁琐的工作之一是从磁盘获取执行所需的状态。由于状态位置（例如用户 A 在 DAI 合约中的余额所在的确切存储槽）只能在执行过程中发现，状态获取一直严重拖累扩展：它阻塞执行，耗费时间，最终拖慢一切。有了 BAL，节点执行所需的一切都可以提前知道，并且可以一次性并行加载到缓存中。这进一步加快了速度。
-
并行化后状态根计算。 另一个昂贵的任务是遍历更新后的状态树以计算后状态根，这是确保每个人在区块执行后对磁盘上的内容达成一致所必需的。由于交易后状态已经存在于 BAL 中，节点可以在执行的同时并行进行此操作。一个曾经需要等待所有交易完成才能执行的重任务，现在可以与预取和执行同时进行。
-
快照同步（v2）。 区块链中一个经常被忽视、不太引人注目的方面是同步。节点需要追上链，并且追上的速度必须快于链前进的速度。目前，大多数节点进行快照同步：在追赶最新区块的同时并行下载区块、区块头和状态，然后在接近链顶端时“修复”数据库。修复意味着向对等节点请求 trie 节点、接收、验证并更新本地数据库。这是一个迭代、网络密集的过程，可能需要一些时间，尤其是更高的吞吐量会使此阶段达到极限。BAL 在这方面也有帮助：通过快照 v2，节点可以追上链顶端并完全跳过修复阶段。在更高吞吐量下的同步变得更加稳健和可靠。
总结
综上所述，BAL 包含两样东西：
- 区块访问的状态位置
- 每笔交易后的状态变化（包括新值）
性能提升与展望
我们今天已经看到了巨大的性能提升：在 6 核机器上，EL 客户端验证区块的速度最高提升了 5 倍，这使得区块 Gas 上限达到 3 亿成为一个非常现实的结果。ePBS 将通过解耦区块与有效载荷，为验证者提供额外 2-4 倍的执行时间，进一步增强性能。为了不冒进（安全仍然是第一要务），分叉可能会以 2 亿 Gas 上限推出，但我们不会在此停留太久，很快就会推向 3 亿甚至更高。自我们开始认真对待扩展问题以来，这相当于在不触及硬件要求的情况下实现了 10 倍的扩展。
如果没有人们全身心投入、埋头苦干、交付成果，这一切都不可能实现：在会议中花费了无数小时讨论正确的设计方案，经历了无数次迭代来完善规范，编写了大量测试用例（并且仍在继续）。从白板到生产就绪代码的道路是一段旅程，我们还没有到达终点线，但就我所见，以太坊的前景看起来非常乐观。Glamsterdam 将是一个展示分布式、去中心化社区在共同目标下，聚焦于提供足够区块空间以接纳下一波用户时所能达到成就的分叉。
