ERC-6900: Modular Smart Contract Accounts and Plugins

EIPs
32

Sorry if this doesn’t make sense, but why can’t validateUserOp just be a module/plugin? The module can then use a runtimeValidator which appropriately casts the data to (UserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds) and does whatever additional checks it needs to do like signature validation.

33

Good question This is something we chose to “bake in” to the standard to allow the account to be a single source of truth for the modular account config.

One of the core parts of the standard is allowing for multiple types of transaction validity to coexist at the same time in an account. To do this, the logic of validateUserOp switches and is routed differently based on what function is being called, as specified by the selector in the first 4 bytes of userOp.callData sent to validateUserOp. If the switching behavior of validateUserOp is implemented as a plugin, then the relationship between the function selector and which validation function to run would have to be implemented within the plugin, and the “modular account config” would end up being in 2 locations.

If we only wanted one logical component to run during validateUserOp, then it would simple to make a plugin that just defines the function with its single implementation. But, since we want to allow different types of user ops to be validated differently, and for this validation logic to live in separate contracts that can be added or removed, then the plugin defining validateUserOp must now manage the execution → validation function mapping and the overall state of installed / uninstalled plugins. The reason validateUserOp is given special treatment and required to be a native function for 6900 is to consolidate the installation management and modular features, so plugin developers don’t have to re-invent modularity.

Would love to hear more of your thoughts too – is this something you’re interested in for supporting other validity checking functions?

34

Yeah, I was trying to think how wallets could install a plugin to support ERC-7521, which requires a similar validateUserIntents function. I’m still confused why whatever you would have installed as a Pre User Operation Validation Hook couldn’t just be installed as a Pre Runtime Validation Hook for the function validateUserOp installed in some base 4337 plugin. This would allow you to stack any sort of additional rules that apply to specific user operations. It would be kind of ugly to add another exception to ERC-6900 for ERC-7521 user intent validity checks. It would also help reduce ERC-6900 complexity if there were no special exceptions at all.

35

Hi all, we are excited to share the latest update to the ERC spec. This completes the update we began with the changes we posted on August 23, and focuses on expanding and refining the permissions system for plugins. This change also allowed us to streamline parts of the spec by removing the special-case validation for standard execute functions. Finally, we have updated visual and text portions of the spec to make it easier for builders and stakeholders to engage with.

As a next step, we’ll be releasing a Reference Implementation incorporating all of these changes in the next few weeks. Stay tuned!

The full changelog, along with areas we’re still thinking through, can be found below.

ERC Changelog

  • Expanded permission system
    • Plugins that define execution functions can optionally define sets of permission strings for each function to indicate their level of sensitivity. These can be discovered with view calls by wallets and displayed to users when other plugins request permission to use them.
    • Plugins that wish to perform calls through the account to external contracts can request specific permissions to do so. These requests can be scoped to specific address, or to selectors on those addresses, via executeFromPluginExternal. This was introduced in the previous update, and now the plugin manifest struct for permittedExternalCalls is updated to move the field for “any external contract allowed” up one level to the manifest itself.
  • Updates to standard executions
    • Introduce return data to standard execute functions.
    • Removed the “multiple validation functions” special casing for the standard execute functions. This was originally added specifically to provide expanded capabilities for plugins, but using validation functions to do so ended up being rather cumbersome. It also introduced an additional difficulty for wallets preparing calldata. Since plugins no longer execute through the standard execute functions, it is therefore unnecessary to support multiple validation functions for the standard execute functions.
      • This also removes the validator based hook assignment in the plugin manifest used to special-case standard execution hooks.
      • This also removes previous account storage fields.
      • Together, these changes greatly simplify the account storage requirements to be ERC-6900 compliant, without compromising on feature capabilities.
  • Updates to installPlugin and uninstallPlugin
    • The spec is now more open-ended in implementation choices for how accounts should maintain consistency of installations, but requires that consistency is enforced.
      • For instance, one wallet implementation may choose to put installation data into storage, while another may choose only calldata with hash checking.
      • A custom configuration field is added to uninstallPlugin to support implementation-specific data needs. This is expected to be handled via the wallet software itself.
    • Dependency injection in plugin installation is updated to also inject the function ids of the provided methods, as opposed to just the plugin address, to allow for more user flexibility in configuration.
    • Naming change: pluginExecutionHooks ⇒ permittedCallHooks
    • Additional permission-enforcing mechanisms can be done by hooks, with an added workflow for applying permittedCallHooks during install time to protect the account. These hooks may perform custom checks, like decoding calldata to interpret a parameter or checking storage for valid state.
    • Installation of protected function selectors is now prohibited by the spec. Protected selectors include:
      • Function selectors for calls the ERC-4337 EntryPoint contract makes to non-account contracts, such as paymasters and aggregators. Without blocking these, accounts installing unknown plugins with clashing selectors may exhibit unexpected behavior and pay gas for other entities.
      • Function selectors for methods natively defined on the account (non-plugin functions). To help accounts maintain data consistency, these should be avoided.
  • Miscellaneous changes
    • Updated drawings, Terms and refactored Interfaces sections to improve clarity and readability.
    • Simplified manifest structs for validators and hooks, due to the same type of assignment.
    • There are more naming changes on concepts and variable. For example,
      • for clarity, replace usage of the phrasing “execution selector” with just “function selector”. “Execution function” remains as the name for fallback-handling functions on the account.
      • VALIDATION_ALWAYS_DENY ⇒ renamed to PRE_HOOK_ALWAYS_DENY to indicate valid assignment target.
      • VALIDATION_ALWAYS_ALLOW ⇒ renamed to RUNTIME_VALIDATION_ALWAYS_ALLOW to indicate valid assignment target.

