Frame Transaction Breakout #7

Transcript

Mario Vega: Hello.

Lightclient (Matt Garnett): Hello, hello?

Marc Garreau: Hey everyone, we'll get started in, like, 2 minutes.

Justin Florentine: Good morning, Frame Transactors!

Marc Garreau: Alright, we've got representation from 3 client teams, EEST and Pandas here, so I think we're good to kick off. Welcome, everybody, to Frame Transaction Breakout Number 7. Today is October the 20th, 2026. I'll drop the agenda. In the chat. And we've got the usual template for an agenda today. Let's jump straight into… how devnets are going, and then we'll take a look forward at, upcoming devnet planning. Then we'll tackle the rest of the agenda. There's not a lot there, so I think we got time to dig into, specific PRs that are open, and some other proposals that people want to prioritize. So, would one of the pandas like to… give us an update on how current devnets are going, or have gone.

Stefan Starflinger: Yeah, I can do the quick update. So, we launched bogota-devnet-1. It's been running pretty well so far, but we've also not been stressing it too much. We've been finding a few bugs in our tooling. As well, or I would say, trying to improve it for, Frame transactions, a little bit, and also noticing that they're… are still quite a lot of issues with the RPCs. Of clients, so it's not that easy to interact and get all of the information that we need for frames. From all of the clients so far. But otherwise, we've been spamming some basic Frame transactions, on the network, not too many, but, yeah. That's kind of where we are with bogota-devnet-1.

Marc Garreau: Matt asks, have we run spec tests on the network?

Stefan Starflinger: I haven't run any spec tests directly on the network. But I can, do that.

Marc Garreau: We have time if, do you want to describe any of the… updates to Panda tooling to support this? Is that… Worth thinking folks aware of?

Stefan Starflinger: It's mostly, just right now looking into spamoor, so it's been… Having trouble, keeping a consistent throughput on Frame transactions. And that's just something, that I've been looking into, and just getting, kind of, the receipts from clients for the Frame transactions. as well. they have not been consistent across the clients. I think it's also something where the… spec for the, APIs are not, quite… finished and merged yet, so that's something we should, I think, prioritize.

Marc Garreau: Would anybody like to react to that?

Stefan Starflinger: I mean, I can give, like, an example. For example, for Frame transactions, there was an issue that, the, spec for the execution, or for the RPCs, it said, nonce instead of nonce sequence for Frame Transaction, so we should kind of decide if we want to, for frames, reuse nonce as the field. or nonce sequence, across the board. I saw a lot of clients were using nonce for Frame transactions, but not, nonce sequence, and that was kind of an inconsistency.

Lightclient (Matt Garnett): Sorry, was that just on, like, regular getters for the Frame Transaction? Like… Get Transaction by hash, or… Was that for submitting things? Yeah. Okay. Okay, yeah, it's kind of been on my to-do list to work through these RPC… PRs, but I have not gotten to them.

Marc Garreau: So we have two votes for nonce, as opposed to nonce sequences. Do we have, enough consensus here to make a good decision on that now? Thumbs up from Daniil. I'll move on as well. So that's the 3… that's at least 3 clients, Sorry, Justin, Besu was represented here, too. Do you have an opinion?

Justin Florentine: I'm still chewing on it. The only reason that I haven't expressed an opinion is that there, you know, there's a new way versus legacy way that might be important to capture in the nomenclature, but I don't have a strong, cogent opinion on it, so we're gonna abstain for the moment.

Marc Garreau: Okay, this, I'll suggest, is a good… Like, fast follow item, if we can, resolve that. Quickly, sometime after the call. So whenever you get a chance to form an opinion there. Okay, so… JSON RPC headaches described, are there any other… Action items we could… Sort of address here and now?

Stefan Starflinger: I don't think there's much more from my side.

pk910: I might have one thing, from the RPC side, we have a lot of… or the receipts are pretty much covered, but none of the clients have implemented tracing APIs yet. And especially the Explorer uses, call traces to analyze what… or to show what the actual frames do later on. So it would be great if we could think about the tracing API.

Marc Garreau: Have any clients taken a stab at that yet? I'm gonna assume… no. Okay, that could be another fast follow, then, if nobody's got anything to add to that conversation here. Okay. Let's call on any points people would like to raise about, ongoing or past devnets. Otherwise we can switch gears to… Looking ahead to the next one.

Alright, I guess we'll move on. I'm… not up to date. What is the latest thinking on, this, like, the scoping discussion that needs to be had for the upcoming devnet.

