Frame Transaction Breakout #6

Transcript

Lightclient (Matt Garnett): Hello.

Marc Garreau: Hey, everyone.

Daniil Ankushin: Hello guys.

Marc Garreau: We'll get started in a couple minutes. Pasta.

Guruprasad Kamath: the.

Marc Garreau: From now.

Okay, we can kick this thing off. It might be a smaller meeting today. Also, thanks to… A successful deployment of Glamsterdam to Sepolia. Congrats, everybody, for that. Today is, October the 6th, 2026. Welcome to Frame Transaction Breakout number 6. We can get… I'll post the agenda again, but… we've got sort of the usual template for today. So, first is an opportunity for any, spec changes or test release announcements. I don't think that's the case, since we've just kicked off, frames devnet zero, so maybe we'll first Speak to how that's going. And then we'll tackle the rest of the agenda from there. I think, Barnabas is the only panda we've got in the room with us. Are you able to…

Tell us how frames devnet zero is going. Or might that be a Stefan concern?

Barnabas Busa: Looking at it, it looks 100% to me, so… All good?

Marc Garreau: Awesome.

Barnabas Busa: Excuse me.

Marc Garreau: Thanks. Would any of you, has any other… Client team has been… Watching the network, would you like to comment on how that's going? Are we doing anything interesting on that network yet, or keeping it pretty vanilla?

Barnabas Busa: So we have a spammer instance up that is sending frame transactions. I don't think you're sending that many. and check. Sending about 10 pairs, each block. So if you check on Dora, you can see that we have about 10 transactions every single block, and each of those transactions are FrameType transactions.

Marc Garreau: Okay, cool. Sounds like no news is good news, then. In that regard. Is… is there anything… Further, that we want to get out of Frame's devnet zero. Or are we content just to… Let this run.

Barnabas Busa: I think we can just let this run until, people are comfortable to move on to… Like, I'm not sure how… How feature-proof frames are on this effort.

Marc Garreau: Okay.

Barnabas Busa: in different client races. Otherwise, I would propose to increase the scope already. with a couple of more EIPs in the future, upcoming devnet.

Marc Garreau: Right, so that's the next. conversation on the agenda. The one question I'll pose first is, are there any other client teams that are approaching readiness to join, DevNet Zero? And, would adding more features now, throw a wrench in your plans? I'm not sure what sort of client representation we have here. It might just be Geth and Nethermind on the call, am I wrong?

Barnabas Busa: I honestly don't think we should be waiting on Klein. clients to implement the DefNetZero scope. If we have 3 stable clients, then that's good enough to move on to the next scope increase, and just keep pushing forward. And then once we have the merged data, then we can wait a bit more. For client implementations, but we shouldn't… Hold the Netherlands back, just because we don't have enough, donuts.

Marc Garreau: Sure.

Barnabas Busa: Yeah. Matt's saying, I think they're just pushing. So let's maybe dial down, like, what scope increase we want in the future, definitely.

Marc Garreau: Yeah, sounds good. So we'll move on to that, that next conversation. I've gotten… Notes from… ethrex… And Nethermind both advocating for adding 8250 and 8272 to DevNet 1. Matt also suggested considering 7906. So… Let's start with 8250 and 8272. Are there any… Hesitations, any concerns about Or any objections to adding those to devnet one?

Lightclient (Matt Garnett): It's not an objection, but I really don't like 8250 from a like protocol design perspective. I haven't come up with really, like, a great alternative solution. Like, I understand why we are adding a precompile that keeps track of nonces for users, but to me, it… It's very ugly, and… Also, like, when we change the tree structure in the future. You know, what, how are we going to migrate that? Are we going to migrate it? Is it going to continue just living in this contract? I just don't know all the implications of Making this decision? Running with that decision and then how it could impact us in the future. You know, with other things that we want to do.

Marc Garreau: Simone?

soispoke: Yeah. Is like what you don't like is that it's part of the transaction envelope or?

Lightclient (Matt Garnett): Because, like…

soispoke: But what…

Lightclient (Matt Garnett): I don't like that it's a precompile. Like, we're now kind of combining… the user states. With. the, you know, Important validation state for the You know, for the user.

