marc | wolovim:All right, welcome everyone. I will post in the agenda in the chat, and then we'll kick this thing off.
Transcript
marc | wolovim:So welcome to Native Account Abstraction Breakout Number 1. Today is April 22nd, 2026.
marc | wolovim:The agenda is a big one, so,
marc | wolovim:Let's… let's get through what we can, and
marc | wolovim:Find out how much is left over for the next chat.
marc | wolovim:The context for this new series is that EIP8141, that's Frame Transactions, was recently proposed as a headliner for HEGOTA, the Ethereum upgrade after Glamsterdam.
marc | wolovim:It garnered support from a variety of stakeholders in the ecosystem and was CFI'd, meaning considered for inclusion in that upgrade.
marc | wolovim:But ultimately was not selected as the headliner by client teams, and the reasons given varied
marc | wolovim:And they are hopefully well represented in today's agenda.
marc | wolovim:But in short, if I may summarize, client teams wanted more time to understand the implications on the mempool, stateless efforts, privacy preservation, and the post-quantum roadmap, among other design decisions.
marc | wolovim:More broadly, though, the proposal generated
marc | wolovim:Well, it feels like real momentum for shipping native account abstraction in the Hego Tough Fork.
marc | wolovim:So there's been a flurry of other proposals, both alternatives to 8141, and those complementary or compatible with it.
marc | wolovim:So now seems exactly the right time to start to converge on a version of this feature set that we can all live with.
marc | wolovim:The sooner we have rough consensus on an approach, the sooner client teams can begin pipelining the work, and the sooner the broader ecosystem can begin the long road to adoption.
marc | wolovim:Last logistics note, breakout calls like this one cannot change the inclusion stage or the headliner status of an EIP. That can only be done by rough consensus within an all-core devs call.
marc | wolovim:So I would suggest that a good use of time here is to improve our collective understanding of the trade-offs we need to make, to refine the existing proposals, steal good ideas, and identify whatever the next steps are to move forward with confidence.
marc | wolovim:So that's sort of the preamble.
marc | wolovim:Before we jump into hearing from proposal authors on recent updates,
marc | wolovim:the first feedback I've heard that I would like to at least briefly acknowledge is the sentiment that we…
marc | wolovim:should be sure we're clear on goals and what we're solving for here. It's true that account abstraction means different things to different people.
marc | wolovim:And much has been written on that topic. For example, Vitalik has outlined core and stretch goals in his full account abstraction doc that you can find in the agenda.
marc | wolovim:I've heard Matt and Felix and others describe their motivations on all CoreDev's calls, but I wanted to leave at least a little space here.
marc | wolovim:So the prompt is, would anybody like a minute or two to communicate what you think is most important for a native account abstraction proposal to accomplish?
marc | wolovim:Those I've mentioned already are welcome to come up and reiterate any points. Maybe this is a good opportunity for other ecosystem stakeholders to chime in, so just raise a hand if you'd like to
marc | wolovim:Say a few words?
ivo Georgiev @ ambire:I can give you a few thoughts from the point of view of a wallet developer.
ivo Georgiev @ ambire:So…
ivo Georgiev @ ambire:There's a couple of things, and they're all related to the practical efficiency of existing account abstraction solutions.
ivo Georgiev @ ambire:So, one of them is…
ivo Georgiev @ ambire:really, 7702 and all solutions before 7702, which were just proprietary solutions, what they managed to achieve, a lot of things, but without actual upgrade paths for existing EOAs and existing accounts, the adoption really stalled.
ivo Georgiev @ ambire:7702 kind of solved it, but the issue with this is that it still requires
ivo Georgiev @ ambire:an authorization, and most hardware wallets still don't support this feature, so they still, like, either rely on a very narrow, whitelist.
ivo Georgiev @ ambire:or they don't support it at all. So, in practice, the current account… the current state of account abstraction is that you cannot use account abstraction features in many EOA accounts. So, this is something that frame transactions solve.
ivo Georgiev @ ambire:So that's fantastic. And then the second thing is, 4337 really is kind of a bit clunky. Some would even say bloated, and that's also another point of, point of view that, frame transactions solve. So this is, like, the practical implications.
marc | wolovim:Thank you. Agus, if I'm pronouncing it anywhere close to right.
Agusx1211 (Polygon):Yeah, I think so.
Agusx1211 (Polygon):In our perspective, we are a polygon, we are X-sequence, we are also Smart Control Wallet. Our point of view of account abstraction, really, or in the context that we are discussing this, is that this is what, in the old times, was called
Agusx1211 (Polygon):every layer, like, this is an alternative to have a proper solution to be able to execute the smart contract transactions on-chain. And our point of view is not really about migration from old accounts or anything like that. We are working mostly with new accounts.
Agusx1211 (Polygon):But what we want to preserve is the flexibility to develop new functionalities on smart contract wallets. And what we want to gain is not having to maintain and develop around custom, like, vertical layer that is not a great, like.
Agusx1211 (Polygon):not a great participant in the whole stack. It's not decentralized, etc.
Agusx1211 (Polygon):M… So… From our perspective.
Agusx1211 (Polygon):any solution, we are big supporters of frame transactions as they are, mostly because they do allow for a full spectrum of development of new functionalities and things like that. If we go into something more constrained.
Agusx1211 (Polygon):what will likely happen for us is that we will just not use it, and we will keep, like, working on some of the previous standards.
Agusx1211 (Polygon):But… Frame transactions as they are is something that, like, will be very useful for our team.
marc | wolovim:Thanks, Matt.
lightclient:Hey guys. Just wanted to share a little bit of my perspective. I've shared it in…
lightclient:you know, many different contexts over the past few months, but if I could try to address one point that's been coming up a bit around the post-quantum side of AA and the frames transaction.
lightclient:You know, when we originally started with frames, we had a…
lightclient:A lot of conversations, like, what are we trying to achieve?
lightclient:And…
lightclient:there's a doc that I shared by Vitalik that, you know, kind of goes over many of the core goals that we had in mind with accounts abstraction.
lightclient:And at that time, you know.
lightclient:And even today, I feel like post-quantum is becoming something that everybody's realizing we need to start thinking about and focusing on.
lightclient:And I felt that…
lightclient:focusing AA and frame transactions a bit in this direction of post-quantum was good, because, you know, broadly, everybody feels this is a direction that we should be working towards and focusing on.
lightclient:And we know, as, you know, people who have been working on the protocol for a very long time, and people who have, you know, been working on account abstraction in different ways for, you know, 6, 7, 8 years, you know, we know all of the downstream effects that AA would provide, and it's very difficult to…
lightclient:You know, have these breakout rooms, have these, you know, long.
lightclient:running discussions about what the protocol should and shouldn't do, and, you know, how should they deliver accounts abstraction, how should they not? You know, we're all kind of seeing how difficult it is to define what accounts abstraction even is. You know, it's different for every single person, and it just depends on, like, where in the stack you're sitting.
lightclient:And so I felt like, you know, focusing a bit on post-quantum was a good rallying point for people, where we could say, look, it's not that we don't care about UX, it's not that we don't care about these other things, it's just that, like, we need to solve post-quantum, and we have this really good technology that does tons of other things at the same time that we've been working on for a long time.
lightclient:And, I don't know, maybe that was, like, kind of, like, the wrong initial approach.
lightclient:And some people have, like, you know, pushed back and said, do we really want to tie, you know, post-quantum to count abstraction? And it, you know, it's a question. I still think that, like.
lightclient:you know, broadly, this is the right direction for us. It's not the easy path to solving post-quantum, but it's a path that we understand pretty well at this point, and we just need to, you know, put in the work to achieve it, and to define the exact feature set that we're trying to, you know, achieve.
lightclient:And so, you know, through all these conversations, I've also kind of, like, realized that there's one, you know, other piece that's kind of in this original Vitalik doc, but, like, maybe wasn't, you know, communicated as clearly from the beginning with 8141.
lightclient:And that's something that I… you know, this is something that I think that most other proposals, you know, also don't really support. And the frames and the native AA proposals are basically the only ones that support it. And that's that, you know, we're trying to reduce
lightclient:the centralization around transaction flow in Ethereum. And we're trying to allow all users of Ethereum, you know, both ELA and smart accounts, to make use of new, you know, hardening functionality in the protocol, like FOCIL.
lightclient:And that's, like, you know, maybe something that we haven't highlighted quite as much in the past, but I think, like, going forward, it's something that we should be keeping in mind. Like, yes, we need to have batching, yes, we need to support key rotation, this is all, like, critical for accounts abstraction, but we need to make sure that we're doing this in a way that, you know, supports post-quantum.
lightclient:Supports post-quantum aggregation types of techniques.
lightclient:And reduces the reliance on centralized relayers.
lightclient:And so I think, like, this combination is kind of how we've come up to, you know, presenting the frame transaction. And, you know, some of the decisions of the frame transaction may not always be the most obvious of why these decisions are getting made.
lightclient:But all of this… all of these decisions are coming from, like, many years of experience across, like, you know, Felix Vitalik and I from the protocol, Derek from the wallet side, and then interacting with, like, you know, tons of people in the wallet community and the application developer community on understanding, like, what their needs are.
lightclient:So, that's kind of, yeah, how we've ended up, you know, from our perspective on the solution that we have.
marc | wolovim:Thanks. Ben?
Ben Adams:Yeah, so, I appreciate the flexibility of frame transactions, but, from
Ben Adams:my perspective on approaching it more pragmatically, and, what's practical in terms of… so, for instance, a frame transaction, you could, in theory, do a, like, a post-quantum signature, and then…
Ben Adams:Validate that.
Ben Adams:In… in that, but at the moment, we don't have a way in the EVM of
Ben Adams:Efficiently running that.
Ben Adams:So, you know, like, Falcon would be, like, 2 million gas. Dilithium would be about 8 million gas transactions.
Ben Adams:So these, these are, like, heavy. I mean, even EDSA is…
Ben Adams:I don't know, it's like 100,000 gas or something?
Ben Adams:Versus… as…
Ben Adams:in protocol, as a precompile or native, then it becomes, you know, 3,000 gas. So it's orders of magnitude different.
Ben Adams:If it's running as… current EVM bike code. I know there were…
Ben Adams:proposals, which I'm not sure are currently active to do, like, EVM Max and FIMD to do efficient
Ben Adams:crypto… Cryptographic, processing.
Ben Adams:But I don't think they are active at the moment. I could be wrong.
Ben Adams:So I… my… my concern is that we would…
Ben Adams:Deliver something that, in theory, can
Ben Adams:Meet lots of needs, but in practice, would fall down.
Ben Adams:If you see what I mean. So if your… if your transaction, just to verify the signature is costing 2 million gas, you can only have 30 in the mempool.
Ben Adams:And you… that's the size of a block, just verifying those signatures.
Ben Adams:So for instance, scheme transactions would say, alright, well, we accept that we need currently, native.
Ben Adams:Processing for these, signatures.
Ben Adams:Rather than… you know, write it as raw EVM bike code when
Ben Adams:That would be extremely expensive to process.
Ben Adams:Yeah, it's more about practicality. Will it deliver?
Ben Adams:On the expectations in a practical way.
marc | wolovim:Thank you, Ben. Mustav?
Mislav:Yeah, hi everyone. On my end, I just wanted to basically reiterate, support, from my end for the frame transactions.
Mislav:Though the critiques are certainly valid, and by any means I'm not an expert in post-quantum cryptography. I think for what we've seen in the cases of existing AA teams and the use cases that we have been serving for the last
Mislav:2 or 3 years. Frame transactions luckily capture all of them in a very elegant manner. Even Derek made a proposal yesterday to access, like, some bits of,
Mislav:non-self state without hurting the mempool, etc. So I feel, as far as the coordination is going on the account abstraction teams, we can do a lot, and standardize a lot, through the frame transaction,
Mislav:through the frame transaction, proposal as it is right now, maybe with a few minor changes, and that's, yeah, that's definitely something I would…
Mislav:give it as a big plus, because, you know, like, it's always been notoriously difficult to coordinate in the AA community, and yeah, frames have actually managed to achieve that in quite a significant way, so I think that's a very big plus.
marc | wolovim:Thank you. Press switch.
prestwich:The things I think are most important for native AA to accomplish are transaction batching and permanent key invalidation.
prestwich:You need to be able to permanently invalidate the credentials of an account.
prestwich:And replace them.
prestwich:Frame transactions accomplish these in…
prestwich:reasonable, but fairly complex ways. They require an awful lot of wallet rollover.
prestwich:and…
prestwich:you know, I think that simplifying implementation is the other main thing native AI should accomplish. I don't think that…
prestwich:Future compatibility for unspecified aggregation systems, or for…
prestwich:Other unspecified future cryptographic systems is important.
marc | wolovim:I appreciate that. We're gonna wrap up here, but Chris, are you able to…
marc | wolovim:Speak quickly on this topic?
Chris - Base:Yeah, I can go… try to go super quick, but, like, I think, you know, in summary, I think, you know.
Chris - Base:Teams have different kind of opinions on, like.
Chris - Base:What's important based on, you know, if their wallet, if they've run protocols, etc, like, and…
Chris - Base:frame transactions, like, you know, I think
Chris - Base:speak to the ethos of Ethereum, like, being uncensorable.
Chris - Base:And compatibility with FOCIL, like, that's all…
Chris - Base:You know, super powerful and whatnot, but…
Chris - Base:I do think, like, I hear a lot of feedback from, you know, wallet teams, it's like, well.
Chris - Base:again, I think the only feature they do want is, like.
Chris - Base:So the ERC20 gas payment, and then a few signature types.
Chris - Base:key rotation.
Chris - Base:And that, you know, that seems to be, like, you know, roughly it. So, I think there's,
Chris - Base:a bit of overhead being paid and, like, the complexity of frame transactions for, like, maybe future features that we may not necessarily use. And that's the, you know, I'm just trying to, like, aggregate some of the feedback, that I've gotten as well, just on, you know, why teams aren't… don't want to do, A141.
Chris - Base:I think, like, everything else has kind of been said. And then, like, in general,
Chris - Base:8130 is, like, just trying to address some of the performance issues while still being general, but more…
Chris - Base:defined in certain sense, so it's not quite as flexible, like, the frame ordering is… Sorry, the ordering of, like, what you can do and what you can call is explicit to try to make, things easier for protocol and denial of service risks and whatnot.
Chris - Base:But all those, like, things have to be considered as…
Chris - Base:Like, obviously 8141, and, like, AA in general touches, you know, pretty much the entire stack, from protocol, right, to wallets, to, like, UX to everything, right? So…
Chris - Base:Yeah, just to add that.
marc | wolovim:Great, thank you, and that's, maybe a good transition as well.
marc | wolovim:maybe my parting thought on this topic is that I don't think it's reasonable to expect consensus on this topic.
marc | wolovim:Yet, it is very valuable to hear what's important and what's at stake for different users of Ethereum.
marc | wolovim:Let's transition here to the, proposal updates section. So, for each, proposal, I welcome the authors to
marc | wolovim:catch up… catch us up on developments from, let's say, the past month or so, because it was, maybe three-ish weeks ago, where the last debate of account abstraction or
marc | wolovim:These… this set of proposals occurred.
marc | wolovim:And I know there's been a lot of activity since then.
marc | wolovim:I'll leave the floor open, does anyone,
marc | wolovim:Does anyone want to step up to…
marc | wolovim:Provide some updates for the proposal they are an author for.
Derek Chiang | ZeroDev:Oh, I think I can probably, like…
Derek Chiang | ZeroDev:give some updates on the firm's side. So…
Derek Chiang | ZeroDev:I think based on what everyone has said, it's clear that there are two competing…
Derek Chiang | ZeroDev:I guess, goals of AA that, I guess are pushing some of the Yazis, you know, EIPs in different directions, right?
Derek Chiang | ZeroDev:So, one thing that people want, is flexibility, right? You know, people want to, for example, be able to.
Derek Chiang | ZeroDev:originates transactions from privacy protocols, right? So that will save users of privacy protocols from having to rely on centralized relayers. So that's, like, one example of the larger goal of
Derek Chiang | ZeroDev:Flexible validation logic. But then on the other hand, you also hear people who want to have.
Derek Chiang | ZeroDev:essentially predictable performance when it comes to the mempool, right? So people want to be able to validate transactions very cheaply, without necessarily having to chase through a very large transaction, right? And that's also true for L2s, right? You know, so that's why Chris from Base
Derek Chiang | ZeroDev:mentioned that, some L2s, they, you know, they also want that, right?
Derek Chiang | ZeroDev:So one update, you know, so, and by the way, like, that's actually been the top priority, within, kind of like, the firm's author group, which is to adjust this dichotomy, right? You know, like, the, kind of like the tension between flexibility and performance. So, one solution that we, worked on, I actually posted a PI in…
Derek Chiang | ZeroDev:the AA Mafia, you know, yesterday. Basically.
Derek Chiang | ZeroDev:It's this idea of allowing, friends to be structured such that the payment, the payment frame.
Derek Chiang | ZeroDev:can come before the sender validation frame. So, normally for every transaction, obviously, like, no one pays gas unless the sender signature is valid, right? Because if the sender signature is invalid, then obviously this transaction should not be authorized, and therefore no one pays gas, right?
Derek Chiang | ZeroDev:But since frames kind of, like, decouples the authorization from the ordering, right, you know, because you can order firms in any way, we're actually able to allow, I guess, people to approve the payment of a transaction
Derek Chiang | ZeroDev:before the validation of the sender signature. So what this does is that, if a member pool sees a friend's transaction where the payment is authorized first, then they actually do not have to check
Derek Chiang | ZeroDev:they do not have to validate the sender logic. So what this means is that, for example, today, if you want to send a, a privacy, you know, a transaction originated by a privacy protocol.
Derek Chiang | ZeroDev:that may be hard to propagate through the public manpool, because the privacy protocol validation might take a lot of guess, right? But with this change, as long as you can find another sponsor for your transaction, which can also, by the way, be one of your other wallets.
Derek Chiang | ZeroDev:Then the mempool just has to validate the payer signature. The mempool doesn't have to validate the sender signature. So that's essentially one way for us to achieve very predictable performance in the mempool.
Derek Chiang | ZeroDev:wire still allowing arbitrary, sender validation logic. So, I think that's, like, a really, sort of, like, noteworthy update that is currently being worked on for friends.
Derek Chiang | ZeroDev:Yeah, not sure if there are any questions, or if maybe Matt or Vitalik want to add anything.
marc | wolovim:Okay, thank you. Ben?
Ben Adams:Yeah, so I added, I tightened up the spec for frame transactions a little bit, and that's been merged.
Ben Adams:But also… So they, added two more EIPs, which are, Contact contract payer transaction.
Ben Adams:And the idea… so… You'd have something… Else that would handle,
Ben Adams:Changing the cryptographic keys in terms of what you're signing with, which
Ben Adams:would be schemed, but I think there's a number of other EIPs for that.
Ben Adams:And so if we divorce that, from…
Ben Adams:From the system, then the idea with
Ben Adams:The contact payer transaction is… it would be, like, one-to-one, so a contract would say, I accept.
Ben Adams:I am the… I am the… I am owned by this signer, so your, your… the EOA effectively becomes a signer.
Ben Adams:And…
Ben Adams:the Memple could go, okay, does this contract have enough ETH to pay for the transaction? And it becomes a very light way to verify it.
Ben Adams:Rather than having to invoke the, EVM.
Ben Adams:And then… Also, there was the counterfactual transaction.
Ben Adams:Which is a similar thing.
Ben Adams:But you can validate that a privacy pool could pay for the transaction. What's being withdrawn… you prove that what's being withdrawn from the privacy pool can cover the transaction gas, so those are the two others. But it's,
Ben Adams:So the combination of the EIPs is more unbundling than Frame, which is a different kind of layering.
Ben Adams:That's this.
Ben Adams:I… I'd highlight a difference in the sponsorship,
Ben Adams:So the contact payer transaction is essentially one signer to one vault. The signer can have, like, many assets, many contracts that approve them.
Ben Adams:So you could,
Ben Adams:you could sign, you know, you could say, I'm using this smart contract. You'd essentially do two, and the… the smart contract, because it's a smart contract, can do batching and all that sort of stuff, so that's… that's fine. But it wouldn't do what Frame Transactions does, where you could
Ben Adams:have a difference between… I could be sponsored by somebody completely different, you know, that could be disconnected. It would be like.
Ben Adams:You… you can be sponsored by your assets, which are in a different account, not…
Ben Adams:Some third party can do it.
Ben Adams:If that makes sense.
Ben Adams:Buddy, you can… Through that, you can achieve key rotation and all that.
Ben Adams:Stuff as well, because you change who the signer key is for…
Ben Adams:For that vault. And then the assets are now at a different address.
Ben Adams:And the identity would be associated with the smart contract, because that's the thing that contains everything.
Ben Adams:So that would have your… You know, you're…
Ben Adams:ENS names, your positions on Aave, or… or whatever.
Ben Adams:So it just sort of inverts everything.
marc | wolovim:Cool, thank you, Ben.
marc | wolovim:If we've got time for it,
marc | wolovim:there are sub-bullet points for privacy and adoption strategy. Some of this is, good debate to occur there as well.
marc | wolovim:The…
marc | wolovim:last EIP on my radar. I know Frederick was interested in saying a couple words about, 7906, which is…
marc | wolovim:Compatible with, frame transactions?
marc | wolovim:Frederick, do you want to jump in?
Fredrik:Yeah, yeah, sure.
Fredrik:Yeah, to give you a bit of a background, so during the outreach of the trillion dollar security project, we asked
Fredrik:basically hundreds of people and entities for feedback on areas, that they felt we should focus on to help onboard the next billion users. And…
Fredrik:There was one thing that was always brought up as one of the most problematic factors for mass adaptation, and that was the amount of hacks that people fell victim to, primarily to things like drainers and phishing attacks and other things.
Fredrik:It's obviously a problem here when someone do lose their funds, on, like, in its own.
Fredrik:But then, this is amplified by quite a lot, when, you know, they will naturally tell their friends, their family, colleagues, etc, about what happened. And that kind of creates this negative spiral.
Fredrik:So…
Fredrik:We have been looking into ways to fix this, and there's no, like, silver bullet to fix this, but, you know, there are projects such as
Fredrik:Clear signing being worked on that would help people more easily understand what they're signing. There are verifiable frontends that help provide the ability to wallets to
Fredrik:display warnings if a front end that people are interacting with has been compromised in any way. And then there's transaction assertions, which is, yeah, I guess the topic here.
Fredrik:So, you know, today, if you use a wallet, normally what it will do is simulate what you're about to sign, and you can see that it looks like this is gonna happen. But a simulation is…
Fredrik:Just a simulation, so it's not, you know, binding.
Fredrik:And the real issue is not…
Fredrik:Like, if the intended action happens, but…
Fredrik:I mean, that's not the only issue, it's also if any extra side effects happen that the user never approved.
Fredrik:And that can be, for example, you know, you think that you're gonna get a NFT by doing this transaction, which you might get, but you also approve a spender… a malicious spender address on your USDC, for example.
Fredrik:And then, so transaction assertions, they basically solved this by letting the user approve.
Fredrik:what could be called an envelope of effects. Basically, execute this specific thing, but then revert your transaction if the actual outcome goes outside of this policy.
Fredrik:We've been discussing many ways of doing this,
Fredrik:But I think this fits very naturally into frame transactions, because frames already separate the execution into stages, so, you know, frames can give us the structure, and then assertion can give us the safety policy at the end.
Fredrik:we've been thinking about different ways of doing this. It's been, I guess, discussed in various forms for, like, a year or so, maybe even more. We had a big… a fairly big breakout at DevConnect about this as well, discussing the pros and cons of
Fredrik:For example, one idea was to have a new transaction type,
Fredrik:Which was then, kind of, shelved after discussions.
Fredrik:And then, basically the…
Fredrik:the best approach seems to be to have an opcode. So, there's an EIP for this, 7906, which basically helps fix this.
Fredrik:The next step here is basically to create a proof of concept that this works, some kind of a demo playground that shows, you know.
Fredrik:With… without, 7906,
Fredrik:This is what would happen during a malicious transaction with 7906. This is, you know, how it would be stopped, basically.
Fredrik:And then, create some tests and such, so we can hopefully be included in a future hard fork.
Fredrik:Yeah, I guess,
Fredrik:Something I did want to bring up is that I saw that eTrex made this,
Fredrik:cool them implementation of transactions, and yeah, perhaps…
Fredrik:We can chat later about doing something similar to this to show, basically, how 7906 ties together with the frame transactions and provide the ability to prevent these kind of attacks from happening.
Fredrik:Alex is the author of 7906. I think he's in the call. I think I saw him, at least, at one point. I don't know if he wants to say something.
Alex Forshtat:Yeah, hi, everyone. Thank you very much for, the interest, and yeah, I would, love to cooperate with Ethrex on the demo, like, thought, about it for…
Alex Forshtat:quite some time, and, yeah, it's, it's a very strong primitive to be able to provide, the, like, negative, assertions, like, and negative conditions for…
Alex Forshtat:per transaction, it plays very well with frame transaction, doesn't necessarily require frame transaction as an opcode. You can…
Alex Forshtat:done in… In parallel, yeah, I guess that's it, I,
Alex Forshtat:If anyone has any questions, I'd also be happy to answer.
marc | wolovim:Thank you both. Tomas has a hand up.
Tomás Arjovsky | Lambda | Ethrex:Hey, no, just a quick clarification from the Ethrex team. Aside from the demo, we have also implemented a small DevNet. It's running on one server, so it's nothing to prove on low tests or high scale, but if you want to try, give some RPC requests to some running nodes, we already have them. We can send you the links if you want.
Tomás Arjovsky | Lambda | Ethrex:And there's also a faucet, and there's a couple of contracts for a Paymaster example, and a gas sponsor example that can be used to test, how frame transactions work. So yeah, let us know if that's something that you'd be interested in testing.
marc | wolovim:Excellent, thank you.
marc | wolovim:So I see we've got plenty of follow-up questions in chat. I think that's a good thing. I will acknowledge we will not be able to go down each of those rabbit holes here. We've got about 20 minutes remaining in the call, so I'll suggest we move to the
marc | wolovim:the next section, which is… there are many more rabbit holes here as well. We're definitely not going to be able to get very deep into any of them, but hopefully we can make enough progress to identify
marc | wolovim:For example, next steps, or whatever open questions exist that need to get answering… are answered before we can move forward.
marc | wolovim:So, next section is compatibility discussions, or these are just a series of considerations. I've heard the most noise about people wanting the most clarity, or asking for the most clarity about
marc | wolovim:For any of these given, proposals.
marc | wolovim:there's… at the risk of, choosing the wrong thing to focus on first, I'm…
marc | wolovim:gonna take the order that exists there. The first one is adoption strategy, so…
marc | wolovim:quick context is, this is one of the categories of concern for any Native AAA proposal I've heard, is essentially how do we ensure adoption reaches critical mass in a timely manner?
marc | wolovim:There's a lot to dig in here, like how opinionated are patterns within the proposal, how much work and risk is there for wallets or app developers.
marc | wolovim:Would anybody like to… to…
marc | wolovim:Try to describe the state of… of… of how you're thinking about your proposal and
marc | wolovim:Rolling it out effectively to the world, or what questions you have that maybe some others on this call can help answer.
marc | wolovim:David's got a hand up.
david:Yeah, it's David from Trust Wallet. Actually, some of the arguments that I have been, seeing regarding, like, A141 was
david:The low adoption of 7702.
david:And I think, like, from a wallet developer perspective, it actually does take a lot of effort, too.
david:have, like, some of these fundamental level shifts as a wallet. Like, we need to audit our SPAR contract, like, and then, like, our front-end layer, how we have, like, the bundler, paymaster, or, like, the relayer systems. So, from a wallet perspective, having these types of updates actually do take a bit of time.
david:However, if we have a look into the data today, there is, like, nearly, like, 100 million weekly 7702 transactions, actually not there, but close to. And trustwall also have been seeing, like, meaningful traffic, leveraging these.
david:And also a lot of wallets, use these techniques to somehow make it more automated.
david:So, I believe that it will be somehow in line with a one-for-one. Like, in my personal opinion, it wouldn't be, like, extremely drastic as soon as things get merged.
david:But wallets actually look into the opportunities of how we can, like, really automate or make wallets smarter, and then they work on these, and then by the time they're, like, confident enough through multiple rounds of security audits and development, it actually gradually gets rolled out to the users.
david:So, from that perspective, having these foundations, I actually, believe will be a big plus.
david:And ultimately, like, a way that, like, the consumer wallets potentially would be willing to go.
david:But there will need to be a bit of time buffer, because there needs to be a lot of preparation for those.
david:And also, one of the reasons why I think this A141, this needs to be merged, or potentially something that could do these merged in a timely manner, is because, like, wallets also are transitioning from more of a passive helper.
david:into a more automated solution at an ecosystem level. And then if we actually do not have some things to support these.
david:at the protocol level, each wallet or each solutions will come up with their own ways, like, basically their own private, really, networks to just automate their wallet experience. And actually having something like a 141 will…
david:create a more, on-chain, verifiable way of how wallets actually end up building your automation solutions. So, yeah, those are just my two cents as a wallet developer.
marc | wolovim:Thanks, David.
marc | wolovim:Carlos, is this, maybe I'm confused by your question in chat. Is this related to adoption concerns?
CPerezz:No, not adoption.
marc | wolovim:Okay, if it were stateless or mempool, or…
marc | wolovim:Something else, those… those we can tackle next?
marc | wolovim:Thanks, Dirt.
Derek Chiang | ZeroDev:Oh, yeah, sorry, I just wanted to speak, kind of like… I just wanted to comment on what David said. You know, I think, really, really, really truly agree with what David said. I mean, honestly, TrustWallet's obviously one of the top adopters of AA, right? You know, they adopted
Derek Chiang | ZeroDev:7702-4327, you know, so I trust their experience a lot. You know, so I think, like, our experience at Zero Dev has been very similar in that, the three core adoption…
Derek Chiang | ZeroDev:sort of, like, roadblocks to AA, in my opinion, are, one, you have to audit smart contracts, right?
Derek Chiang | ZeroDev:Two,
Derek Chiang | ZeroDev:you have to rely on relayers, right? You know, like, if you want to take advantage of the gas abstraction features. And the third one is that smart accounts do not work as reliably across chains
Derek Chiang | ZeroDev:as EOAs do, right? So I think, like, David mentioned point 1 and 2, and I just want to emphasize 3 as well, right? And so that's why, like, for firm transactions, we're actually trying really hard to adjust all three core adoption barriers. So for, the need to audit smart accounts.
Derek Chiang | ZeroDev:We are solving this in two ways. So one is that firm transaction just natively supports EOAs. Like, EOAs just work. You don't have to, like, order new smart contracts for it to work, right? Like, EOAs will be treated as if they have… are running a default smart accounts.
Derek Chiang | ZeroDev:Which is obviously, you know, guaranteed by the protocol in terms of security. And, you know, so even EOAs can start doing things like batching, you know, getting guests sponsored, paying guests in yes-20 tokens and whatnot, right?
Derek Chiang | ZeroDev:So that, so this one. The second way we are addressing this, which, you know, we are still working on, is basically defining a set of, what we call, canonical verifiers. So these are basically smart contracts, like, very minimal smart contracts, that wrap
Derek Chiang | ZeroDev:existing precompiliers, such as, you know, EC Recover and P256 Verify.
Derek Chiang | ZeroDev:So these are essentially smart contracts you can use.
Derek Chiang | ZeroDev:you can compose with your smart accounts to, to leverage new signature algorithms, right? You know, so, so again, you know, we hope that we can take away the burden of auditing the most obvious, sort of, like, authentication path.
Derek Chiang | ZeroDev:from the wallet developers, right? And then on the second point of, relayers, you know, NativeA, of course, solves that problem, because with NativeA, you don't need relayers, you know, that's kind of, like, the whole point.
Derek Chiang | ZeroDev:And then on the third point of.
Derek Chiang | ZeroDev:compatibility across chains. That's actually, like, the trickiest part that's, we are trying to solve right now, because, again, you know.
Derek Chiang | ZeroDev:from talking to L2s today, including base, Arbitrum, and whatnot, there are definitely, like, some concerns over, kind of like, with native AA,
Derek Chiang | ZeroDev:how they can achieve predictable performance and cost when it comes to validating transactions. So, yeah, you know, so I think that's, to me, like, the largest outstanding unknown here, you know, which is basically, like, whether we can convince, all the L2s, at least all the leading L2s, to
Derek Chiang | ZeroDev:support some kind of native AA, right? You know, so I think that's the… yeah, that's my view on, you know, on this topic.
marc | wolovim:Thanks. Follow-up question, is there…
marc | wolovim:What is progress on those discussions already?
marc | wolovim:Has that begun?
Derek Chiang | ZeroDev:You mean the discussions with, L2s?
marc | wolovim:Yes.
Derek Chiang | ZeroDev:Yes, yes, we are actually…
Derek Chiang | ZeroDev:you know, group chat with, base and Arbitrum. Obviously, if there's OP folks in here, please join as well. And yeah, you know, so I would say the discussion's ongoing, you know, but I wouldn't say that any consensus has been reached, but I don't know if Chris wants to speak from his perspective.
Chris - Base:Yeah, I wouldn't say consensus has been reached,
Chris - Base:I think, yeah, things are still in flux in development and whatnot.
marc | wolovim:Okay, are there any clear next steps that can be spelled out here?
Derek Chiang | ZeroDev:I think, from my perspective, yeah, just, like, keep working towards the consensus, with the L tools, seeing if there's, like,
Derek Chiang | ZeroDev:we can get firms to a specs where they feel very comfortable supporting. That's what I'm hoping we can get to, you know.
marc | wolovim:Okay.
marc | wolovim:Keeping an eye on the clock. There's only 12 minutes here left, so we are definitely not making it all the way through.
marc | wolovim:Are there any of these other, bullet points that can be tackled quickly, whether it be the current state of thinking on mempool implications, statelessness, compatibility, or privacy? Ben, go for it.
Ben Adams:Yeah, so I have a concern of any transaction type that needs to
Ben Adams:In fact, the EVM, in terms of… First…
Ben Adams:If it's pushing the cost… the base cost of a transaction up to, you know, 10 times what it normally is.
Ben Adams:Then… that might not be practical. And also, if,
Ben Adams:If they all have to be run in the mempool, that again is a problem, so…
Ben Adams:Essentially, the mempool is going to be processing you know, like… A hundred times the number…
Ben Adams:the amount of gas that would go in a block. It seems like now we're… we're in a situation where we wanna… we wanna put more transactions through the block, but we're…
Ben Adams:Forcing the validators into,
Ben Adams:spending all their, all their CPU on, processing transactions that aren't paying for anything.
Ben Adams:And so that's some of my concerns.
marc | wolovim:Before we go to Carlos, would anybody like to quickly respond to Ben's point?
Ben Adams:I mean, it… To… to be very specific, if… if…
Ben Adams:all the transactions now cost 10X on their… on their base, then we've, like, drop the…
Ben Adams:What can be included in that quite significantly, also.
lightclient:I guess I don't really understand fully the issue here.
Ben Adams:If you're validating signatures in the, in the… In the block and mempool.
Ben Adams:Using EVM instructions.
lightclient:Right, but why is this such an issue? Like, we already expend compute.
lightclient:It's just a different type of compute to validate the transaction.
Ben Adams:Is that the evening.
lightclient:Apparently inefficient about these things?
Ben Adams:Well, because the… at the moment, we use the EC Recover precompile.
Ben Adams:Which is… If you write EC Recover in EVM bike code, it is significantly more expensive.
Ben Adams:Brazile.
lightclient:Oh, well, we're not proposing people do that, though. Like, people will use the precompiles for…
lightclient:Most of their cryptographic needs, and it's just a matter of some…
lightclient:You know, interpreter functions to push and pop data to get in the correct form to submit to the cryptographic precompile.
Ben Adams:Okay, so then you'd have to introduce… The signing schemes as, that's pre-compiled.
Ben Adams:Is that correct?
lightclient:I mean, did we ever say that we would not be?
lightclient:Introducing… Designing schemes discrete precompiles?
Ben Adams:I think so from that document, Jared, it's like the walk-away test, it could be automatically upgraded without
Ben Adams:Or devastating anything. So that would… imply that… Oh, we've got a new…
Ben Adams:quantum signature we want to do, so we'll… someday can write a contract that verifies that… for that.
Ben Adams:Will be a massive expense.
vitalik:Yeah, so, like, one example is that any, hash-based signature algorithm, like, that definitely can be done without any precompiles, because the, like, the acceleration that matters is, already done in the existing hash precompile, right? And, you know, there is overhead in the sense of needing to, like, take
vitalik:a hash output and put it back into a hash input, but if you, like, kind of do the EVM math, it's, like, less than, like, 1.3x or something, right? I guess, like, two other big categories of examples of this that count. One of them is that, you know, with this,
vitalik:possible vectorization precompile, you will, be able to
vitalik:do, handle a large volume of, different lattice-based schemes that have different, different nuances and, different parameters, and there again, basically, yeah, what's going on is that the expensive object is being wrapped in a precompile, but, not the, sort of…
vitalik:customizable glue around it. And then probably a third example is, like, even if you do have a precomp… like, even if we do have to have a precompile for each
vitalik:individual algorithm, like, that's…
vitalik:still better than, having it be a, an account type, and, one of the big reasons why is because it's composable, right? Because, like, if it's in the form of a precompile, you can combine it together in a multisig, you can combine different schemes, you can have hierarchical multisigs, you can, mix and match things in
vitalik:whatever… in whatever format, that you want. So I would say, like, those are the…
vitalik:Big… big situa… Situations in which it's, an in… like, there's an actual improvement available over having, like, types for each individual thing you want to do.
marc | wolovim:In the interest of time, we've got 5 minutes left here, I'll suggest we have…
marc | wolovim:Carlos, Tomas, and Presswich.
marc | wolovim:Carlos, you've been waiting patiently, so the floor's yours.
CPerezz:Thank you. I'll try to be quick. So, we have discussed a lot, like.
CPerezz:AA, and the flavors of AA, and the different ideas, and all that stuff, but I think that's another big discussion, which, I mean, I'm not sure to which extent wallets and LTOS want to actually give input, or really have any interest, I don't know, whatever, but certainly, we are putting a lot of effort in on other areas of the protocol, like,
CPerezz:having CK validation and statelessness and stuff like that. And we have already seen that this is quite conflicting, depending on the flavor and the strategy that we go for in frames.
CPerezz:So, at the beginning, Frames was set to go for Strategy 2, which, that basically translates into you only can have sponsorships of ETH,
CPerezz:but not ERC20s. But seeing what wallets and Ltos say they want, it's clear that this is not gonna be enough.
CPerezz:So that basically only gives two options. One is we force every single node to hold all ERC20s.
CPerezz:Or the other one is we have a whitelist of VRC20s, which to me sounds crazy, but whatever. I mean, it can be done, of course. And…
CPerezz:I'm not sure if there's any kind of preference or idea, or wallets care about that or not, but that's certainly, from a protocol perspective, having this whitelist, although I don't like it, would be for sure the best trade-off.
CPerezz:Because otherwise, what we're saying is, every single node is gonna be forced to hold mostly two-thirds of the state already.
CPerezz:So once EKBM or any sort of statelessness lands, and people drop the state, that's gonna be a huge requirement, and therefore, we will lose a lot of member pool health, if not all of it.
CPerezz:So, my question to the authors, is basically, what kind of strategy are we going for? Because it clearly seems that we are not going strat 2.
CPerezz:And if… what's the approach gonna look like? Meaning, are we going for everything that wallets ask for, and then cutting down, based on how
CPerezz:crazy or hard, or the consequences on other parts of the protocol we observe, or are we going minimal to start, and then adding features as long as we agree on the trade-offs? Like, what is the approach, and how do we discuss that with wallets and stakeholders? Because it's not clear to me at all.
marc | wolovim:Thanks, Carlos.
marc | wolovim:Tomas.
Tomás Arjovsky | Lambda | Ethrex:Hey, so a couple of things. I mostly wanted to answer a couple of comments by both Ben and Carlos. So, Ben mentioned a couple of minutes ago the problem with precompiles. I don't think that the frame transactions idea is inherently against precompiles.
Tomás Arjovsky | Lambda | Ethrex:I think that it just opens the way to either use them or not, and in the future, you can just add a new precompile if you really require it, and that wouldn't be an issue, because you just don't need to have a new transaction type for that.
Tomás Arjovsky | Lambda | Ethrex:That on the one hand, and if you don't, then it's even more seamless. Regarding Carlos, I won't be able to answer the part regarding statelessness. I think that's an interesting topic of discussion, but regarding the strategies, I'm not familiar with the numbers of the strategies.
Tomás Arjovsky | Lambda | Ethrex:But I think that you can have a ERC20 sponsorship without necessarily having that either centralized or pre-whitelisted. I think that
Tomás Arjovsky | Lambda | Ethrex:we can have different paymasters, and paymasters can have their own list of supported ERC20s. And if you have something like that, you don't have to have anything protocol level, but you still can have some level of control by each of the paymasters, on what are the ERC20s that they trust. So I think that that is something that
Tomás Arjovsky | Lambda | Ethrex:In itself could be in the direction to solve this issue.
marc | wolovim:Great. Press switch, and then I'll close this out.
prestwich:So, through the call, we've talked about a bundle of features that Frame should provide.
prestwich:transaction batching, ERC20 paymasters, gas abstraction, etc, post-quantum.
prestwich:But it seems like a lot of those are…
prestwich:unfinished. Like, we've been talking about, just now, ideation on how to handle ERC20s safely.
prestwich:So, that feedback frame provides, we're not confident it provides it yet.
prestwich:And in chat, we've been talking about post-quantum.
prestwich:Frames don't provide that. We need follow-on EIPs for precompiles for specific signature schemes, we need follow-on EIPs for what ECE Recover does.
prestwich:afterwards… You know, frames don't provide some of the things that they are supposed to provide… yet.
prestwich:Do we want to do this if we're still in ideation on a lot of the benefits?
marc | wolovim:Nico.
marc | wolovim:And then we're… we're done here.
Nico C:Yeah, on the… Post quantum stuff, I think the question…
Nico C:are, like, the two options are basically hash-based or lattice. Hash-based, we don't need to pre-compile, and Lattice, we will probably
Nico C:find a way to have the generic precompile that Vitalik described.
Nico C:So, like, this part is done.
Nico C:EC DSA deactivation and EC recover is kind of independent from Frame. Like, if you take this in any scenario, we would have to do it.
Nico C:So yeah, the only remaining question, I feel, is the stateless part, and I think it's,
Nico C:Like, probably something that… Can be where, like…
Nico C:Defined in the next few weeks?
Nico C:And we have almost,
Nico C:3 quarters until we actually ship this. So, yeah, I think it's kind of fine.
Nico C:But yeah, the post-quantum stuff, and the ACDSA deactivation, and…
Nico C:AC recovery modification, I feel like, yeah, it's… it's… Either independent or, done anyway.
marc | wolovim:Okay, thank you, everybody, for, for coming, participating.
marc | wolovim:And, going deep in the chat. Hopefully this is…
marc | wolovim:helpful for at least illuminating what important next questions need answering. And, I'll work to get this up on forecasts, but I encourage others to, don't wait for
marc | wolovim:for that to happen before, figuring out next steps for yourselves.
marc | wolovim:We don't have a date for the next one yet, but we'll announce, if and when we do. So,
marc | wolovim:Until then.
marc | wolovim:Catch you in the usual channels.
marc | wolovim:Thanks for coming, everyone.
lightclient:Thanks, Mark.
Chat Logs
00:07:35
marc | wolovim:https://github.com/ethereum/pm/issues/2018
00:11:36
Chris - Base:I'll need to add 8130 to next AA schedule - found out about this meeting too late unfortunately
00:11:53
marc | wolovim:Replying to "I'll need to add 813..."
You can still give a quick update if youre up for it
00:11:58
lightclient: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
00:13:37
lightclient: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
00:14:35
lightclient:this is AA btw
[Full message cannot be displayed on this version]
00:16:58
prestwich:👋
00:18:56
prestwich:PQ aggregation should be a non-goal, as the crypto is certainly nowhere close to ready
00:19:55
lightclient:we should be able to support it in theory in the future
00:20:11
prestwich:that should be a non-goal, as we don’t know what “being able to support it” means
00:20:19
Nico C:SPHINCS- with keccak is 200K gas
00:20:27
Danno Ferrin - Tectonic:We will need precompiles for crypto primitives, I don't think we will get away from that.
00:20:32
prestwich:Replying to "that should be a non..."
we don’t know what “it” is. how can we support it?
00:20:32
Doris Hernandez | Functor:Just to clarify - the only way to upgrade existing EOAs to use Frame tx will always be with the 7702.
00:20:41
marc | wolovim:In the interest of time, will wrap up this prompt after Ben -> Mislav -> prestwich
Proposal authors can speak to latest updates next
00:20:52
lightclient: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
00:20:57
Derek Chiang | ZeroDev:Replying to "Just to clarify - th..."
Frames natively support EOAs. Check the “default code” section of the spec
00:21:01
Nico C:So 2$ right now during the Defi drama ! (not free) but certainly not out of range
00:21:17
marc | wolovim:Replying to "In the interest of t..."
Thoughts still welcome via text/links in chat here though
00:21:20
Jeevan:Replying to "We will need preco..."
yes along with , crypto agility built in the ystem natively
00:21:24
Doris Hernandez | Functor:Replying to "Just to clarify - th..."
Ahh this is what you added right.
00:21:30
lightclient:you can send infinite invalid 10 MB txs in the mempool today
00:21:33
CPerezz:Replying to "We will need precomp..."
That will hurt the ZKEVM folks significantly
00:21:42
CPerezz:Replying to "We will need precomp..."
As they are trying to get rid of as many as possible
00:22:08
Agusx1211 (Polygon):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
00:22:31
Agusx1211 (Polygon):that's the kind of design space we need
00:22:33
marc | wolovim:reminder: current prompt is “what do you think is most important for a native AA proposal to accomplish?”
00:22:46
Danno Ferrin - Tectonic: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.
00:23:26
Danno Ferrin - Tectonic: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
00:24:02
lightclient:wdym wallet rollover?
00:24:04
CPerezz:No one has mentioned ERC20 sponsoring. Is this not the “most desired feature” ?
00:24:19
CPerezz:Replying to "No one has mentioned..."
I’d love to hear that it is not btw. Just asking stakeholders
00:24:23
Derek Chiang | ZeroDev:The #1 desired feature in commercial settings is gas abstraction, including gas sponsorship and paying gas in ERC20s
00:24:31
ivo Georgiev @ ambire:Replying to "No one has mentioned ERC20 sponsoring. Is this not the “most desired feature” ?"
I meant it indirectly. Should’ve been more clear
00:24:35
Agusx1211 (Polygon):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
00:24:46
Parthasarathy Ramanujam:Replying to "No one has mentioned..."
Yes, erc20 is used to pay for gas. Not necessarily for sponsorship.
00:24:52
ivo Georgiev @ ambire: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
00:25:03
Mislav: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.
00:25:26
lightclient:we have a lot of wallet teams here who seem to support 8141?
00:25:55
prestwich:Replying to "Lots of these things..."
signature aggregation, especially PQ, is the main completely unspecified thing
00:25:56
ivo Georgiev @ ambire: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
00:26:01
Doris Hernandez | Functor: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?
00:26:29
Mislav:Replying to "Lots of these thin..."
fair point
00:26:31
Jeevan:From this I currently See PQ with native AA is very noce to have , but not a must
00:27:59
Milos:Replying to "Two questions for me..."
if we can get agreement on the design, then likely H* fork
00:28:22
marc | wolovim:Prompt: For each proposal, what's changed in the last ~month?
e.g., spec changes, implementations, prototypes, testing, data collection, etc.
00:29:47
Iván | ethrex:We are hosting a devnet for frame transactions, we’ll announce it in AA Mafia soon
00:29:55
lightclient:https://github.com/ethereum/EIPs/pull/11555
derek is talking about this idea
00:29:58
Chris - Base:Interesting can you share - what if sender validation is invalid? (will read nvm)
00:30:00
Chris - Base:thanks
00:30:15
lightclient:Replying to "Interesting can you ..."
basically the guarantor still pays for the invalid tx
00:30:28
Agusx1211 (Polygon):isn't this somewhat similar to 5189?
00:30:35
Chris - Base:Replying to "Interesting can yo..."
And they would inspect the sender frame for validation?
00:30:53
Chris - Base:Replying to "Interesting can yo..."
Or is offchain
00:31:08
lightclient:i think you covered it
00:31:14
ivo Georgiev @ ambire:This is fantastic and very well explained
00:31:19
Doris Hernandez | Functor:Replying to "Two questions for me..."
Great!
00:31:37
Karandeep Singh: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?
00:32:07
Adam Egyed: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.
00:32:20
Jihoon:Replying to "Interesting can you ..."
If sender validation fails but guarantor can afford the tx. Is it a valid or invalid tx?
00:32:32
Derek Chiang | ZeroDev: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"
00:32:48
Bobby | Ambire: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?
00:32:48
marc | wolovim:Ben’s contract payer tx, eip-8223: https://github.com/ethereum/EIPs/pull/11509
00:33:01
Parthasarathy Ramanujam:https://hackmd.io/@FJJgNqPTR2WeGoYk6_URNA/S1dAiErT-l#8223-from-the-wallet-desk-why-the-narrow-case-is-a-trap
00:33:03
Agusx1211 (Polygon):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
00:33:10
Chris - Base:Replying to "Interesting can yo..."
Payment is the best form of DoS protection 🙏
00:33:12
Jihoon: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
00:33:23
Derek Chiang | ZeroDev: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
00:33:31
vitalik:BTW side note, but on the "PQ aggregation is unspecified" claim, actually lean ethereum is very far along in specifying and implementing STARK aggregation
00:33:52
Derek Chiang | ZeroDev:Replying to "Interesting can you ..."
@Jihoon yes, the transaction is valid as long as the payer validation is valid
00:34:05
prestwich:Replying to "BTW side note, but o..."
post the spec
00:34:43
Derek Chiang | ZeroDev: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
00:34:52
Parthasarathy Ramanujam:How do you propose existing wallets migrate assets from their existing wallets to the 8223 wallet?
00:35:06
lightclient:Replying to "BTW side note, but o..."
https://github.com/leanEthereum/leanMultisig
00:36:00
vitalik: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/
00:36:02
Derek Chiang | ZeroDev: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
00:36:21
marc | wolovim:fredrik speaking to https://eips.ethereum.org/EIPS/eip-7906
00:36:32
Ben Adams:Replying to "How do you propose e..."
7702 and then some of the disabling of EC EIPs that perminately convert to smart contract
00:36:34
prestwich:Replying to "BTW side note, but o..."
i was expecting this to be a specification for an integration with frame txns
00:37:19
vitalik:Replying to "BTW side note, but..."
there's also the 4337 aggregators feature, which can be adapted to frames easily if needed
00:37:37
Ben Adams:Replying to "How do you propose e..."
Though it is a point in time thing
00:38:00
prestwich: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
00:38:31
prestwich: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
00:38:42
Parthasarathy Ramanujam: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!
00:38:45
Derek Chiang | ZeroDev:@Fredrik is there a draft for this?
00:38:56
vitalik: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
00:39:15
Alex Forshtat:Replying to "@Fredrik is there a ..."
https://eips.ethereum.org/EIPS/eip-7906
00:39:38
vitalik:Replying to "BTW side note, but..."
how that occurs in the network <--- you mean p2p layer?
00:39:43
Agusx1211 (Polygon):strongly in favor of 7906, it would be awesome for wallets
00:40:31
vitalik: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
00:40:39
Mislav:7906 is amazing! If we can make it compatible for offline validation via hardware wallets - that's a huge boost
00:40:48
prestwich: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
00:41:24
Chris - Base:7906 sounds like a very difficult thing for builders to deal with (especially L2)
00:41:29
prestwich: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.
00:42:21
Alex Forshtat:Replying to "7906 sounds like a v..."
Why?
00:42:36
Milos: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)
00:42:45
Chris - Base:Replying to "7906 sounds like a..."
ohh great :) no problem then
00:42:52
Chris - Base:Replying to "7906 sounds like a..."
Sorry I thought it was tx validity
00:43:10
Chris - Base:Replying to "7906 sounds like a..."
How does frames help then?
00:43:34
Agusx1211 (Polygon):Replying to "7906 sounds like a..."
7906 seems very useful even without frames
00:43:49
Chris - Base:Replying to "7906 sounds like a..."
Yes seems like frames dont matter for it - seems good either way?
00:44:23
CPerezz:Risks for protocol / unknowns are part of this section @marc | wolovim ?
00:44:23
Milos: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)
00:44:34
Danno Ferrin - Tectonic:Adoption has built in headwinds: we need to start talking about how we will be sunsetting ECDSA.
00:44:42
Jeevan:Replying to "7906 sounds like a..."
It compliments frames , but regardless its a good one standalone
00:44:44
Alex Forshtat: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.
00:44:46
Mislav: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
00:45:16
prestwich:Replying to "Adoption has built i..."
this is the only urgent feature in the AA bundle
00:45:28
Chris - Base: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?
00:46:01
marc | wolovim:Replying to "Risks for protocol /..."
Highlighting those sounds appropriate to me - in general, identifying open questions and ideally linking them to action items
00:46:43
Jeevan: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
00:46:54
lightclient:Replying to "Adoption has built i..."
default account + frame tx. we can sunset ecdsa in the default account and turn off other tx types
00:47:50
prestwich:Replying to "Adoption has built i..."
8141 requires a deploy frame from all existing accounts, right?
00:47:58
Chris - Base:Replying to "Adoption has built..."
8130 has full key rotation including ecdsa deprecation ready - no follow up EIPs or ERCs needed
00:48:07
prestwich:Replying to "Adoption has built i..."
also, @lightclient that’s not sufficient to sunset ECDSA, we also need to modify ecrecover
00:48:16
Chris - Base:(other than 1559/legacy deprecation if using an EOA based account)
00:48:18
Nico C:https://github.com/ethereum/EIPs/pull/11506
00:48:25
lightclient:Replying to "Adoption has built i..."
yes ofc, but that is separate from AA
00:48:27
prestwich:Replying to "Adoption has built i..."
making ecrecover frame-aware is inherently very bad
00:48:35
prestwich:Replying to "Adoption has built i..."
“inherently very bad” lol
00:48:38
lightclient:Replying to "Adoption has built i..."
you can use the default account without deploying anything
00:49:01
Agusx1211 (Polygon):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
00:49:13
prestwich: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
00:49:35
lightclient:Replying to "Adoption has built i..."
did i say we would make it frame aware?
00:49:57
prestwich:Replying to "Adoption has built i..."
it’s the only practical choice. you can’t deprecate it
00:50:06
prestwich:Replying to "Adoption has built i..."
you have to modify it to work with the AA solution
00:50:34
prestwich:Replying to "Adoption has built i..."
ecrecover is deeply embedded in too many economically critical contracts. just identifying them will be a huge task
00:50:41
Nico C: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
00:50:48
lightclient:Replying to "Adoption has built i..."
yes it will
00:51:03
Nico C:but not linked to 8141 these are independent problems
00:52:55
prestwich:Replying to "Adoption has built i..."
any written down ideas for modifying it to work with 8141?
00:53:06
Jeevan:Replying to "Here we propose: ..."
looks interesting , thanks will go thru it
00:53:17
lightclient:Replying to "Adoption has built i..."
i dont get why 8141 has anything to do with ecrecover
00:53:59
prestwich: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
00:54:23
lightclient:Replying to "Adoption has built i..."
yeah there are several eips with different proposals for this
00:54:33
Milos:you can't have native AA without any EVM usage
00:54:43
Jeevan: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
00:54:47
prestwich: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
00:54:51
lightclient:Replying to "Adoption has built i..."
https://eips.sh/eip/7819
https://eips.sh/eip/7851
00:55:43
Chris - Base: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
00:55:52
Adam Egyed: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.
00:56:29
Chris - Base:Wrapping precompiles should expect ~10-20% more expensive for smaller public key types
00:57:43
Jeevan: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
00:57:50
Jeevan:Replying to "Adoption has built..."
which I think frame does actually
00:57:58
Nico C:I think there is no need for a precompile on hash based (future ZK hash incoming anyway). For lattice it could be the NVMpy
00:58:12
marc | wolovim:After V, we’ll prob have time for cperezz, Tomas, prestwich and need to wrap up there.
00:58:34
Orca 0x: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
01:02:00
vitalik: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
01:02:18
Adam Egyed: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.
01:02:32
CPerezz: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
01:02:33
vitalik:(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)
01:02:38
Derek Chiang | ZeroDev:@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
01:02:39
Chris - Base:Replying to "the third option i..."
Agree, and think that is the best approach
01:03:53
CPerezz:Replying to "@CPerezz Another opt..."
This will allow for mass invalidation in FOCIL @Derek Chiang | ZeroDev
01:03:58
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
01:04:09
CPerezz:Replying to "@CPerezz Another opt..."
FOCIL <> AA <> Statelessness can’t be solved with 1 EIP IMO
01:04:10
Orca 0x:Replying to "Another benefit of 8..."
for sure, but that’s still an account-level implementation choice
01:04:31
lightclient:it does provide it
01:04:38
lightclient:(erc20 sponsoring)
01:04:43
Derek Chiang | ZeroDev: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
01:04:47
lightclient:it’s just a question of how much to support it
01:04:59
vitalik:without any precompiles, frames does a useful thing for post quantum (the 200k gas hash-based sig)
01:05:09
Derek Chiang | ZeroDev:Replying to "@CPerezz Another opt..."
They don’t have to check any sender validation logic, or access any ERC20 shared state
01:05:20
vitalik:Regarding timing, one big point that I would make, is that post 2027, core dev space is going to have a lot more competition
01:05:34
Agusx1211 (Polygon):Replying to "without any precom..."
and can be combined with a cheap ECDSA with session limits!
01:05:44
Danno Ferrin - Tectonic:Multivariate has entered the chat
01:05:58
Jihoon:Replying to "@CPerezz Another opt..."
What happens when guarantor becomes unaffordable?
01:05:59
vitalik: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
01:06:01
Danno Ferrin - Tectonic:MAYO-2 is my new dream signature
01:06:02
Jeevan: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
01:06:10
prestwich:i love me some Lamport, but why would we consider any non-FIPS PQ signature scheme?
01:06:13
Ben Adams:"Is done" is doing a lot of heavy lifting there
01:06:16
CPerezz:Replying to "@CPerezz Another opt..."
Exactly. I mean, who is gonna run this if they can be totally rugged?
01:06:37
Derek Chiang | ZeroDev:Replying to "@CPerezz Another opt..."
The guarantor in the public mempool would use the canonical paymaster contract which implements the timelock
01:06:51
Danno Ferrin - Tectonic:We should allow non-FIPS, but we also need a FIPS scheme. Crytpo Agility in practice
01:06:53
Pedro:Replying to "Can I know what fram..."
https://eip8141.io/pq-roadmap
01:06:57
CPerezz: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
01:07:05
CPerezz:Replying to "The way I see this i..."
The ideation I mean
01:07:06
CPerezz:Replying to "The way I see this i..."
ofc
01:07:28
Chris - Base:Thanks all!
01:07:35
prestwich: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?
01:07:39
prestwich:<3
Summary
15 highlights
· 3 action itemsExperimental
Summary
15 highlights · 3 action itemsExperimentalcontext and goals
proposal updates
- Frame transactions: payment frame can precede sender validation for mempool efficiency00:28:30
- EIP-8223: Contract payer transaction enables one-to-one EOA-to-vault relationships00:32:10
- EIP-7906: Transaction assertions provide safety envelope preventing malicious side effects00:36:32
- Ethrex devnet for frame transactions running with faucet and example contracts00:42:37
adoption concerns
technical challenges
- Ben: EVM-based signature validation could cost 2M gas vs 3K for precompiles00:53:16
- Vitalik: Hash-based signatures work without precompiles; lattice needs vectorization precompile00:59:34
- Carlos: ERC-20 gas payment conflicts with statelessness—whitelist or full state required01:00:13
- Prestwich: Many claimed benefits (ERC-20s, post-quantum) remain unspecified/unproven01:04:09
roadmap context
- Vitalik timeline: 2026 AA, 2027-28 state, 2029-30 VM work01:05:20
Action Items
- Frame authors, Base, Arbitrum, OP teams: Continue L2 discussions to reach consensus on native AA performance requirements00:51:31
- Frame authors: Define strategy for ERC-20 sponsorship vs statelessness tradeoffs01:02:32
- Fredrik, Alex, Ethrex team: Collaborate on EIP-7906 demo using Ethrex frame transactions devnet00:42:37