---
eip: 5793
title: eth/68 - Add tx type to tx announcement
description: Adds the transaction type and transaction size to tx announcement messages in the wire protocol
author: Marius van der Wijden (@MariusVanDerWijden)
discussions-to: https://ethereum-magicians.org/t/eip-5793-eth-68-add-transaction-type-to-tx-announcement/11364
status: Review
type: Standards Track
category: Networking
created: 2022-10-18
requires: 2464, 2481, 4938
---

## Abstract

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](./eip-2718.md)) as well.

## Motivation

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

[EIP-4844](./eip-4844.md) 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.

## Specification

Modify the `NewPooledTransactionHashes (0x08)` message:

* **(eth/67)**: `[hash_0: B_32, hash_1: B_32, ...]`
* **(eth/68)**: `[[type_0: B_1, type_1: B_1, ...], [size_0: B_4, size_1: B_4, ...], [hash_0: B_32, hash_1: B_32, ...]]`

## Rationale

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.

## 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

None

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).