Stefan Starflinger: I think that's, scheduled for next ACDT. I think Spencer raised a point on if we should have, combined, Network next, for the next one. I'm not… quite, I think, aligned that we should merge the networks that quickly. But yeah, I think it's… it's a point to discuss if we want to do another Bogota devnet, or if we want to do a Hegota devnet.

Lightclient (Matt Garnett): I mean, if we're still discussing if we want to do a combined devnet, maybe we should just have a bogota-devnet-2 next week, because I think there are some cute things that we could… Roll out.

Marc Garreau: Yeah, I was gonna suggest… Maybe we come back to the discussion about combining devnets, because we've got some decisions to make for, whatever the next iteration is on the EL side. for example, the couple of PRs that Matt's got up, and I'm sure that's not all there is to decide on. Does it make sense to pivot to those now?

Stefan Starflinger: Yeah, I would agree with having another bogota-devnet-2.

Marc Garreau: Okay, so that's our working theory for now. And then we'll circle back after we discuss that. The… So the rest of the agenda is… is just open to discussing these open threads. Which… PRs or proposals are most important that we discuss? Like, what needs to get tackled In the next release. So we've got, Matt, you've got the max fee PR, there's some… there's another signature length… PR, what do you want to tackle?

Lightclient (Matt Garnett): I think we can start with this max fee PR, but yeah, I think there's 3 main PRs that I want to see. In the next devnet. The third one, I don't think I've posted, because it's, it's not a Frame Transaction PR, but there's a couple of changes to 7906. that I've proposed, and it looks like… They're both approved, and the second one, I just need to fix some merge conflicts. Yeah, anyway, so max fee… I kind of forget where we left off on this. I think we started talking about it two weeks ago? And there was some conversation. And we didn't feel that… It had… I kind of settled in everyone's mind enough to… to go ahead with in the bogota-devnet-1.

Marc Garreau: Yeah, as of a couple weeks ago, Anders said he got a chance to review and or collaborate on it, and he gave a thumbs up, and then, the rest of the participants hadn't had a chance to look closely at it yet.

Lightclient (Matt Garnett): So I guess, has anyone had a chance to look at it more closely, and is there new feedback? I saw Daniil left a comment here, which I think is… a good point that I'd… Didn't really consider. Regarding the, you know, banning of fee-access opcodes… And the relationship with… Reading the max fee now. So, there's definitely that thread, which we can talk about, but I don't know if anybody else has reviewed the PR and has feedback on it.

Marc Garreau: If not, I would suggest using this time to… Walk through it, at least at a, like, give everybody a head start on the reviewing of it, and then they'll at least have a chance to… Ask any immediate questions that form.

Lightclient (Matt Garnett): Sure. So I guess I could just kind of give a quick summary again of… like, what the idea here with max fee is. It comes originally from the EIP7999. Which is this… Multidimensional fee-market EIP. Which I sent in the chat. And… essentially, we're trying to simplify the UX around You know, constructing transactions, and having users reason about how much a transaction can cost. So… We're starting to… Find ourselves in this, like, multi-dimensional world, where we've got the blob dimension, we have the normal execution gas dimension, and we have the state gas dimension.

Obviously, the blobgas dimension is, you know. it's framed a little bit differently than state and execution gas. You don't have the priority fee, it's not really, like, one-to-one, with how we handle the fee-market on execution in states, but… Like, for all intents and purposes, from a user's perspective, we can consider this just a third dimension. So the idea with… the update in 8141, where we add max fee, is that we want to take this concept of using max fee as, like, the aggregate cost. a fee. Over all of the dimensions. And charging the user for that amount. Obviously, like, that's… You know, pretty different than how we treat the gas payments now, like today, obviously, we… calculates the user's…

You know, total cost of their transaction based on summing together some, you know. Product of the fee they're willing to pay times the gas that You know, the gas limits that they've… Kind of already included in their transaction. So… So I'm just trying to read this last part of the EIP to… See what else needs to get covered. Yeah, so I think, basically, that part probably makes… good sense, I think we're all sort of on board with… supporting the kind of unification of the costs here, and it boils down to… a bit to, like, Anders' presentation a few weeks ago about how do we actually want to interpret The differences between… You know, these dimensions.

So if we're doing this… this max fee idea, you know, his… he had, like, a few questions about how do we actually… You know, kind of implement the… the logic for… potentially taking gas from one dimension and applying it to another, because if you're describing how much you want to pay in a single number. You… May not be able to, you know, describe, like, what the max limit is you want to pay for each individual dimension. So, like, we have the gas limits per dimension, and the question is, do we want to… Have those gas limits be rigid? In the sense that, you know, if my execution gas limit has been reached, would I still have, like, a lot of max fee left to potentially pay for a transaction?

