以太坊第一次给区块体积设了字节上限：EIP-7934 的十兆包裹

Gas 管计算，字节管什么

以太坊给区块的计算量设了上限（Gas 上限），给每笔交易的计算量设了上限（EIP-7825），但对区块编码成字节后有多大，协议层长期没有硬数字。这个空白听起来无害：Gas 都限制了，还能出多大的块？问题在于执行与传输是两回事。一段 Gas 消耗平平的内容，编码成字节可能非常肥——典型的例子是数据密度高、执行便宜的 calldata 类负载。体积直接决定节点间的传输时间、序列化与反序列化的内存峰值，以及同步与重组窗口里的带宽压力。

EIP-7934 把这件事写成了一条协议规则：对执行层区块的 RLP 编码体积设上限，用一个约十兆字节的总包裹框住区块体，其中划出约两兆字节的余量给共识层结构的开销。它随 Fusaka 升级在 2025 年 12 月 3 日主网激活，状态为 Final。

为什么边界恰好与传播有关

共识层的 gossip 协议本身对超大的区块有自己的处理边界，体积过线的区块在网络里的流动会打折扣——这类边界此前更多是工程实现层面的事实，而不是写在执行层共识规则里的条款。两者的缝隙会带来一类别扭局面：一个在执行层完全合法、但体积卡在传播边界上的区块，可能让网络不同部分看到它的速度差异变大，临时分叉与重组的窗口随之变宽。EIP 的动机部分正是把这条边界上提为协议级承诺：执行层不再产生共识层传不动的区块。

对拒绝服务防御也一样。没有硬上限时，构造巨块拖慢全网验证是理论上存在的攻击面；有了硬上限，最坏情况的传输与解析成本变成有界量，节点可以据此做资源规划。

它和 Gas 上限如何分工

一个形象的划分：Gas 上限管一个区块可以做多少事，体积上限管这个区块搬运起来有多重。两条线通常不会同时咬合——常规负载下体积远够不到兆级上限，Gas 先到顶。真正可能先碰到体积线的是极端数据密集的交易组合：大量 calldata、密集的日志写入、或者把许多小额操作塞进一个区块的数据投放策略。两条上限同时收紧的方向一致：为后续提高 Gas 上限做风险配套，计算和字节两个维度都保持在可传播、可验证的包络内。

值得强调的是，这条规则并不改变任何普通用户的体验参数，也不会让谁的费用上升。它更像给网络画的一条安全车道线：正常情况下看不见，异常情况下救命。

顺带一提，把它与比特币对照会更直观：比特币用四百万权重给区块体积设了硬顶，字节维度一直是共识的一部分；以太坊此前把体积问题留给 Gas 与工程默认值处理，EIP-7934 补上的正是这条一直缺席的显式界线。

快速问答

问：十兆是执行层区块单独的体积吗？ 答：EIP 的写法是给区块体设编码上限，并用约两兆的余量把共识层结构的体积一起框进总包裹，具体常量以规范为准。

问：以太坊之前完全没有限制吗？ 答：区块本身有 Gas 上限、单笔交易有大小与脚本规则，客户端也有各自的处理约束，但缺一条统一的协议级体积条款，这次补的正是这块。

问：它会导致区块装不进更多数据吗？ 答：对绝大多数区块而言体积远未触线，实际约束力仍然在 Gas 与数据可用性机制一侧。

常见误区

一是把体积上限与 Gas 上限混为一谈，两者量纲不同、失效场景不同。二是以为这条线是为了让区块更大，它的设计目标是划界与防御，扩容红利取决于 Gas 一侧的参数演进。三是把 gossip 层的既有工程边界当作协议保证，这次升级恰恰是把隐含边界显式化，两者的可验证性与违约后果不同。

风险提示：本文为协议机制科普，不构成任何投资建议；常量与参数细节请以 EIP 原文与客户端文档为准。