EIP-8094 Blob-aware mempool (eth/vhash) (eth/vhash - Blob-Aware Mempool)
Hegota Declined for Inclusion · Networking & nodes · EIP status Draft · created 2025-11-29
Changes blob transactions to propagate first without the blob body (sidecar), with the body requested separately by blob hash (vhash). When only the fee is changed in a replacement (RBF), the same blobs are no longer downloaded again.
Why it is needed
In the current node-to-node protocol (devp2p eth/69), even when a blob transaction is resubmitted with only its fee changed (RBF, replace-by-fee), the whole thing is propagated again including the blob body, just like a new transaction. This is because the receiver has no way to know the content is nearly identical until it has received everything. The problem is that RBF is most often used when fees spike, that is, when the network is already overloaded. Traffic that recirculates already distributed blob content is added at a time of high demand and makes things worse. This EIP lets a blob be referenced by vhash, a content-based identifier, so a blob that a node already has does not need to be downloaded again.
What changes
Today
- Blob transactions are propagated whole, together with the blob body (sidecar)
- A replacement that changes only the fee (RBF) costs the network the same as a new transaction
- The receiver cannot tell whether the content is the same until it has received everything
- When replacements pile up during a fee spike, propagation traffic surges with them
After EIP-8094
- Blob transactions are propagated first without the sidecar
- The blob body is requested separately, referencing the vhash, with a new message GetPooledBlobs
- A blob that a node already has (same vhash) is not downloaded again
- A replacement that changes only the fee needs to recirculate only the small transaction data
Who is affected
- Client teams: A new version of the eth protocol must be implemented. Two new messages (GetPooledBlobs, PooledBlobs) and logic for sending the sidecar separately are added.
- L2s and blob users: When you raise the fee of a blob transaction and resubmit it during fee volatility, the network burden is lower, so replacements are handled more efficiently.
- Node operators: Blob traffic, especially duplicate transmission during fee spikes, is reduced, so bandwidth consumption decreases.
In depth
Type 3 transactions sent without sidecars
The existing Transactions (0x02) and PooledTransactions (0x0a) messages are changed so that type 3 (blob) transactions are sent without the sidecar. A type 3 transaction with the blob body removed is small, so it can be propagated by push like an ordinary transaction.
New messages GetPooledBlobs / PooledBlobs
GetPooledBlobs has the form [request-id: P, [vhash₁: B_32, vhash₂: B_32, ...]] and requests blobs by vhash from the peer's transaction pool. PooledBlobs has the form [request-id: P, [blob₁, blob₂...]] and returns the requested blobs. Blobs must be in the same order as the request, but missing blobs may be skipped. The recipient has to check the blob hashes against the vhashes anyway, so the response does not carry the vhash list again. The message codes are not yet decided, and options such as a blob version prefix, a sent/not-sent bitmap, and the field layout for RS-encoding reconstruction (for version 1, the blob contents without the erasure-code extension, the commitments, and the cell proofs) remain open in the notes.
Changes to the EIP-4844 propagation rules
EIP-4844 specified that blob transactions must not be broadcast automatically, but announced with NewPooledTransactionHashes and sent on request. This EIP changes that: nodes MUST either broadcast blob transactions without the sidecar or announce them with NewPooledTransactionHashes, and blob contents are requested with GetPooledBlobs. A node MUST NOT forward a blob transaction until it has received and verified all of its blobs.
Why vhash and not a sidecar hash
There were two candidate identifiers: a per-blob vhash and a hash of the whole sidecar. A sidecar hash is a single element, which makes the message simpler, but it requires a new identifier (the vhash is already an established identifier outside devp2p) and it makes it impossible to reconstruct messages, for example by splitting blobs and sending fewer of them during a fee spike. So the vhash is used.
Option 3 chosen among three implementation options
Option 1 puts the vhash in the announcement and lets the receiver request the sidecar with or without inclusion, or a partial selection. Option 2, like EIP-8077, puts the nonce in the announcement and assumes a replacement if the receiver already holds a sidecar with the same nonce. The chosen Option 3 pushes type 3 transactions without the sidecar (or announces them and lets peers pull), and the sidecar is requested separately with a new message. It looks like it adds one round trip (RTT) per hop, but a type 3 transaction without its sidecar is mostly small enough to be pushed, and only receivers that need the blobs have to request them. Forwarding is forbidden until the sidecar has been received and verified.
Relation to EIP-8077 and EIP-8070
It can be combined with EIP-8077 (source and nonce announcements) in a straightforward way. EIP-8070 (sparse blobpool) changes the same blob propagation area but has a different goal. 8070 aims at proportional bandwidth savings in normal operation, while this EIP aims at RBF with no extra bandwidth. The two can be combined, but the way to combine them depends on the order in which they are adopted, so the original leaves it as a TODO.
Backward compatibility
A new version of the eth wire protocol must be deployed, but supporting several versions at once is common practice, so older clients can keep using the previous version. It does not change EVM consensus rules, so no hard fork is needed.
Status of the original and fork discussion history
The status of the original is Draft, so the specification may still change. TODOs remain, such as message code assignment and the blob format options. In fork discussions, it was accepted as a Hegotá candidate (PFI) at ACDE #243 on 08.13, but was declined (DFI) at ACDE #245 on 09.10. The author also agreed with the exclusion, saying that most of the core features had already been absorbed into the sparse blobpool.