HomeEIPs
EIPsEIP-2976
EIP-2976

Typed Transactions over Gossip

Adds support for transmission of typed transactions over devp2p.
FinalStandards Track: Networking
Created: 2020-09-13
Requires: EIP-2718
Micah Zoltu (@MicahZoltu)
DiscussionsOriginal linkEdit
1 min read

EIP-2976 proposes adding support for the transmission of typed transactions over devp2p in Ethereum. This would allow for the gossiping of new transaction types introduced in EIP-2718, which are currently unable to be included in blocks without a mechanism for transmission. The proposal defines TypedTransactions as a byte array containing a TransactionType and TransactionPayload, with TransactionType being a positive unsigned 8-bit number representing the type of the transaction and TransactionPayload being an opaque byte array dependent on the TransactionType. LegacyTransactions are still supported, and a TransactionId is defined as the keccak256 hash of the TypedTransactionHash and LegacyTransactionHash. The proposal also defines TypedReceipts and ReceiptLists. The authors chose not to specify each transaction type at the protocol layer to avoid maintenance burden and instead define that typed transactions are supported. Peers are recommended to disconnect if they receive an unknown transaction type to avoid DoS attacks, but this recommendation can be ignored in limited situations. Overall, the proposal aims to enable the use of new transaction types in Ethereum by updating devp2p to support the gossip of TypedTransactions.

Video
Anyone may contribute to propose contents.
Go propose
Original

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. Clients MUST NOT send new transaction types before they believe the fork block is reached.

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 all protocol/versions retroactively.

Definitions

  • || is the byte/byte-array concatenation operator.
  • | is the type union operator.
  • DEVP2P_VERSION = TBD
  • Transaction is either TypedTransaction or LegacyTransaction
  • TypedTransaction is a byte array containing TransactionType || TransactionPayload
  • TypedTransactionHash is keccak256(TypedTransaction)
  • 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 array of the form [nonce, gasPrice, gasLimit, to, value, data, v, r, s]
  • LegacyTransactionHash is keccak256(rlp(LegacyTransaction))
  • TransactionId is keccak256(TypedTransactionHash | LegacyTransactionHash)
  • Receipt is either TypedReceipt or LegacyReceipt
  • TypedReceipt is a byte array containing TransactionType || ReceiptPayload
  • ReceiptPayload is an opaque byte array whose interpretation is dependent on the TransactionType and defined in future EIPs
  • LegacyReceipt is an array of the form [status, cumulativeGasUsed, logsBloom, logs]
  • LegacyReceiptHash is keccak256(rlp(LegacyReceipt))

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 MUST NOT send transactions of a new TransactionType until that transaction type's introductory fork block.

Clients MAY disconnect peers who send transactions of a new TransactionType significantly before that transaction type's introductory fork block.

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

NewPooledTransactionIds (0x08): [TransactionId_0, TransactionId_1, ..., TransactionId_n]

GetPooledTransactions (0x09): [TransactionId_0, TransactionId_1, ..., TransactionId_n]

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

Receipts (0x10): [ReceiptList_0, ReceiptList_1, ..., ReceiptList_n] where:

  • ReceiptList is [Receipt_0, Receipt_1, ..., Receipt_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.

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.

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.
Resources
GitHub
Supported by