ERC2771Forwarder: consider not enforcing trustedForwarder

[sakulstra]

🧐 Motivation
When relaying transactions, you often end up in a situation where you need to relay a token permit in addition to some additional transaction(s). While the additional transaction(s) can be forwarded via ERC2771Forwarder - considering the target contract implements ERC2771Context- the permit can not because the token is not "trusting" this forwarder.
However, not trusting the forwarder is not a problem as the permit does not rely on altering the context.

For any flow that requires an approval in order to forward the rest of a transaction batch this would be very useful.

📝 Details
As far as i can tell the Forwarder itself is not part of the Spec, so i think it's worth considering to remove the isTrustedForwarder check as I don't actually see any downside of not having it - worst case the txn would revert. This is in line with how the previous MinimalForwarder worked.

edit: I see this was changed in #4502 (comment) specifically to prevent accidents caused by approving the forwarder, but the fix as lined out above, can actually cause problems.

[Amxx]

Hello @sakulstra and thank you for raising that issue.

The ERC2771Forwarder is probably not going to be developped any further:

ERC-7702, which should be live soon will provide a good alternative to ERC-2771 meta transaction. This will allow us to remove the cumbersome Context contract. At the same time we will deprecate/remove ERC2771Forwarder from our codebase.

We cannot do that now, as it would be a breaking change, but we will do that in the next major release (v6.0)

In the meantime, we are commited to not doing any breaking change. Changing the validation/trust of the forwarder would be a breaking change as far as security/behavior goes. If we wanted to ship that, we would probably wait until 6.0 ... but again we will lieklly remove the Forwarder entierly in 6.0

@ernestognw WDYT ?

[ernestognw]

With Account Abstraction and especially EIP-7702 it's likely that Context won't be relevant anymore. For now, I agree that we must keep backwards compatibility until 6.0 (we don't have plans for it yet).

In regards to ERC2771Forwarder, we can make the _isTrustedByTarget function internal so people can override it with their own definition.

We initially didn't do this because it's technically a footgun if a user approves the forwarder to spend tokens, but if I understand correctly, the use case is to relay a permit where you don't require the token to trust the forwarder and it's just batched along for convenience. Is that correct?

[sakulstra]

@ernestognw yes exactly.

The scenario is that i have a token A that i want to supply on some pool B.
While i am in control of B and I can implement 7702-context, for a supply to work i need to batch it with an A.permit(B).