EIP-3009: transferWithAuthorization - Gas-Abstracted ERC20 transactions #3009
Conversation
petejkim
force-pushed
the
gas-abstraction
branch
from
3237e18 to
a620568
Compare
petejkim
changed the title
There was a problem hiding this comment.
Thank you for your proposal, @petejkim. I've left a few suggestions on your EIP.
petejkim
force-pushed
the
gas-abstraction
branch
from
e69300f to
29ef230
Compare
petejkim
force-pushed
the
gas-abstraction
branch
from
29ef230 to
8edf2f9
Compare
| This enables the user to: | ||
|
|
||
| - delegate the gas payment to someone else, | ||
| - pay for gas in the token itself rather than in ETH, | ||
| - perform one or more token transfers and other operations in a single atomic transaction, | ||
| - transfer ERC-20 tokens to another address, and have the recipient submit the transaction, | ||
| - batch multiple transactions with minimal overhead, and | ||
| - create and perform multiple transactions without having to worry about them failing due to accidental nonce-reuse or improper ordering by the miner. | ||
|
|
There was a problem hiding this comment.
| This enables the user to: | |
| - delegate the gas payment to someone else, | |
| - pay for gas in the token itself rather than in ETH, | |
| - perform one or more token transfers and other operations in a single atomic transaction, | |
| - transfer ERC-20 tokens to another address, and have the recipient submit the transaction, | |
| - batch multiple transactions with minimal overhead, and | |
| - create and perform multiple transactions without having to worry about them failing due to accidental nonce-reuse or improper ordering by the miner. |
Please move this text to the motivation section. Abstract should be a human readable version of the specification while motivation section is where you talk about why someone would want to implement this specification.
| The popular USD-backed stablecoin [USDC v2](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48) implements an expanded form of this spec. This can also be adopted alongside the [EIP-2612](./eip-2612) spec for maximum compatibility with existing applications. | ||
|
|
There was a problem hiding this comment.
| The popular USD-backed stablecoin [USDC v2](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48) implements an expanded form of this spec. This can also be adopted alongside the [EIP-2612](./eip-2612) spec for maximum compatibility with existing applications. |
The first sentence isn't really appropriate for an EIP. Mentioning one token that already implements this standard isn't relevant to the standardization process. The second sentence could be retained, though should probably be moved into motivation.
|
|
||
| This is especially problematic now that gas prices have become very high and transactions often get queued up and remain unconfirmed for a long time. Non-sequential nonces allow users to create as many transactions as they want at the same time. | ||
|
|
||
| The ERC-20 allowance mechanism is susceptible to the [multiple withdrawal attack](https://blockchain-projects.readthedocs.io/multiple_withdrawal.html)/[SWC-114](https://swcregistry.io/docs/SWC-114), and encourages antipatterns such as the use of the "infinite" allowance. The wide-prevalence of upgradeable contracts have made the conditions favorable for these attacks to happen in the wild. |
There was a problem hiding this comment.
Is it reasonable to inline a description of the multiple withdrawal attack? External links are very likely to break one day and we would like EIPs to stand on their own with minimal or no external references.
| mapping(address => mapping(bytes32 => bool)) authorizationStates; | ||
|
|
There was a problem hiding this comment.
| mapping(address => mapping(bytes32 => bool)) authorizationStates; |
This is an internal implementation detail, which isn't appropriate for a standard.
| ) external view returns (bool); | ||
| ``` | ||
|
|
||
| This mapping keeps track of the nonces of the authorizations that have been used (`false` = Unused, `true` = Used). Nonces are randomly generated `bytes32` unique to the token holder's address. |
There was a problem hiding this comment.
| This mapping keeps track of the nonces of the authorizations that have been used (`false` = Unused, `true` = Used). Nonces are randomly generated `bytes32` unique to the token holder's address. | |
| This function will return `true` if the given nonce has already been used by the authorizer, and `false` otherwise. |
Whether this is backed by a mapping or not is not relevant to the interface definition.
| ### Storage | ||
|
|
There was a problem hiding this comment.
Storage is an implementation detail. Move the contents of this section into Methods.
| ) external; | ||
| ``` | ||
|
|
||
| The arguments `v`, `r`, and `s` can be obtained using the [EIP-712](./eip-712) typed message signing spec. |
There was a problem hiding this comment.
| The arguments `v`, `r`, and `s` can be obtained using the [EIP-712](./eip-712) typed message signing spec. | |
| The arguments `v`, `r`, and `s` **MUST** be obtained using the [EIP-712](./eip-712) typed message signing spec. |
| - However, for meta-transactions, when a transaction containing a sequential nonce value that is too high is submitted, instead of staying pending, it will revert and fail immediately, resulting in wasted gas. | ||
| - The fact that miners can also reorder transactions and include them in the block in the order they want (assuming each transaction was submitted to the network by different meta-transaction relayers) also makes it possible for the meta-transactions to fail even if the nonces used were correct. (e.g. User submits nonces 3, 4 and 5, but miner ends up including them in the block as 4,5,3, resulting in only 3 succeeding) | ||
| - Lastly, when using different applications simultaneously, in absence of some sort of an off-chain nonce-tracker, it is not possible to determine what the correct next nonce value is if there exists nonces that are used but haven't been submitted and confirmed by the network. | ||
| - This is especially problematic now that high gas price fluctuations often cause transactions to "get stuck" in the pool for a long time. Today, if you make a meta-transaction that uses a sequential nonce from one app, and switch to another app to make another meta-transaction before the previous one confirms, the same nonce will be used twice, resulting in one of the transactions failing. |
There was a problem hiding this comment.
now that high gas price fluctuations often cause transactions to "get stuck" in the pool for a long time
EIPs should be worded for a target audience reading it in 5+ years. Since we have no idea what gas prices will be like at that time, we shouldn't discuss their state (e.g., volatility) as an invariant or really even mention anything about the "current" situation.
…ns (ethereum#3009) A contract interface that enables transferring of fungible assets via a signed authorization.
…ns (ethereum#3009) A contract interface that enables transferring of fungible assets via a signed authorization.
|
@petejkim @MicahZoltu @lightclient @Arachnid @tkstanczak I have an EIP which adds 13 lines of functionality to this EIP, would love your thoughts 😄 (from Circle engineering team!) #5987 |
An EIP for
transferWithAuthorization, as used by the USD Coin (USDC) smart contract, alongside EIP-2612.Discussions