FOCIL Breakout #42

Transcript

Justin Traglia: Hey, how's it going?

Jihoon Song: Doing great. GM?

Justin Traglia: GM, indeed. Before other people join, so I'll let you know I'm taking Wednesday, Thursday, Friday off, so… You'll be holding down the fort. If that's okay?

Jihoon Song: Yeah, sounds great. Hope you have a great vacation, and I think nothing will hold me back, so you can just enjoy your time. Off.

Justin Traglia: Sounds good.

Jihoon Song: Great.

Justin Traglia: Thank you, thank you.

Jihoon Song: Hello, guys. I think we can wait for a few more minutes.

Justin Florentine: Good morning, censorship resistors!

Jihoon Song: Welcome, Justin.

Welcome, Pella. Welcome, NC. I think we can kick this off. Hello everyone, welcome to FOCIL Breakout 42. Today's agenda are definite updates and the interaction between FOCIL and frames. Let's start with debit updates. I've tried local interop between clients, and it seemed Teku and Lodestar were not happy for some reason. NC did some debugging, maybe Mehdi as well, so… Shall we start from there?

NC: Yeah, as I said on the Discord, it's basically… Teku is batching… All the, the gossip objects into one single RPC, That exceeds, Lodestar's incoming limits. So that's why Lodestar just dropped. Teku as a peer when Teku proposes. So… I have a PR, it's just trying to increase that limits. From 4MB to 10 megabytes. But, in the meanwhile, you can also play around not having, like, 50-50 Lodestar and Teku. But… Yes, play around on the ratio. And it should, work as well.

Jihoon Song: Is it related to the therapy object limit?

NC: Sorry, what was the question?

Jihoon Song: So we… S&PRs raising… peer-to-peer objects for Engine the other day. And I wonder if this issue is related.

NC: No, it's a… it's a… it's a different… It's totally different, and it's irrelevant to, the inclusion of this.

Jihoon Song: I see. In the meantime, it'd be nice if we could share the link to the PR. Yeah, thanks for sharing the updates. Do other clients also have any updates?

Iván | ethrex: We don't have any update for this couple of weeks, but I would like to remark that there's still a couple of PRs on the execution specs repo that are meant to fix some test cases that are still fairly hype. No rush on that, but just wanted to remark it in case it got lost.

Jihoon Song: Great, could you also share the links to the…

Iván | ethrex: Yeah.

Jihoon Song: PRs? Yeah, thank you.

Marc Harvey-Hill: On Nethermind's side, I guess not updates, but we're ready for the devnet.

Fabio Di Fabio: On Beacon's side, I just rebasted everything on the main branch. And I discovered that we are now failing one EIP test. For Rizzo, that doesn't seem related to… Focil. I checked, and also another mind is failing the same test, seems for similar reason. So, I suspect Maybe the tests should be updated. Due to the latest Glamsterdam changes. I posted the name of the tester in the Discord channel. And, yeah, well, we are also ready for the death.

Jihoon Song: Awesome, thank you.

Cristian Conache: On the Lighthouse side, overall, we're not yet ready for DevNet, but we're making good progress. Since the last call, we've been merging a few PRs, adjusting the hazard block production, as well as, doing some work on the EnginePI integration. We're progressing, with a few more PRs, which are in the review process, and we're focusing now on, working on the gossip verification side. And fork choice enforcement logic, and the bit-bits inclusivity checks. And, yeah, that's, pretty much it.

Jihoon Song: Great, thank you. Zero.

Pellekrab: Yeah, and then I guess on the rest side, pretty much just got added to EthPandaOps, so we're up on there, pushed a few PRs to fix them. failing tests, and then we still have the 12 failing on the Consume RPL, but those, I believe, are all for EIP7610, which isn't slated to be included anymore, so… I don't know if that needs to be removed as well, but their mind's also failing those, I believe.

Jihoon Song: Great, do we have any more clients? Seems like that's it. Yeah, thanks for hearing update, guys. Yeah, Taeko is not here. Sometimes we can… Finalize local definite zero. I think we can't kick this off. I mean… A FOCIL Devon is zero, I still believe that our first priority is shipping to Amsterdam. So, we don't need to rush on this, but… If clients have some spare resources, then please feel free to work on FOCIL. And… Before we jump into FOCIL and frames, I'd like to share a quick update on Get Enclosure-based testing.

