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` ### `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. 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 ### 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 ## 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. 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.