Add 4337 Dependency section to the spec #185
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
PowerStream3604
requested review from
jaypaik,
adamegyed and
fangting-alchemy
jaypaik
reviewed
Sep 27, 2024
standard/ERCs/erc-6900.md
Outdated
| @@ -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
standard/ERCs/erc-6900.md
Outdated
Comment on lines
590
to
609
| ### 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.
There was a problem hiding this comment.
In my understanding validation associated execution hooks can optionally require the UserOperation context, which then use the executeUserOp() flow in order to also forward that context if needed. executeUserOp() is not present in v0.6. While I'm in favour of mentioning the potentially weakening 4337 dependency, I'm a bit sceptical if the wording around inclusion of 4337v0.6, as 6900v0.8, as well as 7579 have been built from the ground up with 4337v0.7 in mind. Given the interface changes, to e.g. validateUserOp() supporting both versions would either require two plugin implementations or compatibility contracts, which would make things more complicated.
standard/ERCs/erc-6900.md
Outdated
| 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. |
There was a problem hiding this comment.
+1 on those points. 6900 accounts can be used with or without 4337 support. It should be able to support different flavors of AA.
jaypaik
reviewed
Oct 9, 2024
standard/ERCs/erc-6900.md
Outdated
Comment on lines
590
to
609
| ### 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.
We discussed this a bit with the working group yesterday. How do you feel about a trimmed down version of this @PowerStream3604 ?
Suggested change
| ### 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. | |
| ### ERC-4337 Dependency | |
| ERC-6900's main objective is to create a secure and interoperable foundation through modular accounts and modules to increase the velocity and security of the smart account ecosystem, and ultimately the wallet ecosystem. Currently, the standard prescribes ERC-4337 for one of its [modular account call flows](#overview). However, this does not dictate that ERC-6900 will continue to be tied to 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 account abstraction on rollups). Moreover, it is expected that ERC-4337 and its interfaces and contracts will continue to evolve until there is a protocol-level account abstraction. | |
| ERC-6900 will follow the research, development, and adoption in the space to address its objectives and create a secure foundation for modular accounts that may eventually be agnostic to the account abstraction mechanism used. |
@nikita-quantstamp - would appreciate your help wordsmithing this!
There was a problem hiding this comment.
I agree with @jaypaik's direction of not diving too deep into technical details in this section and mentioning of what we will keep vs what we will not keep in the future, as it is pretty hard to predict. Overall, I like it, I just added a few changes to tie it together.
Suggested change
| ### 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. | |
| ### ERC 4337 Dependency | |
| ERC-6900's main objective is to create a secure and interoperable foundation through modular accounts and modules to increase the velocity and security of the smart account ecosystem, and ultimately the wallet ecosystem. Currently, the standard prescribes ERC-4337 for one of its [modular account call flows](#overview). However, this does not dictate that ERC-6900 will continue to be tied to 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 account abstraction on rollups). Moreover, it is expected that ERC-4337 and its interfaces and contracts will continue to evolve until there is a protocol-level account abstraction. | |
| In the current state of the AA ecosystem, it is tough to predict the direction the builders and industry will take, so ERC-6900 will follow the space's research, development, and adoption. The standard will do its best to address the objectives and create a secure foundation for modular accounts that may eventually be abstracted away from the infrastructure mechanism used. |
There was a problem hiding this comment.
Appreciate the suggestion @jaypaik @nikita-quantstamp , what do you think of the below suggestion?
Tried to incorporate your suggestions while not losing the original flavor.
Suggested change
| ### 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. | |
| ### ERC 4337 Dependency | |
| ERC-6900's main objective is to create a secure and interoperable foundation through modular accounts and modules to increase the velocity and security of the smart account ecosystem, and ultimately the wallet ecosystem. Currently, the standard prescribes ERC-4337. e.g., [modular account call flows](#overview). However, this does not dictate that ERC-6900 will continue to be tied to 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 account abstraction on rollups). Moreover, it is expected that ERC-4337 and its interfaces and contracts will continue to evolve until there is a protocol-level account abstraction. | |
| The current ERC-6900 v0.8 does enforce EntryPoint v0.7. However, 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 account layer flexibly utilizing/encompassing them as a tool. | |
| In the current state of the AA ecosystem, it is tough to predict the direction the builders and industry will take, so ERC-6900 will evolve together with the space's research, development, and adoption. The standard will do its best to address the objectives and create a secure foundation for modular accounts that may eventually be abstracted away from the infrastructure mechanism used. | |
|
Discussed with @jaypaik regarding the PR and we came up with 2 approaches.
I'm happy to go with either approach! Just considered that the 1st option could be more clear/explicit. |
jaypaik
requested changes
Oct 10, 2024
PowerStream3604
force-pushed
the
PowerStream3604/add-4337-dependency
branch
from
d68a832 to
80f1c81
Compare
|
Rebased and updated the PR to aggregate working group's thoughts & suggestions. Thanks to everyone who shared their thought and feedback. |
Co-authored-by: Jay Paik <[email protected]>
Co-authored-by: Jay Paik <[email protected]>
jaypaik
added a commit
that referenced
this pull request
Oct 15, 2024
Co-authored-by: Jay Paik <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.