Native Account Abstraction #001

Red added read.ai meeting notes to the meeting. Read provides AI generated meeting summaries to make meetings more effective and efficient. View our Privacy Policy at https://www.read.ai/pp Type "read stop" to disable, or "opt out" to delete meeting data.

Starting in 1 min 🙂

Reacted to "Starting in 1 min 🙂" with 👍

https://github.com/ethereum/pm/issues/2018

I'll need to add 8130 to next AA schedule - found out about this meeting too late unfortunately

Replying to "I'll need to add 813..." You can still give a quick update if youre up for it

this is a nice post by V about many of the core goals we have been focusing on https://docs.fileverse.io/0xd961b83d3421bddec9d8966efabf13800617cfea/10#key=Z-XeQk6mE7uZX9Q2ZbqWkiniYi9IZ1oSbd_2vPFyt26S7Kf8gO_UHpLJ936--lp8

Reacted to "You can still give..." with 👍

this is a good post too, sharing many of the ux/wallet features that AA wants to support https://hackmd.io/@FJJgNqPTR2WeGoYk6_URNA/S1dAiErT-l

this is AA btw [Full message cannot be displayed on this version]

Reacted to "this is AA btw" with 😂

Reacted to "this is AA btw [Full..." with 😂

Reacted to "this is AA btw" with 😂

👋

PQ aggregation should be a non-goal, as the crypto is certainly nowhere close to ready

we should be able to support it in theory in the future

that should be a non-goal, as we don’t know what “being able to support it” means

SPHINCS- with keccak is 200K gas

We will need precompiles for crypto primitives, I don't think we will get away from that.

Reacted to "SPHINCS- with keccak..." with 👍

Replying to "that should be a non..." we don’t know what “it” is. how can we support it?

Just to clarify - the only way to upgrade existing EOAs to use Frame tx will always be with the 7702.

In the interest of time, will wrap up this prompt after Ben -> Mislav -> prestwich Proposal authors can speak to latest updates next

it means people can’t introspect the signature data because obviously that will not allow ppl to remove the signature in the future for aggregation

Replying to "Just to clarify - th..." Frames natively support EOAs. Check the “default code” section of the spec

So 2$ right now during the Defi drama ! (not free) but certainly not out of range

Reacted to "Frames natively su..." with 👍

Replying to "In the interest of t..." Thoughts still welcome via text/links in chat here though

Replying to "We will need preco..." yes along with , crypto agility built in the ystem natively

Replying to "Just to clarify - th..." Ahh this is what you added right.

you can send infinite invalid 10 MB txs in the mempool today

Replying to "We will need precomp..." That will hurt the ZKEVM folks significantly

Replying to "We will need precomp..." As they are trying to get rid of as many as possible

full AA allows us to have expensive signatures for securing most funds in a wallet and using cheaper keys (not quantum safe) for day to day spending with something like session keys

Reacted to "full AA allows us to have expensive signatures for securing most funds in a wallet and using cheaper keys (not quantum safe) for day to day spending with something like session keys" with 👍

that's the kind of design space we need

reminder: current prompt is “what do you think is most important for a native AA proposal to accomplish?”

Replying to "We will need preco..." Adding more layers to heavy math computations is not going to work out well in the end. Native crypto ops need to be directly optimizable.

Reacted to "full AA allows us ..." with 👍

Replying to "We will need preco..." FAEST is one example, it has greate zk mapping, but forcing us to do it through RISC-V zk prooving will be 1000x more expensive

wdym wallet rollover?

No one has mentioned ERC20 sponsoring. Is this not the “most desired feature” ?

Reacted to "full AA allows us to have expensive signatures for securing most funds in a wallet and using cheaper keys (not quantum safe) for day to day spending with something like session keys" with 👌

Replying to "No one has mentioned..." I’d love to hear that it is not btw. Just asking stakeholders

The #1 desired feature in commercial settings is gas abstraction, including gas sponsorship and paying gas in ERC20s

Replying to "No one has mentioned ERC20 sponsoring. Is this not the “most desired feature” ?" I meant it indirectly. Should’ve been more clear

Reacted to "The #1 desired featu..." with 😂

trying to define a list of "features we need" is the wrong approach, it is like trying to code the initial version of the EVM with the list of all "contract ideas" we will ever need

Replying to "No one has mentioned..." Yes, erc20 is used to pay for gas. Not necessarily for sponsorship.

Replying to "No one has mentioned ERC20 sponsoring. Is this not the “most desired feature” ?" I think batching and sponsorships have always existed - so I focused on the practical adoption part of those features

