[draft] feat: [v0.8-develop] composable validation example

[adamegyed]

Motivation

It would be useful to have a demonstration of a composable validation workflow using existing account behavior and interfaces.

Solution

Ports over example contracts from the closed PR #84, and modify them to work without any account changes.

The two ported validation plugins are MultisigPlugin and ECDSAValidationPlugin. There is a test contract ComposableValidation.t.sol that has examples of:

• Using the ECDSA validation on its own.
• Using the composable multisig plugin to point to two different validation ids within the ECDSA validation plugin.
• Using the composable mutlisig plugin to point to:
  • One ECDSA validation id
  • One multisig plugin validation id, that points to two other ECDSA validation ids

This example uses userOp.sender as the address to look up, and userOp.signature as the signature field. In the validator-experiments repo, these were pulled out as separate fields instead.

Also note, this only demonstrates composable user op validation. Runtime validation and signature validation are not composable here because their interface doesn't have a field for the account - if that were added, they could be composable.

[fangting-alchemy]

The risk of allow a param and have this function be called outside of account can be huge. However does it ensure the caller is sending the correct Account and sender since there is no UO or sig attached?
Example, a caller can sender over AccountA with SenderA for accountB.

[adamegyed]

I think as long as this function is a view function (no state modifications), it's fine to parameterize the account instead of relying on msg.sender. If a validation function calls out to another validation function, it will be part of the internal logic of the outer validation function, and the account will still only trust the output of the function actually installted.

E.g. consider the scenario

account --calls--> validation function A --calls--> validation function B

In this setup, validation function A and B can both take in a parameterized sender. The account will send its own address, and validation function A should send the same account address. But even if it doesn't, there's no security vulnerability or escalation - the account trusts A, but does not trust B to be a validation function.

[fangting-alchemy]

Right. I think in RI, we are covered. Could there be out of context usage of validateRuntime?
Maybe a word of caution is enough.

[adamegyed]

I think we block it from being installed, because it's a known selector.

Other than that, I think we should be good? If someone calls it directly with execute/executeBatch, it shouldn't do anything.

[fangting-alchemy]

Actually, wouldn't this violate the storage access rules of 4337?

[adamegyed]

The account address is the innermost mapping lookup, so the storage should be associated. If we did ownerInfo[userOp.sender][functionId] it would not be associated.

As for switching from msg.sender to userOp.sender, It should be OK as long as the account, and any validation functions installed on the account, choose to send the correct account address during validation. When going from the account to the outermost validation function, it will always be the correct address, and each inner validation function call needs to also propagate the correct address. If it doesn't, then it would be a bug in the validation plugin that makes it not usable via a regular bundler.

[fangting-alchemy]

If we did ownerInfo[userOp.sender][functionId] it would not be associated.

Is this a quirk? How would switching the order make a difference?
ownerInfo[userOp.sender][functionId] => keccak256(abi.encode(functionId, keccak256(abi.encode(userOp.sender, p))))
v.s.
ownerInfo[functionId][userOp.sender] => keccak256(abi.encode(userOp.sender, keccak256(abi.encode(functionId, p))))

The docs are not very clear. Based on what they say there, both above should be valid since the slot is uniquely related this address.

[adamegyed]

The docs state that the following is one way to get an associated storage slot:

keccak256(A || X) + n

Where A is the associated address, X is any value, and n is a number between 0 and 128. By solidity's convention, X will be the "virtual" storage slot of the mapping, which doesn't actually hold anything.

In the first case, where it is not associated, the hashing to get the slot is:

keccak256(abi.encode(functionId, keccak256(abi.encode(userOp.sender, p))))

The function ID is not the associated address, so the output of this expression will not be an associated storage slot. The address gets included in the nested keccak256 call, but that expression becomes X, not A, in the associated storage calculation.

I found this resource to be helpful in understanding solidity's builtin calculation of mapping storage slots: https://programtheblockchain.com/posts/2018/03/09/understanding-ethereum-smart-contract-storage/

[fangting-alchemy]

Missed keccak256(A || X) + n from the docs.
Good catch The address gets included in the nested keccak256 call, but that expression becomes X, not A, in the associated storage calculation..

Have any idea why keccak256(X || f(A)) + n not included? If the goal is uniqueness, it satisfies. Might be a bit hard to enforce the rule in the client/bundler.

[adamegyed]

I think if you include both, then it loses uniqueness. For example, a mapping(address outer => mapping(address inner => uint256)) value; would be associated with both the outer and inner addresses. This happens with a lot of ERC-20 allowances - by default, the OZ ERC20 contract will have allowances associated with the spender, instead of the token holder.

As for why they didn't choose keccak256(X || f(A)) + n instead of the actual, I think it's just easier on the tracer code within the bundler to detect. But it does make it more annoying for solidity devs, lol.

[fangting-alchemy]

Having an id only on the plugin won't expand the plugin validation function to be able to be installed on the account more than once without the account essentially stores validations differently (not use FunctionReference as a key).

Plugins can build the storage whatever way they want as long as they dont violate the rules.

Like we discussed in the sync today, using an ID or not does not change if a validation plugin can be a layered validation (to be used by account's other validation functions).

[adamegyed]

If the functionId (or validation id, entity id, whichever name we choose) does not specify a new storage space in the plugin, then I think that would prevent multiple installs. On the second install, the storage would overlap any previous installation, and prevent unique configurations for the installations in different places.

And while you technically can compose validation (layer it) without allowing multiple installations at once, it means you would need to deploy a new contract instance of the validation plugin each time you want to install it again, which is more expensive than allowing multiple installations via an ID.

[fangting-alchemy]

What I meant is that having the ID only on plugins won't enable the feature (multiple installation with the same validation plugin).
The account need to change how it organizes validation functions to enable this feature.
In summary, this feature will require account changes and how account and validation plugin communicates (during installation). One example is here.

[adamegyed]

Oh I see, yes that will need to not be pulled from the manifest. The account-controlled auto assign mechanism works, or we can make it user-specified.