Frame Transaction Breakout #2

Transcript

Toni Wahrstätter: Hello!

Stavros Vlachakis: Loan, long.

Daniil Ankushin: Hello, guys.

Pedro (WalletConnect): Hello, everyone.

Marc Garreau: Hey, y'all. I will help moderate today's call, but we're gonna wait for, maybe 3 minutes. Before we get jumping in here.

Alright, everyone, I'm gonna kick this thing off now. Welcome, everyone, to, what is the second call in the native account abstraction Breakout Series? Bit of context is warranted here. When I scheduled this call originally, I believed we were, ready for the first, sort of, implementation-style call for Frames, and therefore it has that name. But there has been a flurry of activity recently, so we've got more to chat about, it seems. I'm gonna… Set some… maybe a couple simple goals for this call, and then share the agenda. The… the… the goals… I think our, to have both proposals very well understood. So, 8141 Frame transactions and 8130 is, the account abstraction proposal that is going live on base and being adopted by some other chains, potentially.

And, there's been a flurry of activity describing exactly how both works, recent developments in Frame. And 8130, so I think this is a good, sort of moment to pause and make sure that everybody gets back to the same page and understands what's in both of these proposals. by the end of today, if we don't have sort of clear next steps, then I would suggest the goal is to at least identify the right set of next questions that need answering. And… with that, the agenda for today, also gonna keep it simple, The first is just to quickly provide context to where we are today. leave a few minutes for Matt to chat about any recent Frame developments, and then Chris will have the floor to present on 8130.

So I'm hoping that takes, only the first half of the call, if that, and leaves the rest open for discussion, because I think that's where the real value is gonna come from. When we get into… Problem-solving mode, and… Being able to ask those questions that need asking. Okay, so brief context, Frames 8141 is CFI'd into Hegota. There's been a lot of momentum. Getting to this point, we've now… the question being asked is, do we elevate it to headliner status? Many client teams have invested real resources in Debating and hardening the spec and writing implementations, and we're… At this point, well on our way to a Frame DevNet, DevNet Zero. More recently, 8130 has been…

selected to go live on… on, bases next deployment in September, I believe. With, with other support from additional chains, so that opens, the door to ask some of these questions. About what is… what is most important that lands on… on each of these chains? So… Let's start with frames. Matt, you've got the floor if you'd like to discuss the latest in Frame Land.

Lightclient (Matt Garnett): Thanks, Mark. So, I just wanted to give a quick thanks and shout-out to the people over the last couple months who have helped on the Frame spec. Nethermind has been pretty instrumental and, you know. helping finalize a lot of these, like, details of the spec, and making a lot of clarifications. Ethrex has made numerous contributions. The EELS team doing the implementation in ELs, and the clarifications, and… changes that came from that, and also Tomas, who's been working on recent roots, and… the 2D nonce proposal on top of frames, and has helped provide a lot of feedback on frames. To get to where it is now. So, thank you guys for all of your contributions. Over the past 2 months, most of the changes to frames have…

fallen into two categories. The first is… you know, basically just clarifications, really things that don't change the actual implementation of frames, but more about ensuring that the EIP Correctly defines the behavior. And there's been a lot of these things, and in some cases, like. You know, it really was very unclear what the correct behavior was, and so we can say that these are also, like, small changes to the frame spec. So a lot of work has been done in this. And then the other main bucket, which is maybe the more substantial bucket, is the work to integrate the Glamsterdam changes into frames. when we wrote the original Spectra frames, obviously, like, we were aware that these types of changes were coming, and…

The reason that the Frame spec until now, or until the last couple months, didn't have the Glamsterdam changes is we were really just waiting for Glamsterdam to get into a bit more of a finalized state. That way we could be confident that the changes that we were adding weren't going to have to be reworked 3, 4, 5 times. So at this point, like, Amsterdam is kind of on its way towards the testnets, and we're pretty happy with, you know, going through with the integration. So most of that work to integrate, and, you know, most of the, like, visible changes to frames now is around this explicit two-dimensional gas support in frames. The reason we added it is because with the Glamsterdam change 8037, we are adding a second, you know, state gas dimension, and the way that it's done in…

you know, 8037 on the existing transaction types is we're sort of hacking it into this, like, one-dimensional, you know, numeric gas value that transactions have, and we're kind of, you know, taking advantage of a few EIPs, such as the 16 million gas limit. To, you know. allow users to specify state gases beyond the 16 million limit that they would normally have. And so with frames, we wanted to kind of do the right thing with respect to supporting the state gas. So now, you know, in the receipts and the transaction object and the handling, we have added the state gas as an official second dimension. And… By doing that, it obviously has lots of, like, small areas of undefined behavior that we needed to define.

And we've kind of got that to the point where I think it… is mostly clear what the behavior should be. There's also a lot of small EIPs in Glamsterdam, things like removing the block refunds that need to be correctly integrated, the data-flow pricing, even from, you know, the previous fork, things that we hadn't perfectly integrated into the FrameSpec originally, and, you know, change a bit now with the, other integrations of Atlantic Amsterdam pricing. the storage refund, the counting in frames. All of this stuff is in this bucket of, like, kind of integrating Glamsterdam, making sure that the gas that we're charging with our frames is correct with respect to, like, all of the EIPs that have existed over the last couple of forks.

So yeah, Frames, for the most part, hasn't changed substantially since we added the signature list back in May. The 2D gas is probably the most obvious thing, and then there's lots of these, like, small clarifications. So that's kind of where Frames is at right now.

Marc Garreau: Thanks, Matt. Added a couple links in there that… Might make it easier to see what the new commits are and, EIPs that are building on top of 8141. Would anybody like to add any, context about the evolution of frames, any work that's gone in recently? Or ask questions about it.

Toni Wahrstätter: Maybe… maybe let me just add one quick point, because Tomas is out of office right now, and I guess he would otherwise add it. So we have been working a lot on building like, a privacy protocol, or building, like, proof of concepts of privacy protocols on top of frames. And there is also an Ethrex definite already. where people can, explore that already. So basically, what it allows you is, like, having, like, a TornadoCash railway, like, privacy protocol where you can withdraw And be sponsored by the pool itself. So you don't need a relayer anymore, which completely cuts out all the intermediaries, and… Yeah, just to add that we have been exploring what can be done on top of frames.

Marc Garreau: Great, thank you, Toni. One last call for any… Frame-related Updates. Okay, I'm gonna hand the mic then to Chris. for, the rebuttal, so to speak, 8130, to give us more information about what is, shipping, and I guess to address some of the The questions that, has been asked of frames, how 8130 takes a different approach. To achieving some of the same ends. So, Chris, are you ready?

Chris Hunter: Sorry, I think… there we go. Thanks, Mark.

Marc Garreau: Yep.

Chris Hunter: Okay, so yeah, 8130, is launching on base, planned late September, as you mentioned, We have, OP stack, also… committing to deploy, at a later point, and then Arbitrum has announced that they will propose, 8130 as their account abstraction standard as well, so it is moving forward, towards, a growing set of adopters. In terms of the spec, I did share the slides, and video, that I just recorded, this morning. We're going through the same slides here. Basically the, I call it the, like, 8130 thesis, so I'll just go through that now, and obviously the audience is, much more familiar with a lot of the concepts here, so I can kind of jump through, much faster in the video. The video ended up at 35 minutes or so, so…

I'll just… Yeah, try to get through, the whole thing quickly. Yeah, but first, so… First, yeah, thank you, everyone, for, you know, listening. This is, you know, why we're here is to give Ethereum the best future we can. Raising concerns, putting forward proposals is all part of the process. And if we didn't work towards finding the best solution together and having conversation, that would be a disservice to everyone building on Ethereum. We're all on the same team, so let's discuss together. This is how… 8130 design evolved into where it is today, so… The goals for 8130 was really to build for the whole EVM. Took L1 goals, you know, with, like, privacy protocols, et cetera, permissionless innovation, L2 goals at L2 EVM for, high performance. Different profiles for different chain goals, but the same foundation underneath.

