Native Account Abstraction #002

gm

Gm

Daniil Ankushin invited Fireflies.ai here to record & take notes. By continuing, you agree to https://fireflies.ai/privacy Type: '/ff pause' - pause recording '/ff leave' - to stop recording View Realtime notes here: https://app.fireflies.ai/live/01M0W8E1ZXV3RW29X8WJD8EHFE?ref=live_chat

2 mins to start

Replying to "[Full message cannot be displayed on this version]" A picture of users enjoying native AA on Ethereum?

//github.com/ethereum/pm/issues/2191#issuecomment-5411174429

Replying to "[Full message cannot be displayed on this version]" Ah frame... i see. Wow i was slow

//github.com/ethereum/pm/issues/2191#issuecomment-5411174429" with 👏

Reacted to "Fyi statement from..." with 👏

Reacted to "Fyi statement from..." with ❤️

Reacted to "Fyi statement from..." with 👍

Recent changes to 8141: https://forkcast.org/eips/8141/?tab=history EIPs building on top of 8141 (4 PFI to hegota): https://forkcast.org/eips/8141/?tab=dependents

thanks again nethermind, ethrex, steel, thomas, and the other 8141 authors!

Reacted to "thanks again nethermind, ethrex, steel, thomas, and the other 8141 authors!" with ❤️

Reacted to "thanks again nethermind, ethrex, steel, thomas, and the other 8141 authors!" with ❤️

Reacted to "thanks again netherm..." with ❤️

Reacted to "thanks again nethermind, ethrex, steel, thomas, and the other 8141 authors!" with ❤️

Reacted to "thanks again nethermind, ethrex, steel, thomas, and the other 8141 authors!" with ❤️

Reacted to "thanks again nethermind, ethrex, steel, thomas, and the other 8141 authors!" with ❤️

Reacted to "thanks again netherm..." with ❤️

Reacted to "thanks again nethermind, ethrex, steel, thomas, and the other 8141 authors!" with ❤️

(I’ll interrupt in 15 mins to make sure we have plenty of time for discussion)

Reacted to "thanks again nethermind, ethrex, steel, thomas, and the other 8141 authors!" with ❤️

Reacted to "thanks again nethermind, ethrex, steel, thomas, and the other 8141 authors!" with ❤️

the reason we don’t have 2D nonce on 8141 directly is because it is a bit of a controversial L1 feature. we don’t want not ship frames because we can’t agree on 2D nonce on L1 or not. if everyone wants 2D nonce then we can do it

Reacted to "the reason we don’t have 2D nonce on 8141 directly is because it is a bit of a controversial L1 feature. we don’t want not ship frames because we can’t agree on 2D nonce on L1 or not. if everyone wants 2D nonce then we can do it" with 👍

Replying to "the reason we don’t ..." Same with recent roots as I can see, right?

Reacted to the reason we don’t ... with "👍"

Reacted to Same with recent roo... with "👍"

Replying to "the reason we don’t ..." ....and tx assertions, and expiring nonces 😁

Replying to "the reason we don’t ..." i think recent roots actually can be done out of protocol with a mempool rule like expiry

Reacted to ....and tx assertion... with "👍"

Replying to "the reason we don’t ..." Can I add pure frames and 8288 here?

Reacted to "Can I add pure frames and 8288 here?" with 🔥

Reacted to "Can I add pure frames and 8288 here?" with 😁

Replying to "the reason we don’t ..." Please do 🙏🏼

Reacted to Can I add pure frame... with "🔥"

like i mentioned in the thread above, recent roots doesn’t need an envelope change

Reacted to "like i mentioned in the thread above, recent roots doesn’t need an envelope change" with 👍

Reacted to "like i mentioned in ..." with 👍

— if you’re an L2 and happy to only allow specific account models, i don’t see why you wouldn’t also be okay with only supporting certain code hashes to originate txs? in that way, you can only allow accounts that authenticate themselves via an 8130-like keystore system

Heeft gereageerd op "i think recent roo..." met 👍

We would not be going inside ML-DSA or lattice based approched on the PQ side of things. Recent research shows that the security boundaries are moving so we will keep it hash based at the protocol level for a while

Would updating the keystore require a hard fork?

if the keystore rules live in a contract instead of the spec, what makes sure every client reads them the same way, and that they can't change outside a hard fork?

It seems like 8130 is not future-prove wrt signature aggregation (which we might need in a pq world). ActorId is exposed to the evm and not in the tx envelope. Would you consider adding it to the tx obj?

