From c26fc4eaa2e82f1cc7e54b779142db72360aec0f Mon Sep 17 00:00:00 2001 From: Csaba Kiraly Date: Sat, 29 Nov 2025 12:26:40 +0100 Subject: [PATCH 1/7] Add EIP: eth/vhash - make mempool messaging vhash aware MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This EIP eliminates the need to redistribute blob content in the mempool if only the metadata (fees) of a transaction are updated, making RBF (replace-by-fee) more efficient and cheaper for the network. It achieves this modifying the devp2p ‘eth’ protocol to address blobs in type3 transaction sidecars by content (vhash). Signed-off-by: Csaba Kiraly --- EIPS/eip-eth-vhash.md | 172 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 EIPS/eip-eth-vhash.md diff --git a/EIPS/eip-eth-vhash.md b/EIPS/eip-eth-vhash.md new file mode 100644 index 00000000000000..fffa535733ad6f --- /dev/null +++ b/EIPS/eip-eth-vhash.md @@ -0,0 +1,172 @@ +--- +eip: TBD +title: eth/vhash - eth/XX - blob-aware mempool +description: Make mempool messaging vhash aware +author: Csaba Kiraly (@cskiraly) +discussions-to: +status: Draft +type: Standards Track +category: Networking +created: 2025-11-29 +requires: 7642 +--- + +## Abstract + +This EIP eliminates the need to redistribute blob content in the mempool if +only the metadata (fees) of a transaction are updated, making RBF +(replace-by-fee) more efficient and cheaper for the network. It achieves this +modifying the devp2p ‘eth’ protocol to address blobs in type3 transaction +sidecars by content (vhash). + +## Motivation + +In the current version of devp2p eth/69, when a transaction is replaced, it +must be redistributed in the mempool like any new transaction. Even if the +actual content is largely the same, protocol participants have no means to +figure this out before getting the full content, making a replacement use the +same amount of network resources as a new transaction would. + +What is especially problematic is that RBF is used most in periods of fee +volatility, and a network overload is the typical case of such a situation. +Thus, when there is already high demand, we make the situation worse by adding +extra traffic redistributing blob content that was already distributed. + +## Specification + +### Transactions (0x02) changes + +Type 3 transaction should be sent without sidecar + +### PooledTransactions (0x0a) changes + +Type 3 transaction should be sent without sidecar + +### GetPooledBlobs (msg code TBA) + +[request-id: P, [vhash₁: B_32, vhash₂: B_32, ...]] + +This message requests blobs from the recipient's transaction pool by vhash. + +### PooledBlobs (msg code TBA) + +[request-id: P, [blob₁, blob₂...]] + +This is the response to GetPooledBlobs, returning the requested blobs. The +items in the list are blobs in the format described in the main Ethereum +specification. + +> Note: optionally, we might prefix the blob format with the blob version number + +> Note: optionally, we might decide to improve the blob format allowing nodes +to reconstruct RS encoding instead of using extra bandwidth, by sending the +following fields per blob: +> - blob version +> - blob content, **excluding** the erasure coding extension in case of version 1 +> - blob commitment +> - blob proof(s), **including** cell proofs of the erasure coded piece in case +of version 1 +> +> It is important to include all cell proofs to keep reconstruction +CPU-efficient. + +The blobs must be in the same order as in the request, but it is OK to skip +blobs which are not available. Since the recipient have to check that +transmitted blob hashes correspond to the requested vhashes anyway, we can +avoid sending the list of vhashes as part of this message. + +> Note: Optionally, we could extend this message with a bitmap of sent/unsent +blobs from the request, or with the list of vhashes sent. This information is +redundant, but it can simplify processing on the receiver side. + +### Other spec changes + +EIP-4844 introduced the following: + + Nodes MUST NOT automatically broadcast blob transactions to their peers. + Instead, those transactions are only announced using + NewPooledTransactionHashes messages, and can then be manually requested + via GetPooledTransactions. + +The above should be changed as follows: + + Nodes MUST send (broadcast or send in NewPooledTransactionHashes) blob + transactions **without** sidecars to their peers. Peers can then request + blob content using `GetPooledBlobs` messages. Nodes MUST NOT forward blob + transactions before receiving and validating all blobs". + +## Rationale + +A typical blob transaction RBF changes the fees only, while the sidecar (blob +content) remains the same. If a node that has the previous version would know +this, it could avoid pulling the sidecar, largely reducing bandwidth +consumption. However, this is not possible with the current messaging. To make +this happen, we have to expose blob (or at least sidecar) identifiers in +mempool messaging. + +### Should we use blob identifiers or a sidecar identifier? +We can either use vhashes, or a sidecar level hash. The latter has the slight +advantage of being a single element, thus simplifying message format, but it +has several disadvantages: +- It would be a new identifier, while the blob level vhash is already well +established (just not in devp2p) +- It would not allow restructuring the message, sending e.g. less blobs under a +fee surge + +Thus, we use vhashes. + +### Implementation options + +There are several options to bring vhashes to devp2p messaging: + +#### Option 1 +- Extend announcements with vhashes +- Allow nodes to request transaction with/without sidecar content, or even +selecting which parts are needed (bitmap or vhash list) + +#### Option 2 +- Extend announcements with nonce (see EIP-8077) +- If hash differs from what we have, request with/without sidecar content based +on whether we already have the sidecars for the same nonce, assuming this is a +simple replacement +- Request again with sidecar if vhashes differ + +#### Option 3 (selected) +- Push (or announce and then pull) type 3 transaction **without sidecar** +- Allow to **request sidecar separately** (new message type) + +At first it might seem that Option 3 is slowing down distribution, adding one +more RTT latency per hop. However, since most type 3 transactions are small +without a sidecar, we could change the protocol behaviour to allow pushing +these transactions without the sidecar, leaving it to the receiver of the push +to ask for the blobs if needed. Forwarding of type3 transactions without +sidecar should be prohibited until sidecars are fetched and the content can be +verified. + +After considering the above options, we chose to propose Option 3, introducing +a new message type. + +### Relation to other EIPs in draft state +- EIP-8077 (announce source and nonce): the changes can be simply combined. +- EIP-8070 (Sparse blobpool): both EIPs change how blob transactions are +propagated over the network. The goal of the two EIPs are different. EIP-8070 +is about a proportional bandwidth reduction in the normal case without dealing +with specifics of RBF. This EIP is about enabling RBF without using extra +bandwidth. The two EIPs can be combined, but the combination depends on the +order of introduction, hence we leave this for later. + +## Backwards Compatibility + +This EIP changes the eth protocol and requires rolling out a new version. +Supporting multiple versions of a wire protocol is routine practice. Rolling +out this new version does not break older clients, since they can keep using +the previous protocol version. + +This EIP does not change consensus rules of the EVM and does not require a hard +fork. + +## Security Considerations + +## Copyright + +Copyright and related rights waived via CC0. From 27c246dc1966cdaf93379a6607aecfcfa13f1f45 Mon Sep 17 00:00:00 2001 From: Csaba Kiraly Date: Sat, 29 Nov 2025 12:38:20 +0100 Subject: [PATCH 2/7] update title Signed-off-by: Csaba Kiraly --- EIPS/eip-eth-vhash.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-eth-vhash.md b/EIPS/eip-eth-vhash.md index fffa535733ad6f..ec1b20a04efbf6 100644 --- a/EIPS/eip-eth-vhash.md +++ b/EIPS/eip-eth-vhash.md @@ -1,6 +1,6 @@ --- eip: TBD -title: eth/vhash - eth/XX - blob-aware mempool +title: eth/vhash - blob-aware mempool description: Make mempool messaging vhash aware author: Csaba Kiraly (@cskiraly) discussions-to: From 36c3248dbd2e57ba9443bd3f80028abea672eedd Mon Sep 17 00:00:00 2001 From: Csaba Kiraly Date: Tue, 2 Dec 2025 17:58:32 +0100 Subject: [PATCH 3/7] rename to EIP-8094 Signed-off-by: Csaba Kiraly --- EIPS/{eip-eth-vhash.md => eip-8094.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename EIPS/{eip-eth-vhash.md => eip-8094.md} (99%) diff --git a/EIPS/eip-eth-vhash.md b/EIPS/eip-8094.md similarity index 99% rename from EIPS/eip-eth-vhash.md rename to EIPS/eip-8094.md index ec1b20a04efbf6..271ffd9b20de5a 100644 --- a/EIPS/eip-eth-vhash.md +++ b/EIPS/eip-8094.md @@ -1,5 +1,5 @@ --- -eip: TBD +eip: 8094 title: eth/vhash - blob-aware mempool description: Make mempool messaging vhash aware author: Csaba Kiraly (@cskiraly) From d26faf8ad769a16130cc3563b17ace6748928033 Mon Sep 17 00:00:00 2001 From: Csaba Kiraly Date: Tue, 2 Dec 2025 17:59:45 +0100 Subject: [PATCH 4/7] adding discussion link Signed-off-by: Csaba Kiraly --- EIPS/eip-8094.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-8094.md b/EIPS/eip-8094.md index 271ffd9b20de5a..52f485bb223f3e 100644 --- a/EIPS/eip-8094.md +++ b/EIPS/eip-8094.md @@ -3,7 +3,7 @@ eip: 8094 title: eth/vhash - blob-aware mempool description: Make mempool messaging vhash aware author: Csaba Kiraly (@cskiraly) -discussions-to: +discussions-to: https://ethereum-magicians.org/t/eip-8094-eth-vhash-blob-aware-mempool/26834 status: Draft type: Standards Track category: Networking From 7fed7122cb0d5efba96e85108b11d3b86a75746f Mon Sep 17 00:00:00 2001 From: Csaba Kiraly Date: Tue, 2 Dec 2025 17:59:59 +0100 Subject: [PATCH 5/7] caps Signed-off-by: Csaba Kiraly --- EIPS/eip-8094.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-8094.md b/EIPS/eip-8094.md index 52f485bb223f3e..2684d19b975a7d 100644 --- a/EIPS/eip-8094.md +++ b/EIPS/eip-8094.md @@ -1,6 +1,6 @@ --- eip: 8094 -title: eth/vhash - blob-aware mempool +title: eth/vhash - Blob-Aware Mempool description: Make mempool messaging vhash aware author: Csaba Kiraly (@cskiraly) discussions-to: https://ethereum-magicians.org/t/eip-8094-eth-vhash-blob-aware-mempool/26834 From 50c7d146ae29f201cddce54165ebd08a5b30790e Mon Sep 17 00:00:00 2001 From: Csaba Kiraly Date: Tue, 2 Dec 2025 18:06:49 +0100 Subject: [PATCH 6/7] markdownlint Signed-off-by: Csaba Kiraly --- EIPS/eip-8094.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-8094.md b/EIPS/eip-8094.md index 2684d19b975a7d..566653445c84b7 100644 --- a/EIPS/eip-8094.md +++ b/EIPS/eip-8094.md @@ -57,15 +57,16 @@ items in the list are blobs in the format described in the main Ethereum specification. > Note: optionally, we might prefix the blob format with the blob version number - +> > Note: optionally, we might decide to improve the blob format allowing nodes to reconstruct RS encoding instead of using extra bandwidth, by sending the following fields per blob: +> > - blob version > - blob content, **excluding** the erasure coding extension in case of version 1 > - blob commitment > - blob proof(s), **including** cell proofs of the erasure coded piece in case -of version 1 +of version 1 > > It is important to include all cell proofs to keep reconstruction CPU-efficient. @@ -105,11 +106,13 @@ this happen, we have to expose blob (or at least sidecar) identifiers in mempool messaging. ### Should we use blob identifiers or a sidecar identifier? + We can either use vhashes, or a sidecar level hash. The latter has the slight advantage of being a single element, thus simplifying message format, but it has several disadvantages: + - It would be a new identifier, while the blob level vhash is already well -established (just not in devp2p) +established (just not in devp2p) - It would not allow restructuring the message, sending e.g. less blobs under a fee surge @@ -120,11 +123,13 @@ Thus, we use vhashes. There are several options to bring vhashes to devp2p messaging: #### Option 1 + - Extend announcements with vhashes - Allow nodes to request transaction with/without sidecar content, or even selecting which parts are needed (bitmap or vhash list) #### Option 2 + - Extend announcements with nonce (see EIP-8077) - If hash differs from what we have, request with/without sidecar content based on whether we already have the sidecars for the same nonce, assuming this is a @@ -132,6 +137,7 @@ simple replacement - Request again with sidecar if vhashes differ #### Option 3 (selected) + - Push (or announce and then pull) type 3 transaction **without sidecar** - Allow to **request sidecar separately** (new message type) @@ -147,6 +153,7 @@ After considering the above options, we chose to propose Option 3, introducing a new message type. ### Relation to other EIPs in draft state + - EIP-8077 (announce source and nonce): the changes can be simply combined. - EIP-8070 (Sparse blobpool): both EIPs change how blob transactions are propagated over the network. The goal of the two EIPs are different. EIP-8070 From 7cbb8d6f0abd3e35eb9126fe02465e21a3f35471 Mon Sep 17 00:00:00 2001 From: Csaba Kiraly Date: Fri, 5 Dec 2025 12:21:28 +0100 Subject: [PATCH 7/7] editorial fixes - line wrap - TODO tag - type3 -> type 3 Signed-off-by: Csaba Kiraly --- EIPS/eip-8094.md | 103 +++++++++++------------------------------------ 1 file changed, 24 insertions(+), 79 deletions(-) diff --git a/EIPS/eip-8094.md b/EIPS/eip-8094.md index 566653445c84b7..080068faf9d945 100644 --- a/EIPS/eip-8094.md +++ b/EIPS/eip-8094.md @@ -13,23 +13,13 @@ requires: 7642 ## Abstract -This EIP eliminates the need to redistribute blob content in the mempool if -only the metadata (fees) of a transaction are updated, making RBF -(replace-by-fee) more efficient and cheaper for the network. It achieves this -modifying the devp2p ‘eth’ protocol to address blobs in type3 transaction -sidecars by content (vhash). +This EIP eliminates the need to redistribute blob content in the mempool if only the metadata (fees) of a transaction are updated, making RBF (replace-by-fee) more efficient and cheaper for the network. It achieves this modifying the devp2p ‘eth’ protocol to address blobs in type 3 transaction sidecars by content (vhash). ## Motivation -In the current version of devp2p eth/69, when a transaction is replaced, it -must be redistributed in the mempool like any new transaction. Even if the -actual content is largely the same, protocol participants have no means to -figure this out before getting the full content, making a replacement use the -same amount of network resources as a new transaction would. +In the current version of devp2p eth/69, when a transaction is replaced, it must be redistributed in the mempool like any new transaction. Even if the actual content is largely the same, protocol participants have no means to figure this out before getting the full content, making a replacement use the same amount of network resources as a new transaction would. -What is especially problematic is that RBF is used most in periods of fee -volatility, and a network overload is the typical case of such a situation. -Thus, when there is already high demand, we make the situation worse by adding +What is especially problematic is that RBF is used most in periods of fee volatility, and a network overload is the typical case of such a situation. Thus, when there is already high demand, we make the situation worse by adding extra traffic redistributing blob content that was already distributed. ## Specification @@ -42,79 +32,53 @@ Type 3 transaction should be sent without sidecar Type 3 transaction should be sent without sidecar -### GetPooledBlobs (msg code TBA) +### GetPooledBlobs (msg code to be assigned <-- TODO -->) [request-id: P, [vhash₁: B_32, vhash₂: B_32, ...]] This message requests blobs from the recipient's transaction pool by vhash. -### PooledBlobs (msg code TBA) +### PooledBlobs (msg code to be assigned <-- TODO -->) [request-id: P, [blob₁, blob₂...]] -This is the response to GetPooledBlobs, returning the requested blobs. The -items in the list are blobs in the format described in the main Ethereum -specification. +This is the response to GetPooledBlobs, returning the requested blobs. The items in the list are blobs in the format described in the main Ethereum specification. > Note: optionally, we might prefix the blob format with the blob version number > -> Note: optionally, we might decide to improve the blob format allowing nodes -to reconstruct RS encoding instead of using extra bandwidth, by sending the -following fields per blob: +> Note: optionally, we might decide to improve the blob format allowing nodes to reconstruct RS encoding instead of using extra bandwidth, by sending the following fields per blob: > > - blob version > - blob content, **excluding** the erasure coding extension in case of version 1 > - blob commitment -> - blob proof(s), **including** cell proofs of the erasure coded piece in case -of version 1 +> - blob proof(s), **including** cell proofs of the erasure coded piece in case of version 1 > -> It is important to include all cell proofs to keep reconstruction -CPU-efficient. +> It is important to include all cell proofs to keep reconstruction CPU-efficient. -The blobs must be in the same order as in the request, but it is OK to skip -blobs which are not available. Since the recipient have to check that -transmitted blob hashes correspond to the requested vhashes anyway, we can -avoid sending the list of vhashes as part of this message. +The blobs must be in the same order as in the request, but it is OK to skip blobs which are not available. Since the recipient have to check that transmitted blob hashes correspond to the requested vhashes anyway, we can avoid sending the list of vhashes as part of this message. -> Note: Optionally, we could extend this message with a bitmap of sent/unsent -blobs from the request, or with the list of vhashes sent. This information is -redundant, but it can simplify processing on the receiver side. +> Note: Optionally, we could extend this message with a bitmap of sent/unsent blobs from the request, or with the list of vhashes sent. This information is redundant, but it can simplify processing on the receiver side. ### Other spec changes EIP-4844 introduced the following: - Nodes MUST NOT automatically broadcast blob transactions to their peers. - Instead, those transactions are only announced using - NewPooledTransactionHashes messages, and can then be manually requested - via GetPooledTransactions. + Nodes MUST NOT automatically broadcast blob transactions to their peers. Instead, those transactions are only announced using NewPooledTransactionHashes messages, and can then be manually requested via GetPooledTransactions. The above should be changed as follows: - Nodes MUST send (broadcast or send in NewPooledTransactionHashes) blob - transactions **without** sidecars to their peers. Peers can then request - blob content using `GetPooledBlobs` messages. Nodes MUST NOT forward blob - transactions before receiving and validating all blobs". + Nodes MUST send (broadcast or send in NewPooledTransactionHashes) blob transaction **without** sidecars to their peers. Peers can then request blob content using `GetPooledBlobs` messages. Nodes MUST NOT forward blob transactions before receiving and validating all blobs". ## Rationale -A typical blob transaction RBF changes the fees only, while the sidecar (blob -content) remains the same. If a node that has the previous version would know -this, it could avoid pulling the sidecar, largely reducing bandwidth -consumption. However, this is not possible with the current messaging. To make -this happen, we have to expose blob (or at least sidecar) identifiers in -mempool messaging. +A typical blob transaction RBF changes the fees only, while the sidecar (blob content) remains the same. If a node that has the previous version would know this, it could avoid pulling the sidecar, largely reducing bandwidth consumption. However, this is not possible with the current messaging. To make this happen, we have to expose blob (or at least sidecar) identifiers in mempool messaging. ### Should we use blob identifiers or a sidecar identifier? -We can either use vhashes, or a sidecar level hash. The latter has the slight -advantage of being a single element, thus simplifying message format, but it -has several disadvantages: +We can either use vhashes, or a sidecar level hash. The latter has the slight advantage of being a single element, thus simplifying message format, but it has several disadvantages: -- It would be a new identifier, while the blob level vhash is already well -established (just not in devp2p) -- It would not allow restructuring the message, sending e.g. less blobs under a -fee surge +- It would be a new identifier, while the blob level vhash is already well established (just not in devp2p) +- It would not allow restructuring the message, sending e.g. less blobs under a fee surge Thus, we use vhashes. @@ -125,15 +89,12 @@ There are several options to bring vhashes to devp2p messaging: #### Option 1 - Extend announcements with vhashes -- Allow nodes to request transaction with/without sidecar content, or even -selecting which parts are needed (bitmap or vhash list) +- Allow nodes to request transaction with/without sidecar content, or even selecting which parts are needed (bitmap or vhash list) #### Option 2 - Extend announcements with nonce (see EIP-8077) -- If hash differs from what we have, request with/without sidecar content based -on whether we already have the sidecars for the same nonce, assuming this is a -simple replacement +- If hash differs from what we have, request with/without sidecar content based on whether we already have the sidecars for the same nonce, assuming this is a simple replacement - Request again with sidecar if vhashes differ #### Option 3 (selected) @@ -141,36 +102,20 @@ simple replacement - Push (or announce and then pull) type 3 transaction **without sidecar** - Allow to **request sidecar separately** (new message type) -At first it might seem that Option 3 is slowing down distribution, adding one -more RTT latency per hop. However, since most type 3 transactions are small -without a sidecar, we could change the protocol behaviour to allow pushing -these transactions without the sidecar, leaving it to the receiver of the push -to ask for the blobs if needed. Forwarding of type3 transactions without -sidecar should be prohibited until sidecars are fetched and the content can be -verified. +At first it might seem that Option 3 is slowing down distribution, adding one more RTT latency per hop. However, since most type 3 transactions are small without a sidecar, we could change the protocol behaviour to allow pushing these transactions without the sidecar, leaving it to the receiver of the push to ask for the blobs if needed. Forwarding of type 3 transactions without sidecar should be prohibited until sidecars are fetched and the content can be verified. -After considering the above options, we chose to propose Option 3, introducing -a new message type. +After considering the above options, we chose to propose Option 3, introducing a new message type. ### Relation to other EIPs in draft state - EIP-8077 (announce source and nonce): the changes can be simply combined. -- EIP-8070 (Sparse blobpool): both EIPs change how blob transactions are -propagated over the network. The goal of the two EIPs are different. EIP-8070 -is about a proportional bandwidth reduction in the normal case without dealing -with specifics of RBF. This EIP is about enabling RBF without using extra -bandwidth. The two EIPs can be combined, but the combination depends on the -order of introduction, hence we leave this for later. +- EIP-8070 (Sparse blobpool): both EIPs change how blob transactions are propagated over the network. The goal of the two EIPs are different. EIP-8070 is about a proportional bandwidth reduction in the normal case without dealing with specifics of RBF. This EIP is about enabling RBF without using extra bandwidth. The two EIPs can be combined, but the combination depends on the order of introduction, hence we leave this for later <-- TODO -->. ## Backwards Compatibility -This EIP changes the eth protocol and requires rolling out a new version. -Supporting multiple versions of a wire protocol is routine practice. Rolling -out this new version does not break older clients, since they can keep using -the previous protocol version. +This EIP changes the eth protocol and requires rolling out a new version. Supporting multiple versions of a wire protocol is routine practice. Rolling out this new version does not break older clients, since they can keep using the previous protocol version. -This EIP does not change consensus rules of the EVM and does not require a hard -fork. +This EIP does not change consensus rules of the EVM and does not require a hard fork. ## Security Considerations