And, you know, we're seeing that, based on the L2 adoption, this story as well. Some other important things, all accounts could migrate, obviously there's a bunch of, like, 437 accounts hanging around. VOAs, and, you know, creating new accounts, that is all, super important. Hi… a goal is basically, like, portability of an EOA. I think, we… like, the experience of an ELA was always, you know, the best, because it just worked everywhere. Trying to get back to that. also build for end-user features, so definitely taking into account, like, you know, high-throughput senders, Agentic, commerce, or Agentic use cases, X402, etc. These all need high-throughput, senders, just for example. And always building for chain performance. This was,

Extremely important, during the development, And was a chief consideration. So for the presentation, the takeaways I hope to convey here is that there's no meaningful capability gap between 8141 and 8130. There is, however, a meaningful gap in how much it costs to get those capabilities, and 8130 being the clear winner here. 8141 and previous native account abstraction attempts have the same underlying issue, which is their account model, which is what I'll try to… This is the 8130 thesis, I guess, so… If we look at, I am sharing my screen, right? Yeah.

Marc Garreau: Yes.

Chris Hunter: Yeah, if we look at Ethereum today, of course, you know, this is just an EOA, so if we look at this architecture, we have authentication, authority, and the account itself. this is a decoupled architecture of responsibilities. You can see the authority is the protocol. The DC Recover over K1 is the, authentication scheme, which returns an address, authority, basically just gives the admin power over the EOA, that gives it its name. The mapping itself is one-to-one. You know, one, authentication address controls the address, obviously. I think we can skip 7702s, just showing, like, as we work towards, you know, adding more features towards native AA, this is just… the updated 7702 transaction to kind of see how we move to the 8130 transaction. So, here we just added code in the,

Account address, and that is now, execution code. But it still maintains the, decoupled architecture. So we moved towards 8130. Ultimately, the only, change that we do is we make that, authority mapping, not one-to-one, it's now updatable. You update it via assigned payload. You… what do you update it to? You can actually update it to any contract-defined logic. So the old K1, authenticator, or sorry, the old, EC Recover is just a contract-defined EC Recover. This means you can, you know, have any sort of authentication scheme you want. keeping the parallels here, after ID is returned instead of address, these, basically, the key store stores the mapping now, but it's just a mapping layer. It's the same, idea, and, and no, like, large changes. It's just instead of one-to-one, we have this, you know, one-to-end

mapping to any contract-defined logic. And we also have… authorization capabilities just add scope. So now, you know, instead of it being an admin only, we add the ability to have, scoped access to the account. I'm calling this a key store authorized account. Now that we… we still have this, decoupled architecture that we wanted to keep, from Ethereum's existing, architecture, and now we'll just start updating the 8130 transaction, to use this. So… basically, you know, signature and payer signature, we're going to update to sender and sender auth. We lost the one-to-one mapping, so we need to be explicit about the addresses, that these are controlled. The, payer auth and sender auth are, this is their encoding, which is an explicit authenticator address, and then the data, passed to that.

Then we'll see, like, ultimately, yeah, I'll, I'll get, move on a bit, but, like, the authenticator address being explicit, explicitly declared in the transaction, is the fundamental goal here. And we'll see why that's so important. So, just some other changes, quickly. Authorization moves to account changes. We now have to update these mappings, obviously. Like, that's a new potential. We… Make account changes, which has the 7702 delegation still, the account changes, so you can update the mappings on the key store, and, account creation for deploying bytecode. Delegation itself isn't like delegation, the same authorization object as 7702, it's been simplified to just be for the sender, so you only have to sign once. Going through calls, the single call becomes calls, and we add, the call phases, so it's a 2D array of,

I think 8141 calls it atomic call batches. And then, continuing on, nonce becomes nonce key and non-sequence, so, we add the 2D nonce you're familiar with from 4337. We saw issues with 4337 2D nonces. Basically, they're used when, coordination issues become a problem. And then a lot of state is written to, the chain, as, you know, you're trying to send a lot of transactions through, and you're just picking random nonces, and, you know, state growth, happens fast. So we had an additional, Sentinel on non-sequence, which allows, non-SLIST transactions, and… That is basically a replay ID over, the calls, essentially. Like, there's… it includes, kind of, all the fields that, would be important for, a replay ID, so what bounds that after is that there's a ring buffer, we store that in there for, you know, a guaranteed.

Amount of blocks, and then basically after that, the expiry. prevents it from landing later on. Valid after and valid before are also good UX for the transaction to have. Again, it's always about lifting dependencies to the top level of the transaction. That is the… a key part of the 8130 thesis. And then for the last piece here, metadata, we just add that because, people are adding, what is it, data suffix, in the… Basically, yeah, they just… appending call data to the end of, a call isn't a great experience, so we just promote this to top level. And our 8130 transaction is done. So, at the end of all that, we've maintained a decoupled setup of an EOA, which is what we want. Authority is external to the account. Authentication is external to the account, so we have, as I said.

Authenticator code is, The authentication of the authority is the key store mapping layer, which is the same layer it always had in Ethereum, it's just now can be updated. Execution code is wallet code. And this separation allows us to have a declarative transaction type, which explicitly has the authenticator top level. This is key, as we'll see. This is just some of the words, that I'll be saying here and there, so just to go over one more time. Keystore is just the mapping layer, it has their auth, so you can see the, after config here, has the authenticator, the scopes, and the expiration, and this keystore contract is updated by assigned payloads. Authenticators authenticate and return an actor ID,

an actor is specified by an actor ID, but it's in the key store with scope, exploration, authenticator, as you said. And accounts just manage actors in the key store, and all accounts can, migrate over. Or just use it as is. A empty key store is just the normal state of Ethereum. All ELAs are just mapped one-to-one to, EC Recover. So if we look at a 8130 transaction, again, we have the authenticator, top level visible, we know, that this is, DC Recover. Pass in the 65 byte sig, it'll return the address A as the actor ID, and then we just look up in the key store If it has, the right scope. We're sending a transaction, so can it send a transaction and can't pay for the gas?

Yeah, again, the authenticator is explicit, therefore we can know dependencies and swap for native code easily. For example, base is, fully native, validation. Coming back to portability, so, yeah, account portability and great UX was, first-class consideration, as we said. Ultimately, we want an EOA to feel like… sorry, a smart account to feel like an EOA. So, whatever chain you go to, we want the experience that you can deploy, sync, and act all on a single transaction. So you could create an account, rotate a key, and, you know. authorizing session key, I guess, where this session key is doing a swap. And then there's, you know, chain local things, typically for session keys, and global changes, which is typically for admin.

So, key concepts here. Again, 8130 CAP model maintains decoupled code, which means we have execution, authentication, and authorization in different places. This enables us to have a transaction type that is declarative, which therefore means dependencies can be known from inspection of the transaction itself. Coming back to, you know, sender auth, having authenticator and data. And then we enshrine just a single thing, which is the mapping system, which is the key store, and it's updatable by signed payloads. So 8141, the account model requires coupled code. So execution, authentication, authorization, are all in the same, account model. So this is just kind of trying to use the same diagram as before, in their own account, which is calling, like, an internally owned account. The authority, is the account.

And the problems it's caused, basically, like, only the account knows, who is authorized, and then only the account knows the dependencies, and authority is trapped inside an opaque box to the protocol. So, the coupled account means the 8141 transaction type cannot be declarative. And dependencies must be discovered, i.e. traced. 8141 enshrines this broken account model, along with new opcodes, trace requirements that can never be removed, and layers of mitigations due to the fundamental issue, the account model. So… Moving on, I know there was, you know, a comment saying, do the EIPs people worked on transfer over to 8130? Happy to say that they do. I'll be sharing this slide, I think it's kind of, you know, a lot of work to go into