soispoke: Yeah, so right now we would live in a system contract. I think the plan would be, you know, when we move to PBT, it would be to move it to… A branch, that is like dedicated to kid mantis. And we've already talked to, like, Carlos and Maria about sort of, like, how that migration would go. And. You know, based on, like, past usage, but also, like, projections, like, it doesn't feel like it's, it will be, like, a ton of, work to actually migrate this, so… Yeah, they have thought through it. I don't think there is, like, a better alternative, at least I haven't really seen any. Umm. And yeah, I don't know. It feels like you know it's been implemented by by ethrex and Nethermind already, and they haven't found like major issues.

Lightclient (Matt Garnett): I mean, you can implement lots of things that aren't great. That's not really, A point to me that… Means that this is a good thing to do. The alternative.

soispoke: mean.

Lightclient (Matt Garnett): Wait for PBT. And to do it right. I'm not saying that we need to do that, but this is like why I felt very on the edge about this EIP from the beginning. Like, this is not the right solution, this is the hacky solution to make it work for this fork.

soispoke: No, I mean, the solution is like the one you need if you want like multiple transactions per sender. Like the, the, like where it lives, whether it's like in a system contract or like in a specific PVT branch is different, but like the solution is not going to change. It's like you, you need.

Lightclient (Matt Garnett): I mean, there's two different solutions. I'm not talking about like. Needing the 2D nonce, like we do need 2D nonce, the question is like, how do you implement it? And I think that like, is a hacky implementation. And we probably need to do it because there's not really an alternative, because the only alternatives that we have is to wait for PBT or, you know, some kind of a tree change, because our tree just does not support What we need to support. For the 2D knots.

soispoke: Yeah, exactly. But then, you know, it's it's also about like the sort of like endgame result of what you want. It's like if you want like private transactions in in Hegota, then you need to ship something with the tree we have, and you can sort of like condition. EIP.

Lightclient (Matt Garnett): He's an.

soispoke: Like user facing changes on future EIPs and tree changes, whether they happen or not. I feel like that's a bit of a risky approach as well.

Lightclient (Matt Garnett): I'm just saying that's the approach that we generally have taken in the past. Like, there's lots of things we've wanted to do that we just haven't been able to because we are kind of waiting for tree changes. So I.

soispoke: And but we can do it, right? Like it's it's yeah, yes, it's a system contract, and and people don't usually like system contracts that that I sort of like understand, but it's not that it's not like we don't have any way to do it at all. It's yeah, absolutely.

Lightclient (Matt Garnett): I mean, we always have a way to do stuff. Like, I'm not saying that we can't, that 8250 doesn't work. I'm saying it's hacky. Because they don't have.

soispoke: Both is the system contract.

Lightclient (Matt Garnett): I mean, it's using user state storage inside of a contract. For protocol invariant about whether or not the user's transaction is unique. That's not an ideal design. I'm not saying that we shouldn't do this. I'm just pointing out my concern why I don't necessarily like this EIP very much, but I think in general, most people support it, and so we should probably move forward with it. I wanted to raise this in case anyone else… in case anyone else agrees, or in case anyone else has an idea to improve it. I'm not gonna block it. But I just wanted to, like, be clear, like, this is something I'm not a fan of. And…

soispoke: Let's go.

Lightclient (Matt Garnett): The alternative is to not have private transactions in Hegota and wait for PBT, which doesn't seem like a great decision, but it's really the only alternative I think that we have.

soispoke: Yeah, I agree. I agree about the alternative. I mean, of course, like if someone sort of like comes up with like a better way to do this, then that would be great. But, And yes, a migration will be possible with with PBT. I've talked to Carlos and Maria about it, and it is possible. And probably wouldn't be like that much data anyways.

Lightclient (Matt Garnett): So yeah, I mean, unless anyone else has thoughts, I feel like we should just move forward with it. I'm happy to keep thinking if it can be improved, but, like, I have thought about it a bit in the past, and there's not a lot of other options. So, I think it's kind of the best, worst thing we can do right now.

Marc Garreau: Okay. It sounds like that's a good, place to wrap it up, given… That we believe there's a migration path when a tree change occurs. Up. Okay, so… 8250. And, 8272. Being, recent roots. I heard… No objections to including those two in… the next devnet I'll, pause there to make sure that's the case. Were there any comments on recent roots? Going once, going twice. Okay. It will be included then. The next question then becomes, do you also want to include 7906 in the next devnet?

