Skip to content

Releases: zerodevapp/kernel

v3.1

19 Jun 17:32
03f7f5c
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v3.0...v3.1

v3.0

23 Apr 00:53
Compare
Choose a tag to compare

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

v2.4

22 Apr 07:04
e00c66a
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v2.3...v2.4

Kernel v2.3

15 Nov 15:31
90fa72e
Compare
Choose a tag to compare

What's Changed

  • executeDelegateCall support
  • protected eip1271

New Contributors

Full Changelog: v2.1...v2.3

v2.2

22 Apr 07:09
c389a57
Compare
Choose a tag to compare

What's Changed

  • V2.1 typed primitives by @leekt in #26
  • Deploy/v2.1 by @leekt in #28
  • Deploy/v2.1 by @leekt in #29
  • feat: added back the force unblock in kill switch validator by @SahilVasava in #34
  • fix: modified kill switch action to disable kill switch when unblocking by @SahilVasava in #35
  • feat: verify typed data and ETH message signatures on SessionKeyOwnedValidator by @0xca11 in #37
  • fix: use absolute imports to fix forge coverage by @0xca11 in #38
  • [WIP] Recovery plugin and weighted ecdsa by @leekt in #31
  • V2.2 lite by @leekt in #39

New Contributors

Full Changelog: v2.1...v2.2

Kernel v2.1

09 Aug 15:21
5f8e8f4
Compare
Choose a tag to compare
V2.1 (#25)

* v4.0.0-beta.10

* updator draft

* removed temp kernel

* create account 142873

* added validCaller

* forge fmt

* small touch on comments

* validCaller changed

* test for external call

* renamed modifier

* removed callcode test

* forge fmt

* added snapshot

* custom errors

* using gas() for prepay

* removed unused copy

* payable for gas optimization

* using solady for optimization

* forge fmt

* cache storage for optimization

* admin less erc 1967 optimization

* unchecked blocks

* validator to payable

* using constant for gas optimization

* removed return

* via-ir for optimization

* change in order of ecdsa validator to lower the gas cost

* squeezing gas

* more squeezing

* removed exec

* kernel helper in yul

* more optimization

* updated aa dependency

* V2.1 optimize (#20)

* factory merged with erc1967 minimal factory

* Kernel Storage to abstract the initData setting

* only one factory to decrease deployment gas

* test cleanup to properly structure the test

* removing killswitch test too

* KernelLite PoC

* files for setting a proper gas report

* using memory directly to reduce gas

* changed order for validator to reduce gas cost

* optimize only

* remove kernel lite gas report

* internal functions for erc1967factory

* change kernel sig order for validUntil and validAfter (#21)

* forge fmt

* fix: parsing typo and mode(1)

* V2.1 session key (#22)

* session Key debug done

* foundry viaIr setting enabled

* forge fmt

* V2.1 stake factory (#23)

* gas optimization by using memory for validateUserOp

* optimization with calldata parsing

* stake for factory

* stake factory

* report

* fmt

* removed unused file

* session key now filters the operation

* fix: using proper bytes for parsing operation

* script for deploying kernel/kernel factory for v2.1

* script for deploying session key

* deployed to all testnet

* kilswitch (#24)

Kernel v1 sessionkey fix

29 Jul 02:46
Compare
Choose a tag to compare

kernel v1 session key short circuit issue fixed