Frame Transaction Breakout #3

Transcript

Justin Florentine: Her vraps!

Lightclient (Matt Garnett): That's such a good voice.

Justin Florentine: I, when I was 13, I… I think it was 13. I was Pee-wee Herman for Halloween. It was… a long month of practicing that voice. Long. Bot of fun.

Lightclient (Matt Garnett): Are you a big VOPS fan now?

Justin Florentine: I mean, I… it's… I'm digging it. I'm digging the vibe. Here, this is… this is… I like the idea of branding a problem space.

Lightclient (Matt Garnett): Yeah.

Justin Florentine: I think that's good for us.

Lightclient (Matt Garnett): I agree.

Daniil Ankushin: Hey, guys.

Lightclient (Matt Garnett): Hello Do you know if Chris is even gonna come today? He said he was gonna have some… Update. Oh, there we go, nice.

Justin Florentine: FOCIL Cruz should be rolling in today, too.

Lightclient (Matt Garnett): Good.

Marc Garreau: Hey everyone, we'll get started in, 3 minutes after the hour.

Alright, Roon's starting to fill up a little bit better here, so we can kick this thing off. Welcome everyone to the Frames slash Native AA, Breakout, call number 3. Today's September 1st. I'm posting the agenda link in the chat. And, the agenda is light, on bullet points, but we've surely got plenty to talk about. Briefly… the… I'll leave space for two things, essentially. Spec updates, or, well, let's call it 3 things. Any spec updates, any client team updates, and then the remainder of the call will be for, proposals, either new or to existing EIPs. So I will kick this thing off with a little bit of context, and we'll jump right in. Picking up from last call number 2, we went looking for common ground on…

what the proponents of 8130 and 8141 wanted to see out of a native AA solution on mainnets and L2s, or mainnet and L2s. We found, some threads to pull on there, Fast forwarding to the… the next ACDE call, last Thursday. We heard a brief update that there… both camps were working towards either a pattern that utilized a single transaction type, otherwise Plan B would be for a couple of transaction types that could live alongside each other. And, towards the end of that Thursday call, 8141 was SFI'd, intending, to send a clear signal that, native account abstraction is to be, a… an absolute priority in the Hegota fork.

And with the understanding that the spec will continue to evolve, and the collaboration will… will continue. So that brings us, to this call. The last logistics note is, if you're here, you've figured this out already, but we are beginning the weekly cadence of this call. We'll do that for as often as feels necessary, and then probably dial back down to bi-weekly. So that's… that's that. Let's jump straight into agenda stuff. Matt, if you're ready, I'll give you the floor for any, like, spec updates or updates to the Frame itself, and if you don't have much to dig into there, then we'll just pivot to client team updates.

Lightclient (Matt Garnett): Yeah, there's actually not really any spec updates in the past week, for the most part, I've just been chatting with various people, including Chris, about some ways that we can improve frames to… you know, have better interoperability between L1 and L2, and find some common ground, but nothing has upstreamed yet. I think there's a handful of open PRs. I'm not sure if there's anything too consequential. I have a couple ideas that I wanted to run past people, but we could do that kind of at the end of the call. At this point, it feels a little bit like we're trying to freeze for this initial DevNet. I don't know if… Yeah, this isn't something that we've kind of, like, talked about formally. I've tried to freeze it a couple times, but we've found…

Cross-client disagreements, and have spent a lot of the last month clarifying things in the spec. Do clients generally feel that we're approaching a place where we should have… you know, the spec frozen for DevNet 0, and new changes need to be going towards DevNet 1. I'm curious, I don't know if, Guru you have thoughts on that?

Guruprasad Kamath: Yeah, the specs seems to be, like, relatively stable over the last, like you mentioned, couple of weeks, so I think this is a decent point to start.

Lightclient (Matt Garnett): Okay. I would probably lean towards that, and try and have DevNet Zero, spin up in the next week or so. I think most people are quite close.

Marc Garreau: Okay, so does it make sense to do a quick, client. Check here if we've got many of them represented. For readiness and, that… about a week timeline.

Lightclient (Matt Garnett): Yeah, go for it.

Marc Garreau: Okay, well, you can speak for Geth, so I'm assuming that means you're ready.

Lightclient (Matt Garnett): Yeah, we're not quite ready for a DevNet, but definitely next week can be ready.

Marc Garreau: Okay, great. Nethermind.

Daniil Ankushin: Nethermind is ready for the DevNet. Should start now.

Marc Garreau: Well, I know ethrex is far down this path.

Iván | ethrex: Yes, we are ready for the Demnit.

Marc Garreau: Great. I see Besu here.

Justin Florentine: Base is not ready yet. We don't have a ETA yet.

Marc Garreau: Okay, does that, week timeline sound unreasonable or reasonable?

Justin Florentine: For us, it's unreasonable, but we certainly don't plan on holding everybody up.

