db20ed5dc6
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
6.9 KiB
| eip | title | author | discussions-to | status | type | category | created |
|---|---|---|---|---|---|---|---|
| 2711 | Separate gas payer from msg.sender | Micah Zoltu (@MicahZoltu) | https://ethereum-magicians.org/t/eip-2711-separate-gas-payer-from-msg-sender/4353 | Draft | Standards Track | Core | 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, senderV, senderR, senderS, gasPrice, gasLimit, gasPayerV, gasPayerR, gasPayerS] would also be valid. In such a transaction, senderV, senderR, senderS is a signature of rlp([nonce, to, value, data, chainId]) where senderV is CHAIN_ID * 2 + 35 or CHAIN_ID * 2 + 36 (see EIP-155 for details on senderV) and gasPayerV, gasPayerR, gasPayerS is 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
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.