整块验证的等待税
今天的节点验证一个区块，要等整个执行载荷收齐才开始执行：先收信标头、再等几十万到几百万字节的交易数据逐片到齐，凑齐才按顺序重放交易、算出状态根。延迟由此分层累积——传播尾延迟、执行串行化、坏块只能整块作废。块越大，等得越久；网络稍一抖动，所有节点的验证时间整体后移。
EIP-8101（2025年12月起草，草案状态）把验证节奏改成流水线：出块者先公布信标头与执行载荷头，随后把执行侧切成一串自包含的执行块（chunk），每块附带一份记录状态差分的访问列表（Chunk Access List，CAL），二者作为独立消息在网络上传播。验证节点不必等全部交易：只要第 N 块和零到 N 的 CAL 都在手上，第 N 块的校验就能开工，各块互不阻塞；全部块校验通过，共识层再正式确认整块。验证从一次性大餐变成随到随吃的流水席。
CAL：让块之间互不依赖的胶水
拆块后最棘手的问题是块间依赖：第三块的交易若读了第二块写的存储槽，校验第三块就得先跑完第二块。CAL 是解药——它按 EIP-7928 的区块访问列表编码，随每个块发布该块执行触碰过的地址、槽与前后值。校验第 N 块的节点无需重放前面的块，直接从 CAL 读出第 N 块依赖的每一格状态应该是什么，对照本地状态验证差分成立即可。依赖关系被文档化、外置化，并行校验自然成立。
常量的量级感：每块 gas 上限 CHUNK_GAS_LIMIT 取 2 的 24 次方，即约 1678 万，恰好是 EIP-7825 定的单交易 gas 天花板；每区块最多 256 块（MAX_CHUNKS_PER_BLOCK 取 2 的 8 次方）、每块最多 65536 笔交易、RLP 编码后的 CAL 最大 16MiB。区块内块顺序先定死，执行边界即传播边界，也顺手成为未来零知识证明系统天然的证明单元。
原子性怎么办
流式结构最容易招致的质疑是：既然块能分开验证，会不会出现半块被接受、半块被拒的分叉？提案把边界画得很清楚：chunk 只是传播与验证的构造物，共识层只在全部块校验成功后才对整块投票，规范链存储的始终是完整执行载荷——出块失败第一处坏块即可早拒、省掉后续算力，但没有任何节点会在部分块上构建。换句话说，收益是延迟与算力，代价只多了几种网络消息，分叉语义一个字没改。
延迟从哪儿省
对比一次坏块场景最直观。旧流程：全量收完、开始执行、跑到坏的那笔才发现非法，整块几十毫秒执行费全部沉没。新流程：CAL 先到，节点立刻并行开验各块，坏块所在分片一旦被证伪即整块拒收，其余分片的等待也同步作废。带宽角度看，块头与 CAL 都很小、可以抢跑，重量的交易数据晚到几秒不再阻塞校验决策——对只推进状态的同步节点，这种早到信息价值最大。
出块者视角的改动清单
协议升级从来不是验证端的独角戏。出块者要先决定切分策略：按 gas 也好、按交易序也好，把载荷划成至多 256 段、每段不超 1678 万 gas，段内交易顺序即执行顺序；执行每段时顺手收齐 CAL，把段头（含 CAL 哈希、交易根与收据根）逐个塞进区块体的 chunk 承诺树。广播阶段则拆成三拍：先喊头，再撒 CAL，最后放交易分片，三者的先后到达决定网络里的校验何时起跑。这些改动全在构造与传播层，共识判定不变——但对出块软件是一次架构级重写，也是此类流式提案落地周期普遍偏长的真实原因：收益摊给所有节点，账单先砸在客户端团队头上。
快速问答
问：节点要存 chunk 吗？不需要，链上历史仍是完整载荷，chunk 只在传播期存在。问：和 EIP-8146 撞车吗？不，8146 处理整块 BAL 怎么旁路分发，8101 是把载荷本身切开、CAL 内嵌进切片架构。问：矿工或出块者需要改什么？出块侧要把载荷切块并发布 CAL 消息，验证侧新增消息处理与并行调度。
风险提示：本文仅解读协议草案，不构成投资建议；结构与常量以官方 EIP 文本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。