Marc Garreau: Do we have any other client teams represented here? Okay, we will follow up with them async. Well, I wanted to give, each client team space to… to raise anything they'd like. In the agenda, Daniil from Nethermind, included for… PRs here, maybe 5? Would you like to cover some of these topics now?

Daniil Ankushin: Yeah, sure, nothing major, from here, so, we put, some tiny changes into the spec. So we put the whole, Frame Family 81, 41, 82, 50, and 8272 into, one shared list of opcodes and modes, so, We, we got some, mismatches here, before, and yeah. This, this is supposed to make, across client testing faster. Also, we, we run, Frozen DevNet fixtures, version 01.0, inside SCI, so, it passes. And also, we, added a, test in the… Execution spec, for the… to cover the, kass accounting bug, on the Button Roll, Rehil path, so, yeah, that's on, the spec side. We also have some, work done on,

our research, site on, max verified gas. So, the thing is that currently we have, verification prefix, max verified gas, limit, 100K, And, we measured a real, privacy pool withdrawal, so, it's proof, checks alone needs, about 216, kg gas, so more than a double. So yeah, it's, current limit is not enough. And yeah, we… we need to perform, some benchmarks, some research, how far we can, Increase the limit. And yeah, this is one of the, important work we, we're currently focused on. Yeah, that's, that's speed from my side.

Marc Garreau: Great, thank you. Do you need support from anyone there? Whether it be PR reviews or something else.

Daniil Ankushin: Yeah, just, if you have any chances to review PRs in specs from Agenda. That's it.

Marc Garreau: Okay, everyone, you can find those links. in the, PM issue. Matt, did you want to mention 8250 in chat?

Lightclient (Matt Garnett): Yeah, one of the things that I've been looking into a little bit is if it's possible for the changes related to 8250 recent roots, if those could, you know, be treated as You know, out of-protocol, Like, basically out of-protocol rules in the transaction pool, the same way that we do with the expiry frame. The main reason is… In my perspective, changing the protocol, changing the envelope of the transaction is… Always. a much, you know, more difficult task, something that lives forever, it's something that we have to maintain, it's something that we can get very wrong and cause issues with consensus. So, if things can be done outside the protocol, that's almost always my preference. And with Recent Roots, as we looked into it more during, like, our conversations for the tiering for Hegota, we just kept coming to this question, like, why does this have to be…

Oh, sorry, yeah, 8272. We just kept coming to this question, like, why does this need to be in a transaction envelope? It doesn't feel like there's anything that's particularly special about the recent roots. The special aspect of it is just that we're basically allowing the, you know, the users to read these roots. In the public mempool. And this, to me, is exactly what the canonical frames are for. So I don't know if anybody has thought of this at all, or if they, you know, some… is there any initial pushback on this idea, or, like, reasons why it's not… it's not possible to, you know. Keep this as an out-of-protocol assumption in the transaction pool.

Marc Garreau: Chris, give you a thumbs up. Did you want to add to that, Chris?

Chris Hunter: I think, whenever I get time, I can just go… I think… thinking the same way on some things here, for sure. Alright. Yeah, I can kind of go through that whenever I speak, but I think it's a good direction to consider.

Toni Wahrstätter: Yeah, I think one of the initial motivations was definitely gas costs. I'm not sure if, removing it from the transaction object would change something there.

Lightclient (Matt Garnett): Why… why is the gas cost so big of a concern?

Toni Wahrstätter: Of course, it should be cheap. Like, the cheaper the better. Like, what you just proposed is you still have the root statically available in the transaction, right? It's just, like… Or where would you move it? From the Transaction Object to?

Lightclient (Matt Garnett): It would basically be in a frame to the recent roots contract, very similar to how it's proposed. It's just that instead of having the recent root list as an outer list on the transaction object, it's just the call data. to the recent Roots contract. And so you can statically reason about how the recent root Contract executes. If you want. Or you can simply just execute it and determine if that, verify Frame passes or not.

Toni Wahrstätter: Right. Yeah, I think this is fine, as long as the root stays statically available.

Lightclient (Matt Garnett): Yeah.

Toni Wahrstätter: Because otherwise, you could have, like, a reorg. And if you don't have the root, you could… you wouldn't know if a transaction is actually, still, proving against the correct root on the right chain. But since the root stays statically available, it should be fine.

Lightclient (Matt Garnett): Okay. Yeah, I mean, nothing necessarily changes about 8141 for this, nothing necessarily changes about 8272 for this. Right now, like, we're still in the process of choosing the Eaps for Hegota. This is kind of my current perspective. So, feel free to take some time offline and think more about it, and if there is a good reason that it should continue to exist in the envelope, then… I'm happy to change my… my preference. Tomorrow.

soispoke: Hi, yeah, I'm sorry, I just joined, but, I think the validation gas I wanted to talk about, Was that if you don't have it in the envelope. it needs to somehow become a gas that's part of the verify frame gas you would use. And, you know, if you have, like, 16 roots, it actually ends up costing quite a lot, like, 40,000 gas. So that's one reason we would want to sort of, like, keep it in the envelope.

