Spec Update 7 (v0.7.0) clarified that pre- and post- exec hooks should be run based on the state of the account at the start of the execution phase. This was described as relevant to installPlugin and uninstallPlugin, since they modify account state and can potentially affect the set of hooks that apply over their own selectors. (See https://github.com/erc6900/reference-implementation/pull/34/files)
There are actually more cases in which account state may change mid execution. Because the concept of authorization is abstracted out into user operation validation and runtime validation, there exists a way for account state to be modified within the context of a single execution step - any validation function, execution function, or hook may re-enter the account and perform a state modification via installPlugin or uninstallPlugin.
Accounts will likely either choose to load all calls to perform into memory, or only load from storage as needed while iterating through the set of plugin functions. This variability could lead to diverging behavior between account implementations, potentially risking security principles if one type of account is affected differently by the state modification. This also may make plugin development trickier, if they have to handle these cases rather than the account implementations.
The solution to this should be to define expected state loading steps in the ERC-6900 specification. I propose that a clean way to split this up, while still keeping implementation relatively simple for accounts, is to load state at the start of validation and at the start of execution. One notable point with this setup to watch out for is that runtime validation should be considered separate from the pre-exec / exec / post-exec phase, to correctly mirror concepts from user op validation.
Spec Update 7 (v0.7.0) clarified that pre- and post- exec hooks should be run based on the state of the account at the start of the execution phase. This was described as relevant to
installPluginanduninstallPlugin, since they modify account state and can potentially affect the set of hooks that apply over their own selectors. (See https://github.com/erc6900/reference-implementation/pull/34/files)There are actually more cases in which account state may change mid execution. Because the concept of authorization is abstracted out into user operation validation and runtime validation, there exists a way for account state to be modified within the context of a single execution step - any validation function, execution function, or hook may re-enter the account and perform a state modification via
installPluginoruninstallPlugin.Accounts will likely either choose to load all calls to perform into memory, or only load from storage as needed while iterating through the set of plugin functions. This variability could lead to diverging behavior between account implementations, potentially risking security principles if one type of account is affected differently by the state modification. This also may make plugin development trickier, if they have to handle these cases rather than the account implementations.
The solution to this should be to define expected state loading steps in the ERC-6900 specification. I propose that a clean way to split this up, while still keeping implementation relatively simple for accounts, is to load state at the start of validation and at the start of execution. One notable point with this setup to watch out for is that runtime validation should be considered separate from the pre-exec / exec / post-exec phase, to correctly mirror concepts from user op validation.