Lots of these things aren't really unspecified though. Gas abstraction, sponsorships, 2D nonces, paying gas with erc20s, batch execution, ... There is a body of lived experience within AA teams from which these conclusions are derived.

we have a lot of wallet teams here who seem to support 8141?

Reacted to "we have a lot of wal..." with ➕

Reacted to "we have a lot of w..." with ➕

Replying to "Lots of these things..." signature aggregation, especially PQ, is the main completely unspecified thing

Replying to "No one has mentioned ERC20 sponsoring. Is this not the “most desired feature” ?" Even before 4337 we had wallets doing those. In a nutshell all of the AA proposals serve to improve the practicality of said features - from not requiring proprietary relayers to using them in existing accs or using them without overhead or mempool complexity

Two questions for me: 1) Are there any estimation on when will this be included in mainnet 2) The only possible way is to test in ethrex? Testnet?

Reacted to "we have a lot of wallet teams here who seem to support 8141?" with ➕

Replying to "Lots of these thin..." fair point

From this I currently See PQ with native AA is very noce to have , but not a must

Replying to "Two questions for me..." if we can get agreement on the design, then likely H* fork

Reacted to "Even before 4337 we ..." with 👍

Prompt: For each proposal, what's changed in the last ~month? e.g., spec changes, implementations, prototypes, testing, data collection, etc.

Reacted to "Prompt: For each pro..." with ❤️

We are hosting a devnet for frame transactions, we’ll announce it in AA Mafia soon

https://github.com/ethereum/EIPs/pull/11555 derek is talking about this idea

Interesting can you share - what if sender validation is invalid? (will read nvm)

thanks

Replying to "Interesting can you ..." basically the guarantor still pays for the invalid tx

isn't this somewhat similar to 5189?

Replying to "Interesting can yo..." And they would inspect the sender frame for validation?

Replying to "Interesting can yo..." Or is offchain

i think you covered it

This is fantastic and very well explained

Reacted to "i think you covere..." with 👍

Replying to "Two questions for me..." Great!

Had a question with Frame tx, how would gas sponsorship work for privacy pool (shielded) transfers? Today, relayers/broadcasters can determine the fee they’ll receive from the transaction (e.g., via data revealed to them), and decide whether to submit. How would that model translate here?

The guarantor change would be similar to the behavior of existing Safe multisig wallets needing 1 signer / other EOA to relay the transaction, which assumes the risk of invalid signatures leading to reverts. +1 for utility in mempool performance.

Replying to "Interesting can you ..." If sender validation fails but guarantor can afford the tx. Is it a valid or invalid tx?

Replying to "Interesting can you ..." If sender validation is invalid, the payer pays anyways. That’s why in this case we call the payer a "guarantor"

How is the actual sender protected in the case of a guarntee? I can guarantee for account B but account B is not mine so I forge a signature for him. If that signature is not validated, how does it work?

Ben’s contract payer tx, eip-8223: https://github.com/ethereum/EIPs/pull/11509

https://hackmd.io/@FJJgNqPTR2WeGoYk6_URNA/S1dAiErT-l#8223-from-the-wallet-desk-why-the-narrow-case-is-a-trap

the idea of a guarantoor which is it by itself an EOA that has funds, that sounds like a relayer with extra steps... now if the guarntoor lives onchain, it becoms a public service not a meta-relayer

Replying to "Interesting can yo..." Payment is the best form of DoS protection 🙏

Replying to "Interesting can you ..." I'm asking whether that tx is valid even though sender validation fails, i.e., can be included in a block

Replying to "Interesting can you ..." So in practice, we expect the guarantor to be either other wallets the user owns, or third-parties with commercial / trust relationships with the user, or somehow have out-of-protocol knowledge that assures them that the transactions won’t revert

BTW side note, but on the "PQ aggregation is unspecified" claim, actually lean ethereum is very far along in specifying and implementing STARK aggregation

Reacted to "So in practice, we e..." with 👍

Replying to "Interesting can you ..." @Jihoon yes, the transaction is valid as long as the payer validation is valid

Reacted to "@Jihoon yes, the tra..." with 👍

Replying to "BTW side note, but o..." post the spec

Reacted to "The guarantor change would be similar to the behavior of existing Safe multisig wallets needing 1 signer / other EOA to relay the transaction, which assumes the risk of invalid signatures leading to reverts. +1 for utility in mempool performance." with 👍