do I say the transaction's out of gas, or do I, like, reach into another bucket to continue the transaction? You know, kind of in pursuit of this… easier UX, better ability to reason about the transaction. And I think that's kind of, like, where we… Left off on it with Anders' presentation. I looked into it a bit after the presentation, and… from… yeah, I think from my perspective, this… This idea of taking gas from one bucket and using it in the other bucket, I don't like. it's very similar to, like, how we treat the state gas, you know, in Glamsterdam today. And I think that it's kind of a messy way of handling the gas accounting, and…

Generally, I prefer to have, like, strict bounds on how much gas is getting used. So, I think, like, my preferred approach is kind of, like, what's… I think what's specified in the EIP now… Which is that whenever your dimension is consumed, that's kind of the… The end of, you know, the consumption for that dimension. Tomorrow.

soispoke: Yeah, I think maybe zooming out a bit, I'm, yeah, I wasn't there in the last presentation, but, like, it… how much of this does it, like, it feels like 7999 is, like, such a complex sort of, like, EIP. And I'm wondering whether it needs to be… I don't know, like, just shipping it as a PR, within frames. seems a bit dangerous, just because of the… I think it deserves a lot of, like, sort of, like, scrutiny and… And there are gonna be, like, a lot of complexities, I think, involved with EIPs like 7999, so I'm wondering If you've thought about this, or, like, how do you… how do you think about this?

Lightclient (Matt Garnett): Yeah, I mean, this is kind of also my fear, which I've mentioned to Anders. Like… On the surface, it's a great idea. And I think it is definitely… I mean, basically, when we presented it two weeks ago, I think most people were in favor of the concept, you know, including Chris from Base. I don't see on the call. But, you know, from my perspective, the question is, is, like, how can we… know that this isn't going to introduce complexities to the protocol? How do we know that this is not going to introduce unexpected behavior on the margins? And I don't have a good answer for that. And I think that, really, the only answer that we

You know, the only way that we can get to an answer is by implementing it, and… You know, trying to work with it. And so it's part of the reason why I'm, like, fairly pro-supporting this, is that… You know, the change to the Frame Transaction isn't that significant. You know, we're changing the fields a little bit, and we're changing some of the, like. The logic around handling gas. you know, handling the fees for gas, but other than that, it's not… it's not something that we can un… that we can't undo in the future. You know, if we find a couple devnets that this just isn't really working, or we learned something that wasn't so obvious when we were looking at the PR, then I think it's, like, quite easy to…

to undo. Whereas, like, not all changes to… the transaction, object that I z10 do. So, I think for that reason, I feel, like, more positive on try to make this work, because people, like, broadly support this idea and concept, and the details will… You know, often only… come out, when we actually work with it. And to be fair, like, Anders, you know, I've talked to Anders. Is in deep support of these ideas, and he doesn't believe that they're That there's, like, complexity that we don't understand or know about. So, it's not like we… Don't have anyone who's been thinking deeply enough about it.

soispoke: Yeah, I mean, that makes sense, it just… like, historically, it feels like, sort of, like, multi-dimensional EIPs have been… Hard to ship… Specifically because there are, like, a lot of, sort of, like, hidden complexities and extremely, like, multiple ways to do it. And for me, it almost feels like another EIP, you know, like, that should be actually, sort of, like, discussed. Like, I'm a bit worried about just, like, going with it, trying to sort of, like, make it work. Without, sort of, like, the scrutiny it probably deserves, because it might turn into, like, an absolute, like, sort of, like. rabbit hole of complexities and nuances, I don't know. I feel like multi-dimensional fee pricing has been there for, like, you know, 5 years or something, and people are still very scared, so yeah, that just makes me a bit worried, but…

Lightclient (Matt Garnett): I mean, I think one… One other difference, which, you know, a lot of the previous multidimensional proposals had that is different in this PR, is that we aren't introducing more base fees. So in that sense, like, we're not… Creating that, like, true multi-dimensional market where the base fees can move in different ways, and maybe we have different, you know, long-running Goals for what… what, you know, how much that resource should be consuming for the network. And this is really just more of an accounting technique about how do we charge users for gas. in a, you know, in a way that we already have. Like, we already have execution gas, we already have state creation gas, and so the question is, like, do we account for that individually? Is, like, you know, have them submitting their priority fees per dimension, submitting their, like, max fees per dimension, or do we, like, create this, like, more aggregate

