v3.0
What's Changed
Full Changelog: v2.4...v3.0
Kernel v3.0
ERC7579 wallet
Kernel V3 is adopting the erc7579 standard to leverage the plugin ecosystem built by the community.
Kernel V3 aims to be the fully compatible wallet for erc7579, while maintaining the high security standards.
erc7579 has these following modules
- 1 - Validator
- 2 - Executor
- 3 - Fallback
- 4 - Hook
- 5 - Policy
- 6 - Signer
Validation Methods
For validation, kernel v3 has 2 types of validation methods, using simple erc7579 validator modules or using permission system that is built with N policies and 1 signer.
For both validator and permission, they can be assigned to the function selector to check if the validator or permission is allowed to call specific userOp.callData[0:4](or userOp.callData[4:8] if userOp.callData starts with executeUserOp)
And for both methods, they can be assigned with specific hook. If validation has been done with the method that needs hook, then userOp.callData will go through executeUserOp , which is optional interface for erc4337 account, to let wallet know of validation phase info on execution phase.
And executeUserOp will trigger the hook before/after the call.
erc7579 Validator
using erc7579 validator is nothing special, wallet will forward the requested userOp and userOpHash to validator with validator.validateUserOp(userOp, userOpHash) and return the result back to entrypoint.
Modular Permission
Modular permission is designed to have the most composable validation method.
Main focus of the modular permission is to separate the signer and policy and the set of the composed list can be identified by permission id.
Why Modular Permission?
Most of the current “modular smart accounts” use single validator to use within a validation phase. This works but this hurts developer experience and user experience.
For example, let’s say there is a session key validator plugin, and session key validator can filter the userOp.calldata and check if signature is properly with secp256k1.
This is fine but if, a developer, wants to build a session key plugin that checks the signature with secp256r1 to introduce passkey usage.
Developer needs to build a new session key plugin that works for this, even though there is audited version of “session key k1 signature validator” / “r1 signature validator” and get audited for the new plugin.
But what if we was able to separate the “session key validator” into “session policy” and “k1 signer”, and “r1 validator” can be “r1 signer”. In this case, developer can just use “session policy” and “r1 signer” without any issues.
And if a user wants to be extra cautious about the session key and wants to add the “time validity” on top of the requested permission, it is not possible without writing new contract if we rely on static plugin implementation(including hardcoded pre-validation hooks).
Again, if we have a composable modular permission, then it means that user can add more policy on top of what is requested, thus making it more secure and user friendly by making user choose what permission they are going to grant.
Modular Permission in Kernel v3
In kernel v3, or at least on kernel v3 initial launch spec, permission can be composed of N policy(maximum of 254) and 1 signer.
You can assign a 4 bytes permissionId to the set, and we call it “permission”.
When you trigger a validation with permission, kernel will go through the policies if the userOp meets the standard, and signer will check if the userOpHash has been signed.
Selectors
For selector, kernel supports 2 options. 1) fallback 2) action
Action will be mapped to specific msg.sig and kernel will delegate call to the action when requested.
If selector installed fallback, it will do erc7579-fallback that will be called with "CALL" instead of "DELEGATECALL" by having 20bytes of the address(this) encoded at the end of the msg.data
Executors
Executors are external entities that can call “executeFromExecutor” to account.
Kernel will map a hook per executor to make sure executor can call those data
Hooks
Hooks are widely used on kernel v3 to properly control the access to the operation.
Hooks should be assigned to 1) validator 2) action/fallback 3) executor to make sure the execution is handled with proper access control