each of these, but I think you'll see the, pattern, if you look at them, and we're going to go into a case study on the next slide, but, many of the EIP ports have the same difference, frames defines new behavior by a protocol envelope change. 8130 defines new behavior by contract. So yeah, I encourage you to try, you know, porting your thing over to 8130 to see how natural it feels. Again, it is, like, there's no actual significant changes to Ethereum, it's just this new map… we're just updating the mapping system to enable, Any contract to find authentication scheme. So, recent roots case study. The ring buffer of recent roots is a great idea, and both proposals can use that. If we compare the integration.

frames, this EIP… I'm just reading it from the EIP itself. This EIP inserts recent root references immediately after blob version hashes in the 8141 frame TransactionType Payload. So we have an envelope change, and ultimately what it's trying to do is declare its dependencies. 8141, you know, I've heard it said, like, oh, it can be the last transaction type, and it's already, you know, requiring, updates that break RLP encoding, etc. Compare that to 8130. No payload changes needed. 8130 authenticator is declared. Its dependency list can be known from the top-level transaction, and no changes are needed. We define the new authenticator, recent root auth, and basically we have this encoding, which has, everything needed for the recent root references. RecentRootAuth, I mean, I guess you could code,

have the schema be whatever you want, but the protocol can see recent root auth as the authenticator, and then go, okay, I know how to speak this language. Okay, and there's a sub-authenticator here, which is like the pool zk auth. So, I'll do my, you know, recent root tracking, and then just call the cool zk authenticator, at a later time, or once I'm, like, once I need to, or whatever. So, again, 8130, no change, it's contract definition, with the protocol integration. Which is, the ideal system we want. Going into post-quantum, 8130 speaks the right language, so there's an example of an EIP not needed, we'll see that comment as well. That's just because we updated the mapping layer over the theorem, and obviously you can just map so the ELA K1 address doesn't work anymore.

The 8355, quantum, algorithm is, naturally 8130 shaped and converts very well. So I'll… you can share that link here, but, We have, like, the aggregation scheme and everything, set up. Aggregation's also very easy in 8130. Everything's explicit, or, yeah. And then, yeah, all old transaction types can be migrated to post-quantum. Again, it speaks, you know, the same language, 1559, 4844. Obviously, we don't have, blob, information in 8130, coming back to it being a, EVM standard, and not, like, L1's, you know, all the blob… all their use cases for L1, and not trying to consider, like, the whole EVM ecosystem. 8130 is the obvious post-quantum choice. statelessness. Another 8130 advantage. So, 8130 is bound to just the key store and world state. It's easy to extend to additional ones, again, because it's declarative.

We just did that with Recent Roots. 8141, all storage and its discovered dependencies again, and that gap matters for Ethereum's goals like FOCIL. EIP8369 is another thing that tries to mitigate frame issues for validation-only partial statelessness. Not needed again for 8130. Other wins of having the authority, live with the protocol, or it's always been, is basically since we have, you know, the protocol can speak keystore, obviously, it can collect, it can garbage collect, expired, authorizations. So for session keys, for example, you know, I imagine in the future. there's… I'm gonna have a lot of expired session keys. You can just run, like, a, pseudo-random periodic suite over the keystore and just clean up, these. So this, this also helps statelessness, keeping the key store, storage growth, more bound to only, you know, active actors. Not possible when the, account model, is the one defining that, authority.

So, stateless or ephemeral accounts are also easy in 8130. Ephemeral ones are important for privacy applications, which I'm using for a segue here. stateless accounts, I have a link here, which is kind of a cool thing to check out, just an idea, but, It's… when the protocol speaks the, you know, account and authorization, and authority, you can, Have some, interesting properties. So using that segue now. L1 Privacy Protocol goals are first class, so… Privacy requirements, what do you need for a private transaction? Untraceable sender account, so ephemeral, that's the… what I just mentioned, or a single entry point. Untraceable, permissionless, no intermediary gas sponsorship. And 8130, gas payment, requires paying for a transaction invalidation pre-execution. So it needs the tools, to be certain that at the end state of a transaction, it is one where it is repaid.

So you need 4 things to do this. It's just a proof via a state transition function. So you need to know the initial state, which, you… you do know, because an authenticator is a contract, you can look around. You need to know the state transition function, which you do, because it's the EVM, and it can… it knows the code it cares about. You need to know the state inputs, which you do have, because the Transaction Context precompile has, calls and CAS, so you know, what calls will execute, and they'll have enough gas to do what they need. And then finally, so that kind of gets you to, you know, the state that you care about as the first state, as the first call in a Transact, the first call, you know, the first call phase of an 8130 transaction.

And then basically, you need to know anything that occurs after, won't revert your repayment. So, that's the, 8130 call phases, guarantee that call phases are committed. So we have all four of those, and basically you're guaranteed that You can pay for gas up front and get repaid. So authenticators can support any permissionless on-chain pay for repayment flow. Privacy ERC20, and we have some contract examples there. Okay, yeah, and there's a fifth condition on… what a permissionless payer needs, that's what we just built here, is that it needs a high number of transactions in the mempool to be useful. For the protocol to grant this, it needs two guarantees. The signature surface is stable, or trackable.

So the transaction won't become invalid due to, you know, an invalid signature or an invalid, check somewhere. And then, basically, the ETH won't just go to zero for the account, so it can hold, like, thousands of transactions, and there's no mass invalidation risk. So if we just compare the two here, Frames has a high rate pair, which is canonical bytecode. 8130 has a high rate pair, which is canonical bytecode. But again, execution validation code is coupled So, mempools need to keep and allow this management for new payers. So if I wanted to write a, new privacy payer integration. It's up to, you know, the mempool to update to allow that. So it's either permissionless, innovation suffers, mempools have to have… allow this management, or ultimately, you may write… end up writing some key store-looking, like, canonical bytecode.

And that's kind of, you know, maybe should have used the keystore in the first place, and then… for 8130, Execution, authorization, and authentication is decoupled. So if you want to permissionlessly write a new permissionless hybrid pair, just go ahead, just write an authenticator, no allow this management needed by any of the nodes. One bytecode can support any flow. Hey, Chris.

Marc Garreau: We're running a little late on time here, so I'll encourage you, if there's any, Yeah, I can…

Chris Hunter: And he's last time.

Marc Garreau: center points.

Chris Hunter: Yeah, so we have performance… As we've gone through. I know people often say, run 8130 on frames, doesn't actually work. We instantly lose our benefits as we've lost visibility into the decoupled setup due to the frame transaction type. I usually counter with run frames on 8130. It's not great either, but for a different reason. Basically, if you want your account code to be the sole authority, you're always free to do so. The entire system supports you making any account type you like, so you just implement iAuthenticator on your account. And have this whole actor use the account address. But now we've just lost the benefits again, because we're using… we're back in the Frame account model, and we've recoupled our decoupled architecture.

So… Either way, frames is forcing, stuff on the account model. So, how to fix frames. If you fix the account model, you can Adjust the transaction type to then be declarative. You can drop a signature list of codes, modes, flags, and approvals. And the only thing that remains is, like, the… frames themselves, which is, like, call phases. That's not frames, that's 8130 at the end of the day. And then closing thoughts, I mean, this is the same thing as we've gone through, which is just coupled accounts, decoupled. Envelope behavior versus contract defined. And I guess the… This is the last slide before moving on, but… So yeah, EOAs felt good for a reason. They just worked because the protocol managed the authority mapping. It was, rigid but universal.

Smart accounts broke when that authority tried to move into wallet bytecoding coupled with everything else. 8141 would enshrine that break. Mitigations will persist forever. 8130 keeps the job where it belongs and simply generalizes the mapping. It enshrines only the exact piece that's needed. 8130 doesn't, take implementation details from wallets. It enables VOA portability for smart accounts as a protocol feature. We believe it's the right foundation for L1, L2s, and VVM, because it's the same foundation that's always been there. We just couldn't see it. Thank you, yeah, that's everything, so… You know, please, yeah, here to discuss. Anything, and thank you for your time.