number. And so, that's kind of, like, why I'm more positive on it, is that, to me, it's much more of an accounting technique that's future compatible with other multidimensional schemes, rather than, like, bringing the whole multidimensional gas problem into the EIP. Justin?

Justin Florentine: So… I think, okay, I'm just kind of parting with your last thought there, because I think that actually resonates. I think that, yeah, maybe there's an opportunity here that we're seeing that we can take to improve on this. I have always preferred 7999 over, like, things like 8037, and 8037 was not nearly as simple as we thought it was gonna be, right? So I do think that this could be another case of us trying to sort of dip our toe in additional multidimensionality without going full-on into it. The idea that this is just an accounting change… I think… I think that's a good point, but it's also… it's also a little insufficient, and I can't decide whether or not the fact that we're not introducing new base fees is a feature or a bug, right? Like…

The partial nature of this is giving me a lot of pause from a design perspective. So, I just wanted to air that out there. So, for example, like, bandwidth. There's a resource that we don't actually do any tracking for, right? You know, what happens when we decide, oh, we need a bandwidth dimension for gas? Can we extend this accountability mechanism to include that? Maybe. Does it belong in frames? I don't think so. Like, I would rather see this accountability stuff pulled out. And, you know, us actually grapple with 7999. That being said, I don't want to make this sound like I'm against the idea, because I do see this as a good opportunity here as well to improve

the multi-dimensionality of it. Like, putting a new frame transaction mechanism in here kind of warrants it, at the risk of just, you know, expanding complexity.

Marc Garreau: a meta comment here, and just acknowledging we're about halfway through our time here today. How important is it, do you think, that we come to a decision on this, prior to the next devnet?

Lightclient (Matt Garnett): I think it's a good time. Like, we're still a little early, it seems, on this, like, integrated FOCIL frames. Devnets. So, it feels like this next devnet is, like, a really good opportunity to… Or… start working on it. It also gives us an opportunity to sit with it, and then maybe discuss it in… Mumbai a bit, in person. So, I would… Yeah, I would be pretty positive on… on, adding this to devnet 2. if… yeah, I mean, if anyone is still, like, kind of opposed to it. like, let me know, we can keep discussing, but I think of people, I, like, generally… Supportive, or maybe want to… want to read more on it, then I would say lean towards…

Us spending the next 2 days or so… Yeah, getting the EIP, or getting the PR ready to merge to the EIP. And then… maybe on AllCoreDevs, I can just check again and see if anyone is… has opposition. And then we can just proactively merge it and see what happens.

Marc Garreau: Go ahead, Justin, first.

Justin Florentine: Just real quick, I think I do oppose this, but I am looking at the PR change, and this is a net improvement as far as simplification goes, so… I don't even know that opposing that would make me… like, opposing the idea underneath this would make me oppose the PR specifically, which might complicate your job on ACDE.

Lightclient (Matt Garnett): Yeah, so if you are opposed in one part, and also supportive, does that cancel out?

Justin Florentine: I think because… I'm mostly kidding. I know you're mostly kidding, but, like, it's a question of complexity, right? Like… And I see this as a net gain for complexity. Sorry, a net improvement.

Lightclient (Matt Garnett): Red.

Justin Florentine: It reduces the complexity, it makes it simpler to reason about, so I think I would be for this PR. But I think the broader discussion is warranted. And I think this illustrates why we should keep this stuff into 7999, like, the conclusion here is, well, none of this should have been in there in the first place, but I don't know that that's realistic.

Marc Garreau: I think it might be useful to get a temp check on the rest of the clients as well. ethrex for Nethermind, would you also like to… Wayne, your current thoughts after today's discussion? See, Ivan just made a comment. I like the idea of giving it a try, implementing it, seeing how it goes, and decide then if we keep it or postpone it. Toni's asking a clarifying question. Is it only state versus execution gas? And blobs, says Matt. Marc from Nethermind same would be happy to include it.

Lightclient (Matt Garnett): Didn't they?

Marc Garreau: Melissa, you unmute if you want to jump in.

Lightclient (Matt Garnett): Yeah, I mean, there's still this question by Daniil on the PR, which I need to think about a bit, Because, like, we do need access to some of these values. We need to decide if this value is something that's going to be accessed in the verify frame, but I need to think through, like, the sponsoring flow to see how that would actually work. So, obviously, that's some… that's a prerequisite before we even get to discussing merging. So, I think that… yeah, okay. People sound like they kind of want to give it a try, maybe Besu is opposed. What I would say is, let's spend the next two days, I'll… think through this some more, I'll work on this PR, try to answer this question that Daniil raised, and then on ACDE…

