Yes, I completely agree with what Yoav said:
-
For modular wallets, plugin is not enough. This is the solution we implemented (a detailed document will be released by David in a few days):
- Plugin is a collection of hooks.
- Because the Pre-UserOpValidate hook, plugins can only access associated storage. To address the issue of dynamic storage for plugins, we introduced
Plugin storage(plugins can read and write the wallet’s storage, but each plugin has its own separate storage).
2. There is a significant use case: 2FA. We introduced out of signature data in the Pre-UserOpValidate hook to address this. Even if the data are outside the signature, data security can still be ensured easily (【1】 【2】). To avoid conflicts when different plugins parse guardData, the wallet must parse ExtData and pass it to the respective plugin based on its needs.
-
Module is an external contract authorized to execute a specific list of functions.
-
As Yoav mentioned, a permissions model needs to be defined. In our implementation, we require the Permission list to be pure [module] pure [plugin]. However, this cannot solve the problem (as it is actually invoked using staticcall on chain) unless the contract source code is audited to ensure “pure” functions.
-
Yoav suggest can use sstore2, and Dror suggest can use Bundler.UserOpValidate.simulate. All reasonable. However , taking into account security and simplicity of implementation, I suggest using an
Request -> Approval Model:-
Plugins have a permission request manifest. When users add a plugin, they need to input the corresponding permission manifest code. This ensures that all necessary permissions are granted, considering that if only certain hooks are allowed, the plugin may not function properly.
-
Modules have a permission request manifest. When users add a module, they need to input a list of permissions (
bytes4[]) that the user allows. This allows customization of permissions based on user requirements.
-
-
-
I suggest removing ExecutionMode.DELEGATECALL because it poses unresolved security risks that cannot be mitigated.
- In our current implementation, only the
upgradeTo(address)function ( in UpgradeManager.sol) can access delegatecall, but this function is accessible to any authorized module:- Users have the freedom to choose their wallet implementation (with a 48-hour waiting period).
- In case of any big issues, we can add our new version of the implementation to the whitelist, allowing users manual to upgrade immediately.
- [context: by default, users trust our whitelist, and only modules in the whitelist can be added immediately. Other modules need to wait for 48 hours to take effect.]
- In our current implementation, only the
Looking forward to the author’s reply.