feat: add call flow spec for validation and execution

[adamegyed]

Motivation

We want to formally specify the requirements for modular accounts on ERC-6900 v0.8 with respect to call flows for validation and execution.

Solution

Remove the old spec for validation and execution, which was needless restrictive and verbose.

Add a spec for ERC-6900 v0.8. Includes:

• Validation types: user op, runtime, signature
• Implementation-defined (aka non-standardized) selection of validation functions.
• Validation applicability: global or selector-based
• Hook execution ordering
• Self-call validation restrictions for execute and executeBatch.

Also adds ERC-1271 as a mandatory interface for modular accounts.

This PR does not yet update the spec for the install flows in v0.8.

[fangting-alchemy]

Suggested change

	The account MUST define a way to pass data separately for each validation hook and the validation function itself. This data MUST be sent as the `userOp.signature` field for user op validation, the `authorization` field for runtime validation, and the `signature` field for signature validation.
	The account MUST define a way to pass data separately for each pre-validation hook and the validation function itself. This data MUST be sent as the `userOp.signature` field for user op validation, the `authorization` field for runtime validation, and the `signature` field for signature validation.

Is the second sentence necessary?

[fangting-alchemy]

We should use pre validation hook(s) for all validation hook(s) references to be precise and consistent.

[adamegyed]

Is the second sentence necessary?

Yes, if that is not standardized, then the modules may be written to expect the data in different locations, which would result in modules that are compatible with some 6900-compliant accounts, but not all.

[adamegyed]

We should use pre validation hook(s) for all validation hook(s) references to be precise and consistent.

I thought about this, but I think the fact that there are not post validation hook(s) means that the "pre" wording doesn't differentiate it any further. It gives some insight into when to expect it to be run, but that's not really necessary for this section of the spec.

[fangting-alchemy]

I definitely get what you mean. However, I think there are benefits to have pre as it makes it a bit easier to understand how it works for new comers to (4337 and 6900) who does not know a ton how exactly validation works yet.

[jaypaik]

I'm leaning towards just calling them validation hooks (adding "pre" might signal that there exists a "post", similar to execution hooks). But I see that we do reference "pre validation hooks" in the prior paragraph. We should be consistent everywhere.

[fangting-alchemy]

Good point on signaling "post". Happy to go with "validation hooks" with consistency.

[adamegyed]

Updated to be consistent

[fangting-alchemy]

Suggested change

	The set of validation hooks run MUST be the hooks specified by account state at the start of validation. In other words, if the set of applicable hooks changes during validation, the original set of hooks MUST still run, and only future invocations of the same validation should reflect the changed set of hooks.
	The set of pre validation hooks run MUST be the hooks specified by account state at the start of validation. In other words, if the set of applicable hooks changes during validation, the original set of hooks MUST still run, and only future invocations of the same validation should reflect the changed set of hooks.

[Zer0dot]

I think it's been decided to just use "validation hooks" as the consistent term yeah?

[fangting-alchemy]

We should state the risk where if the isPublic function changes states, omitting validation can be dangerous.

[adamegyed]

Do we need that extra detail? I think that is obvious from the spec stating that validation can be skipped if the function is marked public.

[fangting-alchemy]

The code comment on isPublic is Whether or not the function needs runtime validation, or can be called by anyone. .
Why didn't we name it skipRuntimeValidation flag?

My concern of the name isPublic is that it does not indicate that it can potentially be state changing. We only skip runtime by using the old ALWAYS_ALLOW.

[adamegyed]

Why didn't we name it skipRuntimeValidation flag?

That does seem like a good idea, makes it more literal. Maybe less obvious to connect it to view functions, but it would match the naming of other flags.

[fangting-alchemy]

Maybe less obvious to connect it to view functions

They don't have to be view functions is the whole point (to allow state changing though I am not sure what the use cases are, maybe exec timelock tx after trigger time or sth), right?
Otherwise, it can just be isPublic or isPublicView or isView, etc.

[adamegyed]

Makes sense. Let's update that in a different PR, because it also requires code changes.

[Zer0dot]

This, in other words, means that the result of UO validation should always be the longest possible time bound that satisfies all time bounds form hooks , right?

[adamegyed]

Yes. Technically I think it is accurate to describe it as the "longest time bound that satisfies hooks", but intuitively, the operation of intersecting them is to take the min. E.g. if you have ascending timestamps $t_1$, $t_2$, $t_3$, $t_4$, and hook 1 returns the range $(t_1, t_3)$, and the validation function returns $(t_2, t_4)$, the result of validation should be the range $(t_2, t_3)$.