一个参数，两处硬编码
坎昆升级引入 blob 交易后，每个区块允许多少条 blob 成了协议参数。尴尬的是这个参数同时存在于两个地方：共识层客户端按自己的规则验证”这个块最多几条 blob”，执行层客户端也在代码里写死一份同样的上限，两层各自执行一次校验，靠引擎接口的数据一致性检查对齐。EIP-4844 的设计哲学是”执行层不信任共识层，重复验证一切”，但 blob 数量的场景里这种重复带来一个具体摩擦：上调 blob 数量需要两层同步改代码、同步改参数表，任何一侧晚一步，两种客户端就会对同一个块产生分歧。EIP-7742 想做的，是把这条锁链从两头解开成一头。
提案的两板斧
第一板斧针对上限（max）：blob 数量上限本来就由共识层验证，执行层在引擎接口的一致性检查中已经间接继承了这条验证——提案指出执行层那份严格检查在逻辑上是多余的，删掉它，上限的权威归属唯一化到共识层。第二板斧针对目标数（target）：blob 基准费按”实际数量与目标数量的偏差”逐块调节，目标值必须两层一致才能算出相同价格。如果执行层不再知道上限，它也无从推算目标。解决办法是把目标值显式化：共识层每次通过引擎接口交付载荷时附带当前 target_blobs_per_block，执行层区块头为此新增一个 64 位字段把它写进块结构。执行层验证区块时核对该字段与共识层发来的一致。这个设计的参照系是提款队列——目标值的可信性由共识层背书，“和提款一样”，而写进区块头是为了保住乐观同步的安全属性：同步节点不看执行细节只看头部承诺，目标值必须暴露在头部承诺之内。
它停在哪，意义在哪
提案状态 Stagnant（2024 年 7 月创建，引用 EIP-4844），没进任何升级清单。它的精神却在别处活了下来：blob 参数的上调路线后来走的是”只改参数的轻量分叉”框架（每次小步调整仍是一次两方同步的升级），而不是运行时解耦。这恰恰展示了协议演化的典型分岔——“让参数随时可动”与”把参数变动仪式化”是两条竞争路线，后者以每次变动都走升级流程为代价换取实现简单、历史可追溯。EIP-7742 记录的是前者未走完的那半程。
读懂它需要的三块背景
其一，引擎接口（Engine API）是执行层与共识层之间的进程边界，共识层组装块结构并递交执行层执行，执行层回以有效性裁定；其二，乐观同步下执行层客户端信任头部序列，代价是头部里的每个共识字段都必须被诚实标记，“谁验证谁声明”的边界模糊会直接开洞；其三，blob 基准费的调节算法只认目标数，现行机制里目标值按与上限的固定关系定义；解耦提案特意强调目标值可由共识层独立给出、不再被上限的固定比例绑死，为”上限动、目标按曲线走”留了空间。三块背景齐了，就能明白这份提案不是运维便利条目，而是在两层架构里重新划分参数主权的尝试。
一个类比
把两层架构想成海关与邮局：共识层是决定”这批包裹符合入境名录”的检疫口，执行层是称重计费并投递的窗口。EIP-4844 的做法是名录在两边各贴一份，窗口每天对照检疫口自查一遍；EIP-7742 说名录只需贴在检疫口，但检疫口每次放行时要把”当日计费的基准吨位”随包裹交给窗口，并且把这行字印在包裹封面上供全网核验。类比的每一处对应都严格：封面字段对应区块头里的 64 位目标值，对照自查对应引擎接口的一致性校验，名录唯一化对应执行层删除上限检查。它甚至继承了类比里的弱点——窗口仍然默认检疫口诚实申报基准吨位，信任没有消失，只是从”两份名录互相制衡”改成了”一个字段加签名承诺”。评估这类提案时的通用问题也随之浮现：冗余校验省下的灵活性收益，是否抵得上少掉的那份独立性？
快速问答
问：现在上调 blob 数量要改几份代码？ 答：两层客户端各自的参数表都要改，这也是每次 blob 扩容都要捆绑一次升级公告的原因之一。
问：目标值由共识层报，执行层不会被骗吗？ 答：执行层核对区块头字段与共识层申报值一致，而区块头承诺覆盖该字段；撒谎的共识层产出的是无效块，保护来自头部签名与承诺链。
问：和 BPO 分叉什么关系？ 答：BPO 回答”参数怎么改”（轻量小分叉），7742 回答”参数归谁验证”（单一权威）；两条路线互补但都被搁置了后者。
风险提示：本文是协议草案解读，不构成投资建议；参数现状以当期客户端文档与升级公告为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。