Creates EIP-2711: Separate gas payer from msg.sender

EIPS/eip-2711.md

@@ -0,0 +1,51 @@
+---
+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, 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 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
+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
+<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
+
+## Implementation
+<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
+
+## Security Considerations
+<!--All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.-->
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).