Isn't this proving that 8130 can do a prefunded sponsor who gets repaid, not that the transaction can self-fund? The payer still needs ETH before execution starts. How does a privacy withdrawal with no pre-existing payer acquire ETH first and then use that ETH for its own gas?

Replying to "It seems like 8130 i..." Agreed we should encode it as: Authenticator + actorId + data

The keystore keeps an account to authenticator mapping. With frames the verifier can be pinned by its code hash directly in the entry, with no registry. What does the registry give L1 that hash pinning does not?

Reacted to "Isn't this proving t..." with 💯

Why are we calling exec and validation code “coupled” in frames?

Reacted to "Why are we calling exec and validation code “coupled” in frames?" with 🤷‍♂️

Reacted to "Why are we calling e..." with 🤷‍♂️

"Frames have discovered dependencies, 8130 declares them." "8130 declares the validator entry point, not its dependency set. On the permissive L1 path an authenticator can depend on arbitrary mutable world state, and 8130 explicitly requires touched-state tracking and revalidation. Declared code is not declared dependencies."

Replying to "The keystore keeps a..." Code hash pins more than the authentication logic — it pins the entire account code. An authenticator is JUST the authentication logic, e.g. k1, r1, etc. So the registry allows you to maintain a much shorter whitelist of just the authentication schemes, whereas with code hashes you’d have to whitelist all account implementations even though they may only share a small number of authentication schemes.

Reacted to "Why are we calling exec and validation code “coupled” in frames?" with 🤷‍♂️

Reacted to "Why are we calling exec and validation code “coupled” in frames?" with 🤷‍♂️

"Isn't the actual asymmetry the opposite? Frames can implement the 8130 actor/authenticator model in account code, but 8130 cannot implement Frames' transaction lifecycle - for example execute first and approve payment afterwards. How is that a false equivalence?"

Wouldn't "run frames on top of 8130" be implementing a custom authenticator? Which means for the privacy usecase I might not make it into the public mempool.

Thanks! Is there a link to the slides?

Replying to "Isn't this proving t..."

//ethresear.ch/t/frame-transactions-and-the-three-gates-to-privacy/24666#p-59572-how-frame-transactions-eliminate-relayers-2

Reacted to "Isn't this proving t..." with 💯

If a future authentication scheme needs protocol recognition to obtain the good path, then authority is not really generalised - governance has become part of the account model.

Reacted to "Thanks! Is there a l..." with 👍

recent roots requires storage so it can’t be pure

Replying to "Thanks! Is there a l..." Up on this would like to get the slides

Reacted to "Isn't this proving that 8130 can do a prefunded sponsor who gets repaid, not that the transaction can self-fund? The payer still needs ETH before execution starts. How does a privacy withdrawal with no pre-existing payer acquire ETH first and then use that ETH for its own gas?" with 💯

Reacted to "recent roots requires storage so it can’t be pure" with 👍

Replying to "Why are we calling e..." In the sense that under Frames, the authentication code lives under the account itself, whereas under 8130, the authentication code lives in an authenticator contract, which is a separate contract from the account contract This has the benefit that it’s easier to gate by authentication logic — you can just gate authenticators without caring about what specific code the accounts themselves run. So different accounts can share the same authenticators and the accounts don’t have to be gated separately

Reacted to "Thanks! Is there a..." with 👍

Replying to "Thanks! Is there a l..." Recording of this speech is here: https://x.com/_chunter/status/2092236785329766404?s=20

Replying to "Thanks! Is there a l..." & example of a permissionless gas payer for a privacy flow here: https://github.com/base/eip-8130-examples/blob/master/src/authenticators/gas-payers/SimplePoolAuth.sol

Reacted to "Thanks! Is there a link to the slides?" with 👍

Reacted to "Recording of this sp..." with 👍

Antwoord verzenden naar "Thanks! Is there a..." @Chris - Base could you share slides? :)

Replying to "Isn't this proving that 8130 can do a prefunded sponsor who gets repaid, not that the transaction can self-fund? The payer still needs ETH before execution starts. How does a privacy withdrawal with no pre-existing payer acquire ETH first and then use that ETH for its own gas?" I agree both designs can use a permissionless prefunded sponsor that is atomically repaid from the withdrawal. But 8141's consensus model also permits execution before payment approval - for example withdraw ETH first and then approve that newly funded account as payer. 8130 structurally precharges before execution. Do you agree that is a capability difference, even though current 8141 public-mempool policy does not yet relay that shape?

Reacted to If a future authenti... with "👍"

I think we’re exaggerating the “pure” claims if you’re supporting something like recent roots

Replying to "— if you’re an L2 an..." if you don’t want to execute, why not just do this?

