Add EIP-7702 support

[Agusx1211]

No description provided.

[ScreamingHawk]

This pattern prevents cross chain counterfactual implementation upgrades. e.g. Upgrade to wallet v4 would need to be another delegation signature per chain.

We could delegate to a Wallet proxy instead of directly to the implementation.

[ScreamingHawk]

If we do this, Stage7702Auth could act like Stage1Auth providing only counterfactual auth, and we upgrade the implementation to Stage2 when the image hash is no longer counterfactual. As per the existing flow.

[Agusx1211]

I did consider delegating to a proxy, but keep in mind that it wouldn't be as simple as delegating into an existing wallet proxy. Stage1 uses the self address to verify the counterfactual configuration, in 7702 this would end up being the EOA address, which has no counterfactual info. Doing the proxy directly to the Stage2 doesn't work either, because it needs setup, and we don't have a clean way of setting it up.

In order to make it work we would need to write a Stage1-7702 special contract, that verifies the imageHash by first loading the code from the EOA, then with that fetching the address of the proxy, and verifying the counterfactual data against that address, possible but imho a bit ugly.

My thinking is, at the end of the day 7702 is already a proxy, updating a 7702 wallet can be done by signing a new authorization, there is no need to add another layer and mechanism that does exactly the same, it increases gas on every transactions for what in my mind is no gain.

[ScreamingHawk]

The feature miss with the current approach is we can't use a single signature for cross chain implementation upgrades, since 7702 doesn't use chain id = 0 as any chain. We will end up with the same pain we have for v1 wallet migrations.

[ScreamingHawk]

Approved.
I think the cross chain implementation upgrade concern is still valid. If we are happy to wear this risk for v4 then 👍