# EIP-2976: eth/##: Typed Transactions over Gossip Source

Author Micah Zoltu https://ethereum-magicians.org/t/eip-2976-eth-typed-transactions-over-gossip/4610 Draft Standards Track Networking 2020-09-13 2718

## Simple Summary

Adds support for transmission of typed transactions over devp2p.

## Abstract

Typed Transactions can be sent over devp2p as TransactionType || TransactionPayload. The exact contents of the TransactionPayload are defined by the TransactionType in future EIPs, and clients may start supporting their gossip without incrementing the devp2p version. If a client receives a TransactionType that it doesn’t recognize, it should disconnect from the peer who sent it.

## Motivation

EIP-2718 introduced new transaction types for blocks (which presents itself in the makeup of a block header’s transaction root and receipts root). However, without a mechanism for gossiping these transactions, no one can actually include them in a block. By updating devp2p to support the gossip of Typed Transactions, we can benefit from these new transaction types.

Note: See EIP-2718 for additional motivations of Typed Transactions.

## Specification

All changes specified below apply to the eth/TBD protocol/version and newer.

### Definitions

• DEVP2P_VERSION = TBD
• Transaction is either TypedTransaction or LegacyTransaction
• TypedTransaction is a byte array containing TransactionType || TransactionPayload
• TransactionType is a positive unsigned 8-bit number between 0 and 0x7f that represents the type of the transcation
• TransactionPayload is an opaque byte array whose interpretation is dependent on the TransactionType and defined in future EIPs
• LegacyTransaction is an RLP encoded array of the form [nonce, gasPrice, gasLimit, to, value, data, v, r, s]
• TransactionHash is keccak256(TypedTransaction) or keccak256(LegacyTransaction)

### Protocol Behavior

If a client receives a TransactionType it doesn’t recognize via any message, it SHOULD disconnect the peer that sent it.

If a client receives a TransactionPayload that isn’t valid for the TransactionType, it SHOULD disconnect the peer that sent it.

Clients SHOULD NOT start propagating transactions of a new TransactionType until that transaction’s fork block is reached to avoid being disconnected by their peers.

### Protocol Messages

Transactions (0x02): [Transaction_0, Transaction_1, ..., Transaction_n]

BlockBodies (0x06): [BlockBody_0, BlockBody_1, ..., BlockBody_n] where:

• BlockBody is [TransactionList, UncleList]
• TransactionList is [Transaction_0, Transaction_1, ..., Transaction_n]
• UnclesList is defined in previous versions of the devp2p specification

NewBlock (0x07): [[BlockHeader, TransactionList, UncleList], TotalDifficulty] where:

• BlockHeader is defined in previous versions of the devp2 specification
• TransactionList is [Transaction_0, Transaction_1, ..., Transaction_n]
• UnclesList is defined in previous versions of the devp2p specification
• TotalDifficulty is defined in previous versions of the devp2p specification

NewPooledTransactionHashes (0x08): [TransactionHash_0, TransactionHash_1, ..., TransactionHash_n]

GetPooledTransactions (0x09): [TransactionHash_0, TransactionHash_1, ..., TransactionHash_n]

PooledTransactions (0x0a): [Transaction_0, Transaction_1, ..., Transaction_n]

## Rationale

### Why not specify each transaction type at the protocol layer?

We could have chosen to make the protocol aware of the shape of the transaction payloads. The authors felt that it would be too much maintenance burden long term to have every new transaction type require an update to devp2p, so instead we merely define that typed transactions are supported.

### Why have peers disconnect if they receive an unknown transaction type?

We could encourage peers to remain connected to peers that submit an unknown transaction type, in case the transaction is some new transaction type that the receiver isn’t aware of it. However, doing so may open clients up to DoS attacks where someone would send them transactions of an undefined TransactionType in order to avoid being disconnected for spamming. Also, in most cases we expect that by the time new transaction types are being sent over devp2p, a hard fork that requires all connected clients to be aware of the new transaction type is almost certainly imminent.

## Backwards Compatibility

Legacy transactions are still supported.

TBD

TBD

## Security Considerations

If a client chooses to ignore the SHOULD recommendation for disconnecting peers that send unknown transaction types they may be susceptible to DoS attacks. Ignoring this recommendation should be limited to trusted peers only, or other situations where the risk of DoS is extremely low.

Copyright and related rights waived via CC0.