Got a thumbs up from Daniil. It was suggested by Matt, so that's Guess and Nethermind accounted for. And again, I think that might be all of the clients we have represented here. Pandas in support?

Barnabas Busa: Having support in whatever clients can… Ship. Can we ship this in… a week? I would… I would prefer to have, Move fast than move slow in the beginning. So I would rather have fewer EIPs implemented faster than try to add, you know, 10 EIPs already for DevNet 1.

Marc Garreau: Right, so I'll open it up to the clients then. Guess, or Nethermind, what's the status of 7906 in your client?

Daniil Ankushin: Nethermind's implemented already.

Marc Garreau: Cool. Matt.

Lightclient (Matt Garnett): I have not implemented it, but I'm not worried about the implementation.

Marc Garreau: Okay, does that… One week. Horizon, seem reasonable?

Lightclient (Matt Garnett): Yeah, that's fine.

Marc Garreau: Okay, let's call it a plan, then. 3 new EIPs will be added to. frames devnet 1, that's, 7906. 8272, and 8250.

Barnabas Busa: Do we want anything else? 8253 was, proposed, and, 7979 from, Spencer from the steel team.

Marc Garreau: Spencer, did you want to make a case for those?

Spencer Taylor-Brown: I think in initially. Yes, I think, at least from my side. I'm usually quite optimistic and it's nice to like get EIPs in earlier than Then later, but I think… Would be happy to defer to add these, to… Future DevNet. I think it would be good to keep frames as simple as possible. And then when we merge with FOCIL and do the interop there, And. Hopefully there's going to be no issues, and then after that, add these smaller EIPs.

Marc Garreau: Okay, so I'm hearing, an advocation for keeping it at the… the… Just 3 new additions.

Spencer Taylor-Brown: I think with 7906, at least on our side. There'll be, like, a reasonable amount to test. And I think, yeah, we'll try and get released out, I guess, as soon as we can. But yeah, I guess what kind of timeline do people want to aim for, for… Just evident, I guess.

Marc Garreau: Barnabas is suggesting a week out. Is that something? That feels reasonable for the testing team. Spect team.

Spencer Taylor-Brown: From my side, yes. What do you think, Guru?

Guruprasad Kamath: Yeah, so I was about to say, I think we've been, working a little bit on the, 8250 and, 8272 already. 7906 is something we are a little bit behind on, I guess, so. So those two EIPs plus tests, we should be good, and 7906 is something we will push to… Get through during this week, and Hopefully by middle of next week, we should be good with all three of them.

Marc Garreau: Okay, Matt has just suggested we target, like, Thursday of next week. For the, the actual dev net. So does that give folks enough time?

Guruprasad Kamath: Yeah, that sounds… That sounds pretty good.

Marc Garreau: Cool. Anything else folks want to cover related to DevNets?

Barnabas Busa: I think we should try to aim to do a new devnet every two weeks. So, try to scope each event based on that. So, like, Frame 72 should be then scheduled for 3 weeks out, and And then we can start discussing, maybe next week already, what we… what new stuff we want to see in there. And then, two weeks after that, we should already focus on having the merged, devnet with FOCIL. I'm not sure if, we already want to… Yeah, 3 weeks from now is probably already a time when we might want to have the FOCIL Development Mission.

Marc Garreau: That was the next question for the agenda was the strategy for merging with FOCIL devnet. At one point, the goal was to do that before DEVCON. Don't know how optimistic that was or realistic, but how are we feeling these days?

Lightclient (Matt Garnett): I honestly haven't looked at into it a lot. So, I think, honestly, it depends, like, how ready FOCIL is. For us to integrate with. I think others have looked into it more, though.

Marc Harvey-Hill: Yeah, I started working a bit on some specs for it, But yeah, I think, excuse me, ethrex team also have been thinking about it as well, so I'm still kind of waiting for some feedback from them so we can actually, like, align on the details. But I think in terms of the implementation, it shouldn't be that. That big, but yeah, it's more about just how long it takes to align on those details.

Marc Garreau: There's time on the agenda for that conversation today. Is it helpful to talk through any of it now? This is broadly, like, the… The frames plus FOCIL strategy conversation.