Areas we’re still working on

  • Working on the final pieces of a reference implementation to be released in the coming weeks.
  • How the plugins should request access for and use native tokens.

PR: Pull Request #7796​

3 Likes
36

are there implementations of std execute that consider the toggle for delegatecall if value is set to max uint, or otherwise, examples of providing both call and delegatecall in an account that conforms to 6900 (whether in the combined function mentioned above or separately)?

37

related somewhat, I think ERC6900 might recommend, but not require, the convenience of executeBatch in order to simplify its adoption by accounts. Accounts currently can implement a multicall method from libraries like Solady and OZ to batch execute as well as other ops. There are also multisend batching contracts (though this would encourage delegatecall which might be noted). The goal I think should be to maintain simpliciity, like ERC4337 (which only requires that accounts implement one function, validateUserOp). I am a fan of the execute interface and see this an overdue standardization :~).

38

Hi all, we are excited to share the reference implementation of ERC-6900 with you. The reference implementation reflects the most recent revisions to the spec around the plugin manifest and permissions. To maximize alignment between the spec and this implementation, we’ve also made some smaller changes to the spec itself. We describe these in the changelog below.

Publishing these changes is an opportunity to build on the conversations we’ve already been having with the community. Please take a look at the repo and leave comments and PRs or leave comments here!

We’re looking forward to building together!

Ref Implementation

The reference implementation is a draft implementation of ERC-6900. The reference implementation is an example to show how to build an ERC-6900 compliant modular account. It is NOT a production-ready implementation.

The implementation includes an upgradable modular account with two plugins (SingleOwnerPlugin and TokenReceiverPlugin). It is compliant with ERC-6900 with the latest updates.

Important Callouts

  • Not audited and should NOT be used in production.
  • Not optimized in both deployments and execution. We’ve explicitly removed some optimizations for reader comprehension.

ERC Changelog

Most of the changes to the ERC are for clarify and consistency, including

  • More sections are added like expected behavior for different Executors.
  • Struct and interface updates to be more efficient and consistent with reference implementation.
  • Naming changes for clarity and consistency, notably:
    • permittedCallHooks ⇒ InjectedHooks in IPluginManager .
    • validator ⇒ validation / validationFunction in various places.
    • association ⇒ associated in various places.
    • functionSelector ⇒ selector in various places.
    • ManifestFunctionType ⇒ ManifestAssociationFunctionType in plugin manifest.
3 Likes
39

@PixelCircuits Implementing ERC-7521 via a plugin, and making use of these hooks, is a good way to go about it. The specific handling of validateUserOp is needed for transaction validity switching, and we are looking into either making this modular switching step either apply to other functions too, or de-enshrining it’s handling, to better support other transaction flows in the future. Will definitely take this into consideration for that design research as well.

2 Likes
40

@z0r0z Thanks for the suggestions! A while back we made the call to not require accounts to support arbitrary external delegatecall s in the spec, and leave that choice up to implementation, to support a higher maximum security bar for ERC-6900 compliant accounts. Packaging it within the existing execute function using the maximum amount for the value param would technically break this spec, but it seems like a reasonable way to save some gas and code overhead, so it should be fine as an implementation choice. Wallet software for those accounts would just need to be aware of that behavior and display the appropriate warnings and safeguards.