I will mention it, and we can see. So, Justin, if you have a chance to sit with it a bit longer over the next couple days, that would be great.

Justin Florentine: Yeah, I think… in doing that, one of the things I would consider, and maybe you can just cut me off right here if this is a fruitless path of thought, but, like, what would 8141 look like if it didn't address gas accounting at all? Like, is that a thing that you could refactor out of the EIP? In general, and then punt it to 7999.

Lightclient (Matt Garnett): I mean… I really don't like the 8037 state gas reservoir. And I feel like the Frame Transaction is the right… Place to address that? Because if we don't… Included in the Frame Transaction object that we won't have the… You know, actual lever to let people specify how much state gas they want to… to use. So, I… yeah, I think that we have to include some… new gas accounting logic, unless people, like, want to just, like, reinforce this 8037 reservoir in the Frame Transaction.

Justin Florentine: I want to reinforce 7999. Which… So I want to consider, like, just excising all of the gas accounting from 8141.

Lightclient (Matt Garnett): Was 7999 proposed for Hegota? That's one question I'm wondering.

Justin Florentine: I think it was…

Lightclient (Matt Garnett): I mean, look, like, if you want to make the argument For 7999, or have somebody else do it. I'm happy to listen, and I'm interested. it's not… yeah, it's not really my area that I feel… that comfortable… You know, championing. Like, I would much rather that, like, you know, Anders, for instance, is… Working with us to… figure out what that integration looks like. And I've worked with them a little bit on this PR for similar reasons. So, I think if you want to go all the way here, I would… either work with Anders, or just, like, go yourself and, like, try to make a PR to frames. And show us what it would look like if…

You know, 8141, and 7999 were… basically merged.

Justin Florentine: See, that's the thing, is I don't actually want to merge them. I think they are warranted to be separate entities. Right?

Lightclient (Matt Garnett): I mean, the problem is that… I mean, this is the problem with, like, a lot of these, like, frame… you know. you know, auxiliary frame EIPs is that if you're changing the actual frame transaction object. It's a little bit weird to separate them. And, like, we separated them in the beginning because… They were separate ideas that we needed to pursue independently. And, you know, same with 7999. But at the end of the day, like, we need to integrate it, and, you know, we need to build those EIPs on top of frames, because the Frame's transaction object has to express the concepts, whether it's, like, the multiple numbers of, you know, multiple base fees, or if it's the multiple limits, or the single max fee, like, all of this stuff has to exist in the Frame transaction. And because 7999 wasn't included in Hegota, and I think we need to do something, I would say, like, just make a PR to frames.

To show what it would look like.

Justin Florentine: Okay. Alright, I… I think that's.

Lightclient (Matt Garnett): Because at least then we can use a delta between, like, what the max fee PR is right now, and what, like, full 7999 would look like, and we could decide, you know, how much more complicated is it to do the whole thing? is the whole… is the max fee PR that we have today… Is that going to be compatible with how… 7999 actually is gonna look on frames. Like, these are things that I just don't know yet. My hunch is yes, the max fee is compatible, and it's more of, like. Layering in more new accounting, layering new base fees, but… I could miss something.

Justin Florentine: Alright, let me think about it. I think the way that this might end up looking is that I propose a PR to 8141 that removes this, and instead of Depending on 7999 to pick up the slack. We just have status quo, which is 8037.

Lightclient (Matt Garnett): I mean, I don't think that we should rely on just 8037 for frames.

Justin Florentine: Okay.

Lightclient (Matt Garnett): I think that 8037 is a hacked to make state gas in a one-dimensional transaction object. And… It's a great technique. That was backwards compatible, but there's just, like, really no reason if we're introducing a new transaction object to not expose the state gas. field.

Justin Florentine: Okay. I feel like I'm hogging up a lot of time here. We'll keep talking.

Lightclient (Matt Garnett): Yeah, I think we've probably reached the max amount of discussion on this topic. I feel like I don't have… Yeah, I don't feel like I have a lot more additional content to say on. I need to, go back and try and answer this question that Daniil listed and, rebase this PR. But let's keep going. So I've got two other PRs we could discuss quickly. The second one, also on the agenda, I'll paste here. I think this one's fairly straightforward, so unless someone is gonna raise, objection here, I'll probably go ahead and merge it. So… Several months ago, a user on ETH Magicians raised this, and it's been in the back of my mind, and I think now is just, you know, the best time to actually solve it.

