AllowanceHolder Use top-level calldata for authentication and avoid Permit2 ecrecover and nonce cancellation PRO-73
#25
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
PRO-73 Exploit EIP-1153 transient storage for gas efficiency in taker-submitted OTC
Presently, due to the gas overhead of having to redeem 2 Permit2 coupons, OTC through 0xV5 is not as gas efficient as the latest 4th-generation AMMs. We only have ~30k gas to work with, which is quite challenging. Using EIP-1153 transient storage and re-using the transaction signature (the 21k inherent gas) for authentication would help us achieve that. In essence, we'd make a version of Permit2 that uses |
duncancmt
changed the title
ecrecover and nonce cancellation PRO-73ecrecover and nonce cancellation PRO-73
Also make other-than-first-hop UniV3 sells be proportions of tokens, not absolute amounts
…e key with validation in holderTransferFrom (#51) Rather than assume `tx.origin` is the owner during `holderTransferFrom`, we can validate the `holderTransferFrom` params by using `hash(operator, owner,token)` as the key for the ephemeral allowance. `tx.origin` is completely removed, which removes the need for `moveExecute` as contracts can use this function. `operator` is included in the ephemeral key and the storage of this value is removed. In the case of malicious usage, ephemeral allowance key existence is the protection and a key miss results in a revert. * swapping out `owner` would result in a ephemeral allowance miss (different owner) * attacking from a different malicious contract would result in a ephemeral allowance miss (different operator) * swapping out `token` would result in a ephemeral allowance miss (same as before) Replaces #50
…e `AllowanceHolder` gas snapshotting (#49) Rather than assume `tx.origin` is the owner during `holderTransferFrom`, we can validate the `holderTransferFrom` params by using `hash(operator, owner,token)` as the key for the ephemeral allowance. `tx.origin` is completely removed, which removes the need for `moveExecute` as contracts can use this function. `operator` is included in the ephemeral key and the storage of this value is removed. In the case of malicious usage, ephemeral allowance key existence is the protection and a key miss results in a revert. * swapping out `owner` would result in a ephemeral allowance miss (different owner) * attacking from a different malicious contract would result in a ephemeral allowance miss (different operator) * swapping out `token` would result in a ephemeral allowance miss (same as before) Replaces #50 I wonder is the reason that `AllowanceHolder` is less than 5k gas cheaper than `Permit2` is due to the overhead in decoding calldata arrays? We know that `Permit2` adds an extra ~4k gas when batch is used.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR also cleans up some assembly that wasn't safe for 0.8
closes #11