What
On eth/72, ethrex computes the announced size of a fully-held blob transaction from the full wrapped encoding (NewPooledTransactionHashes72::new builds P2PTransaction::EIP4844TransactionWithBlobs and takes encode_canonical_len(), crates/networking/p2p/rlpx/eth/eth72/transactions.rs), while the eth/72 serve path always emits the elided encoding (PooledTransactions72 encodes via encode_elided_canonical, same file). For a single-blob tx that is a ~137 KB announcement against a ~6 KB delivery.
This is deliberate today: our own receive side skips the size check for blob txs, with a comment stating exactly this asymmetry (PooledTransactions72::validate_requested: "Size validation skipped for blob txs: announced size reflects full-blob encoding while eth/72 elided encoding is smaller").
Why it is not (yet) a bug to fix
The devp2p spec does not say which size to announce — txsize is specified as the "consensus encoding", which no client announces (ethereum/devp2p#281). Current behavior is interop-safe only as long as other clients also skip the announced-vs-delivered check for blob txs on eth/72. Evidence the ecosystem is converging on elided-size announcements: reth is switching to the elided size (paradigmxyz/reth#26574). If any client starts enforcing the check on eth/72 (geth's fetcher enforces it on ≤ eth/71 with an 8-byte tolerance, see #7235), ethrex gets dropped for the mismatch on every blob tx it announces and serves.
Related, same incident family: #7235 (gone-bundle announce size), #7237 (elided bundle announced on pre-72 links).
Action
Blocked on ethereum/devp2p#281 resolving (or on measured evidence of a client enforcing the check on eth/72). When it resolves — most likely to the elided size:
- Switch
NewPooledTransactionHashes72::new to size blob txs from the elided encoding (encode_elided_canonical(...).len() + RLP string-header overhead), regardless of whether the bundle is held full or sparse.
- Re-enable the blob-tx size check in
PooledTransactions72::validate_requested (same 8-byte tolerance as the ≤71 path).
- Re-check the announced-size fields against whatever the spec text pins, and update the
validate_requested comment.
What
On eth/72, ethrex computes the announced size of a fully-held blob transaction from the full wrapped encoding (
NewPooledTransactionHashes72::newbuildsP2PTransaction::EIP4844TransactionWithBlobsand takesencode_canonical_len(),crates/networking/p2p/rlpx/eth/eth72/transactions.rs), while the eth/72 serve path always emits the elided encoding (PooledTransactions72encodes viaencode_elided_canonical, same file). For a single-blob tx that is a ~137 KB announcement against a ~6 KB delivery.This is deliberate today: our own receive side skips the size check for blob txs, with a comment stating exactly this asymmetry (
PooledTransactions72::validate_requested: "Size validation skipped for blob txs: announced size reflects full-blob encoding while eth/72 elided encoding is smaller").Why it is not (yet) a bug to fix
The devp2p spec does not say which size to announce —
txsizeis specified as the "consensus encoding", which no client announces (ethereum/devp2p#281). Current behavior is interop-safe only as long as other clients also skip the announced-vs-delivered check for blob txs on eth/72. Evidence the ecosystem is converging on elided-size announcements: reth is switching to the elided size (paradigmxyz/reth#26574). If any client starts enforcing the check on eth/72 (geth's fetcher enforces it on ≤ eth/71 with an 8-byte tolerance, see #7235), ethrex gets dropped for the mismatch on every blob tx it announces and serves.Related, same incident family: #7235 (gone-bundle announce size), #7237 (elided bundle announced on pre-72 links).
Action
Blocked on ethereum/devp2p#281 resolving (or on measured evidence of a client enforcing the check on eth/72). When it resolves — most likely to the elided size:
NewPooledTransactionHashes72::newto size blob txs from the elided encoding (encode_elided_canonical(...).len() + RLP string-header overhead), regardless of whether the bundle is held full or sparse.PooledTransactions72::validate_requested(same 8-byte tolerance as the ≤71 path).validate_requestedcomment.