Reacted to "I think we’re exaggerating the “pure” claims if you’re supporting something like recent roots" with 👍

Replying to "Isn't this proving t..." Yes I agree but I’m not sure in practice how big of a difference this is. The paymaster could be the privacy pool itself if it reserves like 1 eth for sponsoring

Heeft gereageerd op "Thanks! Is there a..." met 👍

Replying to "Isn't this proving that 8130 can do a prefunded sponsor who gets repaid, not that the transaction can self-fund? The payer still needs ETH before execution starts. How does a privacy withdrawal with no pre-existing payer acquire ETH first and then use that ETH for its own gas?" is a legal difference

Replying to "Why are we calling e..." I get that, but that has nothing to do with coupling. What I hear from what you’re saying is that you’re concerned with code sharing/performance more than a flexibility/coupling issue

Replying to "Isn't this proving t..." Why? The pool itself is not a person

Replying to "Isn't this proving t..." The paymaster can be an immutable ownerless contract

Replying to "Isn't this proving that 8130 can do a prefunded sponsor who gets repaid, not that the transaction can self-fund? The payer still needs ETH before execution starts. How does a privacy withdrawal with no pre-existing payer acquire ETH first and then use that ETH for its own gas?" could be argued the deployer of pool is funding vs the person doing tx

Replying to "Isn't this proving t..." Then the deployer should be funded with tornado 🙂

Replying to "Isn't this proving that 8130 can do a prefunded sponsor who gets repaid, not that the transaction can self-fund? The payer still needs ETH before execution starts. How does a privacy withdrawal with no pre-existing payer acquire ETH first and then use that ETH for its own gas?" which is an example of issue :)

add receipts for individual calls, 2D gas, etc. It feels like 8130 is not open to much changes because they need to ship next month, so it feels like it is trying to be forced on L1 in a way that does not actually incorporate any feedback from L1 devs who have been working on frames for last 6 months. So fundementally, it don’t see how we ship the same EIP on L1 and L2 if base is going to fork next month. If that is the case, where are we going?

Reacted to "I’m not really sure ..." with 👍

Heeft gereageerd op "I’m not really su..." met ➕

add receipts for individual calls, 2D gas, etc. It feels like 8130 is not open to much changes because they need to ship next month, so it feels like it is trying to be forced on L1 in a way that does not actually incorporate any feedback from L1 devs who have been working on frames for last 6 months. So fundementally, it don’t see how we ship the same EIP on L1 and L2 if base is going to fork next month. If that is the case, where are we going?" with 👍

we can debate 8130 all day, but i don’t know what it will do for us

add receipts for individual calls, 2D gas, etc. It feels like 8130 is not open to much changes because they need to ship next month, so it feels like it is trying to be forced on L1 in a way that does not actually incorporate any feedback from L1 devs who have been working on frames for last 6 months. So fundementally, it don’t see how we ship the same EIP on L1 and L2 if base is going to fork next month. If that is the case, where are we going?" with ➕

add receipts for individual calls, 2D gas, etc. It feels like 8130 is not open to much changes because they need to ship next month, so it feels like it is trying to be forced on L1 in a way that does not actually incorporate any feedback from L1 devs who have been working on frames for last 6 months. So fundementally, it don’t see how we ship the same EIP on L1 and L2 if base is going to fork next month. If that is the case, where are we going?" with 👍

add receipts for individual calls, 2D gas, etc. It feels like 8130 is not open to much changes because they need to ship next month, so it feels like it is trying to be forced on L1 in a way that does not actually incorporate any feedback from L1 devs who have been working on frames for last 6 months. So fundementally, it don’t see how we ship the same EIP on L1 and L2 if base is going to fork next month. If that is the case, where are we going?" with ➕

add receipts for individual calls, 2D gas, etc. It feels like 8130 is not open to much changes because they need to ship next month, so it feels like it is trying to be forced on L1 in a way that does not actually incorporate any feedback from L1 devs who have been working on frames for last 6 months. So fundementally, it don’t see how we ship the same EIP on L1 and L2 if base is going to fork next month. If that is the case, where are we going?" with 👍

add receipts for individual calls, 2D gas, etc. It feels like 8130 is not open to much changes because they need to ship next month, so it feels like it is trying to be forced on L1 in a way that does not actually incorporate any feedback from L1 devs who have been working on frames for last 6 months. So fundementally, it don’t see how we ship the same EIP on L1 and L2 if base is going to fork next month. If that is the case, where are we going?" with 👍

Replying to "Isn't this proving t..." Yes this is a real capability gap — Frames can support transactions that pay gas with ETH acquired during execution, while 8130 cannot. The question is how meaningful that extra capability is when it doesn’t work in the public mempool — I can see arguments either way