The thing about getting collateralist was that it's not deterministic. I brought this up in our weekly, And Jihoon pointed out that There are also other methods that we want to test, but don't require a specific output. EF estimate guess is a good example. And Felix told us that we would likely end up adding a testing framework for defining post-conditions. So that's where we are at. I'm gonna… Keep collaborating with people on this, and share updates as we go. Any questions or comments before we move on?

soispoke: Yeah, I… Yeah, I put it in my head.

Jihoon Song: Is it to my ask, what's… what's the blocker for DevNet Zero? We had some issue between CL clients, and… We are currently fixing it, I think the problem, I mean, the phenomenon was that Lodestar and… Teku, who are… Making their own chains. Once we figure that out, I think we can go ahead and try Lunch 7 at 0. Please correct me if I'm wrong, NC.

NC: Yeah, I think you're right.

Jihoon Song: Yeah. Thank you. Any other questions or comments?

soispoke: So we are waiting for every client to be ready before it's launched. Rather than just, like, launching it And then people join when they are ready.

Jihoon Song: No, we are not waiting for all clients. I think the minimum bar is 2x2. We have 3 EL clients ready. Of course, we have to test it. But I believe they are ready, and on the CL, we have Teku and Lowstar working on this, so once we have two CL clients working, then we have 2x3, so I think we are good to go. I mean, if Lighthouse… Make a progress before then. Of course, we can have, like, 3x3, which is great, but… As soon as we have to CFI clients, we can go ahead and launch DevNet Zero.

soispoke: Nice, okay.

Jihoon Song: Cool. Any more questions? Otherwise, our next item is the interaction between FOCIL and frames. Tamar, you ready?

soispoke: Yes, yes, I'm ready.

Jihoon Song: Nice.

soispoke: I don't have, like, a slide, unfortunately, I don't think it would have been super, super useful for you guys, because you have a lot of context, but… Yeah, I do think that now that, you know, FOCIL and Frames are both headliners and both SFI'd, it would be very, very nice to sort of, like, start making progress on the interaction between the two. I think most of, what I… Most of what my thoughts are, are, like, in this sort of, like, informational EIP for now. So it's, EIP8369. With the title that I maybe should have changed, it's called VOPS Profiles for FOCIL Eligibility, but, like, I think the crux of the CIP is to define what the interaction should be between FOCIL and prime transactions, really. Like, that's… the rest is mostly…

well known, like, so you have two profiles… two profiles. Profile one is, like, FOCIL as we know it, with, with sort of, like, regular transactions, and then profile two is, like, friend transactions, and how to sort of, like, dig with it. And it does change, like, a ton of things, because instead of just, like, checking the notes and the balance now, all, you know, from transactions are much more expressive, and so… You need to… Yeah, sort of, like, check a lot more stuff than you need to, if you, if you have, regular transactions. And… so the whole EIP, that's why it's, like, informational, and, like, it's… it sits in a bit of a weird place for now, because it's trying to describe interactions between,

You know, frame transactions and their shapes, and basically, it's all about the verify frame, and what is the load, inside the verifying frames, as it… as in, like, what state, it can read, what's the max verify guess limit, and all these things. Then, you know, FOCIL, of course, and then VOPS, which is, like. validity, only partial statelessness, and I think the easiest way to think about VOPS is just, like. If we move towards a world in which we have any sort of, like, any kind of, like, partial statelessness. And, you know, some nodes can drop. most of the state and just keep the state that's needed to make sure, like, transactions are valid when you are, like, looking at them in the public mempool. Then we need to define

what, should be in that state. And we need to do it now, rather than later, I think, because Applications that are building that are sort of, like, built on Ethereum now. If… the idea is, like, if they build using state that is gonna be in VOPS, it is also gonna be… it's also gonna mean their transactions, are gonna benefit from FOCIL inclusion guarantees. And so we need to give, you know, apps this sort of, like, guarantee, almost, that their transactions will be supported by FOCIL, because that's sort of, like, the minimal state we will ask Mempool nodes to hold, and that means, you know, transactions can go through the public mempool and benefit from FOCIL.

