--- eip: 2711 title: Separate gas payer from msg.sender author: Micah Zoltu (@MicahZoltu) discussions-to: https://ethereum-magicians.org/t/eip-2711-separate-gas-payer-from-msg-sender/4353 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, gasLimit, senderV, senderR, senderS, gasPrice, gasPayerV, gasPayerR, gasPayerS]` would also be valid. In such a transaction, `senderV, senderR, senderS` is a signature of `rlp([nonce, to, value, data, gasLimit, chainId])` where `senderV` is `CHAIN_ID * 2 + 35` or `CHAIN_ID * 2 + 36` (see [EIP-155](./eip-155.md) for details on `senderV`) and `gasPayerV, gasPayerR, gasPayerS` is a signature of `rlp([nonce, to, value, data, gasLimit, chainId, senderV, senderR, senderS, gasPrice])`. ## 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 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 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. ## Test Cases ## Implementation ## Security Considerations ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).