add receipts for individual calls, 2D gas, etc. It feels like 8130 is not open to much changes because they need to ship next month, so it feels like it is trying to be forced on L1 in a way that does not actually incorporate any feedback from L1 devs who have been working on frames for last 6 months. So fundementally, it don’t see how we ship the same EIP on L1 and L2 if base is going to fork next month. If that is the case, where are we going?" with 👍

add receipts for individual calls, 2D gas, etc. It feels like 8130 is not open to much changes because they need to ship next month, so it feels like it is trying to be forced on L1 in a way that does not actually incorporate any feedback from L1 devs who have been working on frames for last 6 months. So fundementally, it don’t see how we ship the same EIP on L1 and L2 if base is going to fork next month. If that is the case, where are we going?" with 👍

Reacted to I’m not really sure ... with "👍"

Reacted to "I’m not really sure ..." with 👍

add receipts for individual calls, 2D gas, etc. It feels like 8130 is not open to much changes because they need to ship next month, so it feels like it is trying to be forced on L1 in a way that does not actually incorporate any feedback from L1 devs who have been working on frames for last 6 months. So fundementally, it don’t see how we ship the same EIP on L1 and L2 if base is going to fork next month. If that is the case, where are we going?" with 👍

Heeft gereageerd op "I’m not really su..." met 👍

Is the registry/keystore a system contract? Would it require a hard fork to update it? If that’s the case are we not just enshrining the canonical contracts and basically increasing the cost of adding new things and putting all of the pressure in the protocol?

non public mempool is just a DoS caution; isn't a hard rule

Reacted to "Yes this is a real capability gap — Frames can support transactions that pay gas with ETH acquired during execution, while 8130 cannot. The question is how meaningful that extra capability is when it doesn’t work in the public mempool — I can see arguments either way" with 👍

Reacted to "non public mempool is just a caution; isn't a hard rule" with 👍

Reacted to "I’m not really sure ..." with 👍

Reacted to "non public mempool is just a DoS caution; isn't a hard rule" with 👍

Reacted to "I’m not really sure ..." with ➕

Reacted to "Yes this is a real capability gap — Frames can support transactions that pay gas with ETH acquired during execution, while 8130 cannot. The question is how meaningful that extra capability is when it doesn’t work in the public mempool — I can see arguments either way" with 👍

My hunch has been for the last few days that the two standards must coexist since Base is launching 8130 and L1 has a lot of work already on Frames. Unification can be done on the SDK/interface level (similar to 5792). The transaction then executes via 8130 on Base and via 8141 on Ethereum. However a hard requirement here is that account contracts, encoders, SDK, interfaces, indexers - all is built by neutral parties and shipped together with Frames. Just so we don't repeat the general purpose 7702 view

Reacted to "Is the registry/keystore a system contract? Would it require a hard fork to update it? If that’s the case are we not just enshrining the canonical contracts and basically increasing the cost of adding new things and putting all of the pressure in the protocol?" with 👍

Replying to "Isn't this proving t..." Fwiw I agree the gap exists I just don’t believe it’s a big difference if it is possible to have ownerless paymasters (which could be the protocol itself, which also allows for mempool txs)

Reacted to "My hunch has been for the last few days that the two standards must coexist since Base is launching 8130 and L1 has a lot of work already on Frames. Unification can be done on the SDK/interface level (similar to 5792). The transaction then executes via 8130 on Base and via 8141 on Ethereum. However a hard requirement here is that account contracts, encoders, SDK, interfaces, indexers - all is built by neutral parties and shipped together with Frames. Just so we don't repeat the general purpose 7702 view" with 👍

The "withdrawing from privacy protocol" example would need a custom a authenticator. Has there been research how this would work?

Reacted to "non public mempool i..." with 👍

Sending txs to non-mempool nodes is more problematic privacy-wise imo

Reacted to "The "withdrawing from privacy protocol" example would need a custom a authenticator. Has there been research how this would work?" with ➕

Replying to "Isn't this proving that 8130 can do a prefunded sponsor who gets repaid, not that the transaction can self-fund? The payer still needs ETH before execution starts. How does a privacy withdrawal with no pre-existing payer acquire ETH first and then use that ETH for its own gas?" then are the deployers of the protocol liable in some jurisdictions?

Reacted to "The "withdrawing from privacy protocol" example would need a custom a authenticator. Has there been research how this would work?" with ➕

Replying to "The "withdrawing fro..." Does this sound like what you are looking for? https://eprint.iacr.org/2026/1074 simple efficient blind signatures