Lightclient (Matt Garnett): Can we quickly just finish, or go back to the devnet 1? I just wanted to make sure people are okay with the changes I proposed, to 8141 as well. Because I also want like to do those for devnet one.

Marc Garreau: Yeah, sorry, I missed those.

Lightclient (Matt Garnett): It's all good.

Marc Garreau: So if you… go ahead, if you want to jump into that first.

Lightclient (Matt Garnett): Yeah. So, I mean, the first one I think is like very straightforward. I don't think anyone would be against it. Originally when I wrote the expiry verifier. With Toni, we… we just added it to the state at the fork block, because it was simple, and we didn't… Spend the time to actually write the implementation in SysAsm and like Get the… the vanity address miner going. And so now, we've kind of just gone back and done that work. So, I would propose that we move towards that. You know, and probably needs to do the same for… for, the… The keyed nonces. And any other contracts that we're relying on. At the fork block. But yeah, my my change is just for even for one right now.

I think that's probably okay with most people. Do the next deploy. Okay.

Marc Garreau: Thumbs up from Daniil.

Lightclient (Matt Garnett): Okay. So I'll merge that one after the call, and then the other is maybe a bigger question. So, two weeks ago, we had Anders on to present The max fee cost bounding ideas. Kind of inherited from EIP 7999. I have tried to integrate that into frames. the handling… Is maybe, like, very minorly different from 7999, but overall… Kind of the same. I felt like people were pretty positive on it. On the call last week, I'm not sure if people have had a chance to look at The exact implementation. Yet. And if people are… Feeling ready to make a decision on it, or if we need to spend some more time.

Marc Garreau: Daniil or Marc, have you had a chance to look at this yet?

Daniil Ankushin: No, I don't have a strong opinion from my side. Mark, do you have anything to say?

Marc Harvey-Hill: I haven't actually seen that, so I need to read it.

Lightclient (Matt Garnett): Okay. Doesn't sound like we should merge it for this next devnet I can leave it as draft, let people have a chance to review it some more. I do think this is a pretty pretty big change conceptually to how transactions work, even though the implementation is kind of straightforward. So I don't want to… I don't want to merge this before people sit with it. So, let's go with… Pulling expiry verifier with Nick's method and I'll hold off on bounding the cost with max fee until. devnet 2, or maybe if I go to devnet O, If we decide that makes sense.

Marc Garreau: That sounds reasonable to me. Okay, we got thumbs up. Okay, well, revisiting the agenda here before… Given anybody whiplash. We've covered spec changes, we talked about a test release to come next week, we've covered DevNets, 0 is running, the scope of 1 is determined. And then I've just got space for, Any client team updates, or… which we might have covered by this point? After that, we've got, just open space for new or existing proposal discussions, and that could include the FOCIL and Frames strategy chat, if… Folks want to have that today. So, before… Before we chat FOCIL, is there anything else

Somebody would like to touch on.

Daniil Ankushin: Yeah, maybe a couple of. words on, the next devnet. I'm not sure, I remember if I, yeah, I mentioned it on the last call, are we going to, change the, verification prefix, limit, for, for mempool? To test, like, different scenarios, complex scenarios, especially with, keyed nonces and recent roots. So, yeah, that's the first thing. And the second thing, I just wanted to mention that Nethermind, already partially implemented Matcha and merged it. And yeah, probably, to the next, call or, next DevNet, it's going to be fully, implemented. for Nethermind. So we're continuing working on that. Yeah, that's it.

Marc Garreau: Got an I'm fine with the higher limit from Matt. Does anybody else want to get into…

soispoke: And. Yeah, I think for the higher limit, I don't think, you know, it should be, like, a commitment to go to a higher limit or anything, but at least it helps a lot with the testing. You know, when you send, like, a bunch of, like, private transactions, and you sort of, like. Test the app and the wallet workflow, like, it's very useful to have these higher limits so you can actually sort of, like, get feedback. From real transactions, on the test.

Marc Garreau: Do we need to elect on a specific number? No.

soispoke: Yeah, 500K is more than enough.

Marc Garreau: Okay, is that something we can agree to here? At least 300K, says Daniil. Matt, are you good with the 500 number specifically?

Lightclient (Matt Garnett): That's fine to me.