Replying to "How is the actual se..." If the sender validation is invalid, sender logic won’t be executed. The guarantor would simply be wasting gas

How do you propose existing wallets migrate assets from their existing wallets to the 8223 wallet?

Replying to "BTW side note, but o..." https://github.com/leanEthereum/leanMultisig

Replying to "BTW side note, but..." This is a good explainer too https://blog.lambdaclass.com/ethereum-signature-schemes-explained-ecdsa-bls-xmss-and-post-quantum-leansig-with-rust-code-examples/

Replying to "the idea of a guaran..." The guarantor doesn’t relay though. You don’t need any relayer since it’s native AA. And yes it can be an on-chain construct. After all, payment is validated through a frame, so it can execute arbitrary logic, including deciding to guarantee based on some on-chain condition

fredrik speaking to https://eips.ethereum.org/EIPS/eip-7906

Replying to "How do you propose e..." 7702 and then some of the disabling of EC EIPs that perminately convert to smart contract

Replying to "BTW side note, but o..." i was expecting this to be a specification for an integration with frame txns

Reacted to "The guarantor doesn..." with 👍

Reacted to "This is a good expla..." with ❤️

Replying to "BTW side note, but..." there's also the 4337 aggregators feature, which can be adapted to frames easily if needed

Replying to "How do you propose e..." Though it is a point in time thing

Replying to "BTW side note, but o..." familiar with the work, and it’s good. we need to judge EIPs based on things we are sure can be specified and integrated

Replying to "BTW side note, but o..." it’s clear that PQ signatures can be aggregated, the thing that needs specification is how that occurs in the network

Replying to "How do you propose e..." I believe all proposals should consider a migration path and make it as easy as possible. Otherwise it will discourage wallets from adopting the EIP. User retention is the biggest problem facing wallets. And it doesn’t help that we have a new EIP/ERC for AA every year!

@Fredrik is there a draft for this?

Replying to "BTW side note, but..." But zooming out a bit, it's good programming practice to support hiding data where possible, in order to make sure it's possible to backwards compatibly upgrade things

Replying to "@Fredrik is there a ..." https://eips.ethereum.org/EIPS/eip-7906

Replying to "BTW side note, but..." how that occurs in the network <--- you mean p2p layer?

strongly in favor of 7906, it would be awesome for wallets

Reacted to "https://eips.ethereum.org/EIPS/eip-7906" with ❤️

Replying to "BTW side note, but..." I agree that's a big challenge, I basically think we should address this iteratively, the exact work needed is pretty independent of the exact scheme used to manage accounts onchain

7906 is amazing! If we can make it compatible for offline validation via hardware wallets - that's a huge boost

Replying to "BTW side note, but o..." that’s part of it. e.g. all the mess with SSA and DSA in stateless ethereum research

7906 sounds like a very difficult thing for builders to deal with (especially L2)

Replying to "BTW side note, but o..." basically the contention is “designing EIPs to support future use cases that we don’t understand fully” has typically been a mistake. i was involved in eip-152, e.g.

Replying to "7906 sounds like a v..." Why?

Replying to "7906 sounds like a v..." I think the idea is that tx would still be included and gas paid, it just that execution would be reverted (all effects of execution)

Reacted to "I think the idea i..." with ➕

Replying to "7906 sounds like a..." ohh great :) no problem then

Reacted to "I think the idea is ..." with ➕

Replying to "7906 sounds like a..." Sorry I thought it was tx validity

Replying to "7906 sounds like a..." How does frames help then?

Replying to "7906 sounds like a..." 7906 seems very useful even without frames

Reacted to "7906 seems very us..." with 👍

Replying to "7906 sounds like a..." Yes seems like frames dont matter for it - seems good either way?

Risks for protocol / unknowns are part of this section @marc | wolovim ?

Replying to "7906 sounds like a v..." You can have clear separation between execution and verification, which makes it easier to implement (both for wallets and app developers)

Reacted to "Sorry I thought it was tx validity" with 👍

Adoption has built in headwinds: we need to start talking about how we will be sunsetting ECDSA.

Replying to "7906 sounds like a..." It compliments frames , but regardless its a good one standalone

Replying to "7906 sounds like a v..." It is useful even without Frames, but it is a very clean approach to have a Frame Tx that contains "pre-validation" - "execution" - "post-validation" flow.

Replying to "7906 sounds like a..." Yeah it's just like another piece of callData in a batch which is a specific assertion on state diffs

Reacted to "It is useful even without Frames, but it is a very clean approach to have a Frame Tx that contains "pre-validation" - "execution" - "post-validation" flow." with 👍