It's basically kind of an attack against users who are getting their Frame Transaction relayed onto the chain. Basically, the way that… The way that we charge for signature data, Most of the signatures, we understand, they're fixed size, we can charge for them, you can't, you know, include more bytes or include less bytes, and so, it's really, like, a non-issue. But when we introduced the arbitrary, signature object. in this, the, signature list. That introduced this, you know, concept of having A dynamically sized amount of, of… signature data-related, you know, signature data that's in the signature list. And when you have the arbitrary amount of signature data, you need to charge proportionally for how much of this, like, you know, overall transaction call data you're using. So, we added the formula to charge the user based on that,

on the arbitrary signature data. The problem is that That signature data is not always included in the signature… the canonical signature hash. Or, is it… Yeah, so it's not included in the canonical signature hash, so it's malleable. And if the signature data is malleable, then that means that, anyone who's relaying that transaction can… Strip the signature data off, which is usually not a problem, because if you strip the signature data off, generally, like, the transaction's not going to be valid, or parts of the transaction will fail. But if they add information to that signature data, like, imagine they pad the signature data with, like, you know, a kilobyte of call data, then that could get charged for the user.

And the user obviously is not intending on, you know, having this, like, maliciously padded data. So the idea with this PR is that we're going to bound these arbitrary signature objects by actually hashing into the canonical signature hash the length And so this way, we don't need to… You know, we don't need to worry about the cost potentially blowing up for a user. It's still possible, just like it is today, where, you know, a relayer can change the signature and cause the validity to change. But now, like, if somebody does this, then the worst that can happen is that the validity has changed. And that's kind of, like, the trade-off you have to make whenever you are using the canonical… you know, whenever you're getting elided from the canonical signature hash.

you have… you're accepting some… some amount of malleability. But we are bounding it, the… the potential, like, cost ramifications of it. So, I think that this is, like, a pretty critical update. Unless somebody is opposed to this change, I'll probably just merge it after the call, and… We'll include it on the next devnet.

Marc Garreau: Any questions, or would anybody like to push back?

Lightclient (Matt Garnett): Okay. One more PR… This one is on, 7906. So, I didn't post this to the agenda, but it's probably used for people to know, potentially discuss. So… it looks like Alex did approve this, but… I'm also open to feedback here. One thing I've kind of been looking at on the 7906 EIP for a while is just thinking about how many different fields there are. You know, in, in these… Three operations that were being introduced. So… Yeah, basically, you know, it's only 3 opcodes, TXTRACE, TXDIFF, and the EVENTDATACOPY. And the TXTRACE, to me, is kind of like the original… idea, the original concept of, like, how to do assertions, how to, kind of introspect what happened in the transaction. And so, to me, like, TXTRACE was…

You know, is obviously, like, the critical part of it, and that gives you the ability to iterate through all the changes that happen in the transaction. TXDIFF was introduced… And basically, the TXDIFF kind of gives you the ability to… directly query certain… You know, the changes that happen at a certain address or a certain storage slot. And in the… in, you know, pursuit of simplicity. it felt like, to me, that TXDIFF was not absolutely required. There were some parts of it that… I think, like, couldn't really be replicated with TXTRACE, which in this PR I tried to add back. Things like, you know, knowing if the nonce has changed. What the nonce change values were.

But in general, like, to me, that… the opcodes seemed like an optimization. And I am kind of proposing in this PR that we… basically remove the TXDIFF opcode, and try to just rely on this TXTRACE. it's possible there are use cases that I'm missing where you would really want TXDIFF. But overall, I… yeah, it feels like TXTRACE… Kind of… solves that. Alex, do you wanna… Sure, thoughts.

Alex Forshtat: Yeah, so one, like, use case that, like, I had in mind for TXDIFF is, like, looking actually at the pre-state of a transaction. So, for example, when it's kind of useful is if you are, for example, doing a clear signing. So, there is a problem there where the intention of a transaction depends on the implementation slot. Of a proxy contract address you're interacting with. So, to kind of prevent, like, being front-run by an upgrade of a proxy or things like that, you could, like, make a requirement that, when you send a transaction, the pre-state implementation slot of this contract was thumped in a given. So, it's kind of this category of use cases where you actually care about the state of the slot before the transaction.

where, like, TXDIFF actually shines, and also, in a particular, like, use case, if you want to check, like, one balance change. And in Transaction, it made a lot of state changes, it is an optimization, but, like, we would have to, like, traverse all the, like, TXTRACE to discover the changes. Which is possible, just maybe not very optimal, depending on the transaction size and the number of changes that happen. Yeah, that was the idea for the TXDIFF.

