Addressing the Permit2 parameter synchrony requirement by having the front-end client pass the PermitSingle struct

[PaulRBerg]

While writing #53, I came up with the following way of framing the devilish problem that led @razgraf and @gavriliumircea to spend weeks debugging Permit2 signatures:

The core issue is that the ProxyTarget contract requires users to ensure that all of the following parameters are in synchrony:

• The values passed as the ERC-20 transfer amount (e.g. createParams.totalAmount)
• The non-signature struct fields in Permit2Params
• The local values the user has signed over to generate the bytes signature

In hindsight, this seems to me like a bad design because it's easy to shoot yourself in the foot with it.

To cut the proverbial Gordian Knot, we could follow in Uniswap's footsteps and require the front-end client to pass the PermitSingle struct alongside the Permit2 signature:

https://github.com/Uniswap/universal-router/blob/b01e71f8ea6458ce86cb94ad68b5d4d92d3a7382/contracts/base/Dispatcher.sol#L163-L170

This approach is more verbose; values like nonce and spender would have to be handled by the front-end. However, this should be a worthy trade-off because the system would become more robust and resilient against human error.

WDYT, @razgraf, @gavriliumircea?

[razgraf]

While some items like token would be duplicated, I see this as a win for our UX. As I said in a recent Slack message, after spending the last days debugging, I can appreciate the clarity of both an API and some docs, over reducing redundancy.

values like nonce and spender

These are already handled client-side as we need them, esp. the nonce (async call) for the signature generation. No issue here.

[PaulRBerg]

Awesome. It looks like we have a winning solution.

Waiting for @gavriliumircea to confirm and then I'll create an issue.

[gavriliumircea]

Yes I think this solution should bring a lot of clarity, so I think we should go ahead and implement this. Also I think it is a plus that we are going to use the uniswap approach, given the fact that at least at front end level docs and examples are missing.

[PaulRBerg]

Great.

[PaulRBerg]

Closing, this was implemented in #58.