This proposal introduces a protocol-level cap on the maximum RLP-encoded execution block size to 10 megabytes (MiB), which includes a margin of 512 KiB to account for beacon block sizes.
Motivation
Currently, Ethereum does not enforce a strict upper limit on the encoded size of blocks. This lack of constraint can result in:
Network Instability: Extremely large blocks slow down propagation and increase the risk of temporary forks and reorgs.
DoS Risks: Malicious actors could generate exceptionally large blocks to disrupt network performance.
Additionally, blocks exceeding 10 MiB are not propagated by the consensus layer’s (CL) gossip protocol, potentially causing network fragmentation or denial-of-service (DoS) conditions.
By imposing a protocol-level limit on the RLP-encoded block size, Ethereum can ensure enhanced resilience against targeted attacks on block validation times. Adding an additional margin of 512 KiB explicitly accommodates beacon block sizes, ensuring compatibility across network components.
Specification
Block Size Cap
Introduce constants:
MAX_BLOCK_SIZE set to 10 MiB (10,485,760 bytes)
MARGIN set to 512 KiB (524,288 bytes)
MAX_RLP_BLOCK_SIZE calculated as MAX_BLOCK_SIZE - MARGIN
Any RLP-encoded block exceeding MAX_RLP_BLOCK_SIZE must be considered invalid.
Thus add the following check to the Ethereum protocol:
MAX_BLOCK_SIZE=10_485_760# 10 MiB
SAFETY_MARGIN=524_288# 512 KiB
MAX_RLP_BLOCK_SIZE=GOSSIP_UPPER_LIMIT-SAFETY_MARGIN# if true, the block is invalid and should be rejected/not get built
defexceed_max_rlp_block_size(block:Block)->bool:returnlen(rlp.encode(block))>MAX_RLP_BLOCK_SIZE
Changes to Protocol Behavior
Block Creation: Validators must ensure the total RLP-encoded size of any produced block does not exceed MAX_RLP_BLOCK_SIZE.
All Ethereum client implementations must integrate this size check as part of block validation and propagation.
This limit applies independently of gas-related metrics.
Rationale
Why 10 MiB?
A cap of 10 MiB aligns with the gossip protocol constraint in Ethereum’s consensus layer (CL). An additional 512 KiB margin explicitly accounts for beacon block sizes, ensuring compatibility and consistent block propagation across the network. Blocks significantly larger than 10 MiB will not be broadcast by the CL, potentially leading to network fragmentation or denial-of-service scenarios.
Backwards Compatibility
This change is not backward-compatible with any blocks larger than the newly specified size limit. Validators and miners will need to ensure their block construction logic strictly respects this limit.
Security Considerations
Restricting maximum block size provides inherent protection against deliberate oversized-block attacks.