FOCIL Breakout #36

Transcript

Jihoon Song: Hello guys, I think we can wait a few more minutes. Ideally, we can have some yellow depths here.

Right? Things like this is, so I think we can start off. Hello everyone, welcome to FOCIL Breakout 36. Today, we can discuss development updates and spec updates. Cause I have… So many details to discuss for spec. I think we can start with development updates, but not sure if we have any updates.

Nico Flaig: Yeah, so from Lodestar side, we rebased on top of Glamsterdam DevNet5, and we should also be able to accept bits there, so we could test the censoring, if Bharat already got that working.

Bharath Vedartham: Yeah, I think I have, like, I have a branch of FOCIL that works. But I tried it, last week, and there was actually, like, a… I think there's… a bug in, like, Lodestar, which I should have reported, I haven't reported that yet. the… the bug mainly is, like, I think on the gossip, like, you don't serialize… the bid, right? Like, I think you're scheduled…

Nico Flaig: fixed already. What's it with the bits? Like, the new… Bits, yeah.

Bharath Vedartham: I think the bits were, like, still… you were serializing the Gloas version of the bit thread. You fixed that recently, is what you're saying.

Nico Flaig: Yeah, that one is fixed, yeah.

Bharath Vedartham: Yeah, I haven't yet tried it. Like, today I'll be a little busy, I can try it tomorrow again, right? So… but the builder works, like, I… I think that was one bug I faced, and I think… Like, I think with the latest branch, I'll test it again, and… I think with that, we should have a censoring, like, builder pretty easily.

Nico Flaig: Yeah, we mostly need to see, then, if ELs give us the right error code, and then if the CL handles it correctly. Because that was mainly last time I tested this at Indoor Op, was that ELs didn't give me the right error code. That they are supposed to.

Jihoon Song: Gotcha. Thank you. Do we have more updates?

Eitan Seri-Levi: Yes. I just rebased Lighthouse on top of the banks are in there. Neat, bye. I don't think it's worth it.

Jihoon Song: Not sure if I got you correctly because of the audio, but it seems like Lighthouse is still, working on…

Eitan Seri-Levi: Yeah, sorry, we're testing right now, I'm not sure if our implementation is working yet. Maybe I'll have another update in a couple hours.

Jihoon Song: Oh, cool. Okay, thank you. Yeah, so, I think we can move on to Specting, because we have… Yeah, let me share my screen… Is the screen good?

Justin Traglia: Yep. Yep, it is.

Jihoon Song: Okay, thank you. So… I have many details to discuss. First off, I want to start with IL bit lists, whether to keep it or not, and if you were to keep it, how to change the engine API or the Beacon event. Next, I want to share how the spec will be changed. The change is centered around side branches, so when you move to a different branch, how do you enforce IL? It is also related to how we want to define non-finality for turning off intellectual waste. And that will be it. It took me some time to think about many edge cases. I believe the changes that I'm gonna introduce will be sufficient, but… I'm gonna seek more… seek for more feedback, perhaps, by preparing a write-up or something, so…

Yeah, and please feel free to unmute yourself and interrupt me, because I might not be able to see the chat. Yeah, so for BitList. The reason we have IL bid lists in the bid is to give a proposer a signal that the corresponding payload will be IL compliant. However, currently, builders initiate payload building process based on payload attributes event. But that event has IL transactions, not ILs, so there is no way for builders to construct IL bit lists in their bits. So, we have 3 options here. One is changing FCU to send a list of IELTs. In this case. The EL will gonna deduplicate IL transactions. This might be more efficient, because the EL is RLP-aware.

The second option is adding IL bitlist to payload attributes event. But payload attributes event has been matched to the, actual payload attributes parameters, so this will gonna be an exception. And the third option is removing ILP lists. One use case that we found out is that you can use this bit list to punish builders who produced non-IL compliant payload. But… In fact, you can punish them even without ILP lists. But still, having ILP lists could be a good signal. When the period goes bad, such as non-finality situation. So, before we move on to next topics… Do we have any thoughts or feedback?

Bharath Vedartham: Dion, what was the last thing you said? Why the IL could be… IL bitlist could be good related to non-finality, like…

Jihoon Song: Oh, yeah. That's because… When you are in a different branch, you are not gonna hear you're not gonna accept IELTS from different branch, because those two branches, if the divergence less for more than an epoch. They were gonna have different dependent route. So, from your perspective. IELTS coming from a different branch is… kind of bad, so you're gonna just drop it. And then peers might gonna disconnect with each other, because they think that they are sending you some bad objects. So… Yeah. in this case, having this ILT list could give you, like, a good confidence that, oh, this… Corresponding payload, we're gonna… Satisfying collateralese. against my IL view, or something like that.

Bharath Vedartham: But from the IL bitlist, like, we… we can't know, like. which IL committee route, it has used, right? Like, the builder. Like, from the bit list, you can't determine the committee route. Which… which, I think depend… each branch will have its own committee route, right? So…

Jihoon Song: But, yeah, but don't you know which state the bid is constructed? And from state, you can derive which IL committee root.

Bharath Vedartham: Correct.

Jihoon Song: than I expect, yeah, yeah.

Bharath Vedartham: Oh, that makes sense. Yeah, I guess my only thing to say, I'm not worried about, like. what the builders have to do. I mean, I think builders can also just listen to… the IELTS via P2P and, like. set the bitlist based on that, but… yeah, I guess my only thing is, like, there's no way to, like. I know if the IL actually… if the bit list is right. Like, I think that's my only thing. A builder could just fake it and… say, okay, I satisfied the entire IL, but then… and the bid gets selected, but then when you reveal, like, okay, they've actually not satisfied the IL, which is fine, you, end of the day, Fork Choice will reject that payload, and you build on empty, but…

But, I mean, that just… that's also not desirable, like, you don't want to… You don't want them to… you don't want that to happen. So, yeah, I guess my only thing is, like, the bitlist can be faked, is what I think, so… So, that's why, like… I'm not 100% sure what value it serves. If this is something that can be manipulated easily. Yeah, that's my only take.

Jihoon Song: Gotcha. Thanks.

Justin Traglia: Oh, no.

Jihoon Song: Corporation.

Justin Traglia: The proposer still be paid by the builder?

Jihoon Song: If it's trustless payment, right?

Justin Traglia: So even if it gives the… Even if it lies about the IL bitlist.

Bharath Vedartham: Yeah, I think so, yeah. Trust us. As Juhun said, if it's a trustless payment, it will… And the blog gets enough attestations, yeah.

Justin Traglia: Okay.

Jihoon Song: But if it's trustless payment, if it's trusted, then…

Bharath Vedartham: Oh, yeah, who shared, like…

Justin Traglia: Well, that's their fault.

Jihoon Song: Yeah.

Bharath Vedartham: Yeah, that's true.

Jihoon Song: So I think we can decide first. whether we want to keep it or not. Like, what do people think about Tipping it.

Bharath Vedartham: This is not used when we're processing the bid, right? So when… But attesters process the bid. Do they… I don't think they use the.

Jihoon Song: No. Not the testers, but just a proposer, and actually… I think it is up to client implementation. Like, there's no way to expect to, you know, enforce clients to follow, you know, a superset IL bitlist. It's just a signal.

Bharath Vedartham: Yeah, because I think I also don't see, like, a P2P rule, where… that… I think we have… we talked about this, but… I wonder if it makes… again, raising it again, I wonder if it makes sense for… to be on the gossip route, like, you don't have to reject, but let's say somebody sends you an IL, and… So, you get a bid, and… That's not your superset. That bit list is not a superset of yours? You could just reject it, I don't… But again, a builder could just send all ones. If they want to.

Justin Traglia: I was thinking just because it can be faked, I don't really see the value in keeping it.

Nico Flaig: Yeah, I would probably either say option 1 or 3. I think option 2 is not great to… To do this. But maybe option 1 is also good in general, if we want to let the EL deduplicate. And then the FCU would… or the payload attributes, would also emit all the ILTs, right, that you need to satisfy as a builder. Oh, how do you do that right now, Bharat?

Bharath Vedartham: Right now, I…

Nico Flaig: No, wait, we… alright, no, no, we sent the transactions you need to satisfy. Yeah, but they are deducted, right? Yeah.

Bharath Vedartham: Yeah, and now in the builder, we just set it to all ones. We don't, like, do much. So… yeah, the bitlist, we just set it to once.

Justin Traglia: What's the benefit of option 1? I don't fully understand it.

Jihoon Song: Because currently, the CLD duplicate case by… byte-to-byte compression, but the EL can be a little bit smarter. Because it's already object.

Nico Flaig: And I mean, the purpose is you can reconstruct the bit list From that, right? If you emit all the IELTs?

Jihoon Song: Yes, yes.

Nico Flaig: Yeah, that's the only one.

Jihoon Song: And if we…

Nico Flaig: We want to keep it the bit loose, yeah.

Jihoon Song: Yeah, so… so with option one, I think there's another thing on top of, like, keeping intellectually spit, which is, like, where do we want to do deduplication? Currently, we do it on the CL, but yeah. It's a bit stupid, but… Is it… what do you think, like, is it fine, or…

Bharath Vedartham: I don't know, in my opinion, like, I think… if we have the… I think we are… my main thing is, like, do we really need it? Like, and if… I'm not too worried about, like. What do we need to do for the builder to set the bitlist? Because I mean, I would… I can as well, like, just, like, listen to the inclusion lists, like, P2P, and fill my inclusion list according to that, so… And either kind of maintain my own inclusion list, or… I'm not too worried about that. I think, for me, the main thing is, like, do we need it? And it seems like it can be faked, and if we don't need it, then…

Like, they might as well not have it. That's the way I'm seeing it. Otherwise, like, I'm not worried about how builders will set their bit lists, do we need to add this to the event? I don't… I think even… I'm not worried about that, like… Like, builders can maintain their own stores, it's quite easy to do that. It's just, like, the question of whether we have it or not, and…

Jihoon Song: Yeah, gotcha. So, I think… the best word would be removing IL bitlists, and we can just keep the engine API as is. But in the future, if we want to do the duplication of the EL, then we can change the engine API. Alright, I can make the spec changes based on this. Decision.

Justin Traglia: Okay. I think that sounds fine to me.

Jihoon Song: Okay, thank you. Alright, and… next is about… payload status V2. Currently, we piggybacked on payload status V1, But there was a feedback that the relationship between valid and IELT satisfaction is not clear. A good example would be when you move to a different branch. Let's say the EL returned IL unsatisfied. Then, doesn't mean that the head payload is not satisfied, or all payloads are not satisfied? This is what we cannot fully represent with current scheme, so I'd propose to have payload status V2 with the latest IL-satisfied hash. The thing is that, you know, IL is a fork choice rule, it's not a validity rule, so even if latest information is satisfied hash points to the head payload, it doesn't mean that all previous payloads

are IL compliant. I think we can double-click on this in a later example. So… And the next topic is also about moving to a different branch. When you receive a payload from a non-canonical branch, the EL returns accepted status. And in order for the CL to compute the weight of the branch, we need to decide IL compliance of accepted payloads. I think it is natural to consider them as IL compliant, because otherwise you cannot move to a different branch. So this is… yeah, in the CL spec, this part is abstract with is payload in culturallySatisfied function? So, in the actual implementation, the CL will have to handle, like, if payload is accepted, then you just return true for that function.

And in the same vein, it is also about how the EL treats accepted payloads. So, if the CL pass some IELTs. and the EL returns accepted status, then EL has to remember the ILs passed by the CL, and they use it for IL enforcement later if The EL has to validate those accepted payloads by some FCO call.

Justin Traglia: Could you just quickly clarify how long it needs to be remembered? Is it just one… Like, one or two slots. Or is it longer?

Jihoon Song: I think… So… I'm gonna… I'm gonna… Double-click on that with a later example, but in the actual implementation. So I've looked into, like, what kind of edge cases There are, and my opinion is that it is sufficient to remember IELTS for the head payload, or maybe the head payload and the previous payload. I need to double-click on this, but the reason is because It is driven by fork choice, so if… There's malicious. Attesters that have a control over 30% of total stake data. per branch, then they can canonicalize non-IL-compliant payload. But still, the EL will kind of just follow the CL for which block to be based on, and from… based on that become block, CL will kind of decide which payload to extend.

So, yeah, and so what we are interested in is whether the head payload is IL compliant or not, so it will be the latest payload, I think. Maybe just one more… I mean, the parent of the head payload, but I think, yeah, it will be just head payload.

Justin Traglia: Okay, thanks. Yeah, that sounds completely reasonable. Doesn't sound like too much.

Nico Flaig: That should be exactly the same as with the PTC votes, right? So, as soon as you have a tester wait on each branch, like, full and empty, you need to… Pick your head based on the weight you have.

Jihoon Song: That's true, that's true. Speaking of which, do you remember why we put PTC in block. It's to prevent ex-anter reorg, right?

Nico Flaig: Yeah, I think that's the reason. I think Porto's… talked about this in EePBS at some point, when we talked about… yeah, there was some discussion about removing it from the block, even.

Jihoon Song: Yeah. Yeah, the difference here is we don't record IELTS on-chain, but the mental model is very similar. Justin, did you have any questions?

Justin Traglia: No question, I was gonna say, I don't know.

Jihoon Song: Oh, okay. Yeah, so, let's take… go look into some examples. So, let's say that we were in this branch, and then CL picks up This branch, after running get had, when you run GitHub depends on implementation. It could be at… second zero, or 4 seconds, or after receiving unplug, or whatever, but just let's assume that we just picked this branch. And then you also receive this payload N plus 3, so you were gonna call FCU with this payload. Then… The EL, we're gonna validate all payload, N plus 1, N plus 2, and N plus 3. And let's just assume that all payloads are IL compliant, and then the return of this FCU will have this latest IL-satisfied hash with payload N plus 3.

If it's not IL compliant, then it will be N plus 2. But this applies only when these two branches have the same dependent route, because If the divergence lasts more than an epoch, then… the notes here coming from this branch, will not have any ILs for this branch. So from that node's perspective, this payload is IL compliant, because it will gonna validate with zero ILs. So there will be a split view Between notes on this branch and notes coming from different branch. But it will gonna recover after a slot, because… Yeah, it depends on which one wins, it depends on the weight between, nodes and which… payload status. that, proposer for N plus 4 picks up because of the proposer boost, but still, after one slot, they were gonna recover. And this also relates to

When we want… when we want to turn off intellectual waste during the finality, so… Yeah, so… It is about when we turn… when we trigger non-finality, so… Currently, isFinalizationOK helper function defines it by two epochs, so if the latest… if the last finalized epoch is more than two epochs ago, then we considered we are in an unfinalizing situation. But if we decided as a more than one epoch for IL, then we can prevent such situation, because we can guarantee that any four… I mean, any branches will have the same dependent route. So we can also discuss it a bit later. Yeah. And this case is when… this is about a security assumption. So…

In this case, you call FCU with this payload N plus 3. It means that your get head picks a block N plus 3, which means you cannot equalize this bad payload here, sensory payload here. And this can happen when… the militias have a control over more than 30% of weight on this branch. It is also same with X post to reorg that we have today, so if you have more than… if you have a control. more than 30%, then you can reorgan innocent payload. We don't add or weaken that assumption.

Justin Traglia: what's important.

Jihoon Song: And in this case, when you call FCU with payload N plus 3, the EL should return payload N plus 3 as the latest IELT satisfied hash.

Justin Traglia: Also just when we have contiguous proposals, right? Like, if you're the proposer for two… Yes. Master Box.

Jihoon Song: Yes. It depends on, like, how many slots consecutive slots, the malicious can have a control. And yeah, I'm just assuming, like, worst case scenario here. Yeah, so, Do we have any questions or comments? Like, is this crystal clear, or is it a bit… Does it need some time to digest, like, what's going on, and whether it is correct? I'm just curious whether if I just… it is okay to just move on.

Nico Flaig: So in general, you also have the same problem if this happens on your own branch, right? You could mark the payload as not IL-satisfied, but if it gets more weight, then…

Jihoon Song: Yeah.

Nico Flaig: Can you work?

Jihoon Song: You were gonna…

Nico Flaig: Use it as head, right?

Jihoon Song: Yeah, you were gonna join… join the other branch after one epoch, because your GitHack will pick up the branch with that node. non-IL compliant payload.

Nico Flaig: Now, I think it should be in the next slot, right? Essentially.

Jihoon Song: Next slide, in the next slot, I think you were gonna vote for the parent, and in the next slide, you were gonna realize that you lose, so you were gonna move to a different branch.

Nico Flaig: Yeah, but that's what I mean, right? It's one slot delayed, basically.

Jihoon Song: Yeah, yeah.

Nico Flaig: attester maturity voted. For that block, you will be forced to set this head, otherwise you are clogged off, basically.

Jihoon Song: That's true. And you can replace it with just reorging an innocent payload today, or a block. So… Yeah, IL is, I think that's how I established my mental model. It is… It shares the same security assumption that we have today.

Nico Flaig: So, I mean, the thing is, so N plus 2 is not IL compliant, but… basically, N plus 3 could make the whole branch IL compliant, in a sense, right? If that payload basically satisfied all the ILs of the next committee. Because, I mean, we assume that the next committee will… have a lot of transactions in their IELTs that were not satisfied previously, right? Assuming they, like, should have the same view of the mempool, right?

Jihoon Song: Yeah, if they… if this block N plus 3 wins.

Nico Flaig: So, basically, there's no sustained censoring that you can… Even with 33% of the stack, you cannot have this sustained, right?

Jihoon Song: Very significant.

Nico Flaig: We propagate a non-IL-compliant branch and make it canonical with 33%.

Jihoon Song: With 33%… if that… if you have more than… if you have, like, 30% of testers in slot N plus 3, then you can just vote for this, plug N plus 3, and then it will become had. But I think it also depends on what happens in N plus 4, Because proposal boost. Because you're fighting against, other, like, 67. So, yeah, it depends on the situation, but if you assume that all slots, like, coming after, like, N3, N plus 3, if malicious had control over, like, consecutive slots, then, yeah, with ProPoster Boost, they can canonicalize payload N plus 2.

Nico Flaig: Yeah, I need to think more about this. I mean, the other branch should have more weight, though, right? You need…

Jihoon Song: Other branch, like this branch?

Nico Flaig: Yeah. Like, how in that scenario do the… do you even switch the branch to the non-IL compliant, if it's only 33% of the testers?

Jihoon Song: Yeah, so, I just drew two branches here, but I was assuming, like, I don't know, like, 10 different branches. For whatever reason, then… If this branch has, like, 10% of total stake it, and if this branch has, like, 30%, then we're gonna move to here. whether the… how much likely that situation is is a different topic. I just wanted to convey some… a hypothetical scenario that what should the EL return In this case. But in this case, if this branch is compromised. and payload N plus 3 is good, then you will gonna return payload N plus 3 for this new field.

Nico Flaig: Yeah, I think that seems fine, to me, at least.

Jihoon Song: Yeah. And one thing I wanna… Re-emphasizes this… all this, like. scenario. It's based on the same security assumption that we have for expos to reorg. So, yeah, this kind of, you know. Cannon equalizing a bad payload… a censoring payload. can be replaced with just reorging an innocent payload, and that will, I don't know. It can make it more easier to, you know, digest.

Bharath Vedartham: I have a dumb question, but, like, you can't build on a non-IL-compliant payload, right? Ideally. Like, attesters wouldn't, like, Vote for that. Brunch.

Jihoon Song: Yes, an honest attester will not gonna vote for it. But… If you have, like, a control over.

Bharath Vedartham: And…

Jihoon Song: Yeah. When the militias wanna censor some payload, then… Yeah.

Bharath Vedartham: Okay, good, that's…

Jihoon Song: So, that's for switching branches. And for a syncing node, a syncing node is in a node that newly joins the network. The CL follows the heaviest weight. It's just like, you follow the weight, no matter what PTC said. You follow the weight, no matter what, you know, you don't care about IL compliance for previous pay… past payloads. And we can assume that all payloads will do good, assuming honest majority. And honest major… honesty here is defined as following the spec Plus, having a good IL view. And the CL will gonna pass IELTS once it's synced, and it might miss… in the case that it misses some IELTS, And that makes IELTS have some sensor transaction. Right after it turned into synced mode, then it might lose the authentication rework, because they were gonna accept the payload, while honest majority were expected to

reorg the payload. But the network will progress as long as we have honest majority. And the next question is, okay, then how bad is it gonna be like? Then, yeah. So, the condition is here, and in my opinion, it is not likely, and even if it happens, it's just one attestation reward, you're not gonna get slashed, so… yeah, I think it's fine.

Nico Flaig: So that's the… so you have a scenario where you synced the block, but the ILs were broadcast in the previous slot, so you didn't observe those, right?

Jihoon Song: It can be, yeah. So, yeah, it depends on timing, yeah.

Nico Flaig: Yeah, I was thinking you have the same with PTC, but that's the part where, like, they are also in the block, right?

Jihoon Song: Yeah.

Nico Flaig: That block you. served the PTC awards. Yeah. There we cannot do that for IELTS.

Jihoon Song: Yeah, but… with IELTS, you can also request from your peers for your missing IELTs. If that helps.

Nico Flaig: So, but… So you asked specifically about the IELTs that were before the attestation, or before the U freezes?

Jihoon Song: Before you call new payload with the head payload. you were gonna just call all missing ILs, and the testers will gonna, I mean, Yeah, other validator will gonna give you IELTs that they observed until the due. I owed you.

Nico Flaig: Yeah, so you have to trust their view, basically, right?

Jihoon Song: Yes, but it is also the same with trusting them for giving you, like. I don't know, good payload or something else, isn't it? Of course, like, IELTs are not… It is something that you cannot validate, so it is a bit different, but still…

Nico Flaig: So the problem is, not a peer could give you an IL that was received really late, and that the proposal could not satisfy.

Jihoon Song: cookie. Could be.

Nico Flaig: You enforce it on your attestation, which would not be, like, that would be incorrect.

Jihoon Song: Could be. Then you were gonna lose a test station reward. And as long as we don't lose at least the majority because of this, you know, bad request response, then the chain will gonna recover, and then, yeah, we're gonna join the majority after one slot. I wonder if there is any…

Nico Flaig: and… Maybe just a check that the node doesn't vote if it didn't observe. the IELTS from the previous slide.

Jihoon Song: That is.

Nico Flaig: Seems, like, not that relevant, to be honest.

Jihoon Song: But then, still, you're gonna lose authentication reward, right?

Nico Flaig: Oh yeah, but I mean, if you restart your node, I mean…

Jihoon Song: Yeah, could be. It could be.

Nico Flaig: the rare case, right? It's the same today, if you restart it, and you got unlucky, and it was zoomed, whatever, a few seconds after it had to attest. Then you're also not gonna attest.

Jihoon Song: Possibly, yeah. It could be an optimization strategy per client, I think.

Nico Flaig: I think the only thing we don't want is them voting incorrectly. I think rather than that, they should not vote at all.

Jihoon Song: I see. Yeah, makes sense. But even if you don't vote. You might follow the wrong branch.

Nico Flaig: But you follow the branch with the weight, based on the weight, right?

Jihoon Song: Yeah, so after, like, one slot, you were gonna join the majority branch anyway. Like, is it a big deal to… Make a wrong attestation?

Nico Flaig: I mean, in this case, probably not, but if maturity of the network does it, then yes.

Jihoon Song: Oh, I, I, yeah. You can watch me, yeah.

Nico Flaig: But yeah, for the syncing node, thing, it's not really… I don't… like, this is really… an edge case, right? It's not gonna happen really often.

Jihoon Song: Yeah, unless, like, more than 30% of all testers suddenly, you know. Disconnect and try to rethink. It's an edge case, yeah.

Nico Flaig: But I think this is a general topic, maybe, that needs more discussion, because we have this in Lodestar, where if our head is too far behind, we go into syncing mode, which basically stops us from producing blocks and attesting. The main reason is we don't want to do these kind of attestations that are basically… that could be, like, even a DOS for the network, because other nodes need to process them, and they could be for really old heads. So I'm, like, this, I think, a general thing, could discuss further. I think maybe it's part of the hardening, even.

Jihoon Song: Right, you're… you're talking about… The one epoch window, right? when you fall behind 33 slots, you turn into thinking and then don't do any validator duties. And I think this is also the same with other clients, except Racism, if I'm not wrong. So…

Nico Flaig: I think Lighthouse at least does something similar.

Jihoon Song: Yeah.

Nico Flaig: And what you want to avoid there is mainly that you don't build on really old heads, which could even cause more havoc if the network is already unstable.

Jihoon Song: Yep. This might be a topic that we were gonna revisit after we… when we run some, I don't know, maybe more few DevNets.

Bharath Vedartham: How long do the CLs, like, maintain the inclusion lists for a slot? Like, so in the inclusion list store, you store this… ILC have seen for the slot. Do you prune that? Do CLC have to prune that?

Jihoon Song: So for CL, they can prune it after one slot, but I think they wanna… retain IELTs per branch. If, I mean, per branch that shares the same dependent route.

Bharath Vedartham: Gone.

Jihoon Song: It's like… Yeah, from… from IELT source perspective, they don't know whether this I.L. is coming from different branch or not, if they have the same dependent route, because it's just a… just the same… just different ILTs with the same IL committee root.

Bharath Vedartham: So, yeah.

Jihoon Song: It's just for the latest slot. But before the… yeah, before… for IELTS for older slots. The seal doesn't have to… store that.

Bharath Vedartham: Because I was wondering, like, let's say, I have checkpoints inking from, from a finalized block, like, when I… let's say I'm syncing a block, I fetch the vehicle block, and I also have to fetch the payload, and, like, the only way… maybe I'm wrong here, but the only way to validate that payload is to check if the… Il has been satisfied. So you also need your peers to have the IELTS, right?

Jihoon Song: When you're syncing, you… you will just follow the weight. So you don't care whether the payload has which IL, or whether it's satisfied or not. From your perspective, you will just follow the weight.

Bharath Vedartham: Okay, so you… okay, so I don't think… okay, so CLs, like, they don't call, like, the new payload API tool. I validate the payload, and then, like.

Jihoon Song: They, they call new payload, but they were gonna pass zero IELTs.

Bharath Vedartham: Oh, okay, okay. Huh, okay. 10 bucks.

Jihoon Song: Okay. And I want to ask some feedback regarding… When we wanna turn off intellectual lazy enforcement, like. Do we just felt… I think… We assume non-finality when… The last finalized epoch is older than two epochs. But… based on the example that I mentioned earlier, I wonder if we wanna… Trigger this condition after just one epoch.

Nico Flaig: So if you add this, right, you only need to, keep track of ILs based on your head view, or your head view shuffling, basically. Because there cannot be a divergent branch with a different.

Jihoon Song: Yes. Yes.

Nico Flaig: Yeah, I'm not so… or not 100% sure we should add this or not. But maybe discuss it more? I don't know, like…

Jihoon Song: Oh, thanks.

Nico Flaig: Potuz was in favor of this, right?

Jihoon Song: About what? Like, turning off?

Nico Flaig: Yeah, yeah, turning off IELTS during non-finalization.

Jihoon Song: I think there was a… Good enough rough consensus on turning it off during non-finality. even you… I think, yeah, you raised this issue, right? Like, there could be… peers might disconnect with each other if, you know, network goes bad, and then if we enforce IL, then it will not gonna help. improving aliveness, so it is… it makes sense to turn it off during non-finality.

Nico Flaig: Yeah, I mean, that was my argument, mostly, that we wanna probably prioritize liveness over censorship resistance, so… yeah. Yeah, keep.

Jihoon Song: Seasonal.

Nico Flaig: tracking per branch symbol and stuff like this?

Jihoon Song: Yeah, and even if… When the diversion lasts… lasts on an epoch. proposer, I mean, builders have to listen all IELTs, whether… yeah, because otherwise, there could be a… A valid transaction for both branches. But… Which is only included in… some IL in one branch. Then, in the other branch, if you are on a tester, and you listened to that IL, then you were gonna… Try to reorg a payload if it doesn't include the transaction. So, it is… it is just all about whether attesters and builders have the same IL view. And if there's any, like, divergence, then maybe it's better to

Not strictly expect builders to have like, perfect IL view. Yeah, so the point that I want to make is that Turning it off when network is fragmented makes sense to me, But… When do we turn… turn it off? It's something we have to discuss.

Justin Traglia: My personal feeling is just one epoch. So, we're looking for equal.

Jihoon Song: Bonnie Park.

Justin Traglia: I mean, I view this as, like, a circuit breaker, right?

Jihoon Song: Yep.

Justin Traglia: Stop. I, I don't think that… Censorship resistance is a priority during periods of non-finality. Yeah, I don't know, I spelled that one was appropriate. Okay.

Jihoon Song: Come on, Jermaine So, whether we put this one epoch or two. so, Nico, did you change your mind on having this… Condition.

Nico Flaig: No, no, I think it's… it's good to have it, But I'm just not sure we had enough people think about it or look at it.

Jihoon Song: Okay.

Justin Traglia: We can probably open it up in the Discord channel and see if we can get more… People to chime in?

Jihoon Song: Yeah, I can. it didn't sound like Justin, but anyway, yeah, I can, but… the only concern that I have…

Justin Traglia: Yes, it's too much.

Jihoon Song: Oh, hey. Yeah, my concern is that people are still busy with the ePBS, and if we just… you know, put everything on the list, then it will just stop there. So, my preference is a bit that, like, I don't have a strong opinion on having this condition, but still, I think it is better to make some progress, so my preference is okay. making the change with this… having this condition in the spec, and we can just make a list of something, like, something that could be more discussed. And if more people chime in and then vote for removing this condition, then we can take it out.

Bharath Vedartham: So, how does this look like practically? So, let's say… You, do you see that, okay, it's been more than epoch since… Finale, non-finality. It's been basically more an epoch since the last finalized epoch. At that point, the ease, inclusion list satisfied check. will… in that check, you basically pass, like, an empty list of IELTs to the EL. And which will always return, like, true. So I'm just, like, thinking… So, at that point, like, basically, in the CLs, you'll have it checked, like, okay, if… We are more than one epoch from the last finalized epoch. The IL list is just, like, an empty list, and we pass that to the.

Nico Flaig: No, no, I don't think it's like that. You would still pass the normal list to the EL? But in the… what is it called? Is inclusionist satisfied in fork choice? I think there would just be this check, is finalization okay, and then you return true, right, always. I think that's how it would look like, but, yeah.

Jihoon Song: But isn't it better to not pass IELTs in the beginning? Because the EL might be busy with some other task in this situation.

Justin Traglia: Yeah, I think… The goal of this circuit breaker is to free up some bandwidth for the rest of the duties to… to sort of, like, function more optimally. So, for me, it makes sense to sort of, like, limit bandwidth. as much as possible during… like, that's the whole point of the feature, I think.

Jihoon Song: Yeah, yeah. Yeah, I think we can discuss more on how we want to implement this feature in the spec PR. That I might gonna open in a week or two. Yeah. Okay…

Justin Traglia: Sorry, just maybe… it's neat at this point, but I feel like… You know, if it is something that needs to be discussed and sort of, like, get more attention from more client teams, maybe, like, the sort of, like, logical path is not to implement it, and… And sort of, like, wait for that question to be answered, instead of spending time working on it, and maybe that is worth for nothing. I think it's just a matter of choosing. Okay, yeah, that is… that is if… Yeah, sorry. Oh, good. I mean, I… I think it just… the only… Sorry, we're just trying to decide if it should be 0, 1, 2, or more, I guess. So there is already rough consensus around, we need that feature, and the only question is 1 or 2, or is it still…

Are there still questions about, like, do we need that feature?

Jihoon Song: In the fossil breakout we had in Svalbard, there was a good enough rough consensus. That's why I brought this up, actually.

Justin Traglia: Okay, okay. So then, yeah, then if it's choosing between 1 and 2, that… your approach makes sense.

Jihoon Song: Yeah, yeah. But, like, yeah, I'm not gonna argue that just because we had, like, good consensus in small board, we have to have this feature. It can be changed, but yeah, but this is where we are at today. Okay, it seems like… We discussed all agenda that I prepared for today. Am I gonna prepare some write-up on this work choice changes? And then ask for more review, Yeah, and this will gonna affect… Testing as well. I haven't really… Looked into how it will change test cases. But, yeah, once it looked like?

When we're gonna follow these changes, then… It's Felix, he's still here. Yeah, Felix and I, and maybe can discuss together to… How we… how we can implement these changes. Alright, I was a full… An hour. Do we have any more comments, or… Questions? Yeah, okay, to sum up, the main changes that I just introduced today are payload status V2, and how the EL treats accepted payloads. The CL needs to interpret the latest IL satisfied hash. Properly to, you know, follow the right fro-choice rule.

And… yeah. That is it from my end. Unless we have more comments or anything to discuss, we can go ahead and wrap up this call.

Justin Traglia: Nothing here, talk to you guys next time. Excuse me.

Jihoon Song: Right, thank you guys. Thank you, everyone. Have a great rest of your day, and… 0 and 2X. Thank you.

Justin Traglia: Bye-bye, thanks. Bye. Thanks. Bye-bye.

Jihoon Song: Thank you.

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