status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-22 11:48:19 +00:00
Code Issues Projects Releases Wiki Activity

2976: Adds Receipts (#3254)

Browse Source
This commit is contained in:
Micah Zoltu 2021-02-07 08:22:17 +08:00 committed by GitHub
parent ab52366caf
commit 3ec9510e81
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 9 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
EIPS/eip-2976.md
View File

@ -3,7 +3,7 @@ eip: 2976
title: '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
status: Review
type: Standards Track
category: Networking
created: 2020-09-13
@ -41,6 +41,11 @@ All changes specified below apply to all protocol/versions retroactively.
* `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.
@ -71,6 +76,9 @@ Clients **MAY** disconnect peers who send transactions of a new `TransactionType
`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.
@ -83,12 +91,6 @@ Also, in most cases we expect that by the time new transaction types are being s
## 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.