Message inventory
| Type | Purpose |
|---|---|
Transactions |
Sends complete transactions without a request. |
NewPooledTransactionHashes |
Announces transaction types, encoded sizes, and hashes. |
GetPooledTransactions |
Requests pool transactions by hash. |
PooledTransactions |
Returns available transactions in request order. |
GetPooledTransactions and its response use a 64-bit request ID. The
recommended request limit is 256 hashes. A peer can return less data because of
local size or service-time limits.
Announcement and retrieval
A node announces pool transactions that the peer is not known to have. The receiver removes known hashes and requests the missing transactions.
The type, size, and hash arrays have equal length. The size is the transaction's consensus encoding size, including its type byte when it is typed.
PooledTransactions preserves request order but can skip unavailable items.
Items before the last returned item that are absent are unavailable. A missing
suffix can mean that the response reached a local limit.
Direct relay
Transactions contains at least one new complete transaction. A node does not
send the same transaction twice to one peer in one session. It also does not
relay a transaction back to the peer that supplied it.
Clients usually send complete non-blob transactions to a small peer set and announce hashes to the remaining peers. EIP-4844 says that nodes must not automatically broadcast blob transactions; peers announce their hashes and request the data.
Blob transactions
EIP-4844 defined the type-3 network wrapper as the transaction payload, blobs, commitments, and proofs, with equal counts and KZG commitments bound to the transaction's versioned hashes.
Blob transactions are announced by hash and fetched with
GetPooledTransactions; nodes do not send them in unsolicited Transactions.
The blob transaction data page keeps the in-progress
eth/72 cell exchange separate from this current contract.
Validation
A receiver checks transaction encoding, signature, sender, intrinsic gas, fee fields, chain ID, nonce policy, and transaction-type rules. Pool admission can also apply local price and resource policy.
Consensus-invalid data and local pool rejection are different outcomes. A valid transaction can still be unwanted because it is underpriced, duplicated, or outside the node's pool limits.
Failure handling
- Reject mismatched type, size, and hash array lengths.
- Discard malformed or consensus-invalid transactions. The eth specification normally does not require disconnecting a peer for an invalid transaction.
- Accept an empty response only when no requested item is available.
- Do not treat response truncation as a protocol breach.
- Do not resend known transactions in the same peer session.
Design rationale
Hash announcements reduce duplicate bandwidth. Explicit type and size fields let a receiver allocate resources before it requests full transactions.
History
eth/65 added pooled-transaction announcements and requests. eth/68 added type and size metadata. EIP-4844 added the blob-transaction network wrapper.