Reacted to "My hunch has been fo..." with 👍

Blind sigs like coinjoin?

You mean there are jurisdictions where it’s ok to deploy a privacy pool as long as it doesn’t sponsor txs? Even if the sponsor money does not come from the deployer?

We are comparing two fundamental different approaches, yes

imo we should just go over time on this

Reacted to "imo we should just..." with 💯

since everyone is here

Reacted to "imo we should just g..." with 💯

Reacted to "imo we should just..." with 👍

Reacted to "since everyone i here" with 👍

Reacted to imo we should just g... with "💯"

Reacted to "imo we should just g..." with 👍

Reacted to "imo we should just go over time on this" with 💯

Reacted to "imo we should just go over time on this" with 👍

Reacted to "imo we should just go over time on this" with 👍

Reacted to "imo we should just go over time on this" with 💯

Reacted to "imo we should just..." with 👍

Reacted to "since everyone is he..." with 👍

Reacted to "imo we should just go over time on this" with 💯

Reacted to "imo we should just go over time on this" with 👍

Reacted to "imo we should just..." with 💯

Reacted to "imo we should just..." with 👍

Reacted to "since everyone is here" with 👍

Replying to "The "withdrawing fro..." blind signature as in the original chaumian e-cash. coinjoin has coordination issues...

Replying to "Isn't this proving that 8130 can do a prefunded sponsor who gets repaid, not that the transaction can self-fund? The payer still needs ETH before execution starts. How does a privacy withdrawal with no pre-existing payer acquire ETH first and then use that ETH for its own gas?" No I mean will people's travel be restricted if is enshrined

Heeft gereageerd op "imo we should just..." met 💯

Reacted to "Isn't this proving that 8130 can do a prefunded sponsor who gets repaid, not that the transaction can self-fund? The payer still needs ETH before execution starts. How does a privacy withdrawal with no pre-existing payer acquire ETH first and then use that ETH for its own gas?" with 💯

Heeft gereageerd op "since everyone is ..." met 👍

Reacted to "Isn't this proving that 8130 can do a prefunded sponsor who gets repaid, not that the transaction can self-fund? The payer still needs ETH before execution starts. How does a privacy withdrawal with no pre-existing payer acquire ETH first and then use that ETH for its own gas?" with 💯

Replying to "The "withdrawing fro..." Ah, it's similar bit different, but not really. I'd want accounts to be able to validate a snark and have this be flexible + inside validation

From a pure cryptography PoV I feel like the canonical authenticator set is a stepback from the approach we have been pursuing. We are putting our efforts on STARK aggregation of a hash based sig on the long run. With 8130 the crypto-agility claim collapses. Going with P-256 and Webauth / Fido2 in ~ 2027 seems like a weird move imo Then from a privacy PoV we would take another hit and make a step back on the very nice 8141 <> recent roots <>

Replying to "Isn't this proving t..." By protocol I meant the smart contract not L1

You are able to use whatever you like on L1

Replying to "Isn't this proving t..." Like, tornado cash can sponsor txs

Replying to "The "withdrawing fro..." right. in this work, our goal was specifically to avoid proofs, and have a very lightweight anon payment using blind sigs

Reacted to From a pure cryptogr... with "👍"

Thanks for sharing. Will check it out!

There are different parties, clients, users, devs, wallets. Something can be easier for clients development, but much worse for everyone else.

Reacted to "Thanks for sharing. ..." with 👍

Replying to "There are different ..." Exactly

The protocol already has the authority k1 -> EOA Any contract -> Account Same thing

there are 2 main things 8130 does 1) it enshrines a lot of wallet logic into the protocol by default and 2) it has a different validation scheme where accounts specify authenticators. so we need to decide if we want these things on L1

Clients/protocol should not own the account, but 8130 is actually also two standards — there’s the account, and then there’s the validation model. What I’m proposing is that we seriously consider 8130’s validation model, but NOT the account. I elaborated on this point in my writeup today: https://x.com/decentrek/status/2092220720235565312

Replying to "Clients/protocol sho..." yeah that’s why i’m trying to get takes on these 2 points

I think people are confusing things here

Reacted to "Clients/protocol s..." with ❤️

The account model of 8141 is definable in 8130 (the account is its authority) 8130 is more expressive because you can also have the 8130 model

Reacted to I’m not really sure ... with "👍"

Replying to "There are different ..." Frames is not easy at all, I don’t think anyone is choosing frames because it’s easy

Replying to "The account model of..." that’s not true

both proposals are turing complete you can define the logic of each in the other

I think we keep bringing up this “coupled” vs “decoupled” terms which hold no technical value on this discussion

