feat(v2): Add signature enum to user operation signature validation

[adam-alchemy]

Motivation

• When we validate owner signatures for both user op validation and 1271 signature validation, if the owner is a contract account and there is more than one owner, then the signature verification must loop over all the owners and attempt calling isValidSignature. The problem this causes is gas inefficiency and a potential DOS attack a contract owner can perform, where it wastes all gas available in the call to prevent future signature checking.
• When the looping happens during user op validation, the owner addresses will all be warmed by the dummy signature, despite not being warmed when ECDSA verification succeeds. This leads to incorrect gas estimation when the execution step of the user operation interacts with an owner EOA, due to the account being warmed during estimation but not execution.

Solution

Two pieces of information may be useful - which owner the signature is for, and whether or not the owner is a contract or an EOA. However, the looping behavior might actually be useful for calldata-constrained networks like Optimism, Base, Arbitrum, etc.

So, the proposed solution is to define a 1-byte enum in the front of the signature to allow selecting between the different signing mechanisms .

• Case 0: EOA signature
  • Signature format: 1 byte enum || 65-byte EOA signature
• Case 1: Contract signature, no address
  • Signature format: 1 byte enum || arbitrary-length contract signature
• Case 2: Contract signature with address
  • Signature format: 1 byte enum || 20-byte contract address || arbitrary-length contract signature

This PR only handles the user operation validation checks. A stacked PR will handle the signature verification for the 1271 case. Enum values for the 1271 case have already been included here.

[jaypaik]

Are we going to be using the bits for checks later?

If not, maybe it's better to just go with regularly incrementing enums.

If we are, maintaining enums might get messy as we add on new signature types. So maybe just maintain these flags in a library and introduce helper functions?

[adam-alchemy]

I was planning on using the bits during the 1271 signature checking, but I'll take a look and see if it makes sense to just drop this down to an enum.

[jaypaik]

Ok! Edited my earlier comment to suggest a library instead if we're using the bits.

[adam-alchemy]

I previously had this as just iszero in assembly, but I figured it might make sense to keep this simple and readable. The gas difference is about 20, so not very significant, but also OK to switch back.

[jaypaik]

Was wondering the same thing. I think this reads better!