Lightclient (Matt Garnett): Why would you have 16 roots?

soispoke: Like, the EIP defines this as, like, max, you know, max 16 roots, per SLAD. Like, if you have, like, 16 different privacy dApps that want to update, like, their roots, then you could have 16 roots. And in that case, that will actually become, you know, quite expensive. to have this, as part of the verify gas, and we… we do want to sort of, yeah, make it as low as possible so we can allow private transactions in the public webpool. So there's a bit of a tension there.

Lightclient (Matt Garnett): The privacy pools update their recent root in the verify param?

soispoke: I mean, if you don't… if it's not part of the envelope, I think it… That gas cost has to be taken into account in the… In… in the verified.

Lightclient (Matt Garnett): I just thought that… well, I thought that the privacy protocols themselves, whenever you would use the privacy protocol, it would update… it would call the recent roots contract and send an update. Whereas in the verify frame, all you're doing is checking that this, like. piece of call data matches a root that's in the ring buffer.

soispoke: Right.

Lightclient (Matt Garnett): It can't write to storage in the verify frame, typically.

soispoke: Yeah, I need to think a bit more about this, but or, like, double-check, and we can maybe take it offline, but I think last time I… last time I… looked, the sort of, like, frame solution for recent roots instead of in the envelope, like, costs a bit more, I guess, in the very first frame. I can just, like, double…

Lightclient (Matt Garnett): Yeah. Okay.

Toni Wahrstätter: Yeah, and just to add, if it becomes a problem that we waste too much gas in the verify frame for recent root-related tasks, then we can also just exempt it from counting against this limit, because the limit is anyway only for the mempool. So, we could just say, okay, it's very deterministic what is going to happen, and we just extend it.

soispoke: Yeah, that's fair. Maybe another question related to this, and I don't want to take the whole call, but, like, should it still be, like, an EIP, though? Like, I mean, the sort of, like, where we want to have these recent roots changes, if we wanted to have, like, a… if we don't want it to have it in the transaction envelope, but I think, like, it would be still nice to define it and… And have a spec for it, So is that still sort of, like, the common shared sentiment, or not?

Lightclient (Matt Garnett): I think an EIP makes sense. As long as it's, you know, clear that it's… if we do go down this path of not updating the envelope, it's just clear that this is, A rule for the public transaction pool, and not the change of the protocol.

soispoke: Okay. Yeah, that makes sense.

Lightclient (Matt Garnett): Anyways, we don't have to necessarily make a decision on this today, I just wanted to, raise it for people to start thinking a bit about this. I'm sure that when we talk about the Hegota features, it will be something that also comes up.

Marc Garreau: Yeah, that felt like a good use of time. The only other thing on my radar in this, client, team updates bullet point was, ivan, ethrex, did you want to… Chat about your… DevNet or TestNet?

Iván | ethrex: Yeah, sure. Thank you. A couple of updates before the BNs stuff. this week, we are currently passing all the Hive tests, I think the hybrands for e-consuming ones are stalled since August 26. Maybe it would be a good idea to look at that. We're also working on writing more execution spec tests. We'll be pushing them between this week The next one? And regarding the testnet? M… We've announced two. We did a soft announcement of the AHEGOTA devnet. last week on the AA Mafia Telegram group. I know this is not an open group, so… For those who… who are not there. I share the links here in the chat.

An hour… an hour ago, I also announced a public Frame Transactions Testnet. It is permission for other clients to… to join. If you want to join, ask us for deposit tokens. we didn't want to wait, for the expand ops, DevNet, so we are hosting One. But we will plan to maintain it until the official one is launched. Mmm… So, yeah, the Frame Transaction Testnet is currently The implementation is up-to-date with the latest spec tests, so clients that are That want to join. They just need to pass all the tests, and… And ask for us for… For deposit tokens, then the interrupt should be… should be tested before adding the client.

And the Hegota one is closed. It's ethrex only, for now at least, and it has initial implementations for several EIPs that are built on top of frames. also a proof of concept of native UTXOs.

Marc Garreau: Amazing, thank you. Does anybody have any follow-up questions for Ivan? Okay. Last call for… Client team updates, and then we'll… we'll change gears. Gone once? Gone twice. Okay. So the rest of this time is set aside for, talking about proposals, where, where the collab has, has gotten so far, or any… whether it be, new ideas were, or new EIPs entirely were floated, or just tweaking of, 8141. I know Chris had some thoughts he wanted to share. Do you want to kick us off?

Chris Hunter: Sure, sounds good. Yeah, so, Frame Team and, 8130 Team have been, chatting, so yeah, thank you for being, you know, just for all the brainstorming and, being receptive to all that. I will share my screen here and just go through a few things I've kind of thought about over the last, few days. I'll just share this first here. Okay. So, I think… like, foundationally, this is what I've touched on before, which is just, Ultimately, like, 8130 and 8141 are, providing a different authority, model. to accounts. And I do think that, like. we can get to a transaction type that supports both of these. And I guess, like, I just want to go through, like, some of the thinking,