And so, yeah, in the EIP, we try to define, The boundaries of that state, It also ties in the privacy EIPs we've been working on, right? Because, for example, I would really want private transactions to be, part of VOPS, and to benefit from FOCIL guarantees. So you have kid nunces in there, you have recent routines in there, so it's a very important part of the problem. And so, yeah, defining that boundary is, like, very important, and I think it needs to be, like, a collaboration between client teams, right? Like, it can't just be sort of, like, arbitrarily determined by, just, like, an informational EIP, so I would really love, like, everyone Of you guys to sort of, like, look into it if you have time, and…

And tell everyone if that makes sense or not, like… You know, to include, like, these states in it, or not. So, yeah, I think the state boundary is, like, very important, because… and the trade-off here is very obvious, right? It's, like. Either include more states into VOPS, and then a broader range of transactions benefit from FOCIL, which is great, of course, but that also means more state to hold 4 nodes, right? So that's the very obvious trade-off we have to sort of, like, deal with here. And so, depending on what we want for the network, we can either, like. have a big VOPS, and then that means, you know, nodes will need to store weighted off state, but…

they can probably, sort of, like, accept, like, a lot more transactions can benefit from FOCIL, basically. Or you have a very small box, which is nice for… nice for decentralization, I guess, like, it's just, like, easier to run nodes, but, it means less, less transactions benefit from FOCIL. So that's one key dimension I wanted to talk about, and then… I think the second important dimension is, like, the whole mechanics of how to check, you know, how to do the FOCIL checks, basically, like, in the normal FOCIL, like a regular FOCIL, let's say, let's call it, like, you just happen the transaction at the end of the payload to… to see if it's valid, and… and here you can't really do that with SRAM transactions, so…

we thought of the builder index sort of, like, mechanism, and that's, that's also something I would love to have some more feedback on, like, does it make sense? And… and I think we also need to get into the technicalities of, like, you know, how that builder index is communicated, and, what… like, yeah, is it part of, like, an existing object? Is it, like, an object on its own? And so, yeah, we'll probably need to settle on this. So I guess that's, like, the other sort of, like, important part, for me, and then… Yeah, more generally, I think, like, as a coordination objective, like, it would be really nice to settle towards, like, some kind of specs for certain frames.

And then there's this sort of, like, yeah, thing we also need to settle of, like, whether that lives in existing FOCIL and prime EIPs. I think it should, I think it actually should live in both. But, you know, we need, like, to… that means we need to update FOCIL itself, we need to update, frame transactions, probably as well, and… and so there… there will need to be quite a lot of coordination around this interaction, and… And, I think, like, the whole… all the concepts are sort of, like, settled. Like, I don't feel like there is any sort of, like, huge questions that are, like, we haven't solved or anything. But now, you know, when we… when we go from concepts to implementations, we…

we get into, like, a lot of, technical things we need to discuss and sort of, so… yeah, I want to… I would want to bring this up, basically. What more can I say? Yeah, that's most of it. I think, yeah, it would be even better if it's just, like, an open discussion as well. Like, if anyone has questions, or… I also assumed a bit of knowledge from the AIP, so maybe there was a lot of assumptions on my end, so yeah, if anyone has questions or wants to… discuss how we can sort of, like, progress, on next steps. I know some clients, including ethrex, has already sort of, like, worked on false swollen frames, So, yeah, just want to, to know what, what you guys think.

Justin Florentine: I got a quick question, Tama. What… what do you imagine is… Like, an upper limit. For validation. Invops. Like, he… Can you imagine a world where, like… Sorry, I'm not sure how to conclude that part of the thought, but I guess what I'm just wondering is, like, in a perfect world, you know, your VOPS profile would be maximal. And… we don't want that, right? So, like, are you imagining that there's, like, an upper limit somewhere where we say, like, please don't do any more validation than this because… it's excessive.

soispoke: So I think the limit… Is… can either be in terms of… you know, state or compute, and those are, like, two separate dimensions, I would say. Like, for the state part, like, and, like, what needs to be involved versus what needs to be out, I think it's very… It's almost arbitrary, like, it also, like, needs to sort of, like, match onto… You know, what users with computers today or, like, running nodes have in terms of storage, and what they could drop if they switch to a two verbs instead of, like, storing all state, and I guess, like, the only thing that's very obvious is, like, that gap needs to be significant, like, otherwise we can just, like, keep the whole state and we stop, caring about this. So in terms of state, I would say, like.

