Weekly Development Updates (5/16/24)

[CodesMcCabe]

• On reducing gas costs of account creation post-ERC-4844:

  • Execution fees can be reduced by eliminating duplication across various runtime and and installed execution functions.
  • A bigger optimization would be to use a default validation scheme (and not installing a plugin) which is important for reducing “cold” SSTOREs on account creation.
  • Working idea: validation functions can opt into a “default pool” to be considered for default validation.
  • [Improvement] Enshrine account default validation feature #37

• Proof of concept for multi-validation in calldata: feat: [v0.8-develop, experimental] multi-validation in calldata reference-implementation#52

  • We are experimenting with allowing selection between multiple validation functions per execution function by adding a specifier within calldata: executeWithValidation(FunctionReference validation, bytes calldata data)
  • In a previous change (feat: [v0.8-develop, experimental] Merge validation function assignments reference-implementation#40), we fully merged assignments of runtime validation and user operation validation, which means the same function reference should be used across those two different validation types.
  • If we want to specify which runtime validation function to use, it must be specified in calldata because runtime validation doesn’t have access to context such as the user operation’s signature and nonce.
  • Open questions:
    • What’s the goal of pre-validation hooks? Is there a way to consolidate now that we can attach multiple validation functions to a given execution function?
    • What does executeWithValidation with executeBatch look like?
    • Can we add a selector as part of calldata to handle default validation?
    • Default validation may introduce race conditions / inconsistencies: e.g., what happens if default validation is replaced while multiple user ops from the account are in flight?