Marc Garreau: Big thank you for presenting, Chris. Gonna open the floor now. I see there's already one hand raised. Felix, you'll start first. I'll just make a general encouragement that from here, we've got about 20 minutes left. If folks can try to channel their energy into figuring out, some solutions-oriented, or how to spin your question in that direction. Basically how we can… think about taking next steps from here. Go ahead, Felix.

Felix Lange: Yeah, I just have a quick question. So, in your slides, you presented this Argument that the permissionless innovation is… enabled by your proposal, because you can just implement an authenticator, and then it will automatically be enabled everywhere, but does that not also introduce similar DOS risks and mempool considerations as Frames does? Because, I mean, you still ultimately have to…

Chris Hunter: So, with the, like, with the decoupled architecture, I mean, ultimately with… with authenticators, a lot of them can be made pure. I think the argument for a permissionless payer isn't one that is necessarily pure, but with recent… the recent Roots work, which I think is great, it can be made pure. And when pure, or, the protocol has visibility into, you know, invalidation easily, and at that point, the mempool can manage it. But… that's not true. Yeah, the argument is that if I wanted to use recent roots for my high-rate payer, I just write an authenticator, and it's automatically a high rate payer, because the protocol knows how to speak that. With 8141, the bytecode, has everything coupled, so you…

there's no way to, you know, pull out just that, behavior you want. And if you write a high rate payer in that scenario, you're stuck at one transaction in Medpool.

Felix Lange: I am still… sorry to interject a second time, I just have some trouble understanding the argument still, but what I'm hearing is that this is mostly about the pure execution then, so it's about avoiding state access from inside of the validation code.

Chris Hunter: Well, it depends. I think, like, we're trying to compare, you know, the same things. Like, obviously, if… It depends on what the trace rules are. The one thing that 8130 has as an advantage is, like, things are cleanly decoupled, so it's much easier to just have a pure function authenticator. In terms of, you know, if we're both using recent roots, we can write pure functions here, and… 8130 makes that, like, I can use that and write a permissionless payer, and it can be a high-rate permissionless payer immediately. Not the same in, on 8141, because of the, coupled bytecode for the mempool allow list.

Felix Lange: Okay, so I understand. But so the way I see it is that, bytecode can execute in a pure way, even if technically the same bytecode contains code paths which would access the state. So I think it's more like, for the way we see it, it's just that How you run the thing doesn't necessarily mean that, like. you know, the code has to be pre-validated to never access the state, it's just more like it cannot hit the state access while it's actually executing. So I feel that this is just a distinction I want to raise, but I'll shut up now, and thank you for your answers.

Chris Hunter: Yeah, yeah, I think that comes back to, like, discovered dependencies versus declared. Like, execution is kind of the thing that we… we don't want to execute to… to know what, will invalid… invalidate, I guess. And when everything's coupled, you can't do, like, you know, a static analysis to determine a pure function. Yep.

Marc Garreau: Official?

Kushal Babel: Hey, Chris, thanks for the presentation. I just had one quick question. Did you consider, kind of, modifying the account right itself, so that some of the authenticators can be put In the account, prior, because anywhere that is accessed when you want to validate balances and so on in the mempool layer. Plus, it seems like… You would have less contention. Because the account objects are already segregated compared to, like, a common key store contract.

Chris Hunter: If I understood correctly, then it is a… like, the common keystore contract does have a lot of advantages, like, we do want that, location. We can… in terms of, like, also promoting… I mean, if we were doing this, like, on L1, we wanted to, like, modify the EVM to… and re-mercalize everything and have the account leaf have some… some data there, I'm not sure if that's what you were asking.

Kushal Babel: I'm just wondering why is the authentication information not stored along with the account object itself? Just like right now, we have, say, you know, balances, nonsense, and public keys stored in the account track, why not store the authentication information there as well?

Chris Hunter: The, the, like, the mappings that will likely occur is, like, you know. a million accounts pointing at, a certain, authenticator. Are you, are you saying, like. Why not hold, like, an array in the account top-level leaf, to… Yeah, all three of them.

Kushal Babel: Wrapping the configuration itself there.

Chris Hunter: Maybe happy to discuss, like, the, you know, lower-level details. I did think about, you know, where the best place to put this is. landed on a contract for, you know, not only… portability reasons, definitely, included. In terms of, like, you know, a larger modification to the EVM was definitely something I was trying to avoid. yep.

Kushal Babel: Thanks.

Marc Garreau: Ben?

Ben Adams: Hey, So, with the… you're saying the dependencies are pre-declared, but aren't you only declaring a… an address? So, if you're using arbitrary… Authenticators, etc. They could just be doing random things. And you still have to trace them to find out what the hell they're doing.

Chris Hunter: You don't have to trace, so you can operate a traceless profile, again, everything is decoupled, and you can actually, statically analyze for, like, pure functions, just see if there's any, calls, it just has to be to precompile, and if there's no other You can basically, yeah, like, on Transaction Ingress, for example, you could see, okay, this fits the, you know, and… You can write it in such a way that you remove the false negatives, but maybe it doesn't cover the whole space, you just have to have certain rules when you write the contract. That's, possible. But in turn, like, I'm not trying to claim that, You know, the setup… would, like, never require tracing. Like, ultimately, if you would have an authenticator that you want to be stateful.

It can be, but then we're back to the trace rules of 8141. That's everywhere. 8130, they're kind of, you know, this is how I've outlined, like, chain profiles. Like, a lot of chains don't want to do tracing. L1 might not want to do tracing with these kind of new capabilities here, and just do pure function rules. There's a lot more freedom having things, you know, able to turn up the dial on exactly what you want.

Marc Garreau: Chris, could you drop your slides in the chat? There's been some requests for that.

Chris Hunter: Yeah, I can do. So, I see, recent roots require storage, so it can't be pure. So, this is where the protocol integration actually comes in. I believe that was one of the reasons for, the EIP, recent roots. So, if you, if the protocol is aware of it and is tracking it, it can just, you know. keep that in the mempool as a dependency. So, the dependency is explicit, the sub-authenticator is the one that would be stateless, and we just pass the recent root to it. It can also see, like, for example, if you're using a 2D nonce for the nullifier, therefore, you know, we have everything we need to, only be using pure functions again there.

Marc Garreau: a separate question I've seen, maybe you covered in your presentation, and I could have missed it, but is, something like 7906 possible in 8130? The transaction assertions?

Chris Hunter: Yeah, so Transaction Insurance, I mean, they have… I think that's an interesting one. That one is, like, you know, Frame, and it has, like, a kind of a DSL for what defines a valid transaction or not. ultimately, like, 8130 is contract-defined, so the, like, equivalent thing to build, would be a precompile that you would call with whatever. The proposal for the that I ended with for, like, 8130's, transaction assertions was actually just allowing, events to be seen on the transaction context precompile as they were made. And the argument there is just that The things that you care about, like, should be well-written contracts, and well-written contracts should probably have events. Maybe that doesn't apply everywhere, but I think that's, like, open for discussion. So those are kind of the two options there for 8130, which is,

Yeah, add Transaction, events view, or, data precompile with that, with that capability. Is the registry key store system a contract? Yes. Would it require a hard fork to update it? Yes, but the, the mapping is very simple, right? Like, it's, just a signed payload that says, you know, add this after ID with this verifier, with this scope, with this expiration. There's not much else there. Then there's the, like, you know, is this a multi-chain, after change, or is it a local after change? And the only last thing on the keystore is the ability to make sure that a key is not revoked, and that enables the high rate payers. But if you… if you needed to make an update on the key store, that would be a fork for, like, it has no… it's obviously, like, not upgradable or whatever.