for me, framing it as, like, the minimal amount of state needed for Mempool to validate transactions is a good proxy, like, it's a good mental model, but then, you know, what we want to accept in this, In this, in this sort of, like, minimal, verbs profile is, is up for discussion. I think it should be quite minimal, but yeah, we can… there's… there's many interpretations, and then the second dimension of the validation part is, like, the compute, right? I guess, and… And I think, yeah, it's also encapsulated in, sort of, like, all the discussions we have around the max verified gas limit for frames, how much that should be. And of course, here my take is, like, I want it to be more than 100K, because otherwise it can't, support private transactions. I think we… I think it's definitely doable, but we need benchmarks, and we haven't… we don't have this yet, so… so we…

Justin Florentine: Okay, so that was gonna be my next question, is then, what's the minimum? And it sounds to me like, if I'm guessing the minimum here, it's, like, signature validity, nonce placement, and… Root recency.

soispoke: Yeah, and cadences, and, you know, we might add, like, one, two storage slots if we… or, like, two to four storage slots is what I suggested in VOPS. But the minimum, minimum will be… well, depending on what EIPs ship, right? But, like, I think…

Justin Florentine: Right.

soispoke: Nuns, nunces, and… Yep.

Justin Florentine: Thanks. And, Jihoon, can we just quickly review, like, FOCIL's current, validity requirements? Just real quick, so like, you know, hey, somebody says, hey, you have to include this. And we say, okay, great, we'll try to include it, but, like, what other validity requirements do we have with regard to, like, you know, the transaction success or anything like that? Can we just summarize that real quick?

Jihoon Song: Without friends, or with friends?

Justin Florentine: Haha! Without.

Jihoon Song: without. Without frames, the, the EL were gonna check whether The transaction is successfully… Decoded. And we're gonna check if it's intrinsically valid. And then we're gonna also check whether it has the right notes and balance. And if there is enough gas left in the block, so on and so forth. But if the transaction is missing, you're gonna check if the transaction can be placed at the end of the block. And I think that's pretty much it.

Justin Florentine: Thank you.

soispoke: And so, this is basically just for people that haven't, like, really looked into it. It matches, like, the sort of, like, Profile 1, Profile 2 in the informational EIP, like, profile 1 is… profile, like, for FOCIL now, and Profile 2 is, like, what do we do for FOCIL and Frames? And I think that's… you can really see the diff, in the IP of what would need to, sort of, like, be included in VOPS.

Jihoon Song: So we are still unsure about our… future DevNet plans? like, whether we want to have CL and EL-only DevNets, and then go to Agora DevNet, or try… Bonsai Frame DevNet first, and then… have CLN EL at DevNets, and then go for Agora DevNet. We're still not sure about it, but maybe it's a good time to… Discuss how do we want to go about this, like, figuring out how we were gonna implement this interaction between FOCIL and frames, and… There you go. Breakout regarding Agora DevNet, once we figure out frame and FOCILs, I'll need to discuss this more with EthPandaOps, their preferences, as far as I know. They want to have this regular DevNet at the end of the DevNet cycle.

yeah, it's still TBD. But… Now that ethrex, as far as I know, ethrex already have I've also had frame dampness, so maybe… we can learn from that effort. It'd be nice if we can have I mean, invite ethrex or Nethermind to share some insights. Maybe we can start from there. This could be one approach.

soispoke: I think my preference would be to… Move… As fast as we can. To figure out the interactions between FOCIL and frames, because… Yeah, I think it's, like… Well, my feeling is, like, once we figure out FOCIL and frames, we can basically not touch FOCIL anymore, because… it's there, and the mechanics to support frames is there, and then the EL side can sort of, like, focus on figuring out everything that needs to be figured out with frames on the mempool side of things. And so… Yeah, for me, it does feel like… A sort of, like, early… for FOCIL Frames DevNet is very valuable. Also, it makes sense, like, there are the two headliners that need to… they really need to sort of, like.

Come together, and those are, like. I guess, you know, if you see headliners as, like, okay, yeah, big features, but also, like, features without which, like, the fork isn't shipping. I think it's… for me, it makes sense to sort of, like, start early. And we have, you know, progress from both ethrex and Nethermind on this, so I would… I would maybe favor, like, an approach that sort of, like, moves quite fast instead of, like, Not prioritizing it.