of, you know, why we ended on these two different authority models as well, and I think, like. underlying, both these things is, like, L1 may have you know, a difference of, you know, be it opinion or requirements on, like, how much, they are willing to absorb into the protocol, versus L2 maybe, is okay absorbing a little bit more to provide a, you know, an experience that we want to provide as well. So I think there's a little bit of, like, you know, we are different. Things, even though we want to be using the same thing, ultimately, but… So this is kind of, like, from last week with, the Ethereum today. Obviously, Right now, like, smart accounts don't have any way to reach protocol visible authority, so they can't approve their own transactions.

With 8141, we get this new approve opcode, which basically the protocol can see. And then 8130 with Keystore is just basically, generalizing the mapping. I could share the Excalibral after, I think that… sorry, this is, it has some other stuff elsewhere, it's quite a big Excalibral, so I'll have to cut it just to the thing I share here. But, I can share that after, for sure. So yeah, with 8130, you know, we come from today, and we just add this, like, the key store, which is now allowing you to update the, authority mapping. So it's a general meant to be, you know, a general system that can express, any authority, being, like, any number of external authorities. You could express yourself as an authority, but it has these defined interfaces, to do so.

And I put, like, our desired architecture for, which is just, like, the externally owned account, because that's what gives us, some of the properties that we want, and also, other chains, like, I guess you could say need. So, coming back to, like, you know, where things… like, ultimately, I think there's, you know, there's varying levels of… what we… what we can agree on, and, like, thinking about this as I was trying to do, kind of make updates to the transaction type, which I'll get into right after this, but I just want to make sure, like, you know, where we have to agree is, like, right now we have these two different, authority models, with Keystore being…

a, you know, a defined interface that requires, yeah, basically wallets to use that interface to update that authority mapping, versus 8141, which is… The code itself is the, authority. And… Basically. Like today, 8130 chains, they have, you know, you can update, again, to any type of authority mapping you want, that's how it works. With 8141, right now, it has, you know, code as the authority, and then in 7851, I don't know if I got that EIP right, but basically that's, like, the, I will, remove my, K1 key and just specify code only as the authority. I'm not sure if that should be in Hegota as well, or if that's, like, a later thing, but basically, like, what I want to make sure is, like, absolutely true is, basically, like, there's no one-way doors, and…

you know, L2 could… even… we can express any authority, but it's like, we just want to make sure, like. You know, at the end of the day, we don't, do something that, basically, we should be able to express any authority mapping Including one that is opcode-based, and, like. going… stepping through all that, I'm confident that we can. It does look something like 7851. Might need a modification or two, but basically we just want to, like, have it such that you know. in the future, if you want to have a, key store be your mapping, sorry, your authority, you could switch to it. If you want to have code be your authority, you could switch to it as well.

Okay, so I can jump into… Right, so… And with all that said, like, we can't agree on an envelope if the verify step is capable of expressing both these models well, which is, like, the externally owned account and the account code model. And this is just me playing around, so, like, it might have ended on not the ideal state, but it could have ended on something that's okay. I think there's a few things to, like, play around with here, but basically, like, take the 8130 transaction, the 8141 transaction. And really try to just, like, generalize it as much as possible. And then these are kind of the principles, that I leaned on. Again, this is not like, you know, hey, let's absolutely do this. I think it's just an interesting, line of thinking. But basically, you know, we lean, like, contract slash precompile.

we, like, no flags for, things, ideally. I think Frame Modes is very powerful, because that is a, a general way to, you know, modify, what kind of call you're actually doing. Ideally no op codes, I think, you know, unless needed, contract defined, maximally general. So these are, like, just, you know, taking the existing verify frame and trying to make it work for both. So we're in mode verify, we are sending to a, so this is the sender address. This is how you specify, like, auth in 8130. Instead of value, I just put, like, selector, because we need a way that, basically… basically, the goal with these two verify frames is to make it such that wallets don't even need to know

What chain, what the chain is using, if they were using an 8130 account. And basically, like, this selector, could be, you know, just unused on the Verify chain, if you're using the 8130 account. Not saying this is the best approach, I think there's actually probably a better way to, like, generalize the frame, sorry, the verify frame, but… With this and these, like, other principles, these are just, like, some example, basically, like, again, you know, I stripped non-soft, and, like, hearing Matt say all these things about Recent Roots, definitely, like, aligned with, what I was thinking, so, like, just, you know, a sponsor, USD send. you know, so I had this require frame, you know, you could maybe argue, like, oh, you could do that with a…

