EIP-7934：RLP 区块大小限制，使以太坊更安全、更可预测
发布: (2026年1月20日 GMT+8 12:40)
6 min read
原文: Dev.to
Source: Dev.to
为什么以太坊需要字节大小限制
在 Fusaka 之前，以太坊仅依赖区块 gas 限制。Gas 用来衡量计算量，但它与字节大小并没有紧密的对应关系。恶意区块可以塞入：
- 许多低 gas 的交易但携带巨大的 calldata
- 产生大量收据的廉价操作
- 过大的 RLP 结构
这些在 gas 规则下仍然是“有效”的，却会导致现实中的问题：
- 传播延迟 → 临时分叉 – gossip 网络会丢弃 > 10 MiB 的区块。
- 超大区块 DoS – 大量 RLP 负载需要大量 CPU 来解码。
- 硬件需求无上限 – 区块越大，完整节点所需的最低带宽和 CPU 越高。
EIP‑7934 强制设定可预测的上限，以便执行层（EL）和共识层（CL）能够保持一致的行为。
提案：10 MiB 硬上限（含 2 MiB 安全余量）
已定义常量
| 常量 | 数值（字节） | 用途 |
|---|---|---|
MAX_BLOCK_SIZE | 10 485 760 | CL gossip 硬限制 |
SAFETY_MARGIN | 2 097 152 | 为信标块头预留 |
MAX_RLP_BLOCK_SIZE | 8 388 608 | 最大 RLP 执行负载 |
区块验证规则
# Reject blocks whose RLP‑encoded size exceeds the limit
if len(rlp.encode(block)) > MAX_RLP_BLOCK_SIZE:
reject_the_block()规则执行位置
- 区块生成 – 构建者必须确保 RLP 大小在限制范围内。
- 区块验证 – 客户端拒绝超大区块。
- Gossip – CL 永不传播 > 10 MiB 的区块。
- RPC – 不能通过 API 提交超大区块。
可视化拆解：10 MiB 限制的工作原理
- MAX_BLOCK_SIZE：10 MiB 的整体区块大小。
- SAFETY_MARGIN：为信标块头预留的 2 MiB。
- MAX_RLP_BLOCK_SIZE：可用于执行负载的 8 MiB。
此分配完全符合 CL gossip 规则，并防止 EL > CL 不一致。
为什么是10 MiB？背后的理由
- 共识层已经强制执行了10 MiB的硬限制。
- 当前以太坊区块大小约为1–2 MiB，仍有充足的余量。
- 未来的吞吐量取决于安全且确定的边界。
- 简单、确定的上限更易实现和审计。
协议更改及开发者影响
客户端实现者
- 将 RLP 字节大小检查集成到区块构建、导入流水线、Gossip 验证以及 RPC API 中。
- 添加测试夹具（已包含在 Fusaka 规范测试中）。
Rollup / L2 开发者
- 在批量处理 calldata 较多的交易时，大批量可能会超过 8 MiB 的 RLP 限制。
- 考虑压缩、分块或并行提交。
- 证明/收据的大小也计入总字节数。
- 设计时需围绕物理区块约束，而不仅仅是 gas。
节点运营者
- 无需额外配置。
- 好处：更快的传播、更少的意外重组、在负载下更安全的网络。
安全影响
- 超大区块 DoS 已缓解——节点永远不会尝试解码超过 RLP 限制的区块。
- CPU 耗尽 已降低——上限提供可预测的验证时间。
- 网络碎片化 已消除——执行层和共识层现在对可接受的区块大小达成一致。
- 传播差异 降低——共识更为稳定。
权衡与考虑的替代方案
| 替代方案 | 被拒绝的原因 |
|---|---|
| 基于 gas 的动态大小调整 | gas 不是字节大小的强预测因子。 |
| 将限制提升至 20–30 MiB | 损害去中心化和本地质押者。 |
| 软限制（仅警告） | 仍会导致传播延迟。 |
摘要
10 MiB 硬上限是最安全且最容易在所有 client teams 中实施的方案。它为即将到来的 throughput upgrades 提供了明确的 guardrail。
EIP‑7934 在 Fusaka 中的作用
Fusaka 是一次面向基础设施的升级，旨在为以太坊的下一阶段 L2 扩容做好准备。EIP‑7934 确保提升后的区块 gas 限额（EIP‑7935 → 60 M）以及其他吞吐量改进不会导致网络不稳定。
Related EIPs
- EIP‑7935 – 将区块 gas 限额提升至 60 M。
- EIP‑7825 – 每笔交易的 gas 上限。
- EIP‑7892 – Blob 数据可用性改进。
开发者要点（快速参考）
- Max execution RLP payload per block: 8 MiB
- Max EL + CL block size: 10 MiB
- 如果 calldata 批次接近 6–7 MiB，则需要进行分块。
- Gas ≠ 字节 – 设计时需兼顾两者。
- 节点客户端现在会提前拒绝超大区块，提高了未来升级的传播安全性。
Conclusion
EIP‑7934 不是面向前端的 UX 功能；它是一项结构性升级，在 rollup 和数据可用性解决方案的需求持续增长的情况下，稳定以太坊。通过强制执行严格的字节大小上限，以太坊获得：
- 可预测的区块验证时间
- 降低的 DoS 攻击面
- 一致的 EL – CL 行为
- 更低的传播方差
- 更安全的 gas‑limit 提升
这个界限看似很小，但对以太坊的长期可扩展性至关重要。