Jihoon Song: Can anyone help us to understand where we are at, what we've learned from FOCIL and frame dev nets, and what we are trying to do next?

Marc Harvey-Hill: At the moment, Ethrex and Nethermind are working together on Frames DevNet. But I haven't tested out Interop with FOCIL and frames enabled. But, yeah, I can try that out.

soispoke: I think… okay, one other question I had is, I think… ethrex was working on specs for FOCIL Frames, But I'm not sure that I saw it, and I… we also had a call with, you know. Jihoon and Steel, and we said it would be important to start, like, with the duck. So… and now I know, like, that, you know, Nethermind has also sort of, like, worked on it, like, a good start will, you know, the DevNet will be nice, but, like, a good start will also be to have, like, a common doc that we can sort of, like, all agree on. What, like… To talk about, the mechanism itself. And see if that, like, everyone sort of, like, agrees on the specs. I think that would be, like, a really good start as well. Like, doesn't have to, you know, it can be in parallel, but, like, it does feel like an important thing we need to do.

Because that would also sort of, like, answer the question of, like, you know, where do these changes live? Do they… do they live in FOCIL and frames, and where, and how, and yeah, I feel like that's important.

Jihoon Song: Great, like, having a PR will be definitely a huge win for everyone. Does the EL use some kind of witness for… omission validation, like the builder tried to place this IL frame transaction at this index. And if so, I wonder… How does EL expect a witness look like?

soispoke: You mean the builder index?

Jihoon Song: I mean, the witness for… Transaction… commission? Like, you can provide the witness that you try to include this frames, a certain index. Like, Transaction Hash and Transaction Index, for example.

soispoke: Yes. Yeah, so the builder… yeah, that's what I call the builder index, but yeah. Yeah, I don't know how… how you guys have thought about this. I think it would be good to ask… ask Nethermind and ethrex, like, is it now a separate object that the builder sends, along with its payload, or does… where does it live? if you guys need to also check back on the code or whatever, I think it's complete. We can circle back on this.

Jihoon Song: Yeah. Another way to put this is, how do you… validate the omission of some I.O. frame transaction. Because on the sales side, I think we need to specify this. somehow… But I'm not sure if you wanna have it on-chain? But also, Don't have a good idea. We're not putting it on-chain, so… yeah.

soispoke: I mean, I don't think it needs to be on-chain, but, cause there, there is no… It just needs to be available, but I don't think we need to keep records of… this on-chain. But yeah, that's, like, one of the key questions to… to sort out And we also need to rethink about propagation, right? Like… Just, like, in terms of, like, do we want to propagate this, sort of, like, another small object, or… you know, it's gonna be very small, so it can just, like, be fit with, like, an existing one. All these queues are, like, more implementation details, but it would be sort of, like, nice to align on this.

Jihoon Song: Yeah, to clarify, The builders will now need to provide this witness. It could be in B2B objects, or it could be in envelope, but if you put it in envelope, then it will gonna stay there for at least, like, 3,000… 33,024 epochs or something at minimum. Is it… Is it a blocker? Then maybe not, because it is ephemeral at the end of the day, after, like, a few months, but still… I wonder if there's a better idea? So, yeah, I just wanted to ask, like, how this is being handled. In a prototype.

soispoke: Yeah, I mean, if… if, you know, if you guys also, like, need to check back the implementation, maybe that's just a good, good thing to follow up in the, in the next, Breakout room, if there is enough time for it. You know, it would be nice to sort of, like. Come back to it also, and, and be, and, and sort of, like, see, See how it's been implemented, and if it just, like, makes sense as a first draft, and maybe… Try to align from there, like, we don't necessarily need to have, like, exact answers now.

Jihoon Song: Yep, we don't need to settle in. Can we, like, list up what we need to do for… the upcoming month or two, like, I think we need… we were gonna work on spec PR in both EL and CL. I think we are also gonna do some benchmarks regarding max verify gas, Sorry, Max Verify Gas. And did I miss anything?

soispoke: No, I think it's good. But, like, the max verified gas benchmark are also… I think, like, ultimately we'll need to get it from all clients, no? Because I feel like it's… the resources it consumes and everything, like, is gonna be probably client-dependent. Yeah, I don't know if you know, Marc, like, I think you guys have been doing some benchmarking already, right? Is that true?

