Community Call #9

[CodesMcCabe]

Reach out to cody@alchemy.com if you would like to be added to the bi-weekly calls.

Previous call recap

Meeting Info

• April 25, 2024, 5:00 UTC
• Duration: 60 minutes
• Meet link: https://alchemy.zoom.us/j/82398771338

Agenda

1. Ecosystem developments
2. ERC-6900 update
3. Research and development
4. Open discussion

To add or request a topic that you'd like to discuss, please comment in response to this Issue below!

[CodesMcCabe]

Ecosystem developments

Contribution Growth

• @dlim-circle, @huaweigu , and @ZhiyuCircle from the Circle team have joined as co-authors of ERC-6900
• @RubensGitHub from Quantstamp has also joined as a co-author. Ruben mentioned that he worked on the audit that helped shape the v0.7 standard, mainly about the reduction or simplification around the hook design. He also mentioned that he's excited to participate in shaping the standard for v0.8

EIP-3074

• @adam-alchemy mentioned various discussions that have been occurring around 3074 including input from Vitalik on the AA Mafia telegram and forum posts on Ethereum Magicians by @noam-alchemy
• The discussions center around exploring how modular accout systems fit into an alternative account abstraction than what is current available, sort of like a base layer.
• The invoker itself could become modular and define its own set of relationships between the core account and plugins, but the same sort of question and system extends to other account abstraction validity setups. Consider things like RIP-7560, a native account abstraction implementation built into the protocol.

Resources

• Showcased a list of plugins for 6900 and modules for 7579 compiled by Vasa from OpenSeaPro. A good place for plugin developers to see whats already built, what's in progress, and what could be ported over from 7579 to 6900.

ERC-6900 updates

Public tracker for standard improvements @jaypaik mentioned:

• tracker link
• a prioritized list of standard improvements that will be used for v0.8.
• please check this out to see the issues currently be worked on, the progress of each one, and how the owrking team is thinking of prioritizing and bucketing the issues
• if you have any ideas, feel free to create new ones or comment on the issues

ERC-4337 v0.7 compatibility updates @howydev mentioned:

• the new v0.7 has some changes that affect 6900
• The first change is the use of a struct that has changed from UserOperation to PackedUserOperation. This change was incorporated into the reference implementation is can be found at these 3 PRs (48, 49, 50)
• The second change is more interesting. They introduced a new method that could be called on the account called executeUserOp. Functionally this allows some context to be passed from the validation stage of a userOp to the execution phase of the userOp. The working team is currently exploring how this could be used in accounts and how we want to enshrine this in 6900. If this is something you're thinking of, you're interested in working on, feel free to contact any of the 6900 authors.

Manifest simplification @adam-alchemy mentioned:

• There are two ways we're simplifying both the contents of the manifest and accounts stored setups in v0.8, merging validation function assignments and merging pre-validation types.
• Specifically what they do is they merge the assignment of user validators and runtime validators. So a selector now doesn't have two separate entries that the account has to maintain where one entry keeps track of what functions were used and validated in the user context and the other function keeps track of what's used to validate it in the runtime context. Instead, each validation function on the plugin is expected to handle both of these cases, and is identified by the same function ID. This reduces the total number of steps during installation and makes it impossible to reach some ambiguous states where one is set but the other one isn't. This simplification applies both to the validation function themselves and for pre-validation hooks. Hopefully this makes it easier to develop plugins and accounts.

Miscellaneous @adam-alchemy mentioned:

• small updates made to the reference implementation to make it easier to iterate on as research and work continues for v0.8 such as moving some samples and libraries as well as removing some needless optimizations.
• PRs 43, 44, 45, 47
• @adam-alchemy mentioned that the reference implementation previously had copies of a linkless Set library as well as a version of that alternate associated storage that was used by the sample plugins. This was an okay place to plublish it but it was a little bit inaccessible to developers using npm as package management for the smart contract repos. So something that the working team did was spin it out into a separate library.

Active research @jaypaik spoke about 3 improvements that are actively being researched by the working team:

• [Improvement] Enshrine account default validation feature #37

• [Improvement] Multiple validation function support #4

• [Improvement] Plugin composability #36

• One of the things that we're exploring is putting in default validation into the account. It would one help reduce in terms of deployment costs. So right now all validation is handled with plugins but if we have default validation, during deployment, a plugin wouldn't need to be installed. And also, it can help simplify some of the plug in account interactions via like a plugin manifest in terms of not having to specify which validation plugin is a plugin. Execution functions are also tied to that and are also getting worked on with other improvements by rethinking how we use ERC 1652 or interface IDs to specify which validation plugins to use. Generally this improvement is aligned in the direction of simplifying things with the validation here.

• Multiple validation functions support we've talked about in prior calls, being able to specify multiple validation functions to apply to a given execution function so you can authorize in to the account in different ways.

• Plugin composability is a big piece that we're prioritizing. Right now we are thinking about how to modularize things in a nice way. To give an example, if we have a multisig plugin and you want three of the signers to be validated with ELA signatures and the rest to be validated with passkey signatures, right now the Multisig plugin would need to encapsulate all of that logic to handle different types of signature validation schemes. But is there a way to separate the concept of a signer and an owner so that the multisig plugin can potentially delegate that signature validation process to a different component, so it doesn't need to know about all the ways to validate signatures? In that way, we can reuse that same mechanism across different ownership plugins and make things more modular.