EIP-5793 Add transaction type and size to transaction announcements (eth/68) (eth/68 - Add tx type to tx announcement)
Final · Networking & nodes · EIP status Final · created 2022-10-18
Upgrades the wire protocol to eth/68, changing the message nodes use to announce new transactions so that it carries the transaction's type and size along with the hash, instead of the hash alone.
Why it is needed
When an Ethereum node receives a new transaction, it announces it to its neighbor nodes (peers). The NewPooledTransactionHashes message used for this contains only the transaction hash (a unique identifier), so the receiver had to decide whether to fetch the transaction without knowing what kind it was or how large it was. The problem is large transactions such as the blob transactions introduced by EIP-4844. If such transactions are broadcast in full to a number of nodes equal to the square root of the peer count, as is done today, the network bandwidth burden can increase significantly. Adding type and size to the announcement lets a node fetch only the transactions it needs, throttle downloads from a specific peer based on past behavior, or balance the load. It also lays the groundwork for reducing the amplification effect of denial-of-service (DoS) attacks that abuse transaction propagation.
What changes
Today
- The transaction announcement message contains only the transaction hash.
- The receiving node must decide whether to fetch a transaction without knowing its type or size.
- Large transactions can be propagated in full to many peers just like any other transaction.
After EIP-5793
- The announcement message carries the transaction type and size along with the hash.
- The receiving node can request only the transactions it needs.
- Downloads of a specific type or of large transactions can be throttled per peer.
Who is affected
- Client teams: You must implement the eth/68 version. Multiple versions can be supported alongside the existing eth/67, so compatibility does not break immediately.
- Node operators: Large transactions can be selectively fetched, so bandwidth usage becomes more predictable.
- Ordinary users: This is an internal protocol change, so there is no directly noticeable difference, but it provides the foundation for the network to run stably in the era of blob transactions.
In depth
Message format change
This EIP changes the structure of the NewPooledTransactionHashes (0x08) message. In eth/67 the message was only a list of 32-byte hashes: [hash_0: B_32, hash_1: B_32, ...]. In eth/68 it is [types: B, [size_0: P, size_1: P, ...], [hash_0: B_32, hash_1: B_32, ...]], which sends the transaction types (types) and the size of each transaction (size_0, size_1, ...) together with the announced hashes. Transaction types follow the type system defined by EIP-2718.
Why types is a byte array and not a list
The types element is sent as a single byte array, not as a list of type values. This is less a design intent than a result of early implementations of this EIP mistakenly implementing it as a byte array. To minimize later rework, it was decided to keep this behavior as is.
Blob transactions and the bandwidth problem
EIP-4844 introduces a new transaction type, the blob transaction. Blob transactions are large, so broadcasting them as is to sqrt(peers) peers could greatly increase bandwidth requirements. Adding the type and size to the announcement lets a node choose which transactions to fetch, and makes per-peer load balancing or throttling possible based on past behavior.
Room for future adjustments without an upgrade
The added metadata fields open a path to adjust behavior in the future without bumping the protocol version again. One example is preventing transactions of a specific type (blob transactions) or above a certain size (128KB+) from being broadcast indiscriminately to many peers. If nodes are forced to send only an announcement and transmit the transaction only when a request arrives, networking behavior becomes far more predictable and the amplification effect of DoS attacks that abuse transaction propagation is limited.
Backward compatibility and rollout
This EIP changes the eth protocol, so a new version, eth/68, must be deployed. A wire protocol can support several versions at once, so even after the new version is released, old clients can keep using eth/67 and compatibility does not break immediately. The EVM consensus rules do not change, so no hard fork is needed, and the original text states that there are no separate security considerations. The status of this EIP is Final.