Can't do post payment

Reacted to "Can't post payment" with ➕

Reacted to "Can't post payment" with ➕

Replying to "both proposals are t..." that is true

Reacted to "Can't post payment" with ➕

Reacted to "Can't do post payment" with ➕

Replying to "both proposals are turing complete you can define the logic of each in the other" Is like flash loans only exist due to post-payback

I will have to drop

Can we go through raised hands? Not sure if we should just speak or wait

But Chris - if there is a default implementation everyone uses, you can statically reason about it the same as with 8130, correct?

Reacted to "Can we go through raised hands? Not sure if we should just speak or wait" with 👍

Reacted to "Can we go through raised hands? Not sure if we should just speak or wait" with 👍

Replying to "But Chris - if the..." Just thinking if I understand it correctly

A level of indirection is more expressive than not having one

Replying to "But Chris - if there..." yes this is my point ^^

Reacted to "But Chris - if there is a default implementation everyone uses, you can statically reason about it the same as with 8130, correct?" with ➕

Replying to "But Chris - if the..." 8141 with a default implementation everyone uses gets the same benefits you sell for 8130 + we can make a separate governance track where wallets can improve independently of core devs and clients

Reacted to "8141 with a default implementation everyone uses gets the same benefits you sell for 8130 + we can make a separate governance track where wallets can improve independently of core devs and clients" with 👍

Reacted to "But Chris - if there is a default implementation everyone uses, you can statically reason about it the same as with 8130, correct?" with ➕

Reacted to "8141 with a default implementation everyone uses gets the same benefits you sell for 8130 + we can make a separate governance track where wallets can improve independently of core devs and clients" with 👍

Reacted to "8141 with a default ..." with 👍

Reacted to "8141 with a default implementation everyone uses gets the same benefits you sell for 8130 + we can make a separate governance track where wallets can improve independently of core devs and clients" with 👍

Is not Frames much less performance scalable by forcing transactions to be simulated as valid before being included? That stops working as you scale to the point that you don't have time to simulate.

Replying to "A level of indirecti..." both do the same thing, it’s just a matter of taste and style

Replying to "Is not Frames much l..." you can also have a subset of frames where you only allow txs from accounts who are able to reason about statically

Reacted to "you can also have a subset of frames where you only allow txs from accounts who are able to reason about statically" with ➕

Reacted to "you can also have a subset of frames where you only allow txs from accounts who are able to reason about statically" with ➕

Reacted to "you can also have a subset of frames where you only allow txs from accounts who are able to reason about statically" with ➕

I accidentally unraised my hand so lemme type it here: 8130’s authenticator-base validation model is clearly superior for L2s, who want to gate transactions by authentication logic L1 doesn’t need the enshrined account in 8130, so we should move that part into a separate ERC, and keep just the validation model for L1’s consideration Frames’s validation model is more expressive — you can pay for a transaction with the ETH you acquired during execution, which is not possible in 8130. However, this is not allowed in the public mempool, so it can only work in private pools. So we need to decide whether this capability is important enough to justify Frames’s more expressive / complex validation model

Replying to "Is not Frames much l..." The level of scaling provided with STARK aggregation would be pretty huge. This world is finite there is no reason scaling beyond certain points imo

More than happy to hear more opinions from clients guys

Yes only pay for repayment

Replying to "I accidentally unrai..." I don’t understand this point However, this is not allowed in the public mempool, so it can only work in private pools. We want privacy pool txs to go through the public mempool no?

Opinionated account model is bigger problem for me on L1 than just paying upfront or at the end

Reacted to "Opinionated account model is bigger problem for me on L1 than just paying upfront or at the end" with 👍

We also need to take into account that a huge L2 (Base) will launch with 8130 and that Offchain will as well. Then the reference implementation of Frames can be 8130 bound.

Reacted to "Opinionated account model is bigger problem for me on L1 than just paying upfront or at the end" with 👍

Reacted to Opinionated account ... with "👍"

Reacted to "Opinionated account model is bigger problem for me on L1 than just paying upfront or at the end" with 👍

To nudge the discussion a bit: what is important to happen if 8141 proceeds on L1, and 8130 proceeds on <L2s>? (Default path)

Reacted to We also need to take... with "👍"

Replying to "I accidentally unrai..." mempool -> focil

Replying to "I accidentally unrai..." non public mempool is just a DoS caution; isn't a hard rule From @Ben Adams

Different chains, differernt reqs

Replying to "I accidentally unrai..." The threat model is builders are censoring and we need to go through focil

Replying to "To nudge the discu..." Interaction interface, default implemetation of a 8130 mapped account for Frames, built out SDK tooling, etc...

