EIP-7934 RLP execution block size cap (RLP Execution Block Size Limit)
Final · Networking & nodes · EIP status Final · created 2025-04-16
Sets a protocol-level cap on the size of a block when RLP-encoded. Blocks larger than the total 10 MiB limit minus the 2 MiB beacon block share are treated as invalid.
Why it is needed
Today Ethereum has no strict cap on the encoded size of a block. So when a very large block is produced, it propagates more slowly across the network, and the risk of temporary chain splits (forks) and reorgs grows. A malicious actor could also deliberately build huge blocks as a denial-of-service (DoS) attack to degrade network performance. In addition, the consensus layer (CL) gossip protocol does not propagate blocks larger than 10 MiB at all, so large blocks can cause network partitions or denial of service. This proposal sets a protocol-level cap on block size, which raises resistance to attacks that target block validation time, and it reserves an explicit 2 MiB margin for the beacon block size to preserve compatibility between network components.
What changes
Today
- There is no strict protocol-level cap on the encoded size of a block
- Very large blocks slow propagation and raise the risk of temporary forks and reorgs
- Blocks over 10 MiB are not propagated by consensus layer gossip, which risks a network partition
After EIP-7934
- A block whose RLP-encoded size exceeds the cap (10 MiB minus the 2 MiB margin) becomes invalid
- Validators must respect this size limit when building blocks
- Every node performs the size check during block validation and propagation
Who is affected
- Validators: When building a block, block construction logic must ensure the RLP-encoded size does not exceed MAX_RLP_BLOCK_SIZE.
- Client teams: Every Ethereum client must include this size check in block validation and propagation.
- The whole network: It adds a basic defense against deliberately crafted huge-block attacks and reduces the risk of a network partition that could arise from a mismatch with the consensus layer gossip limit.
In depth
Constant definitions
Three constants are introduced. MAX_BLOCK_SIZE is 10 MiB (10,485,760 bytes), SAFETY_MARGIN is 2 MiB (2,097,152 bytes), and MAX_RLP_BLOCK_SIZE is computed as MAX_BLOCK_SIZE - SAFETY_MARGIN. Any block whose RLP-encoded size exceeds MAX_RLP_BLOCK_SIZE must be considered invalid. The 2 MiB margin explicitly accounts for the beacon block size.
Validation function
The check added to the protocol takes the form exceed_max_rlp_block_size(block), which returns true if len(rlp.encode(block)) > MAX_RLP_BLOCK_SIZE. If it returns true, the block is invalid and must be rejected, and the block production stage must also not produce such a block.
Protocol behavior changes
Two things change. First, in block production, a validator must ensure that the total RLP-encoded size of the block it builds does not exceed MAX_RLP_BLOCK_SIZE. Second, in block validation, a node must reject any block whose RLP-encoded size exceeds MAX_RLP_BLOCK_SIZE. All client implementations must integrate this check into block validation and propagation, and this limit applies independently of any gas-related metrics.
Why 10 MiB?
The 10 MiB cap is a value matched to the constraints of Ethereum's consensus layer gossip protocol. Blocks well over 10 MiB are not broadcast by the consensus layer, which can lead to a network partition or denial of service. Adding a 2 MiB margin to explicitly reflect the beacon block size ensures consistent block propagation and compatibility across network components.
Backwards compatibility and security
This change is not backward compatible with blocks larger than the new limit. Validators and miners must make sure their block construction logic strictly respects this limit. On the security side, limiting the maximum block size is itself a basic defense against deliberate huge-block attacks. The status of this EIP is Final, meaning the specification is settled.