Layer 2 把数据搬进 blob 之后，一项新成本浮出水面：每个执行层节点都要把每条 blob 交易的完整数据收一遍，很大程度只为传播。EIP-8070 认为这件事没有道理：既然信标层已经把 blob 切成单元格并给验证者分了托管任务，执行层节点完全可以按同一套分工去抽样，只有少数情况才需要拉全量。提案把机制称为稀疏 blob 池，并挂在一个新的 eth 协议版本上。
现在的 blob 池贵在哪
执行层 blob 池是随机广播结构：新 blob 交易进来，节点收全量、验证明、再转给邻居。这条路径的带宽成本随 blob 吞吐线性上升，而节点从全量数据里拿到的边际价值并不高——它既不长期保管数据（托管责任在信标层），通常也不需要自己重算可用性抽样。自从信标层引入单元格级抽样与列托管之后，网络对每个节点持有全量的依赖本就在下降，执行层继续全量收数据更像一层重复开销。
稀疏池的两个动作
第一是概率性全取。提案的取值是 p = 0.15：对每条新的类型 3 交易，执行层节点以约百分之十五的概率拉完整 blob，其余情况只做单元格抽样，用的正是这台机器在信标层的托管集合。按提案自己的算术，抽样节点最少只需下载六十四格中的八格，即八分之一，于是平均带宽约为 0.15 加上 0.85 除以八，约等于 0.25——相当于降到四分之一左右。p 的取值是一个权衡：太小会让拥有全量的节点构成的骨干太稀，影响交易可达性。第二是与信标层对齐。执行层要按信标层当前的列托管去取对应单元格，信标层通过 Engine API 把这个托管集合以位数组形式告知执行层。对齐后，信标客户端本地需要补数据时，执行层池子里恰好有它用得上的部分——双方共享同一份残缺，而不是各自残缺。
构建者隐私是硬约束
如果只有少数节点拉全量，本地出块构建者的取数模式会不会一眼可辨？这是提案花大量篇幅处理的问题：一旦网络能从请求模式反推谁在构建区块，就形成针对构建者的拒绝服务攻击面。因此提案要求构建者的网络行为与噪声不可区分，并在参数选择与可靠性框架里为此保留余量——宁可牺牲一点效率，也不让位置可被反推。此外提案明确不引入规范性节点评分，避免抽样失败演变成大规模封禁；相关断连策略留在实现层。
安全边界与当前状态
抽样型网络的可靠性依赖全量骨干足够连通与足够多的诚实节点，提案的威胁模型逐条讨论了 withholding 与选择性传播等场景，参数在草稿中仍属可标定项。截至本文写作时，EIP-8070 状态为评审（Review），创建于 2025 年 10 月 29 日，声明依赖 EIP-4844、EIP-7594、EIP-7870 与 EIP-8159，未包含在已激活升级中。
一次传播旅程
跟着一条 blob 交易走一遍：它从 L2 提交者发出，进入某个执行层节点后开始扩散。邻居节点收到公告，抽硬币：约每七条有一条会去取完整 blob，其余只按自己托管的列去要对应单元格。取全量的节点构成一条隐形的骨干网，保证每个方向上都有节点拿着完整数据可以继续传；抽样节点虽然缺数据，但手里的单元格与其他节点的残缺拼在一起，全网信息冗余足够重建。若某个时刻骨干太薄，提案的持续抽样与重采样机制会再掷一次骰子，用网络饱和度做反馈。
快速问答
问：抽样会不会削弱数据可用性保证？ 答：可用性的判定依据在信标层的托管与重建机制上；这份提案改变的是执行层节点本地持有量，不改协议对可用性的定义。 问：普通节点会更容易缺数据吗？ 答：对某条具体 blob 的完整可见性确实下降，需要时会走取数与单元格重建路径，这正是可靠性框架负责的环节。 问：这算不算把 blob 分片了？ 答：不算。提案刻意保留 blob 池原有的随机、非分片结构，只把全量广播换成抽样，理由是简单性与抗毁性。
风险提示：本文为协议机制科普，不构成投资建议；参数与带宽估算以提案当期文本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。