Reacted to "Adoption has built i..." with ➕

Reacted to "If the sender vali..." with 👍

Reacted to "Adoption has built..." with ➕

Replying to "Adoption has built i..." this is the only urgent feature in the AA bundle

Replying to "7906 sounds like a..." Isnt alternative AA proposals that have call batching also good for this? Its pretty much just a revert check no?

Reacted to "Yeah it's just lik..." with 👍

Replying to "Risks for protocol /..." Highlighting those sounds appropriate to me - in general, identifying open questions and ideally linking them to action items

Reacted to "Highlighting those s..." with 👍

Replying to "Adoption has built..." I dont think we have a clear approach for that yet , I think the native AA eip should add how they are handling this

Reacted to "It is useful even wi..." with 👍

Replying to "Adoption has built i..." default account + frame tx. we can sunset ecdsa in the default account and turn off other tx types

Replying to "Adoption has built i..." 8141 requires a deploy frame from all existing accounts, right?

Replying to "Adoption has built..." 8130 has full key rotation including ecdsa deprecation ready - no follow up EIPs or ERCs needed

Replying to "Adoption has built i..." also, @lightclient that’s not sufficient to sunset ECDSA, we also need to modify ecrecover

(other than 1559/legacy deprecation if using an EOA based account)

https://github.com/ethereum/EIPs/pull/11506

Replying to "Adoption has built i..." yes ofc, but that is separate from AA

Replying to "Adoption has built i..." making ecrecover frame-aware is inherently very bad

Replying to "Adoption has built i..." “inherently very bad” lol

Replying to "Adoption has built i..." you can use the default account without deploying anything

