Feature request: Complete support of kernel smart account

[KONFeature]

It could be very nice to have a complete support of the kernel smart account.

The pr: #42 only contain very basic implementation of a kernel smart account with an ecdsa validator, and sending transaction only via that default validator using the sudo mode.

Supporting other validator, enabling validator on the fly, or using validator enabled but not default one, is missing from that implementation.

If someone is brave enough, and have enough time, to implement that, here is a quick graph of how the validator stuff work with the kernel smart account: https://excalidraw.com/#json=-gCgSizH7vZ7ULgv2IS9T,Z5P0QeeNxRxp6StJNvdCYA

[KONFeature]

Full Kernel smart account support

Goal:

• Support every features of Kernel smart account, custom validators, temporary validator, and enabling validator on the fly when sending a tx.
• Have some really generic stuff to ease the introduction of new validators after hand
• Have the ability to use a Kernel smart account with different validators type

For small initial research on kernel validators works, here is a small graph: https://excalidraw.com/#json=-gCgSizH7vZ7ULgv2IS9T,Z5P0QeeNxRxp6StJNvdCYA

Proposal

Interfaces:

• kernelValidator
  • Not linked to a kernel account
  • Should expose some base method
    • getEnableData(account: Address): Hex -> Get the enabling hex data of this validator for the given kernel account
    • getDisableData(account: Address): Hex -> Get the disable hex data of this validator for the given kernel account
    • isEnableFor(account: Address): Promise<bool> -> Check if this validator is already enable or not for the given smart account
    • isDefaultFor(account: Address): Promise<bool> -> Check if this validator is the default one for the given smart account
    • signUserOp(params: {userOp: UserOpertion, account: Address}): Promise<Hex> -> Generate the sign data for the given user op
    • signMessage({message: SignableMessage, account: Address}): Promise<Hex> -> Generate a signature for the given message
• kernelSmartAccount
  • Extend regular smartAccount
  • Two options during creation:
    • Setup with a defaultValidator: kernelValidator , to have a pre computer address
    • Setup with no validator, but an already deployed address, like accountAddress: Address (should ensure it's well deployed in that case)
    • If both param present, should ensure that the pre computed address match deployed address param
• The type of a kernelSmartAccount should use a few conditional typing stuff:
  • If setup with no defaultValidator during init, call on getInitCode(), signUserOperation(), signMessage(), signTypedData() are requiring a validator: KernelValidator as param
  • If setup with a defaultValidator, this method should have an optional validator as param
• Expose a few specific kernel methods:
  • getValidatorState(validator: KernelValidator): Promise<"enabled" | "disabled" | "default">
    • Check if the given validator is enabled / disabled for the given smart account
    • If the validator is enabled, check if it's the default one for this kernel smart account
  • setDefaultValidator(validator: KernelValidator)
    • Set the validator as param the default one
    • If not enabled yet, batch call of enabling validator for the account & setting it as default on the kernel account
  • disable(flag: Hex): Promise<void> -> Disable the kernel account

Then, for the logic part, here is a quick scheme of the flow I have in mind (sry not a mermaid graph, so much easier to do with ecxalidraw aha): https://excalidraw.com/#json=6FFLoatem-LgNidFrEvC6,_y3qgkhEE5O6gWldiogksQ

Here is a list of the validators available right now

• ECDSAValidator -> Easy to implement
• ECDSATypedValidator -> Also easy to implement
• WeightedECDSAValidator -> Require additional voting logic (approve, veto etc, for a tx proposal)
• P256Validator
• KillSwitchValidator
• SessionKeyValidator
• ERC165SessionKeyValidator

[plusminushalf]

kernel.js has a better support for kernel over all and for now permissionless will support the minimal version.