Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transient Approval #4959

Closed
Amxx opened this issue Mar 16, 2024 · 4 comments · Fixed by #5071
Closed

Transient Approval #4959

Amxx opened this issue Mar 16, 2024 · 4 comments · Fixed by #5071
Assignees
Labels

Comments

@Amxx
Copy link
Collaborator

Amxx commented Mar 16, 2024

In some cases, an ERC20 approval is granted, that is then used in the same transaction. In that case, using storage is expensive, and potentially dangerous if approval persists.

The idea is to have, next to the normal allowance, a transient allowance.

This transient allowance can be set using a new "approveTransient" function that replicates the behavior of "approve" (minus the event)

When doing a transferFrom (or any operation that consumes allowance) the transient allowance is used first. If that is enough, no storage read or right is necessary. If transient allowance is not enough, normal (storage allowance is used)

If EOA multicall becomes available, either through EIP-3074 or EIP-5806, EOAs will be able to:

  • set transient allowance
  • use that allowance in defi (swap) ?
    In a single transaction. This should save significant amount of gas over the same approach with storage based allowances.

No allowance is left after the tx, reducing risks.

That does not require any change from the consumer side (same transferFrom).

Implementation can be found here

@charles-cooper
Copy link

would be extra good with https://eips.ethereum.org/EIPS/eip-7609 ;)

@wjmelements
Copy link
Contributor

  1. This makes ERC20 transferFrom use more gas on average. Consider making a different ERC extending or replacing ERC20 for transient transferFrom.

  2. I am glad this design makes a separate approve method instead of changing ERC20 approve.

  3. Ideally the sload slot is the same as the tload slot so it can reuse the sha3. This isn't possible in Solidity.

  4. The batch usage that this design targets already benefits from the SSTORE-reset refund in the EVM. It would not surprise me if the transient pattern used more gas, or if the savings was less than 5000.

@Amxx
Copy link
Collaborator Author

Amxx commented Mar 17, 2024

Thank you @wjmelements for your feedback

  1. That would definitelly be opt in (extension to ERC-20). Note that if no temporary allowance is set, it only costs a 2 hashes, a tload, and some ifs. That is not 0, but its very small compared to the cost of doing a transferFrom (2 or 3 sstores !)

  2. It would definitelly be a different approve methode. We need to keep the ERC20.approve function to keep its behavior!

  3. It is not impossible. The difficulty is in figuring out the slot used by the allowance mapping. If using ERC-7201, then that is possible.

  4. I've implemented and run the numbers (with an EIP-5806 based multicall). TSTORE is cheaper!

Capture d’écran du 2024-03-17 13-15-36

@Amxx Amxx added the idea label Mar 17, 2024
@Amxx Amxx added this to the 5.1 milestone Mar 17, 2024
@wjmelements
Copy link
Contributor

3. It is not impossible. The difficulty is in figuring out the slot used by the allowance mapping. If using ERC-7201, then that is possible.

Anything can be done in assembly but in solidity it will compute the same hash twice to determine the slot.

@cairoeth cairoeth self-assigned this Jun 4, 2024
@Amxx Amxx mentioned this issue Jul 21, 2024
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants