FOCIL Breakout #35

Transcript

Justin Traglia: Good morning.

Jihoon Song: Hello guys, let's wait… Few more minutes…

Nice, can you hear me okay?

Justin Traglia: Yep, can you hear me just fine.

Jihoon Song: And get… Sorry, Lindro, I closed the previous call because I was… checking if I can share my slide. It was not intentional. Alright, hello everyone, welcome to FOCIL Breakout 35. Today we can discuss client development, spec changes, and testing. Let's start with client development. I know more clients started implementing FOCIL. Do we have any clients that want to share more detailed updates? Otherwise, I think we can just… tentatively…

say that we're gonna base off of Glam DevNet 5, if it's stabilized, and then move on, because we are… we are waiting for the latest stabilized GLAM DevNet and Glam DevNet 4 instead. it's gonna be okay for clients, because Glam DevNet 5 includes more scope. Okay, so, I got one thumbs up, so… let's just say that we're gonna base off of Glam DevNet 5, if it's good, and then let's move on to spec changes. Yes.

Nico Flaig: So, I definitely don't want to base it on definite 4 specs, so we should definitely go on 5. Makes things easier for us, at least.

Jihoon Song: Yeah, I don't mind if it… delays, I go to DevNet Zero. Yeah, I think it's a matter. And if DevNet 5 is dead, then we're gonna move on to DevNet 6, and so on, so, yeah. So, let me share my… Slides… Has anyone? Can everyone? Yes. See this okay?

Justin Traglia: I can see it as fine.

Jihoon Song: Bye.

Justin Traglia: Actually, it's a little blurry for me, but it just cleared up.

Jihoon Song: Yep. Just give me a sec… Pretty good.

Justin Traglia: Yep, it is.

Jihoon Song: Right, so, just wanted to talk about two things today. It's all about IL validation. So, for syncing, I think, yeah, it's… so it's about, like, IL validation during syncing, and for… sidechain. So, for syncing, I think the cleanest solution is… letting the CL pass IELTS only when it's synced, so… During sinking, the CL will follow the heaviest weight. Perhaps this is already how it is implemented in the CR clients, but I just wanted to make sure We're on the same page. The next item is about accepted payloads. So. Let's say that this is the chain. I drew only payloads for simplicity. Let's say that we are on XYZ chain here at the bottom. And… let's say the CL calls FCU with D, then what happens is…

The EL, we're gonna validate B, C, and D, and choose D as the head. The question is… What if D is not IR compliant? then there could be a discrepancy between notes on BCD and from XYZ, because notes on BCD will… not gonna vote for a become block if it doesn't reorg D. Whereas notes from XYZ, we're gonna vote for it. I'm just ignoring PTC votes here for simplicity, so let's just assume that PTC is happy. So… In this case. we want to know the IL compliance of the tip of the change… the chain. So the change that I'm thinking about is… Introducing Payload Status V2 with Latest inclusion list satisfied hash, similar to, like, latest valid hash.

So until now, we piggybacked on payload status V1, adding IL unsatisfied value. Can I see the chat? Let me read the chat later. Yeah, so… yeah, but you can use this new field to get the same result, and going back to the previous example. Yeah, in this case, the EL will gonna return the block cache of C as the latest IL-satisfied block cache. And this way, we can make all nodes to have the same view when it receives the next become block. But of course, this is not complete yet. The follow-up question will be. what does the EL return when C, this… intermediate payload is not IL compliant. And what does it return when C is not IL compliant, but D is compliant? So, I'm still thinking about this, so I don't have a prepared answer at the moment yet, but just wanted to share.

what's being changed, and why. I'm gonna update the execution API SPR once it's ready. And… yeah. This is what I'm working on these days. So…

Justin Florentine: Can you, Jihoon, can you, like, outline the problem here a little bit? I'm sorry, I showed up a little bit later, but to me, so far, this looks like… a pretty… I don't know, this seems like a non-controversial change to fork choice here, like, you're choosing… you're still choosing the longest one, considering IL compliance, so… Am I… sorry, my dog, am I… am I missing something?

Jihoon Song: Yeah, so, in this case, when you were on XYZ and moved to BCD, then you need to know the IL compliance of this D, because you might have different view from notes on a BCD. And that was the reason, Yeah, of course, we don't need to add this new field to that end, because we can just use the piggybacked status value for the same result, but the question was, actually, was more about what if this intermediate payload is not IAT compliant? Then, do we want to know, like. Let's go back to this trivial question, like, in this case, this latest IL-satisfied hash, we're gonna return the black hash of B, then… Yeah, that was the main, like, reasoning of this introduction of this new field. Like, then, how do you want a CL gonna handle this? Like, do they just want to follow the weight, or do they want to use this information to…

do something more, so yeah, I'm still working on that, so… The view diverges regardless of weight at the tip of the chain, and that's… the same with PTC, right? And with PTC, we're gonna rely on whether Yeah, so at the tip of the chain, we don't follow the weight, because you haven't received our test stations yet. And, yeah, the reasoning is similar here, because PTC and IL are one-slot reorg. And… you need to make a decision for FCU before you receive attestations. So, yeah.

Justin Florentine: think I understand it a little bit better, thank you.

Jihoon Song: Yep. Alright, so, it's still a draft, so it's a bit, you know… not organized, but yeah, just wanted to share, because this will gonna affect on CL and EL, and I just wanted to give a little bit of a heads up.

Nico Flaig: So, can you, ask… so you removed it already? Okay, but, so for the ABC chain, So does it mean that the… the branch got more weight? Because more than, I guess, half of the validators voted for it, so you should be setting it as your head, but due to… like, based on your view, it's not IL compliant, so you… you don't update your head? Or should you only… like, you update your head, but you're not… no, that doesn't make sense, like… and you're not voting for the branch? I'm a bit confused how that should be handled.

Jihoon Song: In the case that… I'm sorry, in the case that which payload is not IL compliant?

Nico Flaig: So I think it was C. Maybe you could quickly reshare. Yeah, it was D, so… or even that case, but that other case as well.

Jihoon Song: Yeah.

Nico Flaig: So let's say D has more weight, right, than our other branch that is fully IL compliant. Then… Okay, so your node sees that other branch, it got more weight, then it has to import D as the head currently, right? Assuming no IELTs. But now, not IL compliant, so, what is…

Jihoon Song: It's not. Yeah, so in this scenario, when you call FCU with D, you are actually calling with a BCOM block, let's say, like, BCOM block E that extends payload D, right? Because you're not calling FC with payload, you're calling with big on block, so… that's where… the assumption of majority of knowledge as a testers kick in, because this is not… you know, not a happy case. So, when you receive FCU that payload D is the head, then… yeah. something's not right. But still, the protocol should be able to handle it, and then, yeah, I'm just thinking about many cases. I'm sorry that my answer is not crystal clear, because, yeah, it's still, like, TBD. So, yeah, what do you think, like, how this should be in this case?

Nico Flaig: I mean, the case where it's only D, and you receive that block, and it's, like… and, like, C is the head, and then you have to vote on D, then it's fine, but if it's, like, deeper in the chain, I mean, how can you set that as head? I'm not sure.

Jihoon Song: Yeah, makes sense.

Nico Flaig: Basically, under your view, the chain is invalid, right?

Jihoon Song: Yeah, yeah, because, yeah, it doesn't extend the head correctly, because you're not gonna follow this chain. But… I'm sorry that I'm just keep brainstorming here, but the thing is, you were on XYZ, and then you receive, some become block that extends payload D, And somehow you found that E has bigger weight than Z. then we're gonna call FCU with E, right? And then… It basically means that you will have to validate B, C, and D.

Nico Flaig: But it's not clear, would we then make the… mark the branches invalid in that case?

Jihoon Song: Yeah. Isn't that clear? Yeah.

Nico Flaig: Also, there's a bigger other issue that I see is when you sync a node and it didn't follow the both branches, it didn't observe all the ILs, right?

Jihoon Song: Yeah.

Nico Flaig: you have to swim with the IELTS as well. I guess, so the idea I think you proposed is you… Only do this for the unfinalized chain, right? But still, that could be a really deep sync chain, or a really deep brown, so you need to get the ILs to even know Whether it's IL compliant or not. Because they are not part of the block itself, right? And I think determining chain validity based on something that's not part of the block, I'm not sure that's great.

Jihoon Song: Yeah, yeah, yeah, yeah, I got what you mean, yeah. So, in this case, if there's, like. 100 unfinalized sidechain, then you maybe need to fetch IELTS for at least the head of each 100 side chains. To generalize this scenario. So, yeah. Okay. Let me think about this more, sorry that it is… a bit brainstorming-y. Yeah, so the reason that… I brought up with this new payload. Status version is that, like, do… was mainly this scenario, like, do we need to… do we want to know that the B was the latest Il satisfying payloads, but yeah. Let me think about this more, so… Okay.

fantastic.

Justin Florentine: One thing I'm not understanding about the premise here that maybe we could clarify real quick is they forked at Block A, which was valid but non-IL compliant.

Jihoon Song: Oh. Sorry, I'm so sorry, it was… it's just my type, I'm sorry.

Justin Florentine: Okay, okay, good, thank goodness. Alright, I was like, maybe we should sort that out first.

Jihoon Song: Oh, yeah. Oh, sorry, I was, like, yeah, quickly jamming.

Justin Florentine: with this.

Jihoon Song: slides right before the call, and then I made a mistake.

Justin Florentine: Okay, all good, Jihoon. Thank you.

Jihoon Song: Thank you, Justin. Right, yeah. So… Yep, okay, that's all that I prepared for the spec changes.

Nico Flaig: So can we discuss, maybe, what's the exact problem we are trying to address with this change?

Jihoon Song: Right, so.

Nico Flaig: implement it, but what do we actually achieve doing this?

Jihoon Song: Yeah, so, the main problem is that we haven't considered The situation where you move to sidechain. And then there might be a, split view between nodes from, coming from different chain, because they don't share IL view of the view of the chain. And then it escalated, like, okay, then what happens if… there are… Majority of malicious or testers somehow canonicalized non-IL-compliant payload in between, then yeah.

Nico Flaig: But this is, like, an honest behavior case, where you just have a split view, or you mean in a attack scenario?

Jihoon Song: Yeah, so I… sorry, I mixed two things up. So, the prior is about honesty, so even when there are no malicious or testers, there could be a split view, because if you were… in the previous example that I shared on the slide, if you were… on XYZ and move to PCD, you have no IL view on payload D. Yikes.

Nico Flaig: Exactly, that would be a concern, right? Because their notes voted per their IL view, so they acted honestly, but…

Jihoon Song: Yes.

Nico Flaig: just had imperfect information at the time. Yes.

Jihoon Song: Yes, that was the starting point. So, I was discussing this with Mikhail about, engine APIs, and then erase these points, and then, yeah, So… maybe we don't need payload status V2, but still, this is a problem that we haven't really thought about, so yeah. There will be some spec changes, in the near future. And… I'm gonna try my best to prepare it. before DevNet Zero, so… Okay. It's… there is no more question, then I think we can move on to testing updates.

Nico Flaig: Another question, just the last, last point, so… Yes.

Jihoon Song: Please go ahead.

Nico Flaig: The attack scenario would be you have a 51% of attesters. basically voting for a non-IL-compliant chain? Was there any adult scenario you had in mind?

Jihoon Song: If he… Scope it to FOCIL only, then… Ice… That is the only alt-tech scenario that I can think of. On the spot. But of course, if you have a control over more than 50% of a testers, then… You can probably do much worse than that. No matter what that is. But still, when it comes to FOCIL, of course, you can canonicalize not IL-compliant payload.

Nico Flaig: Yeah, so I would think it's not an issue, like, the current design, also, having it similar to PTC. But yeah, I would also… I guess we need to think more about this.

Jihoon Song: Yeah. There was a question that, like, Do you wanna increase… the IL enforcement window. to, let's say, like, N, which is bigger than 1. I'm not sure about that, to be honest. What I know for sure is we cannot make it permanent, unless we're gonna make IL on-chain. Because there could be a split view. Even only with honest or testers. If there's, like, client bugs or something. But, yeah. I'm also thinking about it, and then…

Nico Flaig: So, yeah, if you make it deeper than, like, the PTC world, for example, how it currently works, then you would need to… included in the weight counting, I guess?

Jihoon Song: What'd he come to?

Nico Flaig: Like, right now, right, if the payload is not IL compliant, attesters will not vote for that, and then anything beyond, like, the previous slot. That, was voted on, or the previous block, the payload, sorry, will be based on the weight only, right?

Jihoon Song: I mean, past slots, right? Paleo from past slots.

Nico Flaig: Yeah, exactly, but you already voted for the parent block, so it's part of the canonical chain by weight, right?

Jihoon Song: Yes, yes.

Nico Flaig: So if you may.

Jihoon Song: But indeed.

Nico Flaig: deeper than one slot or one block, then it becomes difficult, I think.

Jihoon Song: Yeah, it's… we're gonna complicate the protocol. a lot, it is not technically impossible, of course not, but then, like, when do we stop? The question is, like, do we want to make it, like, one epoch, or up to the final… latest finalized blog, and then… Yeah. Probably not a big of a deal, but… It is somehow… Yeah, okay. So the one-slot reorg thing is, is a separate concern, so… Okay, so, maybe we can move on to… testing updates, not sure if we're gonna have Any changes, but… since we have Felix here… maybe…

Do you want to share any updates? Nothing here? Okay. Yeah. Speaking of which… I think I'm gonna ask for your input once this spec changes, like, figured out. Nevertheless. Oh yeah, Mark reached out to me asking for some pointers, and he said that he's working on FOCIL at the moment, and… Nether… he said, nether mind passes all… Tests. But… He also tried interrupt with, other clients, but since we don't have, stabilized DevNet, it was, like, half-ish interrupt, but it seems like that their mind is also ready. All right, does anyone have any more comments, more questions?

Nico Flaig: So, maybe just what's the plan for the definite? Do we want to launch it with one CL? I don't think it makes a lot of sense, but… Yeah.

Jihoon Song: I think we need at least 2x2, like, two CLs and 2 ELs. The, you know, it just… It is still, you know, heaven… haven't worked out yet, but, you know, we have how many clients? Like, nearly 3 CLs and 3-4 ELs, so I think we have enough clients. We just need stable. Glam DevNet, I think. Cool, thank you, Felix. Yeah, regarding… I got a DevNet Zero, I can… I think we can revisit it. as soon as we have stabilized Glam DevNet, so… For the scope of Hagar Devidence Zero.

We can say that whatever we have live for… Hazy and Bogota. I'm gonna make sure we can have… specs ready by then. Not sure when that would be. Maybe in a few weeks. So, yeah, we can revisit that issue in 2 weeks. So we shouldn't comment?

Justin Florentine: So I'm just gonna keep an eye on both the CL specs and the execution spec branches to see those come in, I assume.

Jihoon Song: Yes. Please. Of course, I'm gonna share it in the… Discord channel.

Justin Florentine: Okay, yeah, I was kind of just, the actual question, I guess, is… Is that Discord channel the primary, coordination point at the moment?

Jihoon Song: Yes, yes. It has been, and it will be for the time being.

Justin Florentine: Okay.

Jihoon Song: just to avoid any confusion, it is enclosure external, and then once we feel like we are mature enough, I think we can merge this breakout into ACDT, and then… Yeah. Just like we did with ePBS and Balls. But for now, I think we could use this breakout to discuss FOCIL-specific changes, and then in Collision Lase channel for any new spec changes, and… development changes.

Justin Florentine: One thing that would be helpful is if we could point, my team, if I could point my team to maybe a condensed version of the, discussion that we had in the beginning of the call. To, like, what to do when, you know, chains of equal weight diverge by inclusion state. If we need to solicit opinions from ELs or CLs on that, it'd be nice to have a quick explainer on the issue to point them to.

Jihoon Song: Got it. I can… prepare a write-up regarding this issue, and then share it in the Discord. It would be really helpful if… Client devs could weigh in and share some inputs.

Justin Florentine: Awesome, will do. Thank you, Jihoon.

Jihoon Song: Great, thank you, Justin. Alright, do we have… more questions?

Nico Flaig: I would just have her ask for some EL, maybe, if you could prepare an image where you can have a malicious or censoring node, that would be great to have, I think. I tried this with Besu, during the indoor op. I think there were some bar-related issues, and Besu didn't quite give me the right arrow codes to reorg those payloads, but I think we should be testing the unhappy case. On Kurtosis before we do a DevNet, and I'm not sure if Barat's builder is ready. Ideally, we want that to be censoring, but yeah.

Justin Florentine: If you still have that branch, Nico, feel free to send that my way and kind of get some basic devs to take a look at it to figure out what was wrong.

Nico Flaig: Oh, I think it was very trivial. I think I just disabled some mempool stuff to produce empty blocks. I'm not sure. I think Fabio should be aware of it.

Justin Florentine: Great.

Nico Flaig: I think the issue was not that, it was rather Besu not giving me the error code when processing the payload. But yeah, that might be already resolved. It's been a few weeks ago.

Justin Florentine: Okay, holler if you need me.

Jihoon Song: Great, and… regarding Build War, I, as Barad last week. And he said that he's working on something else. And probably quite be busy for, I don't know, the next couple of weeks, but… since Glam DevNet is still… in progress, I can ask him again in, like, a few weeks if he can Prepare, build work to produce some… IL in compliant payloads. For our first step, Ned. And that thing? It's something we can also discuss in… Like, 2 weeks for… better availability. Right, any more questions?

If not… Thank you, everyone, for joining, and… Have a great rest of your day.

Pablo Deymo: Thank you.

Nico Flaig: Have a nice week. See ya.

Jihoon Song: Thank you. Bye-bye.

Justin Florentine: Yep.

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