Weekly Development Updates (6/7/24)

[CodesMcCabe]

• ERC-6900 website launched! 🚀

• Experimental: support for a “default” validation function pool - feat: [v0.8-develop, experimental] default validation reference-implementation#63

  • By introducing a "default" validation function pool, we can reduce plugin installation costs, particularly for ownership plugins, by allowing execution functions to opt-in to a default validation pool.
  • Removes the need for a plugin to know each native function implemented by an account

• Experimental: Associating pre-validation hooks with validation functions - feat: [v0.8-develop] associate pre-validation hooks with validation functions reference-implementation#64

  • Follow up to the work being done to allow switching between multiple validation functions (feat: [v0.8-develop, experimental] multi validation in user op signature [5/N] reference-implementation#62)
  • If we continue associating pre validation hooks with a selector, then a single pre-validation hook would apply over multiple validation types. If the pre-validation hook reads from something like userOp.signature, then it could break composability.
  • The combination of N pre-validation hooks plus 1 validation function logically makes up 1 "unit", regardless of the action being validated. This helps enforce security guarantees like "this validation can't transfer my NFTs", because they can't be bypassed by the introduction of a new execution function.

• Experimental: Removing the execute function from plugins - feat: [v0.8-develop] remove execute from plugin reference-implementation#65

  • Remove executeFromPlugin and executeFromPluginExternal from the account, and delete IPluginExecutor.
  • With multi-validation, it is no longer necessary have these two parallel paths for performing calls from plugins.
  • Any function wishing to invoke external contracts can simply ask for permission to validate execute/executeBatch, and validate itself.
  • Additionally, executeFromPluginExternal required accounts to have some opinionated access control functions built-in as part of the standard. This type of access control management is best left to actual plugin implementations

• EIP-7702 and how SSTORES will behave with EOAs - Allow specifying storage locations argotorg/solidity#597

  • https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code-for-one-transaction/19923
  • Solidity language changes to specify variables for storage namespaces will have a direct effect on the ERC-6900 implementation and will be discussed by the working team in-depth over the coming weeks

• Visualization of v0.8 work and dependency tree

  • An easier way for us to view the work being done for v0.8 and the dependencies for each piece