Replying to "I accidentally unrai..." Yes, must work with public mempool. Maybe not the initial version (with more conservative verfiy gas) bit drf in the future. Privacy needs the public mempool for CR.

8130 talks contract

Yeah so the self-funded thing doesn’t work either case and trustless paymasters are possible. The question is whether the self-funded option is useful for non-privacy use-cases

yeah i mean this is an area that we can look into. but in general you can also do this with ARBIRARY sig types

adding 20 byte identifier for each sig is pretty inefficient

The core coordination issue around new signing schemes for 8141 is the DoS attack surface due to state access. For L2s an additional consideration is even just the validation gas consumption, even without the DoS.

Isn't that more about fast precompiles to do the sigs?

Reacted to "The core coordinat..." with 👍

Reacted to "The core coordination issue around new signing schemes for 8141 is the DoS attack surface due to state access. For L2s an additional consideration is even just the validation gas consumption, even without the DoS." with 👍

Reacted to "Isn't that more about fast precompiles to do the sigs?" with 💯

the main thing is that i think on the L1 side, we don’t really want to add an enshrined keystore and we don’t want to enshrine the actor system, permissions, etc into the protocol (correct me if wrong)

Replying to "adding 20 byte ide..." Compress well if used often, at least.

and that seems to be the hard requirement chris has for 8130

other areas are more up for discussion

Agreed we don’t want to enshrine the other things but think keystore could be fundamental enough to be worth enshrining

We will create an EIP for the Guarantor mechanism

Btw I am working on a CROPS version of the guarantor via a state access underwiritng system, would love to speak with all involved stakeholders to see what you think about the proposal - still deciding whether its worth it or not.

A lot of this is just having a separate mempool (basically a separate queue for the sequencers) and being aware of the traffic

Replying to "the main thing is th..." then we should discuss it in the context of 8141 which already is stylistically how core devs want to ship AA (AFAICT)

Reacted to "Btw I am working on a CROPS version of the guarantor via a state access underwiritng system, would love to speak with all involved stakeholders to see what you think about the proposal - still deciding whether its worth it or not." with 👀

Replying to "We will create an EI..." Pedro started in this direction: https://github.com/ethereum/EIPs/pull/11681

Replying to "Btw I am working on ..." Happy to talk! Will message you on Slack

Replying to "Btw I am working o..." tl;dr - protocols can stake ETH onchain to guarantee access to certain state.

Reacted to "Happy to talk! Wil..." with ❤️

Replying to "To nudge the discu..." As long as the don't stomp on each other's addresses, then perhaps after some real world use, one side could implement the other.

Reacted to "A lot of this is just having a separate mempool (basically a separate queue for the sequencers) and being aware of the traffic" with 👍

Reacted to "Btw I am working on a CROPS version of the guarantor via a state access underwiritng system, would love to speak with all involved stakeholders to see what you think about the proposal - still deciding whether its worth it or not." with 👀

Why is there a seemed attraction on the side of the core devs to this “walk-away / less enshrinement” property of 8141? Is it a case of bandwidth / no wanting to maintain anything related to sessions moving forward?

Reacted to "Pedro started in this direction: https://github.com/ethereum/EIPs/pull/11681" with 👍

If you dont pull the authority back out the 8141 account then we dont fix frames

One unexplored design is frames on L2s where the sequencer is strict (analog to mempool) but forced txs are not (because they could pay for validation on L1)

Replying to "If you dont pull t..." Agree

Paying gas by something that happens inside the transaction requires transaction simulation for inclusion.

Reacted to "One unexplored design is frames on L2s where the sequencer is strict (analog to mempool) but forced txs are not (because they could pay for validation on L1)" with ➕

Replying to "A lot of this is j..." fwiw we (base) don't want to have to sim everything, during peak traffic our mempool gets ~100k inserts per second

Reacted to "Why is there a see..." with 👍

Reacted to "fwiw we (base) don..." with 👍

It's not just that what's the gap @Derek Chiang | Ethlabs . You don't need verify frames that are not at the beginning for the "withdraw from privacy protocol" use case.

Pay gas upfront and then execute

yeah i think the thing is that you can just make this as an ERC

Replying to "It's not just that w..." Sorry do you mind elaborating?

Reacted to "Paying gas by some..." with ➕

Replying to "It's not just that w..." The pool can sponsor and the tx has leading verify frames (none in between exec or at the end)

Reacted to "yeah i think the thing is that you can just make this as an ERC" with 👍

8130 has the same, you can use another schemes on L1 in tx And use them in EVM for recovery flows on L2

