One common design pattern in solidity is to fail as early as possible to minimise the gas spent on reverted txs.
However, this can cause problems when building smart account modules, specifically validators. Here's why:
3
1
10
Replies
Validators are called by smart accounts during the validation phase of ERC-4337 to determine whether a signature is valid and a UserOperation should be executed
1
0
1
Bundlers will simulate a userOp with a mock signature to determine the rough amount of gas that will be spent during the validation phase (which informs the validationGas added to the UserOperation)
1
0
1
However, if a validator exits early and there is a lot more compute that would be performed with a valid (not mock) signature, then this can cause the bundler to underpredict the gas limit which will cause the userOp to fail
1
0
1
One example is with a multi-factor validator. One common way to build it would be to return early (and not check the remaining factors) if any factor returns false. However, this runs into the problem described above and will cause an issue in production
0
0
2
@abstractooor
Yup, this becomes a problem with complex modules with lots of failure cases.
Isn't the correct of doing this would be so state overdrive the validator such that it passes validation with a dummy signature M
1
0
2
@ankurdubey521
This would require a bundler to know how a module works though and what storage slots need to have which values, right?
1
0
0
@abstractooor
The optimal solution is actually the anti pattern where you implement the code path of validators in such a way that thereβs no short circuit. And defer the response until all code path has been executed. Also to make sure the dummySig consumes the max gas.
3
0
1