Re: multicall, also something worth considering. Right now there’s one ERC-6900 specific reason to support executeBatch, and that is to avoid duplicating work with validation functions and hooks. Since those outer functions happen before the inner native function, naively doing batch executions only with a multicall and the execute function would result in duplicate ownership / validity checks for each call. With executeBatch, these calls happen once. For hooks that want to do per-execution checks as well, they’re given as parameters all of the requested calls to perform.

There might be a way to write a more custom multicall that allows for aggregation of these checks, but it would take some extra design effort to make sure none of the security invariants are broken. Will explore this idea a bit. Previously we’ve also considered dropping support for the non-batch execute as a way to simplify things, but people generally like the calldata savings.

1 Like
41

What do you mean by “transaction validity switching”? Is this a security concern the ERC-7521 validation function would run into too?

42

I’m referring to what I tried to explain previously here: ERC-6900: Modular Smart Contract Accounts and Plugins - #33 by adamegyed

An ERC-6900 modular account maintains a mapping from function selector → plugin address for execution functions. For validation functions, it also maintains this mapping, even though they all go through the single external function validateUserOp. So, to “switch” which validation function to actually run during the call to validateUserOp, it decodes the function selector from the first 4 bytes of userOp.callData, then does a mapping lookup, then runs the validation function.

If validateUserOp were itself implemented as a plugin’s execution function, it could work. However, it would then run into a problem, having to pick 1 of these 2 options:

  1. The plugin implements validateUserOp with a single “logical” validation function, like checking an owner’s ECDSA signature.
    • This limits the flexibility of modular accounts.
  2. The plugin itself has to re-implement modularity and do the same type of switching as what the account currently does.
    • This makes it harder to do account management and to enforce consistency guarantees.

So, to avoid either of these options, we chose to make validateUserOp a native account function with switching. But like you said, this also limits flexibility for other validity functions. So, I’m currently trying to find a way to possibly genericize the switching process to be able to apply it to other functions as well.

Hope this can be helpful, and let me know if there’s something else I can clarify.

2 Likes
43

So it’s thought that wallets will want different validation logic based on the calldata of the userOp? I’m confused because the reference implementation for 4337 has an example wallet that always uses the same validation logic. I’m also confused because the first 4 bytes of a userOp will almost always be the same (again, in the 4337 reference implementation , userOps are almost always calling the wallets “execute” of “executeBatch” function).

1 Like
44

the reference implementation for 4337 has an example wallet that always uses the same validation logic.

The example wallet from reference 4337 implementation is not meant to be Modular. It is just a SimpleAccount(.sol).

the first 4 bytes of a userOp will almost always be the same

Yes, it can be like this. However, in 6900 it is expected that there will be plenty of execution methods called on MSCA and then forwarded by the fallback function to the plug-in which contains the implementation of this method. So, the first 4 bytes of userOp.callData can be different from execute or executeBatch selector.

45

Has the team heard of a fancy use case where signature verification depends on the calldata?

Also, I can’t really see use cases for wanting to hit a function other than execute or executeBatch. Granted, those functions wouldn’t be able to do script like things that need memory, but that could be solved with executeDelegate and executeDelegateBatch calls. I would say that’s actually preferable to the alternative of requiring a user to install some script function to their wallet. The user can just elect to use scripts (via a delegate call) at sign time instead.

1 Like
46

fancy use case where signature verification depends on the calldata

For example, if there is a method performRecurringPayment(...) in the plugin,
This method can be called by anyone and we do not even need MSCA’s owner sig to validate such an userOp.
So if the userOp.callData[0:4] is performRecurringPayment.selector we want not just some other signature verification algorithm, but no signature verification at all. In this case validation function will verify has the period passed or not and maybe something else.

btw, I’m not a part of the 6900 team. They could have better use case examples.

1 Like
47

I think IPluginManager.installPlugin and IPluginManager.uninstallPlugin are not enough for the ERC-6900 spec.

Consider this situation, if an account has only one plugin. At the same time, this plugin is responsible for selector IPluginManager.installPlugin.

If I want to switch to a new plugin. Maybe I should uninstall the old plugin (IPluginManager. uninstallPlugin) and install the new plugin (IPluginManager.installPlugin).

Uninstalling the old plugin is fine. However, I cannot install new plugin through IPluginManager.installPlugin for there is no plugin responsible for the selector IPluginManager.installPlugin after uninstalling the old plugin.

I think maybe we can unify the interfaces like this.

function updatePlugin(
    UninstallPluginParams pluginToUninstall
    InstallPluginParams pluginToInstall,
)