@marc | wolovim is it time to wrap up and discuss next steps? I would say 8141/8130 should collab and see if we can converge on a shared spec (regardless of the EIP number), with the key decision point being whether an enshrined keystore makes sense for the L1, at the cost of some validation flexibility

Replying to "It's not just that w..." I agree that you can have verify frames at every position, the protocol allows that, but might not be needed as long as the privacy pool can validate snarks and the repayment inside verify.

Reacted to "@marc | wolovim is it time to wrap up and discuss next steps? I would say 8141/8130 should collab and see if we can converge on a shared spec (regardless of the EIP number), with the key decision point being whether an enshrined keystore makes sense for the L1, at the cost of some validation flexibility" with 👍

Reacted to "@marc | wolovim is it time to wrap up and discuss next steps? I would say 8141/8130 should collab and see if we can converge on a shared spec (regardless of the EIP number), with the key decision point being whether an enshrined keystore makes sense for the L1, at the cost of some validation flexibility" with 👍

Reacted to "@marc | wolovim is it time to wrap up and discuss next steps? I would say 8141/8130 should collab and see if we can converge on a shared spec (regardless of the EIP number), with the key decision point being whether an enshrined keystore makes sense for the L1, at the cost of some validation flexibility" with 👍

Reacted to "@marc | wolovim is..." with 👍

Replying to "@marc | wolovim is i..." the only way i see this possible is if we use 8141 as the starting point. i don’t see a way that 8130 is accepted by L1, whereas 8141 is much much closer

Replying to "It's not just that w..." I have this excalidraw if it helps [Full message cannot be displayed on this version]

Replying to "@marc | wolovim is..." agreed, was 8130 even PFI'd?

Reacted to I have this excalidr... with "🙏"

Replying to "@marc | wolovim is i..." Again let’s not get attached on numbers — I agree that 8130 can’t be accepted as is because it has too much “account stuff”, but the validation model can be adopted

Reacted to "Again let’s not get attached on numbers — I agree that 8130 can’t be accepted as is because it has too much “account stuff”, but the validation model can be adopted" with ➕

agreed, was 8130 even PFI'd? We agreed to CFI “Native AA” not a specific EIP

"native aa" was cfi and I brought up 8130 on the call when that was done

Reacted to "agreed, was 8130 e..." with 👍

Reacted to "agreed, was 8130 eve..." with 👍

Reacted to "Again let’s not g..." with ➕

Replying to ""native aa" was cfi ..." 8130 isn’t CFI

Replying to "@marc | wolovim is i..." @lightclient I think we are closer to alignment than ever though. To address your concern about the decision being deadlocked, I think we can just timebox this collab session; if we can’t align in a few weeks we can just accept the fragmentation and go separate ways, but we should give it a try first

Reacted to "8130 isn’t CFI" with 👍

Replying to ""native aa" was cfi ..." https://eips.ethereum.org/EIPS/eip-8081

Reacted to "@lightclient I think we are closer to alignment than ever though. To address your concern about the decision being deadlocked, I think we can just timebox this collab session; if we can’t align in a few weeks we can just accept the fragmentation and go separate ways, but we should give it a try first" with 👍

Replying to "@marc | wolovim is i..." yeah i mean i don’t care about the actual numbers

Replying to ""native aa" was cfi ..." 8130 isn’t CFI We agreed to CFI “Native AA” not a specific EIP like 8141

Replying to "@marc | wolovim is i..." i just care about the design

Reacted to "8130 isn’t CFI We..." with 👍

Replying to ""native aa" was cfi ..." it’s not on the meta eip 🤷

Reacted to "i just care about the design" with ❤️

Reacted to "@marc | wolovim is..." with 👍

Reacted to ""native aa" was cf..." with 😂

I don’t think the technicality matters if we care to have the best native AA standard for L1 Not to argue for either EIP, just saying

Replying to ""native aa" was cf..." we should follow process next time if possible: https://eips.ethereum.org/EIPS/eip-7723 re. PFI section, maybe its not clear enough to L2s

Reacted to "I don’t think the..." with ❤️

Replying to ""native aa" was cfi ..." my point is that 8141 is the vehicle for native AA, and we have spent a lot of time to find a stylistic format that as acceptable to L1

Reacted to "I don’t think the technicality matters if we care to have the best native AA standard for L1 Not to argue for either EIP, just saying" with ❤️

Reacted to "I don’t think the..." with ❤️

and the concepts transfer over to 8130 too though. If the disagreement is having the authority mapping system (keystore) or not then thats probably a schism. Keystore could be simplified if needed but I think thats a requirement for us