Marc Garreau: I see a comment by Matt that's getting a lot of reactions, I was gonna encourage him to step up and bring that chat into this space, but, Derek, would you like to say something first?

Derek Chiang: Yeah, you know, I was actually also going to just circle back to Matt's comments. I don't know if you saw it, Chris, you know, but basically, it's basically like the comment that I shared with you in DM as well, basically. You know, I think, like, me personally, I see a lot of really good technical arguments for 8130, and I know that a lot of, like, the other L1 core devs, you know, share my thoughts as well. You know, so… but I guess, like, the, question for you, It's basically, like, whether BASE would be willing to essentially work with the L1 in terms of, like, not, essentially forcing the L1's hands by shipping 8130 as is.

basically, like, before it's able to incorporate feedback from the OR, you know, because, like, if base makes that committal step, then it means that we are now essentially, do not, like, essentially, like, yeah, sorry, like, did you want to chime in? Yeah.

Chris Hunter: Yeah, I… so… I mean, like, you know, the starting principle of 8130 was always built for every EVM, and, like, L1 is, you know, the most important thing. Like, base would be happy to delay its fork, and get feedback from client teams and final changes, etc. You know, we don't… we do want to, you know, keep, moving quickly, so, like, you know, I don't think that's, like, a, move at the speed of. you know, half a year or whatever, but, you know, would be very excited to work with, everyone on making sure this is, like, absolutely the best spec, possible. So…

Derek Chiang: Yeah, you know, that's my… that's my only question, you know. So, to me, like, that sounds like a really great news, you know, you know, if BASE is willing to… Delay going in life, in order to… you know, for us to keep the possibility open of reaching a spec that can actually be implemented across L and L2s. Yeah, so, yeah, so I would personally recommend that we try to work towards the outcome. You know, to me, like, the final EIP number that we settle on is significantly less consequential than the technical substance, meaning that, like, I really don't care if, like, the number is 8130, 8141, or anything. I think it's really just about, like, reaching a technical design that works across chains and meets the needs of both L1 and L tools, you know? So, you know, I know people tend to get emotionally attached with, like, the EIP numbers, but…

I even want to float the possibility that perhaps we can even, you know, if people feel super attached to numbers, that we can even try to arrive at a new EIP that's, I guess, like, synthesizes the best part of both specs, but I guess that's more like a tactical discussion that we can save for later.

Marc Garreau: I've got a couple more hands and only 8 minutes left, so, let's try to keep it constructive and brief. Ivan? Or Ivan?

Iván | ethrex: Hello. Speaking on behalf of Ethrex, I'd like to say that we've been… to say that we've been working on frames for a couple of months so far. We found that implementing it isn't that complex, and that the flexibility allows. For building impactful features on top of it is very great. We don't have any strong opinion against 8130, but the arguments in favor of it Are not very convincing to us, so… We are still supporting Frames. We'll actually do a proper announcement later this week, or early next week, but we have a couple of… we have exactly two networks, one permissioned privacy-only testnet, including Frames, Keith Nonsense, recent roots, and FOCIL, and also another one more like a kyota-like playground.

including DCIPs and also post-transaction assertions, and a proof of concept of native UDXOs. I'd like for people to look up into the implementations to find themselves if it's complex enough, or if it's easy, and also to play around with the features to see if It's what they want.

Marc Garreau: That's exciting, thank you. Pedro?

Pedro (WalletConnect): I would like to bring back what Derek said, to not get caught up with EIP numbers, because realistically, we're not comparing 8130 and 8141. What we're comparing is a decision whether or not the protocol should own the account model or not. I think the history of Ethereum has shown that it was preferred that the protocol does not own the account model, and it provides the primitives for wallets to actually own the account model. But having spent so much time working with wallets. innovating the account model is essentially just repackaging and rewriting the same transaction batching, gas sponsorship, and key rotation over and over again. It doesn't actually give any competitive advantage, it just provides a burden for wallet implementers.

When realistically, we want the same experience for smart accounts as we want for UAs, where it has instant portability across chains. And that means the account model must be the same. That ownership of the account model to move to the protocol. Means that we do not have to… dictate that one implementer or another has chosen a particular caveat of how to do key rotation, of how to do gas sponsorship. It provides no benefit for anyone. And I think the divide here is, are we… Being bold enough to say the protocol will own the account model or not, independent of which approach. Or we're taking.

Lightclient (Matt Garnett): I mean, does any clients want to… want to stand up and say that the L1 needs to own this aspect of accounts? Any clients want to say that they don't want to stand up and own this aspect of accounts on L1?

Marc Garreau: Can you, state that, another way, like, I know everybody's splitting attention between reading and participating in chat comments, too.

Lightclient (Matt Garnett): I mean, half of 8130 is defining a full account system, you know, the portability of how do you migrate these accounts, the access controls for these accounts with the actors. You know, all of the things that we typically think live at the, like, kind of user layer of the protocol. You know, Pedro is saying that he thinks that the L1 needs to… Take responsibility for those aspects of accounts, and we need to start enshrining that logic into the protocol. And I'm just asking, like. I mean, we need to make a decision on this. Is this something that we're going to be building for or not building for? And I just want to know, like, do any client teams want to support building for…

you know, that world where we enshrine that behavior into the protocol? Or do any client teams, like, think we should not be doing that?

Derek Chiang: So, not to speak for clients, you know, and I know that I'm kind of, like, front-running.

Lightclient (Matt Garnett): Jeremy, can we just hear from the clients first?

Derek Chiang: Yeah, but I do think that, like, this point is, like, confusing enough that it's worth some clarification, you know, before the clients chime in, right? You know, because, to me, the… like, 8130 is not, like.

Lightclient (Matt Garnett): We're not talking about 8130. We're talking about a general question first. We're not getting hung up on EIP numbers. This is just a generic question, like, should L1 own this logic?

Derek Chiang: Okay.

Chris Hunter: It already does, though.

Derek Chiang: fans speak first, and EL would come in.

Mislav Javor: So… If I may, I think this might be a… place that's easier to solve outside of the core clients, and this is one of the reasons why I am intending to support Frames. I believe that, like, there is a divide between what focuses for the client teams and what the focus is for wallet, and then tooling teams, and otherwise. Frames makes this, sort of, elegant divide, where the core protocol clients don't have to work on this anymore after the frames are merged. What I think is missing in this discussion is this idea that we're gonna have, 7702 again, where every wallet's gonna develop their own implementation. I think that neutral… institutions, maybe the EF, maybe ETH Labs, maybe the wallets, maybe we make a new consortium.

Should have a separate governance process, not for a reference implementation, but for a default implementation that everyone uses. Basically, the idea is that you can standardize on top of the protocol, not just within the protocol. I think 8130 is an amazing example of the… good, feature set that might be, given on this, layer, but yeah, I kind of… if wallets don't like something, enshrining it into the protocol is not gonna make them use it. I don't think that's, that's… yeah, I genuinely don't think that it works in that way. So, yeah, that's just my two cents.

Marc Garreau: Real quickly, we're at the top of the hour. If anybody needs to run, thanks for coming and your participation. We're gonna keep this going, though, since we've got, a lot of the right voices in the room. Okay, I see, Mislav, you still have a hand up? I don't know if that's from, your previous point.

Mislav Javor: Sorry, sorry.

Marc Garreau: You're good. Tomas?

Tomás Arjovsky: Hey, so to address what, like I had said a couple of minutes ago about, like, owning or not owning these kind of decisions, I think that in general, one of the philosophies that we agree the most is that the EVM should support I wouldn't say the bare minimum, but the lowest level possible in order for everyone to build whatever they need on top of it. In general, you don't want something as basic as the OS or a hardware like the CPU to have very specific things that then you don't know if they will be used, especially if the cost of upgrading is very high. So, one of the things we… for instance, in the last interop, we tended to agree on, hey, you should try to make