Lightclient (Matt Garnett): So, the proxy example you gave, can you not use the slot before value on the proxy to determine if. What the value of the start of the transaction was?

Alex Forshtat: If I remember correctly, I might be thinking, like, if it did not change Would… it… it would not be visible? If I remember correctly, through the TXTRACE, right? So, like, you would be able to say if… Like, what the implementation slot of a contract you're interacting with.

Lightclient (Matt Garnett): It would be front-run by a different transaction.

Alex Forshtat: Yeah. If it was transformed by a different transaction.

Lightclient (Matt Garnett): ZCC.

Alex Forshtat: unmodified, so that was one of the modules. motivations for a separate TXDIFF opcode, whether it's, like, Fourthly part of, like, post-transaction assertions, it's… It's an open question. Right.

Lightclient (Matt Garnett): Okay, that's a… that's a fair point. I was only thinking inside this transaction. Okay, let me think about this some more. I'm not going to… I won't rebase this so that it will automatically merge. Until we talk about it a little bit more. I think that is one use case that… is not represented. With just TXTRACE. Because you're trying to determine, like, what the state of the slot is. You know, with respect to maybe being front-run on the proxy, so that's a good point. Okay, let me think about this some more, and we'll kind of, like, table that one. Oh, interesting.

Alex Forshtat: on.

Justin Florentine: Yeah.

Alex Forshtat: Okay, thank you. Waiting for feedback.

Marc Garreau: Yeah. Justin, did you want to jump in?

Justin Florentine: I was just lamenting that Matt's wishes have been defeated by the ETH Bot that has just, merged this PR.

Lightclient (Matt Garnett): Either way, I think I'll think about this some more. I mean, I think this is, like, a very narrow use case that we can… Figure out a good solution for. I mean, at the end of the day, this is also something that you can… Implement as a frame. Like, you can… Yeah, let me think about it a bit. Like, you can check what the storage slot of the proxy is that you're calling…

Justin Florentine: With a procedure.

Lightclient (Matt Garnett): I don't know.

Justin Florentine: Yeah.

Lightclient (Matt Garnett): I mean, yeah, it's not great, though.

Justin Florentine: Because then that shows up in the trace, as… You know what I mean? Like…

Lightclient (Matt Garnett): Yeah.

Justin Florentine: It's not being classified as pre-state.

Lightclient (Matt Garnett): Right.

Marc Garreau: Okay, we've got 10 minutes to the end of the call, Does it make sense to go any deeper on… this discussion, or any others. If not, I was gonna recap expectations for the next devnet.

Lightclient (Matt Garnett): I think it would be good to let Justin present his ideas. But if you want to quickly just say the devnet expectations, we can do that for the last 10 minutes.

Marc Garreau: Sure, So I just wanted to make sure everybody was clear about the scope of a next devnet, assuming it, remains EL-focused. there, I haven't heard the introduction of any new EIPs. We've just discussed these three, PRs into existing EIPs in the devnet. Is that the case? Is… is… does that match everybody's expectation of what would appear on the next devnet?

Lightclient (Matt Garnett): I think some people are trying to propose…

Marc Garreau: So, sorry.

Lightclient (Matt Garnett): But from…

Marc Garreau: Yeah, Spencer had proposed some, so let's make sure we, get on the same page there. Spencer, did you wanna, list those out.

Spencer Taylor-Brown: Yeah, I mean, I guess these are the five, I think we would have liked to have agreed on… on ACDT for a hegota-devnet-1, so that would be the devnet after merging, but if… there is time… to, I guess, add the EL-specific EIPs earlier. To me, it makes sense. I think, There's 5 here, maybe that's a lot unoptimistic. The deactivate self-destruct. Reduces the test space for us earlier. SETCODEFROM has already mentioned the, bump nonce of zero-nonce accounts, in, in our opinion. It's good for us to add that earlier, because in order to test it properly, it requires fork transitions. The more devnets, the more fork transitions, and then the two-floor EIPs lets us test benchmarking earlier in the process. This is a lot, and also.

Yeah, I do like pushing to move things faster, but… I do feel like… I don't know if we're going against process by doing this, maybe, maybe it should be agreed on an ACDT But I guess just touching upon this in the call isn't harmful? I'm not sure.