default frame or whatever, but I think… There is some, benefits to it, but, basically, like. You could have the, you know, require… again, they have… this is already kind of in 8141 with this expiry. But you could also have, like, nonce rights, be a require frame. Again, we have our verify frame that we kind of went over, and then… what is this one? Oh, yeah. There's this, you know, again, meaning precompile, like, if you wanted to ensure there was a payer. A specific payer for a transaction, and, like, you could always do it that way. This is just kind of, you know, a way of thinking, not meant to be like, hey, let's do this, but just to, like, you know, kickstart some additional discussion on,

How a, you know, a maximally general, like, more contract-defined way of doing things might work. And then, what's this… what's interesting about this one? Right, we have this, like, A precompile. Again, you know, if you want to communicate to the protocol, you should do it through precompiles. Maybe this is the new 7702 delegation, and the, you know, the question is, like, what's administrative, like, what, you know, an admin should be able to do this. Like, in 8130, we could tell, like, oh, this is an admin, that signed this transaction. But, 8141, you know, there's a question of, you know. just doing an execute call on a precompile is probably not sufficient unless we do some, you know, an additional layer. Maybe we call back into the account that verifies something or whatever. But again, just, you know, directionally a line of thinking here. And this comes back to, like, this rotate authority 7851.

Which is just, like, you know, would it be good to have a, precompile that does some sort of rotation here of authority. Yep. So yeah, just sharing these ideas, not meant to be, anything. Yeah, I see some questions coming down the side here. We can't remove nods. I guess you could… right, so the thinking here was, like. For these require frames, like. You know, you could write the protocol to say, like, hey, there's… you require a non-screen. I think also what's interesting is, like. You know, we have non-CIS transactions in 8130, you could make like, maybe, you know, maybe this is a mode, if it's just, like, replay protection or something, and you need one of those. I don't know, it's just kind of the idea of, like, I think

There's actually more flexibility, we could extract from The underlying Frame model, and just… this is just kind of a pathway of trying to lean into that. Yeah, I guess that's… that's all I have to share. I can, you know, try to get this into a… a single XGal draw to share, but yeah, that's all from me right now. Selector. Right, so Selector is really… So if you think about how these… how these work, like, on an 8130 transaction. In the, sender auth. this is how it's encoded, authenticator data. We already know, like, iAuthenticator is an interface, so we already know the, function selector being iAuthenticator, which takes a… the other data there. And then, on this side, we are calling a wallet, wallet code.

Or account code, and we need to know the selector to call that's actually going to run the approve Oh, I stopped sharing my screen, did I? Okay, sorry, yeah. So, yeah. On 8130, Senderoff has authenticator data. We know the authenticator interface, so we don't need selector. Maybe this is… yeah. On 8141 chain, the selector value, we need to know what, you know, method to call on the wallet such that it runs its, approved flow. I don't love, obviously, like, you know. selector unused. I think there's probably a better way to, like. generalize this. It's just kind of, like, line of thinking that if we can make this verify step, like. You know, invisible, then… Or, sorry, the difference in the verify step, kind of, like, behind the scenes, and I think it's,

Isn't the first 4 bytes of Frame.data the selector? Yes. Right, so, like, that's what I'm separating, you know, this used to be value, but then, if that's the case, value zero. And then we have data being different between the two. Right? Whereas, like, on this side, for an 8130 chain, we already know this is kind of like the, you know, intrinsic Di authenticator. whatever that thing is. Like, that's kind of, like, what's actually going on, so you can't actually select the interface for authenticators to find Does that make sense?

Lightclient (Matt Garnett): I'm still not following, I think.

Derek Chiang: -

Chris Hunter: Right.

Derek Chiang: No, go, go ahead.

Chris Hunter: So, yeah, the flow on 8130, send her off, equals, authenticator. data, right? And this authenticator is what's, the address of the authenticator we want. We send the data and the hash to it. The interface on the authenticator is already defined. And I'm just trying to make it so these two verify frames are… look identical. But if we don't have this selector in a separate place, then data… like, the wallet needs to know oh, this is an 8141 chain, I need to put the wallet, you know, function that actually does the approved flow. So, it's just the difference between these two. Trying to keep these the same, yeah. But right now, they're not the same, so the idea, you know, the first idea was, well, I'll just rip out the selector.

Now data looks the same for both of them, if you're an 8130 wallet, and, you know, we need the selector somewhere for the 8141 chain, so…

Lightclient (Matt Garnett): But on the 8141 chain, you would actually execute the sender. Whereas on the…

Chris Hunter: break, yeah, correct.

Lightclient (Matt Garnett): key store chain, you wouldn't. So isn't that the difference? Like, why do you need a selector to also tell the difference?

Chris Hunter: I'm just trying to keep the data field the same here.

Lightclient (Matt Garnett): Yeah, but, like, it's a data-fuel, this is the same across chains. In this example, what goes wrong?

Chris Hunter: Nothing. Brother.

Lightclient (Matt Garnett): Yeah, you had the selector, so then what does the selector do if nothing goes wrong?

Chris Hunter: So, if we… if we don't pull the selector out, this is just from a wallet perspective, it then has to know I need to prepend the, wallet selector on an 8141.