Marc Garreau: Okay. Unless any objections, then 500 it is. Okay, cool. That covers agenda items as far as I've seen. Actually, I did want to mention there's a The latest comment in the ETH Magicians thread for Frames is pdobacz suggesting a transaction param of 0 halts in any other context, or in any context other than a frame transaction. Should that halting be relaxed? And I'll just, Drop the link. in the chat. I don't expect anybody to have. Read and formed an opinion on this. Just yet.

So if there's any immediate thoughts on that, you're welcome to share them. Otherwise, that's just, something for… for folks to… Read and consider after the call. Okay, floor's open now for… FOCIL and frames, chatter, if there is a conversation to have here today. Is there anything… Folks are wondering, want to talk through while we've got time together? Good, Spencer.

Spencer Taylor-Brown: Yeah, I guess it's more of a… an alignment, for future DevNets, so my understanding now is that we have, frames devnet 1 with the… Free additional EIPs. Then after that, there'll be Hegota devnet 0, which will be the frames devnet 1 interrupt with. Think it'll be FOCIL devnet 1. And then after that, once we have this Hegota devnet 0, do we stop using the FOCIL and frames devnets, and instead. Just, use the Hegota DevNets. Moving forward. I guess that's my, like… Main question, whether that question should be asked here. And, maybe ACDT as well as, yeah.

Barnabas Busa: Yeah, We're gonna be… not doing, like, FOCIL and frame steadmats anymore, if we have the high-quality one. So everything is just gonna go into Hegota.

Spencer Taylor-Brown: Awesome. That sounds good from my side.

Barnabas Busa: Yeah, I mean, it's a bit also trickier to keep adding EIPs, especially when we have to add a bunch of EIPs, because it's a super nice separation for Glamsterdam, I think, that But we were able to merge it later on, and we could test all the features separate. But yeah, I think for Hegota. Bit more valuable to Mercy 2 earlier on. And, circle a bit more later.

Spencer Taylor-Brown: Yeah, I've said this before, but I really do think Hegota… Has the potential to be one of the fastest post-merge forks. And. And yeah, I think merging the devnets earlier feels good for that. So yeah, hopefully we can do it in under 7 months, let's see. After Glamsterdam mainnet.

soispoke: I think for the maybe technical sort of like part of porcelain frames, it's, It would have been nice to have ethrex as well, because my feeling right now is that Nethermind has made a lot of progress. ethrex as well and as Daniil said like I think now it's mostly aligning both client teams on exactly what they want to settle on, like, I think, like, the shape, the overall shape is basically the same, but it's more like, ok, should we just, like Implement this, you know, this particular way or not. And… but if we… I guess if we need, like, 3 clients to move forward, we would also sort of, like, need a… To align the… Geth or someone else,

On… On 47 frames as well.

Barnabas Busa: I think we need to, like, dial down what we want in the forces-endnets still. We probably have time to do one more iteration of FOCIL devnets and I'm not sure if you have a breakout for that. or… Yeah, probably don't. And I think AllCoreDevs is a execution leader call this week. Oh, we do have a FOCIL Breakout, okay. Do we have one this week?

Marc Garreau: No, it's next Tuesday.

soispoke: Sweet.

Barnabas Busa: the Yeah, that might be a bit late for the discussion if you want to launch a week after that already. with the increased scope, so maybe we can start some offline discussion about, scoping DevNet 2, and, maybe aim to also… make a decision, or do this Thursday if we want to do the, Hegota. Merge by the end of this month, because then we really have to… scope devnet to the FOCIL side to that size. But I don't think that there's many CL features we could be including, in devnet 2.

Marc Garreau: Yeah, there's not too much CFI yet.

Barnabas Busa: We could do, maybe, quicker slots. Yeah, I'm not sure.

Marc Garreau: Yeah, that would be, that'd be a reach. Okay, if there's a, something to get on this Thursday's agenda to help with that decision-making. Barnabas, could you make that… could you add that to the agenda, or is there somebody…

Barnabas Busa: Yeah, I can. I can add that to the agenda.