Marc Harvey-Hill: Yeah, we've been developing the benchmarks, I'm not sure about the, like, concrete numbers yet.

soispoke: Okay, okay.

Jihoon Song: Do we need… Any other benchmarks other than max verify gas?

soispoke: I think also, like, the max verified gas is, like, not… you know, FOCIL-specific. It's very much… I mean, it ties into the whole thing, I guess, so… maybe. But, like, it, we need it anyways for frames. On its own, so… So, so even that benchmark is maybe just, like, can be separated a bit from The call for solar.

Jihoon Song: I see. Ivan, do we have any expected timeline for the PR?

Iván | ethrex: I'll try to have it, this week. If I get some delay, maybe next week? But… I'll try to have something before next breakout, for sure.

Jihoon Song: Right. Right, I think… We can say that we can discuss the spec changes, and… hopefully the benchmarks for max verify gas in the next breakout call. Just trying to set up some kind of structural approach to… Mitigate this issue.

soispoke: Yeah, I think that makes sense. Again, I do… Yeah, I mean, we can discuss it as well here, I think it's completely fine to… it's gonna be redundant anyways, like, I feel like that conversation will take quite a lot of space at some point, but I'm talking about the max roof, I guess, but, Yeah, that's not specific to… to FOCI. I feel like that… that will also sort of, like, happen in the frame Transactions Breakout. What… what would have been very nice to discuss here is this, this, FOCIL Frames spec. I feel like, that's, like, the… definitely the good group of people to discuss it with and to start efforts there. And, yeah. I mean, that also maybe tells us that at some point, not now, I feel like that's way too early, but at some point, you know, bridging the gap between the FOCIL people and the frames group will be also very good and interesting.

But but yeah, for now, keeping it separate is really good.

Jihoon Song: Yeah, sounds great. So we can… Take a two-track approach, like, we can still… kept working on FOCIL Devon at Zero, and at the same time, we can also… Figure out how there's… Interaction will gonna affect FOCIL and frame specs, and discuss the interaction in the next breakout.

soispoke: Yep.

Jihoon Song: Cool.

soispoke: I think, a prompt for people is to… Which is, like, an exercise I've been trying to do a lot, but, like, yeah, I think it's a good… Good prompt is… To think about, like, what transactions do I absolutely want? To benefit from FOCIL? Like, what are the sort of, like, use cases I really care about when it comes to, sort of, like, being able to… to get these extremely good inclusion guarantees. And yeah, I think that's important, because if you think back from use cases, then, you know, that tells you basically what you would need to include in VOPS. And I think there, you know, I've obviously thought about, private transactions a lot, so it's why I want recent roots and kid nunces in two verbs.

I feel like it would be crazy not to have good inclusion guarantees for privacy. It's a really good use case, but… I feel like, you know, there is potentially a lot of other use cases that we can discuss as well, and so… Thinking about what use cases come to mind, and how you would want… like, why you would want them to be supported by FOCIL, like, I think makes a lot of sense, and maybe that can drive discussions into should we just, like, add this into VOPS, and that actually sort of, like, unlocks a bunch of stuff that, I don't know, individuals or institutions or whoever else, like, really wants to do or, like, really cares about. So, yeah, if anyone

things about new use cases that should be supported, I think. It would be nice to discuss in the next…

Jihoon Song: Awesome, we can also talk about potential use cases. Mark and Ivan, could you guys also share links to your work so others can also take a look?

Marc Harvey-Hill: Sure, I can share it in the Discord.

Jihoon Song: Thank you. Right, before we wrap up this call, does anyone have any more questions or comments? Alright, to summarize… We can keep working on FOCIL definite zero and specs for FOCIL frames. And… we can discuss the spec changes. For FOCIL and Frame, and maybe benchmarks, and some potential use cases in the next breakout call.

If anyone has anything to discuss, please use the Discord channel, and… Yeah, thanks for joining, guys. I think we can go ahead and wrap up this call. See you in two weeks. Thank you.

soispoke: Thank you.

Justin Traglia: Hi, everyone.

Marc Harvey-Hill: is, but…

Fabio Di Fabio: Mother.

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