Derek Chiang: Can I ask a question that may be dumb, you know, but why couldn't you just, like, include the selector in the data, and then on the 8130 chain, you just ignore the selector? Wouldn't that be the same thing?

Chris Hunter: Same thing, yep. And, you know, maybe a better idea. It just, yeah. As long as you, like, you know, get that you need to… there is that difference there, because we have a defined interface versus an undefined one, then… Yeah, we're, you know, we're having the right conversation, I guess.

Derek Chiang: Right, so, so just to maybe say it again, to make sure I understand, so basically the proposal is something like. right, like, either we put the selector out, or we just, like, have the selector in the data, but then on the 8130 chain, we just ignore the selector. But then in any case, on the 8130 chain, if you see the verified frame, you would just, essentially assume that… So, so essentially, you don't actually execute the sender code, right? Like, you would just call the, key store… like, like, you would just treat it as if it's… You know, a direct call to the keystore, essentially, right?

Chris Hunter: Right, yeah, to the, like, authenticator that the keystore then manages everything. But yeah, this is this kind of, yeah, the line of thinking that, like, you know, ultimately. if you're running one of these wallets, then this kind of… this is just one way of, you know, doing things. If we kind of… agree that we… we do want different, models here, and we also have the… it's not a, you know, not a one-way door. User could, use kind of any authority that they want. I think that's kind of, like, all… all those boxes are checked, and then it's kind of like. Well, you know, this seems very, expressible and extensible. Also, like, I think… just, just, like, some side comments that I mentioned before as well. It's like, I don't think necessarily, like, L2s need these, you know, blobgas fields, like, should we push that to a precompile? And…

Yeah, just kind of, you know, like, that's just kind of the direction I went here of, like, can we push everything to be, like, more contract-based? Yeah.

Lightclient (Matt Garnett): Why do you want things to be so contract-based?

Chris Hunter: Ultimately, I think that's, like, a way that won't need… like, you know, the address space is infinite, and we can always, well, not infinite, obviously, infinite for, you know, our purposes, but, like, we can always add more features that way over, kind of, envelope changes, I think.

Lightclient (Matt Garnett): Sure, but I think that there's, like, other… I mean, I feel like you also mentioned in cases around, like, the TX context precompile that you have with 8130, saying, like, okay, it's nice that this is a contract, but, like, we have the ability to make these native features opcodes, and opcodes are… More easy to reason about and use as a contract. I don't really understand, like, why you place this, like, premium on, you know, the contract in that sense. Like, there are definitely, like, nice times to use it, but I think that there's also, like, generally a lot of good times to use opcodes, and we have the ability to do that.

Chris Hunter: Yeah, I think that's a fair take. I think… I've said before, like, you know. that the… it's beneficial to, you know, like, even just from a gas perspective, not… not having to precompile in some cases. But, Yeah, it feels like, you know, contracts, like precompile us can be, you know, more extensible and don't require kind of continuously updating things. But I think there's a place for them, like, I kind of lean… I was… it's more of, you know, a direction of leaning, like, ideally no new opcodes, but, like, I think there is times where, you want them.

Derek Chiang: Sorry, Chris, do you mind explaining the AA precompile again? You know, I didn't quite get that part either.

Chris Hunter: Yeah, this is just me, thinking, like, you know, if… Again, kind of lean precompile, like, if you want to do certain things, lean away.

Lightclient (Matt Garnett): from…

Chris Hunter: you know, op codes everywhere. You kind of execute a… call, versus, like, you know, having a 7702 delegation. We can, like, have a… delegation path on the… on if we could block.

Derek Chiang: Oh, so the precompile can do 7702 delegation? Like you said, so, I guess, what other things were you envisioning that you can do other than 7702 delegation?

Chris Hunter: Yeah, I mean, these two, I think I just had, like, you know, again, going back to the 7851 thing of, like, do we want to be able to modify, you know, switch your authority there? I think, you know, this is just kind of a way, like. don't, don't, think this is, you know, rock solid, like, this is what we should do here. But just, you know, a exploration of things. You could use this, It's just, like, yeah, you precompile to, like, do, kind of, account abstraction things, once, maybe the old transaction types were gone.

Derek Chiang: Got it. But is the approving the transaction happening through the A precompile, or is that not happening through that?

Chris Hunter: We're still using this verify mode here, to keep things, that way, but you could imagine the AI precompile exposes, like, you know, some sort of approved function that you're calling as well.

Derek Chiang: So the benefit of the A precompile is mostly just to not have to, basically change the transaction envelope. So, for example, like, if you want to do a 772 delegation, you don't have to kind of, like, include the delegation inside the Frame's envelope, but rather you can just do it through a frame. Is that kind of the motivation?

Chris Hunter: And then, yeah, and then individual frames can be, you know, charged whatever gas you want, for them. They can be considered, like, you know, a native step.

Lightclient (Matt Garnett): This was just…

Chris Hunter: So, non-color, yeah.

