[Improvement] Validation and pre-validation merge

[adam-alchemy]

• There is a heavy overlap between what a “pre validation hook” and what a “validation function” does. There are 2 historical reasons why they’ve been separated:
  1. When multiple validation functions coexist (previously with std exec validators, and potentially in the future with calldata wrappers), you want one item to address a “validation group” by. The validation for a specific function is currently defined by the set of {pre validation hooks + validation function}, but to pick which of these should be run out of multiple “validation groups”, you need some way to identify them. The differing type helped with this.
  2. It is unclear what should be done if a pre validation hook returns an aggregator. It is straightforward to coalesce time ranges and valid/invalid flags, but it is unclear what should be done if two differing aggregators are reported.
• If we can find a way to address the above 2 points, merging these concepts would greatly reduce complexity in the standard.

Some background on why we might want the concept of pre validation hooks in the first place (as opposed to just having pre/post execution hooks): https://ethereum-magicians.org/t/erc-6900-modular-smart-contract-accounts-and-plugins/13885/31

[jaypaik]

Related: #4

[jaypaik]

The following diagrams illustrate the problems and the end state we may want to get to.

Current state

This is the current state, where each execution function (e.g., foo()) can have exactly one user op validation function and/or runtime validation function assigned. There may be multiple pre validation hooks assigned for each type (pre user op validation hook or pre runtime validation hook) that run during the validation phase. Note that pre user op validation hooks are prohibited from returning an authorizer value other than 0 or 1, and only the user op validation function is allowed to return an aggregator address. The results of each hook and validation function are ANDed together.

---

Merging pre-validation hooks with validation functions

This is what it may look like if we merge the two components into one. Multiple validation functions are assignable to each execution function, and they are all serially run and the results ANDed to return a final result. The problem to address here is pointed out in ii. above. If more than one user op validation function returns an aggregator, how do we coalesce them?

---

Allowing different validation function groups to be called

With #4, we want to allow multiple validation functions to be applied to a given execution function, and be able to specify which one to run for a given call. For example, one might want to call execute by authorizing both with an EOA or a passkey, which use different validation functions from different plugins. Stacking these validation functions together and ANDing them together does not make sense in this context. We need to separate these and allow them to be called in isolation, passing validation if just the chosen validation function passes.

And with the merging of pre-validation hooks and validation functions, each of those validation functions may also have additional validation functions stacked on top within its "group". How do we install and appropriately group these validation functions? This is the problem that is pointed out in i. above.

[jaypaik]

Some additional thoughts...

Adding in the concept of validation function "groups" definitely increases complexity. Instead of associating "secondary" validation functions (currently known as pre validation hooks) to each "primary" validation function to form these groups, how about associating them to the execution function, so that they are executed no matter which "primary" validation function is used for the call? Something like this:

"Secondary" validation functions apply over all "primary" validation functions

There may be convincing use cases where certain logic is only applicable when routed via certain validation functions, so please comment here if you have concerns with this design.

What you might also note is that now we need to distinguish between "primary" and "secondary" validation functions:

• Primary validation function: Can be chosen per call (via #4), and is allowed to return an aggregator address as its authorizer.
• Secondary validation function: Applies over all primary validation functions defined for an execution function, and cannot return an aggregator address.

Secondary validation functions are looking more and more like what we had defined pre validation hooks to be. Because this design warrants a difference between primary and secondary validation functions anyway, could it be that it may be simpler just to keep pre validation hooks as is?

---

Bringing back pre validation hooks into the design

[adamegyed]

Adding one additional benefit of not merging the two interfaces: with the naming distinction between pre-validation and validation, it is more obvious to the reader that they serve different roles. To generalize, pre-validation hooks often tend to apply permissions or restrictions on what may be done with a specific validation function, while the validation function itself provides the actual "authorization" of an action - such as a signature check or caller check (msg.sender).

If these two concepts are merged, then yes we have one fewer interface, but responsibility now shifts onto the user (or developer, library, SDK, etc) to manage these two different categories of validation functions. If, for instance, the permission-enforcing functions are added but not the "authorization" check, then anyone could perform the actions within the permission bounds. The two categories of pre-validation & validation provide some context & connotation behind what they do that is useful.

[Zer0dot]

+1 to keeping them separate. I was in the opposite camp, but the logical separation between validation and authorization makes conceptual sense to me.