feat(v2): Add enum support to MultiOwnerLightAccount 1271 validation #42
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
As described in #41 , not differentiating between contract owners and EOA owners could lead to incorrect gas estimation, and the looping checks also present a DOS vector.
This needs to also be fixed for 1271 signature validation.
Solution
Keep the existing implementation of the Solady ERC-1271 pattern, where the length and hash equivalence are used to determine whether the transparent EIP-712 pattern or the opaque signature are used.
However, within the internal implementation of
_isValidSignature
for MultiOwnerLightAccount, which uses the derived hash and trimmed signature, perform the enum split to determine whether to do EOA ECDSA validation, specified contract owner 1271 validation, or looping 1271 validation.Also, since this approach avoids using the bitmap logic of the
SignatureTypes
enum, remove all unused enum types.