Derek Chiang: Yeah, that seems interesting, for sure. You know, I think that actually sounds very similar to… there was, like, previously a proposal, forgetting what it was called, I think it was proposed by the… the other client team, like, the… anyways, I'll… if I can find it later, you know, but… but yeah, you know, I think that generally sounds interesting.

Lightclient (Matt Garnett): No.

Derek Chiang: Oh yeah, like, I think Erigon used to propose, like, a proposal that looks kind of like that.

Marc Garreau: There was one more question from Matt. I don't know if you want to raise it here. How do clients feel about removing the signature list and instead having a frame mode signature?

Lightclient (Matt Garnett): Yeah, this was one of the other things that I was wanting to raise at the end of the call, and Chris kind of also pointed at it in the diagrams, but something that I've been thinking a little bit about is Do we need this signature list on the outer part of the transaction? Originally, the rationale in my mind for having this on the outside of the transaction was I felt that signatures were a bit of a special… primitive that kind of existed outside of the execution of the transaction. Like, the transaction really wasn't concerned with the, you know, actual verification of the signature. All that the transaction cares about is the result of those computations.

And also those signatures might be used in different places throughout the transaction. So it felt a little weird to require it to be included multiple times, you know, inside of a frame doing something else. Also, there was a pretty strong push from Dano about having the signatures on the outside of the transaction object, so that it was easier to strip out the transaction data in the future when we do aggregation. So, for those reasons, we kind of went down this signature list on the outside of the transaction object. I think that it's very possible to do it inside the transaction object. And to treat things more like, addresses. the main… the main issue I've run into, which I'm curious, like, what other people think about, is that…

Right now, one benefit of the signature list being on the outside is that for every transaction. the ID which you specify the signature scheme you're using is just one byte. Unless you're using an arbitrary signature, which would then be the address. This ends up being, like, a pretty… Big amount of data to have every single transaction include. Sure, we can have precompiles which have tons of leading zeros. And we won't put quite as much data over the wire, but at the end of the day, this is still a lot of RLP, this is a lot of JSON that has to be handled. And it feels quite wasteful. I wish that there was a better way to do this. I don't think it is a good idea for us to have a special address encoding scheme just for the signature frames. That feels…

Like, another wrong approach? But I don't know if anyone has thought more about… This idea at all. Luca is asking if it's similar to 8288, Yeah, if you haven't seen, this is kind of the… this idea that Vitalik had around having a stark, verification of the EVM execution in the frame. To me, like, I think that we should be planning for signature aggregation without the assumption that there's any kind of, like, EVM, you know, stark proof. like… This technology is obviously… Improving rapidly? But… bringing that into the core protocol is going to be a very big challenge, and I think signature aggregation is something that we understand much more deeply, and something that's much more likely to land in the near future.

I also think that, like, for post-quantum, we really can't gamble on… you know, assuming that ZK EVM will exist, that we can ship into the Layer 1 protocol to do this signature aggregation. I think that, like, in the farther future, it's… You know, a very good, possibility. Very likely possibility, especially for the types of signatures that we don't necessarily understand. I think that's, like, a good place for it. But for this type of signatures that we do understand, that we, you know, very likely will be aggregating when we start introducing, I suppose, quantum, crypto. We need 8288 for PQ private transactions. Yeah, I mean, we need this for PQ private transactions, and when this technology is ready,

like, obviously, we're all happy to implement it, but I think that you know, waiting, expecting that ZK EVMs are going to be ready in time for signature aggregation, which we absolutely need. Just to keep everyday user funds safe, I think is, It's not a gamble that I would want to make. And I would rather that we make sure that you know, supporting post-quantum. Crypto, you know, in a non-private case, is also going to be possible. So the Stark-based aggregation that people are mostly looking into right now is this LeanVM project. I can share it.

Mo Jahanara: Yeah, I mean, but you kind of mentioned that we should, think beyond that for aggregation and not wait for that. I'm asking whether the… are you aware of any scheme that… Does the aggregation, but doesn't rely on a stock prover.

Lightclient (Matt Garnett): I'm not sure what you mean.

Mo Jahanara: Like, for instance, if we don't want to wait for, 8 to, 8-8, or anything similar to that, and still think about aggregation of the proofs. a specific.

Lightclient (Matt Garnett): But it's not the… it's not about the Stark prover, it's about the ZK EVM. like, the LeanVM is a very simple VM for aggregating signatures, like, it's basically purpose-built and focused on just aggregating those signatures. I think that adding the EVM on top of that and, like, allowing to compress general compute into a Stark is… You know, general EVM compute into a stark is a much more challenging Problem.

Marc Garreau: I'd like to zoom out a little bit here. We've got 6 minutes to the top of the hour. And we… Get a dedicated… Place for this conversation to continue? If that's a thread, and… R&D. Or… Another location, what do you think? Yeah, I'll just make the general request then. If we can find a home for the, I think that zooms all the way back out to the top-level question, how do clients feel about removing the signature list? And having a frame mode signature. So that was one thread to pull on. We've got 5 minutes left here, so,

