EIP-2976 Network propagation of typed transactions (Typed Transactions over Gossip)
Final · Networking & nodes · EIP status Final · created 2020-09-13
Makes it possible to send and receive typed transactions (Typed Transactions), introduced by EIP-2718, over devp2p, the communication protocol between nodes. This opens a path for transactions in new formats to actually propagate across the network.
Why it is needed
EIP-2718 introduced typed transactions, which allow multiple kinds of transactions to be carried in a single envelope. This created a framework for including new transaction formats in a block. But for a transaction to get into a block, it must first spread among nodes. Ethereum nodes exchange transactions with each other over a communication protocol called devp2p, and this protocol did not specify how to carry typed transactions. Without a way to propagate them, no one can actually get a transaction in a new format into a block. This EIP amends the protocol so that devp2p can send and receive typed transactions, so the benefits of typed transactions can actually be realized.
What changes
Today
- The node-to-node protocol devp2p only exchanges legacy format transactions
- EIP-2718 typed transactions are defined for the block format, but there is no way to propagate them over the network
- Even if a new transaction format appears, there is no path to deliver it to block producers, so it cannot actually be used
After EIP-2976
- Typed transactions are exchanged between nodes as they are, in the form TransactionType || TransactionPayload
- Even when a new transaction type is created, propagation can be supported without raising the devp2p version
- Peers that send an unknown type or content that breaks the rules are disconnected, which prevents spam
Who is affected
- Client teams: Every devp2p message that handles transactions must handle both legacy transactions and typed transactions.
- Node operators: A node that does not know a new type gets its peer connection dropped when it receives that type, so clients must be updated in time for the fork.
- Wallet & app developers: New transaction formats defined on top of EIP-2718 can actually be sent over the network.
In depth
Wire format and hash of typed transactions
TypedTransaction is a byte array formed by concatenating TransactionType and TransactionPayload. TransactionType is an unsigned 8-bit value between 0 and 0x7f, and TransactionPayload is an opaque byte array whose interpretation depends on the type, with the specifics set by the future EIP that defines each type. The hash is TypedTransactionHash = keccak256(TypedTransaction), which is computed differently from the legacy keccak256(rlp(LegacyTransaction)), which goes through RLP encoding. TransactionId uses TypedTransactionHash for a typed transaction and LegacyTransactionHash for a legacy one. Receipts work the same way: TypedReceipt is defined as TransactionType || ReceiptPayload.
Behavior on receiving an unknown type
A client that receives an unrecognized TransactionType through any message SHOULD disconnect from the peer that sent it. It SHOULD likewise disconnect if the TransactionPayload is invalid for the given TransactionType.
No sending before the fork block
A client MUST NOT send a transaction of a new TransactionType before the fork block that introduces that type. It MAY also disconnect from a peer that sends transactions of a new type well before the fork block. This rule keeps formats that are not yet active from circulating on the network.
Protocol messages that change
The transaction lists in Transactions (0x02), PooledTransactions (0x0a), BlockBodies (0x06) and NewBlock (0x07) become Transaction lists that can hold both legacy and typed transactions. NewPooledTransactionIds (0x08) and GetPooledTransactions (0x09) use lists of TransactionId, and the receipt list in Receipts (0x10) can also hold both TypedReceipt and LegacyReceipt. This change applies retroactively to all protocol versions.
Why the protocol does not know type-specific content
devp2p could have been designed to know the payload structure of every type. But the authors judged that this would require changing devp2p every time a new transaction type appears, which is too heavy a maintenance burden in the long run. So the EIP defines only the fact that typed transactions are supported and leaves the interpretation of the content to the EIP that defines each type.
The disconnect recommendation and DoS defense
If a peer that sends an unknown type is left connected, the node can be exposed to a denial of service (DoS) attack in which the peer keeps sending transactions of undefined TransactionType while evading spam blocking. The authors also considered it almost certain that by the time a new type propagates over devp2p, a hard fork requiring every client to know that type is imminent. Ignoring the disconnect recommendation (SHOULD) should be limited to trusted peers or situations where the DoS risk is very low.
Compatibility and current status
Legacy transactions remain supported, so transactions built the existing way can still be used as they are. This EIP is finalized (Final) as a standard in the networking category.