If pluginToUninstall is empty, just install pluginToInstall.

If pluginToUninstall is not empty, uninstall pluginToUninstall first and then install pluginToInstall.

48

[details=“Summary”]
This text will be hidden
[/details[quote=“cejay, post:15, topic:13885, full:true”]
“EIP: Modular Smart Contract Accounts and Plugins” is generally feasible!

But I think there are several points that may need attention:

  1. add/remove Hook plugins may need to be divided into two parts:
    For example: 1. add plugin → 2. wait for a security time delay (e.g. 48 hours) → 3. user confirms that the plugin has been added.At least the implementation in soulwallet is like this, this is mainly for security reasons, for full context see the previous discussion with the author of ‘EIP-2535 Diamonds’ mudgen at here . So for us only PluginAdd function is not enough, at least a PluginPreAdd similar process is needed, and this process for monitoring purposes, will also emit event

  2. validateUserOp because it will be called at high frequency, so we need to consider the ‘gas efficiency’, in our consideration for the time being will be validateUserOp logic fixed in the contract (rather than through the plugin way to achieve), later if user need to upgrade the logic of validateUserOp, the user can update the ‘proxy contract’->‘logic contract’ address pointer(lower gas).

  3. I think MSCA implicitly aims to create a set of standards that any standard-compliant SCA can use any standard-compatible frontEnd (users don’t need to rely on ‘ONE’ frontEnd only), while the signature assembly and verification process often differs from one SCA to another (gas efficiency first｜stability first｜code readability first… etc.), I’m thinking that this area could be a major challenge for MSCA implementation.
    [/quote]

]

49

Hi all, we have some updates to share regarding ERC-6900. We have made some minor changes to the spec to improve clarity and consistency, and updated the reference implementation to be fully compliant with the ERC specification. We’ve also identified necessary areas to work on for stabilizing and simplifying the standard, and opened an agenda signup for the next community call.

Spec updates and fixes

We’ve addressed some small issues and added simplifications to the existing standard. This makes it easier to dive into the spec and the reference implementation and use modular account features. It is not comprehensive of all planned improvements discussed below.

Change log

  • Renamed Execution to Call.
  • Added the missing struct definition for ManifestExternalCallPermission.
  • Added a native token spending permission flag into the manifest.
  • Moved view-only fields in the manifest out into a separate pluginMetadata function, since they don’t affect the installation procedure but occupy space.
  • Renamed IPluginLoupe to IAccountLoupe for clarity on what is being inspected.
  • Added extra fields to the plugin installation events, to allow full reconstruction of account state by offchain entities.
  • Relaxed rules to allow overlapping hook definitions.
  • Other small cleanups and fixes pertaining to the EIP → ERC repo migration.

The standard and the reference implementation have been updated to reflect these changes. The reference implementation’s git tag has been advanced to v0.2.0.

Updated ERC PR: Update ERC-6900: spec update 6 by fangting-alchemy · Pull Request #116 · ethereum/ERCs · GitHub

Reference implementation: GitHub - erc6900/reference-implementation at v0.2.0

Ongoing work to stabilize and simplify the standard

For a standard to provide value, the upside of conforming to it must outweigh the added costs. We’ve received feedback that ERC-6900 shifts too much of the burden onto account implementers, which risks fragmentation of plugin development. We’ve put together a list of specific steps we can take to consolidate aspects of the standard. This can help reduce the overhead of implementing a 6900-compliant account and make it easier to reason about.

  • Multiple validation function support
    • As discussed in the previous community call, many workflows could be simplified if there was a way for multiple validation functions to be applied over the same execution function. Some proposals were discussed around adding extra data into userOp.signature, but this data is inaccessible during validation. If we can create a generalized calldata format to pass validation context, we can easily allow for multiple validation functions on the same selector.
  • Replace Plugin Operation
    • Uninstalling and reinstalling plugins through executeBatch relies on some fragile assumptions for how the account should behave. If we introduce a standardized replacePlugin method, these issues can be avoided. The current blocker has been the handling of dependencies, which add significant overhead to what the replace plugin operation needs to do to prevent inconsistent account state (described more below).
  • Consolidate user-supplied install config
    • Currently, ERC-6900 supports dependencies and injected hooks as ways to supplement the install config in a plugin manifest. These allow for wider cross-plugin compatibility and for stricter permissions, respectively. But, they come with large complexity costs on the implementation side, due to added tracking outside of the manifest. If we can simplify & consolidate these into a single user-supplied config, we can reduce complexity and make plugin replace operations feasible.
  • De-enshrine validateUserOp
    • The special status of validateUserOp in ERC-6900 is key to allowing custom account security settings and automations. However, with proposed changes to ERC-4337’s UserOperation struct and RIP-7560’s validateTransaction, we do not want to be stuck re-enshrining more special functions. We need to define a strategy for functions to have implementation-switching as needed to have modular validation functions.

