一条链如果靠零知识证明来确认区块正确性——验证者只需验一份证明，不必下载并重新执行整个执行载荷——它的去中心化程度会好看很多。但 EIP-8142 提醒了一个容易被庆祝声盖住的问题：一旦没人再下载执行载荷，“这份数据至少公开发布过”的隐性担保就消失了。这份 2026 年 1 月底创建的草稿把方案叫 Block-in-Blobs（块中块，BiB），目标是把数据可用性（DA）重新焊回共识里，目前处于 Draft。
被重写的那条隐性担保
传统验证流程是三步：下载执行载荷、本地执行一遍、比对状态根等字段与区块头是否一致。正因为“想验证就必须拿到数据”，载荷的可用性被验证行为本身顺带保证了——不需要额外机制。换成 zkEVM 路线后，验证流程变成：下载证明、下载区块头、验证明白。全过程中没有任何角色有义务拿到完整载荷数据。于是出现一种攻击面：出块者（builder）发布一份有效证明、扣住载荷数据不发。证明为真意味着载荷存在且合法，但只要没人能拿到字节，下游的轻客户端、跨链桥、想重新执行归档的人就全被卡住——链在共识上活着，在数据上失联。
BiB 的做法：让载荷住进本来就有 DA 保障的地方
以太坊已有的 blob 空间（EIP-4844 引入、PeerDAS 负责分发与抽样）就是协议内建的“短期数据公告栏”，数据可用性抽样机制保证 blob 内容可获取。BiB 的主张是：区块引用的 blob 承诺列表里，划出一个前缀区段专门放执行载荷的编码数据；zkEVM 证明必须把被证明的载荷与这些前缀承诺绑定。这样得到一条不变量——一个块有效，就意味着存在一串有序的 blob，其字节解码后正是规范执行载荷，且其 KZG 承诺与区块引用的前 payload_blob_count 个承诺吻合；而这些 blob 的可用性由现成的 DAS 机制负责。验证者依旧不用下载载荷，但“不发载荷”从可行攻击变成共识层直接拒绝的无效块。
设计里的两个细节
其一，载荷 blob 与用户 type-3 交易 blob 共享同一个 MAX_BLOBS_PER_BLOCK 上限（该上限由网络配置决定），塞进载荷的额度多了，留给用户数据的 blob 空间就少，这为“每块多少 blob 给载荷”留下治理题。其二，方案完全复用承诺与抽样体系，不新增数据层，代价是载荷必须能高效编码成 field element 序列并算 KZG 承诺——工程重心在这条序列化管道上。
两种失败模式的对照
可以按“谁不守规矩”给 BiB 画一张失败对照表：出块者发证明不发载荷——协议内新增的可用性不变量直接把块判无效；证明合法但 blob 解码不是规范载荷——同样落在绑定条款的射程里。剩下的灰色地带集中在 blob 空间配额上：载荷额度越大，DA 越稳、用户 blob 越挤，反之亦然。这条曲线的平衡点写不进协议常量，只能进治理讨论。
快速问答
问：这等于让 L2 又回到 calldata 时代吗？ 答：不是。calldata 是永久上 L1 状态，BiB 用带保留期的 blob 空间，只要求“可恢复窗口”内的可用性，成本模型完全不同。
问：谁能扣住载荷不发？ 答：提案讨论的主要风险方是出块一侧；zkEVM 证明绑定了载荷承诺后，不发载荷的块直接无效，攻击失去收益。
问：Rollup 现在靠什么保证数据可用？ 答：主流做法是自己发 blob 或 calldata 到 L1，再由欺诈证明或有效性证明约束状态；BiB 谈的是把这份数据与区块有效性在共识层焊死。
一条观察线
凡是“用证明替代重放”的设计，都欠下一笔数据可用性债：证明说得清对不对，说不出有没有。BiB 是这笔债的标准化还款方式之一。读 zkEVM 路线图时，把“证明系统升级”和“DA 配套”配对着看，才看得出真实进度。
风险提示：本文是对公开提案文本的解读，不构成投资建议；提案内容可能随社区讨论修改或作废，请以提案仓库页面为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。