feat: add flag for user op validation and pack efficiently

[adamegyed]

Motivation

While it helps to group the 3 types of validations together (user op, runtime, and signature), they do have certain differences in how they work. For example, while a hook can relatively easily limit what addresses a validation can call from execute/executeBatch via user ops or runtime calls, it is not as straightforward for understanding the context of signatures within a hook. Thus, we've introduced flags into the base account to differentiate between validations capable of producing a 1271 signature, and those that aren't.

There is a similar difference between user op and runtime validation, and that is the implicit ability for user op validation to spend native tokens on gas. Additionally, if permissions aren't fully enforced, there may be some paymasters that user op validations can make use of that spend other account resources, like tokens or some offchain balance.

Thus, it would be useful to have a similar flag limiting a validation's ability to validate user ops. This could be used for setting something to only be an ephemeral signature validation for a specific login. Or, you may wish to more actively protect the account from modules with direct call access, like a cold storage module or an account recovery module.

Solution

Add a third validation flag, isUserOpValidation, to the ValidationConfig type and ValidationData in storage.

Check that this flag applies in _execUserOpValidation, revert otherwise.

Pack ValidationConfig into a bytes25, rather than a bytes26.

Add this to the loupe struct.

Add tests for isSignatureValidation and isUserOpValidation flags.

Update existing tests.

[Zer0dot]

Is there a reason we didn't introduce a runtime validation flag? As it seems right now, you can opt out of using a validation for UOs and 1271, but you can't opt out of runtime. Right?

[jaypaik]

Nit: would be helpful to describe these UDVTs inline with NatSpec comments.

[adamegyed]

Yep, will port over the comment blocks from the corresponding libraries

[fangting-alchemy]

Another things I find that will be helpful is have a line comments on what the 25 bytes for in the IModularAccount. Each time I have to find the lib and figure out where each flag/data locate.

[adamegyed]

Updated! I think this includes what you're describing @fangting-alchemy

[adamegyed]

you can opt out of using a validation for UOs and 1271, but you can't opt out of runtime. Right?

This is correct. I think logically, the way to opt-out of runtime validation is to have no selectors added and to not be a global validation - then, there's nothing the validation may call on the account. But if you have UO validation but not RT validation, it's still possible to make calls, in addition to also spending gas, so it doesn't seem valuable to remove the RT validation as a matter of permissions enforcement.

[Zer0dot]

This is correct. I think logically, the way to opt-out of runtime validation is to have no selectors added and to not be a global validation - then, there's nothing the validation may call on the account. But if you have UO validation but not RT validation, it's still possible to make calls, in addition to also spending gas, so it doesn't seem valuable to remove the RT validation as a matter of permissions enforcement.

Makes sense, thanks! Only one other comment, is the benefit of using a uint8 flags value instead of just getting the individual flags codesize?

No strong opinion either way, I think flags retrieved as a uint8 are fine too. Beyond that, lgtm!

[adamegyed]

is the benefit of using a uint8 flags value instead of just getting the individual flags codesize?

It was actually stack-too-deep 😅