Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Improvement] Explicitly specify behavior for state changes mid-execution #27

Open
adam-alchemy opened this issue Jan 29, 2024 · 0 comments

Comments

@adam-alchemy
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

1 participant