ERC-6900: Modular Smart Contract Accounts and Plugins

ERCs
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