[LSP6] Add EIP-1271 verification mechanism for relay calls

[YamenMerhi]

What this issue is about?

Currently, a controller address having permission, either a contract or an EOA can use the execute(..) function to execute a payload on the target contract.

In the case of executeRelayCall(..) it's a little bit different since the only verification method supported is verification through ECDSA. This means the relay call is only supported for EOAs that have permissions and not for contracts that have permissions.

That means EOAs that have permissions can sign messages and hand them to a relayer, and this relayer entity can submit the signature and the payload and execute successfully.

For contracts that have permissions, there is no way to pass signed messages by the contract as the contract can't sign.

Going further, that means we cannot create an ecosystem of meta-tx, taking efficiency into consideration because each contract that has permissions needs to find a meta-tx way to make a 3rd party relayer pay for his tx.

---

We can provide an example with LSP0, If Bob has an LSP0 and have two controllers, his EOA and Alice's UP.

If Bob wants to execute a payload without paying gas fees, he can sign the payload and submit it to a relayer that can execute his payload on the KeyManager, the KeyManager receiving the signature and the payload can verify through ECDSA that the signer is Bob that have all permissions to execute successfully.

If Alice wants to create a tx on Bob's LSP0 and her LSP0 is owned by her EOA, there is no way for her to submit this tx through a relayer, she is forced to execute from her EOA by paying gas fees. And the only way for her to execute without paying is to have her LSP0 owned by an LSP6 that supports relay call, so the execution would be something like this:

While we push for an ecosystem full of contract-to-contract interactivity with smart contract accounts and taking into consideration efficiency, there is a need to verify signed messages of smart contracts to support all relay calls type and simplify the execution chain.

Solution

One way to solve this issue is checking if a signature of a contract is valid through ERC1271, in this way relayers instead of just executing payloads of EOAs controllers, can also execute payloads of contracts controllers based on their logic of verifying signature with ERC1271.

Going back to Alice and Bob example of LSP0, now Alice having her LSP0 owned by her EOA can make a relay call, by going with the logic inside the isValidSignature of her LSP0 contract, which says that if the owner is an EOA, then the contract checks if the signature is valid through ECDSA and returning the address of the owner.

And if Alice's LSP0 is owned by an LSP6, the verification mechanism of isValidSignature(..) in LSP0 will call isValidSignature(..) on LSP6, validating the call if the address recovered through ECDSA have SIGN Permission.

Thinking that all LSP0 will be associated with LSP6 is misleading, also thinking that all contracts controllers will only be LSP0 is misleading, we can have some sort of logic-based contracts that can validate signatures based on some sort of time-lock + signatures or secret hash + signatures, etc.. , that's why we need to allow relay contract execution regardless of the type of the contract, if the latter supports EIP-1271.

Changes Needed

To Allow this behavior, non of the core logic of the KeyManager needs to be changed, it's either having a new overloaded function that takes the address of the contract controller that is supposed to support ERC1271, or we can add the contract address to the first parameter of executeRelayCall, and inside the function:

• Checking the length of the signature param
• If 65 it's an EOA verification through ECDSA (what we currently have)
• If the length is 85 then it's the signature + an address, which resolves the verification through 1271 by calling isValidSignature(..) on the address (last 20 bytes).

If this method seems too hacky we can have separate functions, that have an additional address contract parameter.