We’ve opened these specific topics (and more!) as GitHub issues here, to track design progress and allow for easier discussion. Big thanks to community feedback from previous call, posts here, and others working on modular accounts for helping improve the standard and bring us closer to interoperability.

Community call agenda

We’ve also opened a public agenda for the community calls for anyone to sign up with a topic they’d like to discuss here. And, we’ve added some starting topics about the planned changes.

As always, we appreciate feedback in all forms. Feel free to leave comments here, open issues on GitHub, or bring up topics in the community calls.

3 Likes
50

Great point. There are a couple of solutions we are exploring that tackle this problem.

One is very similar to the solution you’ve described: [Improvement] Replace plugin operation · Issue #13 · erc6900/resources · GitHub

The other is a change that would allow more than one validation function to be installed for a given selector. This would, for example, allow one to install a new ownership plugin before uninstalling the old one: [Improvement] Multiple validation function support · Issue #4 · erc6900/resources · GitHub

Note that multiple validation function support would not help in a strict plugin upgrade scenario if the new plugin shares the same execution selectors as the older version. And as such, these solutions are not mutually exclusive.

If you have more ideas here, would love to hear your thoughts in the issues above!

51

Hi all, thank you to those who have been attending and contributing via our community calls and standard improvement issues! We have a new spec update that includes changes that came out of these discussions:

  1. The removal of permitted call hooks and injected hooks during plugin installation
  2. Disallowing use of hooks as dependencies

These changes will help to simplify the standard and account implementation, and improve security around state held in plugins. Please take a look at the issues linked above for more context and description of the changes.

Spec updates and fixes

Change log

  • IPluginManager
    • Removed structs InjectedHook, InjectedHooksInfo
    • Removed the injectedHooks parameter from event PluginInstalled
    • Removed the injectedHooks parameter from function installPlugin
    • Removed the hookUnapplyData parameter from function uninstallPlugin
    • Renamed the callbacksSucceeded param of the PluginUninstalled event to onUninstallSucceeded, as there are no longer multiple callbacks for uninstalls
    • Renamed pluginInitData param of installPlugin to pluginInstallData to be more consistent with the pluginUninstallData param of uninstallPlugin
    • FunctionReference type declaration has been moved from IAccountLoupe to IPluginManager, since the former is an optional interface
    • installPlugin’s comment for the dependencies param is now explicit about each FunctionReference being a validation function
  • IAccountLoupe
    • Removed function getPermittedCallHooks
  • IPlugin
    • Removed function onHookApply and onHookUnapply
    • Removed member permittedCallHooks from struct PluginManifest
  • PluginManifest
    • Added a note for canSpendNativeToken to clarify that the plugin can spend up to the amount that it sends to the account in the same call even if this value is false
    • Updated comment for dependencyInterfaceIds to no longer include hooks
  • Calls to installPlugin
    • Included instruction to store the plugin’s native token spending permission
    • Included instruction to store interface IDs for the manifest’s interfaceIds
    • Included instruction to also emit dependencies in the PluginInstall event
  • Calls to uninstallPlugin
    • Removed reference to hook dependencies
    • Included instruction to remove the plugin’s native token spending permission
    • Included instruction to remove interface IDs
    • Included note that if there is more than one instance of the same hook installed on a given function or if the same interface ID is added to the account by more than one plugin, they must persist until the last plugin that added them is uninstalled
    • Included instruction to emit the PluginUninstalled event
  • Calls to execution functions
    • Added clarity around how duplicate hooks (identical FunctionReferences that are applied to the same function) should be handled during execution
    • Added more clarity around how hooks should be executed
  • Simplified the plugin execution flow diagram and the description of the install and uninstall behaviors accordingly
  • Consistency improvements across comments
  • Fixed typos

The standard and the reference implementation have been updated to reflect these changes. The reference implementation’s git tag has been advanced to v0.7.0.

Updated ERC PR: Update ERC-6900: 0.7.0 by jaypaik · Pull Request #219 · ethereum/ERCs · GitHub

Reference implementation: GitHub - erc6900/reference-implementation at v0.7.0

4 Likes