ERC-6900: Modular Smart Contract Accounts and Plugins

ERCs
29

Hi all, we’re excited to share some updates to the proposal taking into account feedback provided thus far.

Most notable are changes to the way plugins are configured on the account and the introduction of an interface for plugins. Updates related to the plugin manifest that enable plugin installation and removal are largely a product of suggestions and feedback by @yoavw, who will be joining as a coauthor to this proposal. As a result of these updates, the former IPluginUpdate interface and the updatePlugins function have been removed.

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

ERC Changelog:

  • Updated shared components diagram to more accurately depict modular functions and their relationship to plugins.
  • Added “native function” definition under Terms.
  • Added the IPlugin interface that describes the functions a plugin must implement.
    • Plugins must implement ERC-165 and support this interface.
    • Associated functions in the interface take a uint8 function identifier to support multiple implementations of the same type of associated function.
  • Removed the FunctionReference custom type, as function identifiers do not represent function selectors.
  • Removed the hook group concept and its associated types.
  • Replaced the IPluginUpdate interface with the IPluginManager interface.
    • The function updatePlugins has been replaced by the functions installPlugin and uninstallPlugin.
  • Updated the IPluginLoupe interface to reflect the above changes.
  • Added the IPluginExecutor interface, which introduces new functions executeFromPlugin and executeFromPluginExternal that allow plugins to interact with execution functions on the modular account as well as external contracts.
  • Standard execution functions and executeFromPluginExternal should not allow calls to contracts that implement the IPlugin interface to maintain the integrity of account and plugin configuration.
  • Added a section describing the plugin manifest, and the expected behavior for installPlugin and uninstallPlugin.
  • Added a section describing the expected behavior for calls made from plugins.
  • Style updates and typo fixes.

Areas we’re still working on

  • We’re actively working on introducing a permissions model similar to what @yoavw has described in an earlier comment. We hope to release an update on this in the next couple of weeks.
  • Using ERC-165 is one way to enforce data integrity on the account and associated data within plugins, but presents additional overhead during standard execution. We’re still exploring ways we can improve this flow.
  • The way dependencies are requested by the plugin manifest and provided during installation prevents having to make immutable dependency references in the manifest, and offers flexibility for the user in providing a plugin of their choice for the dependency. However, there is still some rigidity in that the expected class of plugins for a given dependency must all implement the same interface. We’re giving more thought to this area to see if there is room for improvement.

As stated, some details are still in flux and will be ironed out in subsequent updates. We’d love to continue to refine the proposal with input from the community. Let us know what you think!

PR: Update EIP-6900: Spec update 3 by jaypaik · Pull Request #7516 · ethereum/EIPs · GitHub

6 Likes