whatever is needed so that they can build their own account models, their own signature systems. If they need precompiles, then you can have precompiles for the most performance-impactful operations. But then you should probably not try to all get fixed on one account model, or something that makes flexibility very difficult in the future. I think that's one of the reasons why we are supporting frames over 8130.

Marc Garreau: Chris, did you want to correct any…

Chris Hunter: Yeah, so I keep hearing, like, account model bringing the wallet features into the protocol. Like, I think this was basically coming back to what I was trying to say in my slides, which is. The existing, like, the existing, setup today is that the protocol does manage the authority. Externally owned account is an externally owned account, and the mapping is controlled by the protocol. All we're doing in 8130 is allowing that mapping to be updated. the model… the account model of 8141 is definable at 8130. Just deploy an account with its, Actor as itself. As its own authenticator. There you go, you now have brought authority back into the account. And you can define, you know, any kind of logic you want, and that's also multi-chain. What 8130 is actually doing is just…

enabling that, generalizing that mapping layer that already exists today, it's just one-to-one. But, again, since it's decoupled, it's easy to recouple again to the 8141 account model, which we went through, like, on the slides, which is, you know, causes all of those, follow-up problems, basically.

Marc Garreau: Chance for Tomas, if you wanted to get a last word in, otherwise I'm gonna move on to Nico.

Chris Hunter: Oh, sorry, one… it says both proposals are training complete. You can define the logic of, each and another. So that's, like, the last slide, which is, like, oh, run 8130 on, On frames, which, again, you… the Frame TransactionType is not, declarative, so… running 8130's account model means it's all… it is, you know, you could set it up contract-wise that way, but ultimately, it's being forced through an 8141 view of the account model, and we lose all the benefits. That's like the… in the slides.

Lightclient (Matt Garnett): But you can recreate that through contracts in 8141.

Chris Hunter: So, you can create… recreate, like, 8130 is portable across accounts, but if you look at the Frame TransactionType, it is only calling the account. Like, you know, it calls the sender to get it approved, so we were trying to execute the account code, which has.

Lightclient (Matt Garnett): Yeah, but the account code can be an enshrined code that implements 8130.

Chris Hunter: That, so the account code could be a keystore-based system.

Lightclient (Matt Garnett): Yes.

Chris Hunter: Right. And that's fair. I'm arguing that the key store is the, like, the existing ethereum is a key store, but it's only one-to-one and updatable mappings. And all we're doing in 8130 is generalizing that. So…

Lightclient (Matt Garnett): Yeah, but you're saying a lot of stuff. You're saying, like, 8130 is more expressive, you're saying that you can't, like, define these, like, you can absolutely define 8130 with 8141, and you can create…

Chris Hunter: These are… A key store is not 8141. You said define a key.

Lightclient (Matt Garnett): I'm saying you… you can define a key store account system with Frame transactions, if that's what your L2 wants to do. Like, Frames does not stop you from doing these things. Frame allows you a superset of behavior beyond what 8130 provides.

Chris Hunter: If you have, like, the pointer to an account being external, we can always point it to the account again. So, like, I believe the superset is 8130, because we can go back to… like, if you wanted, we could be external, and, you know, call the…

Lightclient (Matt Garnett): We can just agree to disagree on that, because I don't agree at all.

Chris Hunter: Yeah, down to discuss offline, or whatever.

Marc Garreau: Okay, let's move on to another point. Nico, you wanna jump in?

Nicolas Consigny: Thank you. So, one quick point around the aggregation and 8141. So, Frame has been designed with a forward-syncing signature that lives in a typed after list, validated outside of the EVM, and so this gives us, like, agility, and it allows to have the feature Aggregation that we've been working, so… This is the best way to scale the L1. After years of research, this is the best we have. And I do feel like, 8130 is trying to sacrifice everything for, like, L2. Scaling and some efficiency that we're, Yeah, we're simply not gonna get the same scaling. If you take the global picture, the one start amortizing thousands of sphinx and XMSS verifications. is simply the best way that we have to scale the L1, and the frame has been designed exactly for this.

So I just do want to point that if we go another way, we are just, you know, losing months of research, and I simply don't know where we are going. And then on the crypto agility and the schemes, if we go with the enshrined account model, we will be creating a forever governance debate. On post-quantum schemes, and what we've just learned in the last 6 months is that the space is moving very, very fast. I was myself the, one of the first person to push for the lattice-based, schemes to go on Ethereum. We worked with external teams, and we created EIPs for this, the first version of the precompliance for Falcon and MLDSA. And yeah, recently we learned, thanks to the entropic attack team, that the,

Security boundaries are moving very fast on lattices, so… Not only would we introduce a infinite, governance game that is… that is going to be very, very challenging to manage, but also, we're gonna enter the emergency hot fork, every time, a new, AI company, post the paper. So, just from a cryptography point of view, I think Frame is way stronger and much more forward-thinking. And then there is the entire privacy rabbit hole that I would just drop for the sake of time.

Marc Garreau: Thanks, Nico. Go ahead, Chris, if you can…

Chris Hunter: Super quick. Like, ultimately, you can… L1 can decide to run any sort of, rule set it wants to do on the authenticator set, so you can have yours, be completely, you know, permissionless deployment and follow whatever rules you want, similar to 8141, if that's what you prefer. the restrictions, that, like, the other, you know, L2 profile is defined in the, spec is just so that there is some standards for wallets, to know that this implementation is everywhere, and, basically, those are only for, like, admin keys. Agree on, like, post-quantum moving quickly, so that's a little bit of something, but at the end of the day, there's not going to be, like, you know, a hundred algorithms that we need to support, I think, on that set. So, even adding, you know, more post-quantum to the set for L2s or whatever.

Isn't, shouldn't be an issue.

Nicolas Consigny: But then we would also need to spend a lot of time removing the non-post quantum ones, and discussing which one we remove, and all of this becomes a lot of politics, isn't it? But, agree with Serpo. Thanks for the answers.

Marc Garreau: Okay, Stavros.

Stavros Vlachakis: Yeah, hello guys. wanted to chime in a bit, in behalf of Nethermind in order to actually answer what Matt asked a few times ago, many discussions since then. So, actually, in Nethermind, I don't think we want to own it, Matt. And actually, what we don't want is to limit L1 on any specific account model. whether that's 8130 or whatever other number. We feel that… A loan behavior should be generic, and marketing adapters of it should decide what to use and how, and it shouldn't be coupled to any L1 governance and needing add hard forks in order to change something. Yeah, that's what I want to say, Nethermind. I don't know if Bono wants to add something.

Ben Adams: Yeah, it's… it's, So, more important is giving the tools to create, these things. One of the things that 8130 doesn't allow you to do is post… Transaction payment, so you can't… You can't pay the transaction afterwards. For instance, withdrawal from a privacy pool, the transaction that is… the person doing the transaction can't pay for their own transaction. from the withdrawal, you'd need, like, the privacy bull to… sponsor it with 81 through 0, which could have legal implications, in that, you know, now everything in that privacy pool is smeared to The pool, because the pool's paying for them, versus, well, it's the individual who did the withdrawal. that's their responsibility. It's isolated to them. So there could be,

sort of legal implications, depending on jurisdictions. But also, yeah, it's more about giving the tools, rather than saying, this is the opinionated account model, and if you want changes to that, that has to go through ACDE, and we have to do a regular state transition on the smart contracts. All that sort of stuff, rather than the market, you know, if this is… if 8130 is the best. thing. You can implement it on top of frames, And, you know, the market can agree with you, or somebody else can innovate, come up with a different one, and that can… Can replace it. Whereas enshrining an account model, a very specific… particular form of smart contracts, essentially is putting it on

ACDE… of… You know, what's this gonna be for the next 100 years?

