EIP-7934 Final

RLP Execution Block Size Limit

Authors: , ,

Introduce a protocol-level cap on the maximum RLP-encoded block size to 10 MiB, including a 2 MiB margin for beacon block size.

Timeline

Fusaka

Included

EIP Created Apr 16, 2025

Key Benefits

● Prevents network instability from oversized blocks
● Reduces risk of denial-of-service attacks
● Improves block propagation efficiency
● Ensures compatibility with consensus layer limits

Trade-offs & Considerations

No trade-offs documented yet.

Stakeholder Impact

End Users

More reliable network with reduced risk of temporary forks and more consistent transaction confirmation times.

Application Developers

More predictable block propagation and reduced risk of network instability affecting transaction processing.

Wallet Developers

More reliable transaction confirmation times and reduced risk of network issues affecting wallet operations.

Tooling / Infrastructure

More predictable block sizes and network behavior, simplifying infrastructure planning and monitoring.

Layer 2s

More reliable base layer for settlement transactions with reduced risk of network instability.

Stakers & Node Operators

Need to implement block size validation, but benefit from more stable network propagation and reduced DoS risks.

CL Client Developers

Minimal impact as this primarily affects execution layer block validation and propagation.

EL Client Developers

Need to implement block size validation logic and ensure block construction respects the new size limits.

North Star Goal Alignment

● Improve UX: Improves network reliability and reduces the risk of temporary forks, leading to more consistent transaction confirmation times.

Abstract

This proposal introduces a protocol-level cap on the maximum RLP-encoded execution block size to 10 megabytes (MiB), which includes a margin of 2 MiB 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 2MiB 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)
- SAFETY_MARGIN set to 2MiB (2,097,152 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 = 2_097_152  # 2 MiB
MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN

# if true, the block is invalid and should be rejected/not get built
def exceed_max_rlp_block_size(block: Block) -> bool:
    return len(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.
Block Validation: Nodes must reject blocks whose RLP-encoded size exceeds MAX_RLP_BLOCK_SIZE.

Protocol Adjustment

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 2MiB 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.