Marc Garreau: Okay, thanks. Okay. We have been getting towards the end of the, the agenda items, but I see we've got a few more people joining, too, including Anders, so I'll just mention. that Matt made a suggestion, to… Alter the… the frame spec, and. If you haven't seen that, I'm looking for a link to drop it in there. Anders, did you get a chance to… are you aware of that change? And if you wanted to comment on it, you're welcome to here.

Anders Elowsson: Yeah, I have reviewed the change. And if we're talking about this PR, I reviewed it and we made some changes. It looks good.

Marc Garreau: Okay, great. Just wanted to see if you had a chance to feedback on it.

Anders Elowsson: Yeah.

Marc Garreau: The max gas changes, that is. Okay. We're at the end here. Anything we want to cover before we wrap up? Yes, Lumi, I'll get that link out to you. There it is. Okay, we covered a lot of ground here today. We talked about a… DevNet 1 scope, targeting next Thursday. That includes the addition of 3 new EIPs. 8272, 8250, and 7906. This Thursday, we'll continue the conversation about, when DevNets are to merge.

FOCIL and frames, that is. And we've made a couple other decisions, about scope, for example, matt will merge in, the, Nix method… X-ray verifier. Daniil, go ahead.

Daniil Ankushin: Yeah, I just wanted to remind, about the, PR and about the idea to redefine the. const max refi gas as a shared mempool floor rather than a hard limit to make it, let's say, the minimum amount of The guaranteed amount of Frame Transaction Verification Prefix for, let's say, the weakest node. And, allow other nodes to use higher verification prefix limits, if they can. So we… this way we could, kind of have organic, gradient way to, to, pass, harder and heavier transactions with, hard and heavy, verification prefix. But it's going to be slower, but it's… there's still a floor that guarantees, some verification, limitation, but yeah, it's just, just already fine, to add more flexibility on that.

So, yeah, just, just please, give me, your, opinions on that. It's non-urgent, can be done, I think. Thank you.

Lightclient (Matt Garnett): How do you communicate to your peers what your verification floor is?

Daniil Ankushin: So, we basically… the idea, basically, is to use, current MaxVerify gas as. floor, not as a limitation. So, yeah, basically, if we have, we have, let's say, 100% nodes that can, gossip, under, transactions that are under, max verification gas. But, the, the more… verification prefix, above the, MaxVerify gas, the less, the less, node supports it, so, fewer chances to, for this, transaction to be gossiped. So, yeah, so…

Lightclient (Matt Garnett): Are you saying that you send transactions to peers who can't? Verify them. And then they fail to verify because it's over their limits.

Daniil Ankushin: Yeah, it's just, will be slower, but fewer chance to be included.

Lightclient (Matt Garnett): Right, but I think it's not a good thing to send transactions around the mempool that we know can't get accepted by peers. Like… We need to optimize the mempool a lot from where we are today, and I think adding more rules that Make it not possible to do that is not going to help us. So like the alternative is to have a protocol to communicate what your. You know what your verify limit is. To me, that that feels a little a little heavy, but it's like something we can obviously do. I mean, it's the same type of thing that we've done with storage of history. So, you know, you don't want to be sending a bunch of transactions to peers that can't process them, because then you also don't know

If they didn't process them and then you might again send them later if they send you the hashes that they have and they don't have the hash, hashes that you have. So to me, like, without a communication mechanism to say what they're able to verify, like, I think this is… This is adding too much stress to the network.

Daniil Ankushin: Yeah, okay, okay, I see that. Yeah, thanks for your feedback.

Marc Garreau: Okay, we've… we've covered a good few of them, but there are, friendly reminder, 13 open PRs against frames. Which you can find in that Forkcast link. So if those… if any of those need to get addressed before the next DevNet, I guess this is, your call to do so. Well… I… remembered one more thread that was introduced last week. Don't know if we had any… Decisions made, or new opinions formed, but there was. A discussion about how to simulate, frame transactions? via the JSON-RPC method. Has anybody had a chance to think any more on that? This came from feedback from jxom, the viem author.

If we don't think that's urgent, then I will… Leave that reminder with you, and we can pick it up again next call. Okay, last call before we wrap up. That'll do it then. Thanks very much, everybody, for attending and sharing. updates, thoughts, opinions, and progress. Appreciate you. See you next time.

soispoke: Thank you.

Lightclient (Matt Garnett): Thanks.

Mo Jahanara: Thank you.

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