I think the important part to understand is that from wallet teams POV "native AA" is in reality "native relayer", and if it is not powerful enough (ie has too tight limitations, doesn't allow code, etc) then there is a tradeoff (features vs native relayer) and users care little about a relayer being native or not so if a solution is not good enough, then eventually it is set aside and wallets just keep using whatever works for them

Replying to "Adoption has built i..." making ecrecover frame-aware appears very messy and like it would have some hard-to-analyze knock on effects

Replying to "Adoption has built i..." did i say we would make it frame aware?

Replying to "Adoption has built i..." it’s the only practical choice. you can’t deprecate it

Replying to "Adoption has built i..." you have to modify it to work with the AA solution

Replying to "Adoption has built i..." ecrecover is deeply embedded in too many economically critical contracts. just identifying them will be a huge task

Here we propose: https://eips.ethereum.org/EIPS/eip-7851 Deactivate a Delegated EOA's Key https://eips.ethereum.org/EIPS/eip-8151 Private Key Deactivation Aware ecRecover

Replying to "Adoption has built i..." yes it will

but not linked to 8141 these are independent problems

Reacted to "Adoption has built..." with ➕

Replying to "Adoption has built i..." any written down ideas for modifying it to work with 8141?

Reacted to "but not linked to 8141 these are independent problems" with 👍

Replying to "Here we propose: ..." looks interesting , thanks will go thru it

Reacted to "looks interesting ..." with 👍

Replying to "Adoption has built i..." i dont get why 8141 has anything to do with ecrecover

Reacted to "i dont get why 814..." with 👍

Reacted to "i dont get why 814..." with 👍

Replying to "Adoption has built i..." because we need a way to revoke ECDSA keys for EOAs when those EOAs are being used to auth via ecrecover

Replying to "Adoption has built i..." yeah there are several eips with different proposals for this

you can't have native AA without any EVM usage

Replying to "Adoption has built..." few are the ones nico shared below Here we propose: https://eips.ethereum.org/EIPS/eip-7851 Deactivate a Delegated EOA's Key https://eips.ethereum.org/EIPS/eip-8151 Private Key Deactivation

Replying to "Adoption has built i..." consider “permit”. we need to make it not work after your deploy frame deploys something and then we ideally need to make it work with whatever your deploy frame deployed

Replying to "Adoption has built i..." https://eips.sh/eip/7819 https://eips.sh/eip/7851

Replying to "you can't have nat..." Without any is true, but both 8141 and 8130 both have native paths for "hot" algos. 8130 decouples that from the account code itself while keeping it native

Another benefit of 8141 is that the execution frame format is standardized. An issue with developing 4337 wallets was inconsistency in execution data encoding across account implementations, which meant that session key permission enforcement code had to be ported to many variants of accounts.

Wrapping precompiles should expect ~10-20% more expensive for smaller public key types

Replying to "Adoption has built..." We can put it this way , The existing EIP's doesnt want to fully support these migration , but atleast it should compliment one of migrating EIP's

Replying to "Adoption has built..." which I think frame does actually

I think there is no need for a precompile on hash based (future ZK hash incoming anyway). For lattice it could be the NVMpy

After V, we’ll prob have time for cperezz, Tomas, prestwich and need to wrap up there.

Replying to "Another benefit of 8..." there is a risk that session keys remain unstandardised, given that this isn’t part of 8141, but there is an effort to put such things into complementary ERCs

the third option is that we figure out how to build a special-purpose AMM that puts all of the risks associated with a hypothetical "bad" token onto LPs

Replying to "Another benefit of 8..." From my read, it seems like 8141 already allows for composability across various permission enforcement contracts by adding each one in a new VERIFY frame, right? Which would mean the account just needs to track the signer -> required enforcer contracts in storage.

What’s the middle ground authors have in mind going for? Are we going Strat 2.5? If so, which way? Are we going from less to more? Or for more to less? @lightclient if you want to asnswer would be nice

(I don't think this can be cooked up and proven safe within a month, but it's very plausibly the best long-term approach)

@CPerezz Another option to supporting ERC20s in the public mempool is the guarantor idea: https://github.com/ethereum/EIPs/pull/11555 The ERC20 paymaster can serve as the guarantor of transactions, and take on the risks of the sender validation failing

Replying to "the third option i..." Agree, and think that is the best approach

Reacted to "What’s the middle gr..." with ❤️

Reacted to "the third option is that we figure out how to build a special-purpose AMM that puts all of the risks associated with a hypothetical "bad" token onto LPs" with 👍

Reacted to "Agree, and think tha..." with 👀

Replying to "@CPerezz Another opt..." This will allow for mass invalidation in FOCIL @Derek Chiang | ZeroDev

Replying to "the third option is ..." The ERC20 paymaster can also just serve as the guarantor. The difference is that the ERC20 paymaster/guarantor would need to be a live service that signs off on transactions, while the AMM could be a pure onchain/passive construct

Replying to "@CPerezz Another opt..." FOCIL <> AA <> Statelessness can’t be solved with 1 EIP IMO

Replying to "Another benefit of 8..." for sure, but that’s still an account-level implementation choice

it does provide it

(erc20 sponsoring)

Replying to "@CPerezz Another opt..." Can you elaborate? As far as the mempool is concerned, the transaction is valid (pays gas) as long as the guarantor signs off on it

it’s just a question of how much to support it

without any precompiles, frames does a useful thing for post quantum (the 200k gas hash-based sig)

Replying to "@CPerezz Another opt..." They don’t have to check any sender validation logic, or access any ERC20 shared state

Reacted to "without any precom..." with 👍

Reacted to "without any precompi..." with 👍

Regarding timing, one big point that I would make, is that post 2027, core dev space is going to have a lot more competition

Replying to "without any precom..." and can be combined with a cheap ECDSA with session limits!

Multivariate has entered the chat

Replying to "@CPerezz Another opt..." What happens when guarantor becomes unaffordable?

The way I see this is: 2026: figure out AA 2027-28: figure out state (incl tree change, also incl expiry, temp state, utxos or any other idea) 2029-30: figure out VM

MAYO-2 is my new dream signature

Can I know what frames does not provide which it tells ? , Also the post quantum yes will need a follow on EIP's , but I do think with frames the ground work is done

i love me some Lamport, but why would we consider any non-FIPS PQ signature scheme?

"Is done" is doing a lot of heavy lifting there

Replying to "@CPerezz Another opt..." Exactly. I mean, who is gonna run this if they can be totally rugged?

Replying to "@CPerezz Another opt..." The guarantor in the public mempool would use the canonical paymaster contract which implements the timelock

We should allow non-FIPS, but we also need a FIPS scheme. Crytpo Agility in practice

Replying to "Can I know what fram..." https://eip8141.io/pq-roadmap

Reacted to "The guarantor in the..." with 👍

Replying to "The way I see this i..." How don’t we do AA & stateless at the same time? They clearly have lots of conflicting points & tradeoffs

Replying to "The way I see this i..." The ideation I mean

Replying to "The way I see this i..." ofc

Reacted to "We should allow no..." with 👍

Thanks all!

Replying to "i love me some Lampo..." anything that can be done in EVM efficiently is allowed (hashes) but why would we officially recommend it?

<3