一件搭错车的东西
EIP-7928 给执行区块头加了一个字段：区块访问列表（BAL），一整块执行触碰过的地址与存储槽清单，节点拿它可以并行预读、并行执行甚至免执行推进状态。但搭载方式是塞进执行载荷，在 EIP-7732 的信标侧执行分离架构下，BAL 混在 SignedExecutionPayloadEnvelope 里，跟交易数据同车、同主题、同一时刻才到。这造成了一个别扭局面：BAL 最值钱的地方是早到——早知道区块碰哪些状态，就能在交易还没齐时先预读、先起算状态根——可它偏偏和它想预读的交易同时抵达，加速价值被搭载方式自己吃掉了。
EIP-8146（2026年2月起草，草案状态）把这件搭错车的行李改走旁路：BAL 从载荷里拿出，走专属 gossip 主题作为独立侧车传播，搭建者在 ExecutionPayloadBid 里放 keccak256(rlp(BAL))——和执行区块头写的同一个哈希——对侧车内容做出承诺。
尺寸账与时序账
先看尺寸。提案引用的六千万 gas 规模分析里，完整 BAL 约 72.4KiB，压缩后的其余区块内容约 71.7KiB——状态差分和交易集几乎一样大。让 BAL 从信封里出去，关键路径上的对象直接对半砍，网络层的抗 DoS 上限也可以跟着下调。这是四个收益里最硬的一个，纯几何事实。
再看时序。侧车被要求比载荷的可用性投票期限提前至少一秒：常量 BLOCK_ACCESS_LIST_LEAD_TIME 取 1 秒，由载荷及时性委员会（PTC）投票作证——每个 PTC 成员对某个区块的侧车可用性投出观察票，委员会聚合出侧车是否在期限内先到。提前一秒意味着执行客户端拿到 BAL 时交易还没进内存池快照，可以按清单先把声明的状态取进缓存、把后状态根计算提前开工。另有一条保留常量 MIN_EPOCHS_FOR_BLOCK_ACCESS_LIST_SIDECARS_REQUESTS 取 3533 个纪元，与 7928 的 BAL 保留窗口对齐，供节点按需回补历史侧车。
顺带的受益者是 EIP-7805 包含列表委员会：第 N 槽的委员会在本槽载荷揭示前就要冻结列表，此前只能凭上一块视野猜哪些交易可能已被区块作废；早到的 BAL 给出第 N 块触碰过的所有账户后值，委员会不必重放载荷就能把状态视野推进一个块。
关注点分离的另一面
提案动机的第一条其实最不显眼也最本质：BAL 是状态差分，载荷是产生差分的交易，两种数据的受众不同。只推进状态的节点——比如免执行同步的客户端——需要差分不需要交易；把它们捆在一条车道上，等于每次都要为不需要的数据付带宽和解析费。分道之后，各取所需的订阅模型才成立。这类结构在 blob 侧车、签名聚合里已经反复验证过：共识承诺留在头里、体积走旁路，是以太坊近年来反复使用的传播套路，8146 是它在 BAL 上的又一次复用。
一秒窗口里发生什么
把这一秒拆帧看。假设载荷在槽内某刻到达并及时委员会给侧车可用性投了票：执行客户端先验侧车哈希与头承诺一致，随即解析 BAL 的哈希清单，对清单上的每个地址与槽位发起并行状态读取，磁盘与网络预读同时铺开；交易数据随后抵达、按序重放，几乎每个状态访问都能缓存命中，后状态根的默克尔重算早在预读阶段已经起步。反面对照是 7928 的原生搭载：BAL 与交易同一秒进门，预读、执行、算根全串在一条串行链上，一块的执行窗口里节点只能干一样的事。一秒听着短，它恰好是执行侧与共识侧时间预算重叠最紧的那一段，把预读塞进这一秒，相当于从整块处理时长里凭空抠出一个阶段。
快速问答
问：侧车丢了区块就废了吗？不会，载荷本身仍完整可执行，BAL 缺席只是放弃预读加速，7928 里 BAL 本就是可推导的冗余声明。问：和 8159 什么关系？8159 解决同步节点向对等节点索取历史 BAL，8146 解决当槽 BAL 怎么抢跑传播，一个补历史一个抢现在。问：谁负责发？搭建者，且以 bid 内哈希自我约束，侧车与头哈希不一致即整块作废。
风险提示：本文仅解读协议草案，不构成投资建议；常量与时序以官方 EIP 文本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。