Chris Hunter: I don't know if you want me to do rebuttals for each of these, but yes, so that is, the, like, only kind of, capability I concede for 8141 that 8130 can't do, which is that frame ordering. You can put approval of a transaction at the end of a a transaction. So, 8130, everything's, you know, it's validated up front. that's… So, yeah, we can't support that flow. I would argue, and the privacy pool case is maybe interesting, but that we want to pay up front, but I think that's fair to concede that that is a 8141 capability. That we don't have. In terms of coming back to, like, this, you know, the canonical thing, like, I don't think, L1 should be concerned about that. If you want fully permissionless innovation, deploy your authenticator, have your account do whatever you want, that's fine.

But… L2s and other EVMs need these standards, so there should be a reliable set that is shared, and that's ultimately what that's trying to do. It doesn't define… like, ultimately, you know, if all the L2s are on 8130 and L1's on 8141, we're gonna be in the same state anyway, so it's better that everything speaks the same language.

Ben Adams: I mean, there is a fundamental difference there, in that, L2s are… there is a certain degree of centralization. And deployment of… you know, they are controlled to a greater degree than L1 in terms of Decentralization and permissions. So I'm not sure the, the, the… I mean… L2s can do whatever they want. I'm not saying it's a bad thing to… You know, to do. Something more controlled? But… Do you understand there's a… there's a… a difference in terms of… How the governance works.

Chris Hunter: Yeah, for sure. I'm just saying, you could define identical, like, trace rules for validation as, 8141 for L1. And never consider yourself with the rest of the standards.

Marc Garreau: I think this is a good thread here, but, I'll invite Sahi to jump in.

Tsahi Zidenberg: Yeah, hi. I… I think that a very good point is, right. what can we do without a hard fork? It's a point that many people raised, and And I think… I don't… I don't really have a horse in the game, right? I want to… I'm from Offchain. I want to see the best… if it's a new EIP or a fix to whatever, but there are things that ABI 130 does very well, and I think that, 8141, when it added the signatures, it took a great step in the correct direction. But there are things it, we should… it should improve on, and should possibly even learn from, 8130. Like, the fact that in 8130,

Signature schemes are basically… Contract addresses. And what that means is, if I go… if today we're in China 8141, at least as I have read it two weeks ago. And tomorrow someone wants to add a new signature scheme. then that someone needs to decide, right, will my new signature scheme be number 4, or number 0X100, or something like that? And that requires coordination. 8130, because the signature scheme is just a contract address, there is no need for coordination, right? As long as I can deploy the same contract On more chains, then more chains can easily make the choice to, to, accept that. So, there are many things that I really like about 8130. And… And if it's not taken as a whole, but just

the correct bits of it are taken, I'm… I'm happy. So, mostly it's around that ability to define new signatures, to define them as contracts, and to be as stateless as possible, so that anything, stateful that happens… Can be really, really, really kept down to a very small, Like, not be a part of a verification that that, as far as I understand, the current idea is for verification to mostly do Something around signatures, but they're not stateless enough, so it's very hard to know what a verification frame is doing just from outside the transaction. Where, if we can push more and more and more logic into the signature frames. More and more ways for signature frames to do

to, to be able to add, to, to allow signature frames to use weirder signatures defined by a smart contract or whatever, and possibly a verify frame or something else that has very, very limited I'm going to do something stateful, but it's very limited, right? All I'm going to do is check a few things in state. That gets me to a very good position. And, yeah, and I think these are the main ideas that we are pushing. We also tried talking about the guarantor, which… The idea of a guarantor for me is allowing someone to take risk away from the sequencer. Someone can say, I want a different… I believe in this, I don't know, new scheme and that… and it requires more verification gas than the sequencer is willing to pay. That's okay, I support it.

I front… I take away risk from the sequencer. And, and now the sequencer can include things easily and know that it doesn't have as much risk. But really, having as much stateless Validation, keeping, and allowing us to really keep stateful to a very, very small thing, I think is the way to go. And if it goes with 8130 or with… 8141, modifications, then wonderful.

Marc Garreau: Thanks, honey. Eric, your time has come.

Derek Chiang: Sure. Yeah, yeah, you know, so I think I just really want to echo what Sahi just said about how we are not forced to adopt EIP as a whole, right? You know, so that's why I keep saying that we should focus on, like, the technical aspects of the EIP, as opposed to getting attached to the numbers. So, regarding 8130 specifically, I think, if I may say to Chris that, like, I think it's, like, important to concede that the L1 will simply not adopt a lot of, like, the more opinionated aspects and functionalities of the accounts, right? Things like the, you know, the actor model, the session keys, the, you know, you know, like, the logs. So I think, like, those are just, like, too opinionated to be forced onto, like, every chain. But the… to me, like, the core… the core technical aspects of 8130, that's really, really interesting, and that's why, like, all the L2s like it.

is the authenticator-based authentication model, right? You know, because like Tahi said, it allows the sequences, as well as, like, element nodes, to very easily tell what the authentication logic is, right? You know, so then it allows you to optimize the authentication logic with native codes. It allows you to, you know, easily gate particular authentication logic. Yeah, you know, so my proposal is for us to like, just regardless of, like, the EIP number, just for us to seriously consider whether that model may be… the best foundation for, you know, for, you know, for a validation model, you know, for, like, all chats, right? You know, because, you know, like Ben said earlier, you know, he's definitely correct that the frames validation model in which you have, like, all these frames where, like, the validation frame can be in arbitrary position.

in the transaction, that model is more flexible and capable than the 8130 model, right? You know, like, with the Frame's model, you can pay gas with the ETH you acquired during execution. And like Chris said, like, Chris also conceded that, like, that's a real capability gap. So I think, like, the question is basically, do we prioritize that capability gap? Or do we think that it's more important to have a, you know, a simpler and more, I would say, legible, safer, authentication model that can be easily implemented and safely implemented across L1s and L2s? So I think, like, that's what the decision comes down to, you know, like, just regardless of the EIP numbers.

Marc Garreau: So this enshrined key store is coming up. Regularly. Is this a good time to temp check on… Clients' appetite for just that component of Accounts being owned in the LM.

Stavros Vlachakis: I think Nethermind's opinion and, Ethrex. from my one, it's already expressed, so I don't know, maybe… Matt, can you speak on behalf of Jeff?

Felix Lange: So, I can give a quick comment on this. I am not inherently against having this kind of functionality, but I also feel that It has to be… somewhat optional. Like, if you wanna… Registering account in the system, it's a… it's a good thing, and it can be encouraged, and it has some advantages. But it shouldn't be the only way, because it has these governance pitfalls, like we were saying, like, if we have a tried registry of these keys and their schemes, it does mean that we have to come to an agreement on them every time. And actually, if this is to be shared, we have to come to an agreement on this across all the chains.

So it does add a significant… Or didn't. Matt St. Justice.

Marc Garreau: this could be an ERC is… I mean. If we want this to be utilized, I think it needs to be packaged. Go ahead.

Felix Lange: this was kind of our position from the start on this, I think that… Technically. it can be an ERC. But the problem with just saying it can't be an ERC is that ERCs have not seen widespread success in some cases, because if you really want to agree on something, it does require a strong signal from the actual developers of the chain. It's like, yeah, you can make any ERC, but then it's just gonna sit in this pool with thousands of others, and the adoption will really only come if it is pushed from the top. And so this is, like, the downside of having it as an ERC, I guess. I do think that the idea itself was pretty sensible, to say, yeah, these are the

recommended and universally supported signature schemes, and as far as I understand, 8141 also now has moved toward that direction by declaring, ever since we added the signature list to the transaction, there is also a way to specify what type of signature it is. So I think it is somewhat of a concession to this idea that, like, we really should agree On some signatures, but as long as there's always the option for the user to use a different one. And this is kind of the escape patch that 8141 provides, that you can use another signature scheme that you have defined yourself, and for us, this is the thing that enables users to then prototype, or even wallets to prototype

