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.

Sign up for GitHub

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

Jump to bottom

Add 4337 Dependency section to the spec #185

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

Add 4337 Dependency section to the spec #185

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
beeb9ca
feat: add 4337 dependency to spec
PowerStream3604 Sep 25, 2024
d68a832
chore: add line and format ERC name
PowerStream3604 Sep 25, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions standard/ERCs/erc-6900.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts on this @erc6900/working-group ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine. Adds some flexibility to the account.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 It provides developers with flexibility when a clean state is not required in certain modules

- the account MUST remove all selectors that the validation function can validate.
- the account MUST emit `ValidationUninstalled` as defined in the interface for all uninstalled validations.

Expand Down Expand Up @@ -586,6 +587,19 @@ ERC-4337 compatible accounts must implement the `IAccount` interface, which cons

This proposal includes several interfaces that build on ERC-4337. First, we standardize a set of modular functions that allow smart contract developers greater flexibility in bundling validation, execution, and hook logic. We also propose interfaces that provide methods for querying execution functions, validation functions, and hooks on a modular account. The rest of the interfaces describe a module's methods for exposing its modular functions and desired configuration, and the modular account's methods for installing and removing modules and allowing execution across modules and external addresses.

### 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.

Comment on lines +590 to +602
Copy link
Collaborator

@jaypaik jaypaik Sep 27, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 UserOperation and 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.

Copy link
Contributor Author

@PowerStream3604 PowerStream3604 Sep 27, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

## Backwards Compatibility

Existing accounts that are deployed as proxies may have the ability to upgrade account implementations to one that supports this standard for modularity. Depending on implementation logic, existing modules may be wrapped in an adapter contract to adhere to the standard.
Expand Down
Loading