I'll just say floor's open for, For suggestions of good next steps from here. Chris introduced… A variety of ideas, so if somebody feels, drawn to any of those in particular, this would be a good opportunity to say, I would like to continue to play with this, this sort of idea, if somebody's got another Good next step in mind. Please voice it here as well. I will also ask a question back to Chris. Do you need, are you reaching a place where you feel comfortable making any specific proposal, potentially back into 8141? Do you need more time to… to chew on it?

Chris Hunter: Yeah, no, like, updates. I think the, like, ultimately, I think the kind of confirmation that, you know, 8130 isn't a one-way door and would work, on L1 as well, is, you know, reassuring in that sense. And then also, yeah, happy just to continue to try to contribute to, 8141, with good or bad ideas. I don't know if they're good or bad yet, but, continue working, there. So, no kind of new updates, but, Yeah, that's the line of thinking right now.

Marc Garreau: Okay, we've got 3 minutes till the end here, so if there's any, final ideas folks want to raise. Or action steps, this is the time. Otherwise, again, this call is gonna run weekly, for now. So we'll have, more opportunities to… to Tratton. Dig further. Yes, Mo, jump in. This is the time.

Mo Jahanara: Thank you. So, I mean, this is the first time I'm joining the call. So, this might be already answered, but me and a few others are looking into, compatibility of Frame Transactions for privacy protocols, and one thing that seems very obvious is 100K is going to be Too low of a cap. And, I mean, I've been trying to come up with reasons. and analysis. For what would be the maximum possible cap? I was wondering if… the 100K is just a heuristic, or if there is, like, a document, or, like… A place that any of you guys would recommend to look into? And if there is possibility to raise that maybe 3X, or something like that.

Before finalizing the EIP.

Marc Garreau: Toni?

Toni Wahrstätter: Yeah, it's a good question, and I want to get exactly the same, so for a ZK verification, for example, you need much more than 100K, and it feels like we will just start with 100K as a very conservative Limit, and then… you can still increase it, like, the protocol doesn't have any limits, this is only for the mempool, and over time, I would just expect this limit to increase.

Mo Jahanara: Yeah, I mean, the context more specifically is some people are thinking about building an… outright billing an alternative mempool, or, I don't know, basically alternative… alternative public infrastructure to facilitate perm transactions being used for privacy applications from day one. with the idea that if we don't do it, we are just encouraging, I don't know, centralized services and private members to take over this flow of transactions, and after that, it would be very hard to replace it. Which I… which I think is a legitimate concern. So, given that, I'm wondering, I'm wondering if you guys are open to, or if anybody shares the same sentiment that we should consider increasing the limit further, even on the first day of launch, so that we don't lose users of the public member?

I understand that 100K is a conservative starting point, but given that the number is in the EIP, and it requires further EIPs to adjust, and we would push that probably, I don't know, 9 months, 12 months to the future, realistically. I wonder whether… for instance, Toni, you think it's possible to consider a higher number right now, and if it's worth, you know, having, I don't know. a working group, or a presentation, or I just share my notes. To get some feedback about, higher numbers.

Marc Garreau: We're at time here, so I'll suggest we continue this async. Daniil, do you want to get the last word in? And then, Matt, I see you're ready to.

Daniil Ankushin: Yeah, I just wanted to say that at the very beginning of this call, I mentioned that Nethermind works on the benchmarks to identify this safe limit, for, for verification. And yeah, just wanted to mention that.

Marc Garreau: Cool. Matt, did you want to close this out?

Lightclient (Matt Garnett): Yeah, I just wanted to also say quickly for Mo that the 100K is kind of the stop right now for something that we are almost certain is totally safe in the public moon pool, and once we have the dev notes running, we will experiment with higher numbers. So, I think the people are indexing a little too heavily on the number that exists right now. It's not that we don't want to have a higher limit, we just want to start with what is safe and move up As we can improve the handling of the transaction pool. I feel like it's likely that we can increase more, because, to me. these are… yeah, I mean, this is just, like, standard, you know, optimizations that need to be made in the transaction pool, and the EVM is usually quite efficient.

So… Yeah, I think that we'll find something, something good there. Anyways, yes. Thanks, everybody. I will talk to the DevOps team, and we'll see if we can try and schedule a, DevNet Zero for Frames next week sometime. In the meantime… Yeah, let's keep talking about some of the ideas that Chris posted. I would love for people to think about the signature list to see, yeah, if it makes sense to move into the frame object somehow, and think a bit about the, you know, data implications of doing so. And, yeah, otherwise, let's keep chatting in 8141 channel on the R&D Discord. Thank you, Mark, for… Moderating the call again, and I'll see you guys on Thursday.

Marc Garreau: Thanks, Matt. See everybody next time.

Lightclient (Matt Garnett): Cheers.

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