signature schemes that are not supported by the protocol natively. And we really, really want to keep this functionality Which is why we think that, in general, we… we see that, like, 8141 has very good extensibility, because It is possible to bootstrap a completely different account system on top of it. And… If this turns out to be successful, it… Can sort of get the blessing from the core development community as well. But the advantage is you can already deploy the system even without any coordination, and we feel like this is very important to maintain. But I do also agree that it is good that we have an ability to agree on specific types of signatures and what they mean. We don't want to leave it fully open, because then it gets very difficult to do the aggregation, and as everyone mentioned.

There are some downsides with that.

Marc Garreau: Okay, we've got 3 minutes to the end of the… First extra half hour, Derek suggesting, and I, sympathize that we… try to wrap up around here, and maybe the best way to do that is, to solicit some next steps and bonus points if, You are the person volunteering to execute on any of these next steps.

Lightclient (Matt Garnett): I mean, I'm mostly just, like, trying to figure out, you know, who are we trying to convince, and, like, what really needs to happen, because, like, in some ways, a lot of core devs, like, already… are happy with the direction the Frames is moving, and there's some, like, discussion points we can keep You know, trying to figure out… But, like… Broadly, like, who do we need to convince? of, like, certain decisions. Like, some people just won't be happy at the end of this. Like, that's just how it is, especially with the count abstracture, where there's so many different decisions that can be made. And so I don't really know, like, what is the decision framework? Like, if we want to, you know, actually commit to doing something as SFI in Hegota, like.

That's usually a decision that the core devs make. Obviously, we want, you know, all of the stakeholders to be somewhat… Happy and accepting of this. change that we're going to make to Ethereum. But, like, in some ways, we're also… I don't know, you know, a lot of this is, like, Q&A with base about 8130, and we need to move away from that, and we need to move to Ethereum adopting account abstraction.

Stavros Vlachakis: On top of what, actually Matt said, I also would want to clarify, let's say. what are we trying to achieve here, and what we should do as core devs, for the best of Ethereum, let's say. It's our job to define, which account modular abstraction is gonna be used, or to just… give to ethereum adapters. The tools and the functionality to… do whatever. they think it's better for their use cases. I think that's the question that needs to be answered in order to move on.

Marc Garreau: As… as for this meeting, The default path is that 8141 proceeds, in its current course on Mainnet, and 8130 proceeds in its current course on… with the L2s. But this is specifically an opportunity to, hear feedback from the wider stakeholder, range about what would be impactful for them, or at least, perhaps get in the way the least about, helping them achieve their goals as well, so… I… I think it has been effective in… in… Unveiling some motivations and some of the specifics underneath. So I'd say one opportunity is… is… To ask the question, what can… Like, what would be the biggest difference makers in… in… Small or large tweaks to 8141 that would, make everyone's lives meaningfully better.

And then, Yeah, I lost that train of thought, but I'll let Ansgar pick it up from here.

Ansgar Dietrichs: Yeah, I mean, I just wanted to briefly say, I think… the framing of who do we need to convince, I think it's too much from the lens of the L1 decision-making process. Ultimately, yes, the decision is with the CREFs, and I don't think anyone is contesting this, and I don't think the argument here is that L2s now should basically be able to vote in… on the L1 governance process. I think the point is more we overall are trying to Bring in more stakeholders, make these decisions more with the actual… needs and interests of the community at hand. Of course, it's more clear-cut with, say, just application developers on there one, but I think for many years now, we've encouraged the use of the EVM as a technology platform across the Ethereum L2 ecosystem.

I think it's possible that we are reaching a point where, not just with accounts, but with several topics, we are… we will see some branching, and maybe L2s will use a different kind of, like, standard going forward than the L1, but I don't think it's inevitable, and I don't know that we should just be cavalier about it, and should just, like, treat that as something trivial that we should just let happen. So I think it's at least clear that we should try our hardest here to see, is there something that we can do that actually satisfies all the needs from all sides? Ultimately, the L1 will go ahead with whatever is best for the L1. That has always been the case, that will be the case, but I do think

it's really, really, really important that we have these very active stakeholder engagements and try hard to find common ground here. So that's all I want to say.

Marc Garreau: The end of my… train of thought there, too, was, that I think Many of 8130's, proponents are perhaps most worried about, Frames being adopted, widely and in a… timely manner, so I think that, concern is… is… Worth, more cycles on figuring out precisely how Any of these schemes are, Actually get into the hands of users. And that's a separate topic that we… Don't have time for today. Okay, oh, I maybe would have liked more, like, specific next steps to happen here, But I think it's about time to close this thing out. Before… this is kind of a last chance, would anybody, like to… commit to any specific next steps themselves, whether it be a proposal to tweak one of, for example, frames to add a specific set of functionality? Is there a next

A very next step, or a specific question. That we can, seek to… to address to keep moving this forward?

Lightclient (Matt Garnett): I mean, I think if somebody wants to make a proposal to add key stores to frames, that's… To me, the obvious way… the obvious place that we can, you know, really… understand the… The proposal, and decide if… That's something that we want to do on mainnet. I think that, you know, a lot of us have spent the last… I mean, I've looked at 8130 for a while, I think a lot of people spent the last week looking at 8130, I don't think any client team right now feels that 8130, you know, in its current form, is something that is going to make sense on L1. And so I think that we should focus on These, like, specific points of contention and see if there are ways to integrate that into this, like, frame structure that we've been working on.

With 8141.

Felix Lange: Is it… I mean, the way I see it is, if we make a, like, an… companion EIP that just focuses on the key stored, then I think that could be a good start. Because…

Lightclient (Matt Garnett): Yeah, that's also a good… a good way, probably.

Felix Lange: We will probably need to do this anyways, because we were saying, like, I mean, if base is gonna have the key stored, then, I mean, there has to be some kind of interoperability between that one and… So, we have to kind of come to a… the way we typically resolve such debates is then just to say, well, if there's some kind of interface that we can both use, and… then it's actually kind of fine, because ultimately, if we… we don't really want to sacrifice the account portability. So if people deploy… if there is a keystore on L1, and people deploy their accounts there, typically, then it's kind of fine if… If, if we, If we disagree on the transaction encoding, because de facto, we disagree on the transaction encoding even now with the L2s. There's no kind of universal transaction.

At least not with most L2s. So you, anyway, have to create a specific transaction for each L2, but if you can at least share The… the keys, then that'd be good. So I think that's… that would be the way forward. And, to Chris's point there in the chat, so, the way it works with 8141 and the mempool is just that we just need the guarantee that a single action on the contract cannot invalidate many transactions that are currently queued up in the mempool. So as long as we can uphold this guarantee, so as long as we can have a model of this contract in the mempool that basically proves that this is not possible. The contract can totally be… added.

to the allow list for public manpool processing. So it's just that the only reason why we don't support completely arbitrary validations and completely arbitrary paymasters in the 8141 is because it could have these DOS risks. But I think with the key store, that doesn't really exist, because you need to send a specific transaction or a specific account to remove or add one key, in which case only one transaction can be invalidated. It does, however, mean that in the long run, we have to make sure the The Manpool kind of can act on these events as well, and then remove transactions that have been invalidated by keystore updates, things like that. But this is anyway something that's more for the long run.

Stavros Vlachakis: Yeah, yeah, sorry, Felix. I would also want to add that… Whatever improvement, anybody sees, either on frames or… Even something, possibly. better than Frames that is generic and allows all these, let's say… Account abstractions, and allowing everyone to use whatever he likes, and adapt it. is very more than welcome, in this EIP or in another EIP, it doesn't matter, it doesn't matter the numbers or the names. I think… Personally, that's… what is gonna… move Ethereum further, and make it bigger and stronger.

Marc Garreau: I think that's a great point to end on. Thank you, everybody, for coming. I feel like we got to a much nicer landing spot there in the last couple minutes. See everybody on, Thursday for ACDE. And, have a great rest of your week.

Chris Hunter: Next up.

Stavros Vlachakis: Oh, mate.

Kevaundray Wedderburn: Thanks.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.