Add 4337 Dependency section to the spec #185
Conversation
PowerStream3604
requested review from
jaypaik,
adamegyed and
fangting-alchemy
| @@ -484,6 +484,7 @@ During validation uninstallation, the account MUST correctly clear flags and oth | |||
|
|
|||
| - the account MUST clear all flags for the validation function, like `isGlobal`, `isSignatureValidation`, and `isUserOpValidation`. | |||
| - the account MUST remomve all hooks and SHOULD clear hook module states by calling `onUninstall` with the user-provided data for each hook, including both pre validation hooks and execution hooks, if required by user. | |||
| - the account MAY ignore the revert from `onUninstall` with try/catch depending on the design principle of the account. | |||
There was a problem hiding this comment.
Thoughts on this @erc6900/working-group ?
There was a problem hiding this comment.
Seems fine. Adds some flexibility to the account.
There was a problem hiding this comment.
👍 It provides developers with flexibility when a clean state is not required in certain modules
| ### ERC 4337 Dependency | ||
|
|
||
| ERC-6900's main objective is to create a secure and interoperable foundation through modular modules to increase the velocity and security of the Smart Account ecosystem and ultimately the wallet ecosystem. | ||
| Currently, the ERC-6900 standard enforces the ERC-4337 for the validation and execution, however, this does not dictate that ERC-6900 will continue to be tied to the ERC-4337. | ||
| It is likely that smart account builders will want to develop modular accounts that do not use ERC-4337 in the future, e.g., Native AA on rollups. | ||
| Moreover, it is expected that the version of EntryPoint contract will continue to evolve until there is a protocol-level account abstraction. | ||
|
|
||
| ERC-6900, having the objective to provide the secure foundation for modular smart account layer, does not try to be tied with a specific version of continuously evolving EntryPoint and AA architecture but rather position to function as a modular layer encompassing them. | ||
|
|
||
| To be in line with this, identical behavior and functions will exist for EntryPoint v6 with `UserOperation` and will continue to exist when a new EntryPoint version comes out with a different UserOp structure. | ||
|
|
||
| ERC-6900 could evolve with ERC-4337 becoming an extension through a separate ERC for ERC-6900 if more builders build on a new architecture, but in its current state, it enforces ERC-4337 within the standard, considering that the vast majority of smart accounts utilize ERC-4337. | ||
|
|
There was a problem hiding this comment.
I'm uncertain whether we need this section until we actually begin to support a more flexible interface. Related issue: erc6900/resources#14.
To be in line with this, identical behavior and functions will exist for EntryPoint v6 with
UserOperationand will continue to exist when a new EntryPoint version comes out with a different UserOp structure.
Is this line implying that PackedUserOperation as used in the current spec is interchangeable with ERC-4337 v0.6's UserOperation? I believe that there are some things stated in the spec that cannot be adequately supported without ERC-4337 v0.7, namely validation-associated execution hooks.
Making the spec more flexible in this way probably requires further discussion.
There was a problem hiding this comment.
I believe that there are some things stated in the spec that cannot be adequately supported without ERC-4337 v0.7, namely validation-associated execution hooks.
Could you elaborate further on validation-associated execution hooks and why it couldn't be supported on the UserOperation architecture?
Would love to learn further on that.
I'm uncertain whether we need this section until we actually begin to support a more flexible interface. Related issue: erc6900/resources#14.
Even if we don't enshrine 4337 or support a different interface/architecture yet, I think it's important that we state the objective of this ERC is on the modular account layer and not the 4337 bound account system. And that ERC 6900 views ERC 4337 more as a tool to enable it, and is flexible/open to new designs if new promising architecture comes up that builders are willing to build on.
I believe this will help this ERC be more future proof for changes in the future, and allow readers understand our focus.
Happy to hear what others think.
Motivation
An update of ERC-4337's UserOperation structure requires ERC-6900 account to be revised and make accounts using the new EntryPoint to be incompatible with ERC-6900.
This may not be fully in line with the vision of ERC-6900 as ERC-6900 focuses on the modular account layer and uses ERC 4337 as a tool to enable it.
Through this PR, we pave the way for ERC 6900 to be more scalable and flexible for diverse technical/design innovation AA, and also not get fully bound to the EntryPoint/ERC-4337 architecture.
Solution
This PR adds a section to the ERC-6900 standard regarding the ERC-4337 dependency.
It explicitly states the objective of the ERC and its intention to encompass diverse architecture and focus on the modular account layer.
Also if this PR/Contribution makes sense to the co-authors, we'd like to carefully ask the option of adding Trust Wallet as the co-author of the standard.