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

Automatically merged updates to draft EIP(s) 2711 (#2712)

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Micah Zoltu 2020-06-11 22:43:25 +08:00 committed by GitHub
parent 6d93750191
commit d95d52154a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
EIPS/eip-2711.md
View File

@ -33,7 +33,9 @@ It would be *better* if we developed a mechanism for enveloping arbitrary new tr
### `GAS_PAYER` chooses `gasLimit` and `gasPrice`
Allowing the gas payer to choose limit and price means that the gas payer can take measures to ensure that the transaction is mined and is successful. The `SENDER` may wish to allow the `GAS_PAYER` to execute some code as part of the transaction (e.g., through a cross-contract callback). In such cases, the `SENDER` will not know the amount of gas that the `GAS_PAYER` will need so they cannot craft a transaction with `gasLimit` hard-coded. The assumption is that the gas payer/payee relationship is semi-trusted (they have extra-protocol mechanisms in place to protect against DoS attacks) and if not enough gas is supplied the only harm done to the `SENDER` is that their `nonce` is incremented.
### Nonces
Since the inner transaction has a nonce, we already have replay protection. There is no need to have multiple parties provide a nonce. We could have the `GAS_PAYER` provide the nonce, or we could have a third signature for the `NONCE_PROVIDER` which is where the nonce is coming from. All of these solutions would provide the necessary replay protection and we just have to make a call as to which one to use. A separate nonce-provider seems like it would provide minimal benefit, yet it increases complexity and adds 3 more fields to the transaction (increasing size). `GAS_PAYER` providing nonce would work just as well as `SENDER`, but we decided to go with `SENDER` due to a coin toss.
The inner transaction needs a nonce to protect themselves from replay attacks. Since the inner transaction has a nonce, we get replay protection on the outer transaction as well, so it is not critical for security to have multiple parties provide a nonce.
We could have the `GAS_PAYER` provide a second nonce, but this would increase the payload size and require `GAS_PAYER` to do replace-by-fee (noisy for gossip) if they want to slip in a new (different inner) transaction with a higher gas price. It would also create the possibility of a deadlock if the `SENDER` nonces aren't ordered the same as the `GAS_PAYER` nonces, and if the `SENDER` nonce isn't the lowest valid nonce for the `SENDER` then the `GAS_PAYER` can't sign and submit yet.
## Backwards Compatibility
Legacy transactions, both EIP-155 and not, would continue to function as normal. Clients will need to implement support for the new trantsaction based on the number of RLP elements present in the transaction.