eth/68 - Add tx type to tx announcement

Adds the transaction type and transaction size to tx announcement messages in the wire protocol
FinalStandards Track: Networking
Created: 2022-10-18
Requires: EIP-2464, EIP-2481, EIP-4938
Marius van der Wijden (@MariusVanDerWijden)
DiscussionsOriginal linkEdit
1 min read

EIP-5793 proposes adding a new version of the Ethereum wire protocol, eth/68, that includes a new field for transaction type in the transaction announcement message. This change will make the protocol future-proof for new transaction types and give receiving nodes better control over the data they fetch from peers. The change does not require a hard fork and is backwards compatible with older clients that can continue using protocol version eth/67. There are no security considerations associated with this proposal.

Anyone may contribute to propose contents.
Go propose


The Ethereum Wire Protocol defines request and response messages for exchanging data between clients. The NewPooledTransactionHashes message announces transactions available in the node. This EIP extends this announcement message such that beside the transaction hashes, the node sends the transaction types and their sizes (as defined in EIP-2718) as well.


The NewPooledTransactionHashes message announces transaction hashes, allowing the peer to selectively fetch transactions it does not yet have.

EIP-4844 introduces a new transaction type for blob transactions. Since these blob transactions are large, naively broadcasting them to sqrt(peers) could significantly increase bandwidth requirements. Adding the transaction type and the size to the announcement message will allow nodes to select which transactions they want to fetch and also allow them to load balance or throttle peers based on past behavior.

The added metadata fields will also enable future - upgradeless - protocol tweaks to prevent certain transaction type (e.g. blob transactions) or certain transaction sizes (e.g. 128KB+) from being blindly broadcast to many peers. Enforcing announcements only and retrieval on demand would ensure a much more predictable networking behavior, limiting the amplification effect of transaction propagation DoS attack.


Modify the NewPooledTransactionHashes (0x08) message:

  • (eth/67): [hash_0: B_32, hash_1: B_32, ...]
  • (eth/68): [types: B, [size_0: P, size_1: P, ...], [hash_0: B_32, hash_1: B_32, ...]]

The new types element refers to the transaction types of the announced hashes. Note the transaction types are packed as a 'byte array' instead of a list.

The size_0, size_1 etc. elements refer to the transaction sizes of the announced hashes.


This change will make the eth protocol future-proof for new transaction types that might not be relevant for all nodes. It gives the receiving node better control over the data it fetches from the peer as well as allow throttling the download of specific types.

The types message element is a byte array because early implementations of this EIP erroneously implemented it that way. It was later decided to keep this behavior in order to minimize work.

Backwards Compatibility

This EIP changes the eth protocol and requires rolling out a new version, eth/68. Supporting multiple versions of a wire protocol is possible. Rolling out a new version does not break older clients immediately, since they can keep using protocol version eth/67.

This EIP does not change consensus rules of the EVM and does not require a hard fork.

Security Considerations


Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve Ethereum Builders, Scale the Community.
Supported by