Welcome to the next crypto level
← Nexorena

Ethereum

Ethereum EIP-7975 reaches its scheduled block-receipt review deadline

The receipt-pagination proposal lists November 1 as its Last Call deadline. It addresses communication between nodes and remains under review; the date proves neither deployment nor a consensus change.

Ethereum EIP-7975 reaches its scheduled block-receipt review deadline — original conceptual illustration

A deadline for transporting receipts

Ethereum technical proposal EIP-7975 lists November 1, 2026 as the deadline for its Last Call review phase. The document still carries that status when checked. Written by Felix Lange, Jochem Brouwer and Giulio Rebuffo, it was created on June 16, 2025. Sunday's development to follow is therefore this review deadline, rather than the creation of a proposal or an announcement of general activation.

The document concerns how node software exchanges transaction receipts. Its aim is to allow a receipt list to be downloaded in several parts instead of requiring it to fit into a single response. The change from communication protocol eth/69 to eth/70 describes that capability. By itself, it does not establish that every client or node already uses it.

Keeping a response within accepted message sizes

The authors explain that raising the block gas limit can increase the maximum size of block receipt lists. In some scenarios, a response could exceed the ten-mebibyte message limit commonly applied by clients. The document identifies a resulting risk of synchronization failure. It describes a potential message-size problem, without announcing an ongoing network-wide Ethereum outage or claiming that the limit has already been exceeded everywhere.

The mechanism adds a flag indicating whether the last returned list is incomplete. A node can then request the remaining receipts in another query, specifying where to resume for the first requested block. This pagination organizes the transfer; it neither removes receipts nor turns a partial response into a complete list. It lets the recipient continue retrieving data instead of depending on a single oversized message.

Partial data still requires checks

That flexibility also introduces additional attack surface. A partial list cannot immediately be checked in the same way as a complete list against the reference recorded in the block header. The proposal therefore specifies checks on the number of receipts, their size relative to the corresponding transaction's gas limit and the total volume allowed by the block gas limit. Splitting messages does not eliminate the need to bound data buffered before validation.

For compatibility, the authors say older clients can continue using eth/69 while the new version rolls out. They also state that this proposal does not change Ethereum Virtual Machine consensus rules and does not require a hard fork. That establishes neither automatic adoption nor a general rollout schedule. The next evidence to follow is the proposal's status and actual software support; the consultation date alone does not establish that the feature has gone live.

Written with love byOlivia ParkerMeet this editorial pen name ↗

Explorer Nexorena