From c5c6d9f309a1cb5d7c75ac4bd0017139c03fafc5 Mon Sep 17 00:00:00 2001 From: Micah Zoltu Date: Thu, 11 Jun 2020 11:11:37 +0800 Subject: [PATCH 1/3] Creates EIP-TBD: Separate gas payer from msg.sender --- EIPS/eip-TBD.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 EIPS/eip-TBD.md diff --git a/EIPS/eip-TBD.md b/EIPS/eip-TBD.md new file mode 100644 index 00000000000000..1108743eb26863 --- /dev/null +++ b/EIPS/eip-TBD.md @@ -0,0 +1,51 @@ +--- +eip: +title: Separate gas payer from msg.sender +author: Micah Zoltu (@MicahZoltu) +discussions-to: +status: Draft +type: Standards Track +category: Core +created: 2020-06-11 +--- + +## Simple Summary +Allow for a second transaction signer who pays for gas, which is separate from the transaction signer who represents the `msg.sender` of the transaction. + +## Abstract +As of `FORK_BLOCK_NUMBER`, Ethereum transactions can be optionally wrapped inside a second signed envelope that will include an additional signature from which the account that will pay for gas (`GAS_PAYER`) can be recovered. The transaction will otherwise operate the same as any other transaction, except the `GAS_PAYER` will cover all gas costs, while the inner transaction signer will be the `msg.sender` for the transaction. + +## Motivation +With the advent of tokens and especially stable coins, it has become common for users to not hold ETH in an account while they may have other assets of value in that account. Some users don't want to be exposed to the perceived volatility of ETH and instead would prefer to transact using other assets. Unfortunately, since gas **MUST** be paid for with ETH, this prevents the user from transacting with their assets without first acquiring some ETH using some other means, and then using that ETH to pay fees. + +This EIP proposes a mechanism by which we can allow people to transact without ever having to own any ETH by allowing someone else to cover gas costs. The arrangements that enable the covering of gas costs is out of scope for this EIP but it could be an extra-protocol monthly subscription, payment could occur as part of the transaction being submitted, the recpient may be willing to cover gas costs, or it could be a free service offered as a value-ad by a company that you are working with. + +While it is possible to implement these sort of mechanisms at the individual contract layer, such solutions require integration by just about every contract and those solutions also end up depending on gas costs being stable with time in order to appropriately bake them into contracts without putting either party at risk of malicious participants in the system. For this reason, it is deemed beneficial that separating out `GAS_PAYER` from `msg.sender` at the protocol layer is valuable. + +## Specification +Currently, a signed transaction is 9 RLP encoded fields (`[nonce, gasPrice, gasLimit, to, value, data, senderV, senderR, senderS]`). As of `FORK_BLOCK_NUMBER`, that would continue to be a valid signed transaction and would operate as normal. As of `FORK_BLOCK_NUMBER` a transaction containing 13 RLP encoded fields interpreted as `[nonce, to, value, data, chainId, senderV, senderR, senderS, gasPrice, gasLimit, gasPayerV, gasPayerR, gasPayerS]` would also be valid. In such a transaction, `senderV, senderR, senderS` would be a signature of `rlp([nonce, to, value, data, chainId])` and `gasPayerV, gasPayerR, gasPayerS` would be a signature of `rlp([nonce, to, value, data, chainId, senderV, senderR, senderS, gasPrice, gasLimit])`. + +## Rationale +### EIP-155 ChainID +I'm open to discussion on whether we should enforce EIP-155 chain IDs or not. It feels like we might as well since we are creating a new transaction type here. +### Transaction Versioning +It would be *better* if we developed a mechanism for enveloping arbitrary new transaction types rather than just relying on "if it has 13 items then it is of this type, if it has 9 it is of that type". However, while there has been a lot of talk about creating a transaction envelope layer that allows us to more freely add new transaction types, no action has been taken on that front and I am loathe to wait for someone to develope such a standard for it first. +### `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. + +## 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. + +## Test Cases + + +## Implementation + + +## Security Considerations + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From a41988e224d94d18d49b1259f7235166937b1043 Mon Sep 17 00:00:00 2001 From: Micah Zoltu Date: Thu, 11 Jun 2020 11:14:13 +0800 Subject: [PATCH 2/3] Adds EIP number. --- EIPS/{eip-TBD.md => eip-2711.md} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename EIPS/{eip-TBD.md => eip-2711.md} (97%) diff --git a/EIPS/eip-TBD.md b/EIPS/eip-2711.md similarity index 97% rename from EIPS/eip-TBD.md rename to EIPS/eip-2711.md index 1108743eb26863..e35247f6c564ca 100644 --- a/EIPS/eip-TBD.md +++ b/EIPS/eip-2711.md @@ -1,8 +1,8 @@ --- -eip: +eip: 2711 title: Separate gas payer from msg.sender author: Micah Zoltu (@MicahZoltu) -discussions-to: +discussions-to: https://ethereum-magicians.org/t/eip-2711-separate-gas-payer-from-msg-sender/4353 status: Draft type: Standards Track category: Core @@ -30,7 +30,7 @@ Currently, a signed transaction is 9 RLP encoded fields (`[nonce, gasPrice, gasL I'm open to discussion on whether we should enforce EIP-155 chain IDs or not. It feels like we might as well since we are creating a new transaction type here. ### Transaction Versioning It would be *better* if we developed a mechanism for enveloping arbitrary new transaction types rather than just relying on "if it has 13 items then it is of this type, if it has 9 it is of that type". However, while there has been a lot of talk about creating a transaction envelope layer that allows us to more freely add new transaction types, no action has been taken on that front and I am loathe to wait for someone to develope such a standard for it first. -### `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. ### 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. From 274638c066be95fdd02cfeb139921029efc9526a Mon Sep 17 00:00:00 2001 From: Micah Zoltu Date: Thu, 11 Jun 2020 13:05:00 +0800 Subject: [PATCH 3/3] Fixes typo. --- EIPS/eip-2711.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2711.md b/EIPS/eip-2711.md index e35247f6c564ca..0364a28cb3fd68 100644 --- a/EIPS/eip-2711.md +++ b/EIPS/eip-2711.md @@ -29,7 +29,7 @@ Currently, a signed transaction is 9 RLP encoded fields (`[nonce, gasPrice, gasL ### EIP-155 ChainID I'm open to discussion on whether we should enforce EIP-155 chain IDs or not. It feels like we might as well since we are creating a new transaction type here. ### Transaction Versioning -It would be *better* if we developed a mechanism for enveloping arbitrary new transaction types rather than just relying on "if it has 13 items then it is of this type, if it has 9 it is of that type". However, while there has been a lot of talk about creating a transaction envelope layer that allows us to more freely add new transaction types, no action has been taken on that front and I am loathe to wait for someone to develope such a standard for it first. +It would be *better* if we developed a mechanism for enveloping arbitrary new transaction types rather than just relying on "if it has 13 items then it is of this type, if it has 9 it is of that type". However, while there has been a lot of talk about creating a transaction envelope layer that allows us to more freely add new transaction types, no action has been taken on that front and I am loathe to wait for someone to develop such a standard for it first. ### `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