Lightclient (Matt Garnett): Yeah, I think, from my perspective, I… Obviously, I think that doing, SETCODEFROM and 8151 is, like, pretty important. you know, the question of the process, like, yeah, we should probably talk about an ACD or ACDT, but I do think those are, like, pretty critical parts of our, like, PQ… Transition, proposal. But I will also say that we still have quite a bit of outstanding work on what we already have, like, we haven't really settled on the RPC formats yet, we still haven't settled on the tracing formats yet. And so… If we're adding more EIPs, then it also reduces our ability to settle in on those. So, balancing that would be… would be good.

Spencer Taylor-Brown: I'm happy to add as many as you guys. Want to add, to be honest, so… Yeah.

Marc Garreau: Okay, so it seems like EEST is not the… or the specs team, not the bottleneck here.

Lightclient (Matt Garnett): I mean, let's talk about this on ACD this week. Since we've got one and two days, that could give us a couple days to think a little bit about what we want to happen. On this next devnet, and then also give us time to ship this devnet later next week, before everyone flies to Mumbai.

Marc Garreau: Cool. Can we make, let's say, like, a reasonable sort of commitment we can make, to client teams want to, bring a… basically a list of what they're comfortable including on the next devnet? to Thursday's call.

Lightclient (Matt Garnett): Sure.

Marc Garreau: Okay. Thumbs up around. Great. We've got 5 minutes remaining, how do you want to use it? Is there any final items? We want to make sure, get introduced.

Lightclient (Matt Garnett): Yeah, I think Justin had some things he wanted to mention.

Marc Garreau: Got a hand from Thomas as well. Justin, do you want to go first?

Justin Florentine: I assume you're talking about Justin Zen, not Justin Florentine?

Lightclient (Matt Garnett): Yes.

Justin Zen: Here are the audios.

Lightclient (Matt Garnett): Pretty bad. Justin?

Marc Garreau: No audio from you now, Justin, do you want to try again? Oh, sorry for unreliable internet. We can jump to Thomas and give you a chance to try again.

soispoke: Yeah, it's very quick, but I also mentioned this in the chat, I think it would be really cool to be able to test, you know, having sort of, like, multiple concurrent transactions, per sender, because there are, like, some… there are some, like, mempool subtleties to get right, so if that could be included, I think it would be actually quite useful to get a view of Hey, is that sort of, like, working out? And we can, you know, design attacks and try to break it to see if it holds.

Marc Garreau: We can add that to the list of, client considerations for what they want to bring Thursday. Justin, did you want to try one more time?

Justin Zen: Yeah, can you hear me?

Marc Garreau: That's better, yeah.

Justin Zen: Can you hear me?

Marc Garreau: Yes, you're coming through better now.

Justin Zen: Oh yes, thank you. So, we like to, like, separate verify frame into two frames. Like, the first one is the non-state frame, and the second one is the stateful frame. And the purpose for that is, like, we could do heavy computation in the non-state frame, like, verify the signature. Do Stefan to read the state, like, like, to check if the recover address is correct. It could save Sequencer from doing the same verification again. If those dates change.

Marc Garreau: Oops, we lost… oh, no. Matt, are you still with us?

Lightclient (Matt Garnett): Yeah.

Marc Garreau: Oh, there you go. Was that clear? Did you, have any immediate thoughts? Or questions?

Lightclient (Matt Garnett): Yeah, I mean, my immediate thought is… I am… Trying to understand what the main difference of this is versus the signature list. That we have. Because basically, like, the signature list, you have a similar concept. I mean, for one, like, any signature that's identified by the protocol is, you know. Verified statelessly outside of the execution of frames. For the arbitrary… Signature schemes, then… You know, it does require some sort of, like, allow list of, like, what signature schemes your sequencer is able to, like, reason about and remember. Because you kind of, like, use the frame destination to figure out. You know, is that going to be a stateless computation? But to me, that, like, solves the same problem that you're doing, and the only cost is that you don't have, like, total permissionless around the stateless

schemes, which, from a performance perspective, I think is fine, because, you know, 99% of your cryptography will be… problem. You know, known, known addresses.

Marc Garreau: We're at time here, so I will suggest we wrap this up and continue async. Justin, I'll give you a chance. Did you want to make any quick reply? Sure, okay, async is good. Okay, let's, wrap here then. Client teams, you have homework for Thursday to bring, basically what you're comfortable including in the next devnet. And… I will follow up with any other, action items there. Thank you, everybody, for joining. Appreciate your participation in the discussion. See you on Thursday.

Lightclient (Matt Garnett): Thanks.

Justin Florentine: Thanks, all.

soispoke: Thanks.

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