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.

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.

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.

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]).

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.

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.

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.

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.

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.

Copyright and related rights waived via CC0.