status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 12:18:16 +00:00
Code Issues Projects Releases Wiki Activity

####: eth/##: Typed Transactions over Gossip (#2976)

Browse Source 
Adds support for transmission of typed transactions over devp2p.
This commit is contained in:
Micah Zoltu 2020-09-13 20:08:41 +08:00 committed by GitHub
parent 64fefe6a64
commit f203da639c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 90 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
EIPS/eip-2976.md Normal file
View File

@ -0,0 +1,90 @@
---
eip: 2976
title: eth/##: Typed Transactions over Gossip
author: Micah Zoltu (@MicahZoltu)
discussions-to: https://ethereum-magicians.org/t/eip-2976-eth-typed-transactions-over-gossip/4610
status: Draft
type: Standards Track
category: Networking
created: 2020-09-13
requires: 2718
---
## Simple Summary
Adds support for transmission of typed transactions over devp2p.
## Abstract
[Typed Transactions](./eip-2718.md) 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](./eip-2718.md) 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](./eip-2718.md) 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.
## Test Cases
TBD
## Implementation
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
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).