FOCIL Breakout #28

Transcript

Katya Riazantseva: Hello.

Jihoon Song: Hello!

You can wait just a few more minutes. Alright, I think we can just begin. It doesn't seem like we're gonna spring more people.

So, can you guys hear me okay? Alright, thank you. Okay, so hello everyone, welcome to FOCIL Breakout 28. Today we can share a little bit about The Hegota status, and then share some development updates, as always. So, for the Hegota side, we proposed a fossil for a Hegota for Hegota. Slightly after the last breakout call, we made a proposal. Here's the link in case anyone missed it. And to my understanding, we'll be deciding the CL Hegota in the next ACDC, which is on the 19th, so please check that call if you are available. Alongside with it, I'm currently working on to updating FOCIL spec.

starting from the CL spec, and then… Execution spec and engine API spec. The CL spec should be ready by next, say, CDC, that's our plan. Yeah, so for the CL spec, I'm thinking about two main changes there. So, one is about IL bit list inclusivity check, and the second one is about, IL compliance check. Yeah, actually, I was thinking about… how can I explain this nicely? And I made a… short scrape, so, Let me share my screen.

Let's see, okay, so, won't be long, don't be afraid. Can you guys see my screen?

Katya Riazantseva: Yes. Yeah.

Jihoon Song: Okay, cool, thank you. So, there are two main changes, and I just wanted to explain what that is, because it's a little bit different from what we Start back in the days, so… Let's start off. with IL bit list inclusivity check. So, we want to add the IL bit list in the bid, so builders build in this bit list indicating which ILS they've considered When building a block. And this serves as a good signal for a proposal. whether the payload will satisfy the IR constraints. It's not a guarantee, so builders can provide with an IL-incompliant block at the end, but if you see a bid that has an inclusive IL bit list, you'd expect the corresponding payload

would be IR compliant. And here, inclusive means the IL place is a super superset of your local IL view, so… If your view is, let's say, 11101, which means you didn't see the fourth IL, you expect bits with 11101 or 11111. And this inclusivity check can be done by either attesters or PTC. The trade-off here is what to reorg when it's not inclusive. If we go with our testers, we will gonna reorg become blocked, while PTC will reorg the envelope. But here, reorging Beacon Block gives us more… made bigger impact, because we were not gonna… we were gonna miss the whole slot, basically. So I think using PTC here is better. And my next question was, can we do better? So…

Do we have to reorg envelope if the bit list is not inclusive? And my current thinking is it doesn't have to be, because the payload can be IL compliant. Even when the petlist is not inclusive. This can happen when the ILs overlap, so the missing IL doesn't really add any new transaction. And this is not unlikely, especially when an IL is able to include most of transactions in the public manpool. So, my current proposal is to let's add IL leads to the bid, and let PTC do vote for inclusivity. But we didn't use it in the fork choice. So, the IL bid list itself is informational purpose, so if you found a builder. That makes a bid with not inclusive bid list.

or they make the bid with inclusive bit lists, but with non… I mean. ILN-compliant block. You can downscore them, for example. But I'm not… but I'm not 100% sure if this is the way we have to go, so if you have any better idea or feedback, please let me know. So, that was for… the IL bit less, and the second one is IL compliance check. So, when a tester for slot N receive an envelope for slot N-1, they check if it satisfies the IL constraints. In this case, let's assume that It did… it's not IL compliant, so it misses this yellow transaction. Then, a tester stored this payload as ILN compliant, and when they receive a PICOM block for slot N, they expect it to extend the envelope for slot

N minus 2, not N minus 1. They vote for the beacon block, or if it correctly reuse the IL-compliant envelope, so… This is it, so these two changes will be the main changes of the CL spec on top of Capella. And… Yeah, sorry, I… I didn't see the, the… the raise then. Yes, Justin?

Justin Florentine: That's okay. I actually had a question on the, the bit list being a superset of what was in the beacon block, and maybe this is a stupid question. how does the… how does the view merge allow for that? Like, aren't we saying that there are additional transactions that, not everybody may have seen?

Jihoon Song: Oh, so, that's…

Justin Florentine: Go ahead. Yes, Bluth, go ahead. No, I'm just… what I don't under… I guess, let me try to elaborate on the question a little bit. What I don't understand is that, we have a bit list of various inclusion lists, yeah? And that adds up to a list of transactions that need to be included, but… If what you're proposing is a superset of what was merged by the committee, couldn't you be asking to include transactions that not everybody has seen?

Jihoon Song: Or… For Builder, I guess, right? Because, like, when… Yeah, build… but I think it doesn't hurt, because the builder ends up including more transactions than you expect, and it doesn't violate any of the fossil mechanisms, so what could go wrong is when… a builder gives you non-supperset IL view, then you probably don't want to accept a bid, because it might contain, it might not contain I.O. transaction.

Justin Florentine: Okay, so we check inclusion against the committee's subset inclusion list.

Jihoon Song: Not against what the actual proposer saw. Got it.

Justin Florentine: That makes sense. Sorry, thank you.

Jihoon Song: Yes, so, yeah, yeah, so, when, testers validate the, IR constraints, they use their local IL view, not the one in the bit list. So… The bit list could be super sad, because proposer… Our builder have one more second to receive and update their IL view? Yeah.

Justin Florentine: So they have no idea that the extra transaction was somebody's inclusion list, they just see it as an extra transaction, they don't care.

Jihoon Song: They actually receive… they might receive an inclusion list that a tester hasn't seen yet. Because they have some extra time to update their IL view. But the… when you are validating, I.O. constraints. what you carry is actually a set of transactions, not the number of ILs. So, there might be a case that… yeah, so that's why I think It is better to not use IL BitLays inclusivity in our fork choice, because there could be a case that it is not a superset, but the payload itself is actually IL compliant.

Justin Florentine: Got it. Thank you.

Jihoon Song: Thank you. Do we have any other question?

Mehdi Aouadi: Yeah, I'd like to ask a question, about the difference between the, PTC, Checks on the attester checks. So correct me if I'm wrong, but, if we go with the, PTC checks, does that mean that there will be, no… Impact on the fork choice, because in my understanding, rearguing the envelope is done earlier, right?

Jihoon Song: Reworking the envelope. Yes, because PTC doesn't… They… I mean, PTC vote doesn't say anything about whether the payload is IL compliant or not. But actually, so what… what I'm proposing is, let PTC to vote for the IL list inclusivity. So, whether the IL is in the bid was a superset to their local IL view. But actually, it doesn't have to be PTC. I think you made the right point. It could be done by our testers. Because, yeah, I need to think a little bit more about this, because, It's not… it's not set in stone yet, so…

Mehdi Aouadi: Okay.

Jihoon Song: Yeah, the… I think the Gist… that I wanted to convey is that, we want to add IR bit list to signal proposal that this corresponding payload would satisfy the IR constraint or not. But… And we also wanna ask testers or PTC to vote for ILB Middle East inclusivity. But we don't want to… I think it's better to not use that information in our fork choice. But whether testers or PTC vote for that inclusivity check is something that we have to think a little bit more, so yeah.

Mehdi Aouadi: Okay, I see. Yeah, thanks.

Jihoon Song: Thank you. Do we have any other question, or anything's unclear, or seems weird? Alright, I'm planning to make a PR By the end of this week, so… I think we can have more productive discussion once we have the code ready. So, yeah, I'm pretty sure that we're gonna revisit this topic in the next breakout, so if my explanation was not clear enough, it's okay, we can just revisit it later. And, yeah, so that was… all that I wanted to share. Do we have any other updates or something to discuss?

Yes, Tyler?

Pelle Krabbenhoeft: Yeah, I guess I can go over some of the research I've been doing on the different delays with the inclusion list. The data's a little messy with using the Excel data, from PandaOps, but, it's pretty much what everyone assumed with the current setup, with zero delay. 20% are… 20% of the transactions in the inclusion list are getting added to the next block, Regardless, so essentially, it's a wasted space, and when we move the delay to 1 and 2, it only increases by about 0.1%. It's still pretty messy, because there's a lot of spam transactions, and I can't check the state, since it's all historical data, but… Other than that, and the censorship-only IOs, which are just transactions that have been flagged as censored, as you can expect, the delay doesn't really affect them, so…

I think a one, slot delay, as talked earlier, wouldn't be too bad, but… I got some new data that I'm gonna go over soon from, Block Native, so hopefully that gives me a little bit more resolution, but yeah.

Jihoon Song: So… if I understood you correctly, delaying it by one slot would give us better results, because It gives us extra 1%.

Pelle Krabbenhoeft: Gives us extra 0.1%, so there's not much of a difference. Yeah, I'm not quite sure if it would really look like this, on, like, a live node with ILS implemented, because we are having such a low inclusion rate of the mock inclusion list. So we're building a mock inclusion list and then checking how many of those transactions get added into the next block. And obviously, the IL is not actually being applied, and that's only about 20% of the mock IL with the current mempool data I have. So, I've been trying a bunch of things to filter it out better, but, right now, it still also seems like it's a good idea to just fill the include… the full inclusion list, opposed to only doing sensor transactions.

Jihoon Song: Could you expand a little bit of the censorship detection algorithm?

Pelle Krabbenhoeft: Yeah, for the censorship detection algorithm, I was just looking at transactions that were valid. They were above the… Base fee, and we're also above the top 10 or 25th percentile of priority fees, so we're not looking at, like, bottom-bottom transactions, stuff that should likely be included. I can pull that up now. The average IL was including for those transactions per block for the mock ILs, but it was just a very simple this looks like it should have been valid and put into a block, but it's been sitting in the mempool for 2 plus blocks, I believe, is the current setup.

Jihoon Song: Got it. Right.

Pelle Krabbenhoeft: And hopefully by next time, I'll have this ran up so it's not just me talking at everyone.

Jihoon Song: Yeah, that makes sense, yeah, great. Maybe we can also have… simulate various Intentionally building algorithm, and then see how it affects the research. I mean…

Pelle Krabbenhoeft: I was thinking, yeah. Yeah. Yeah, it would definitely be possible and pretty easy to, like, add on top of this, but yeah. Definitely for the future.

Jihoon Song: Yeah, yeah, we'd love to see if delaying it by one slot would give us much network bandwidth saved, so… Yeah, it's a great research, I think, so… and thanks for the update.

Pelle Krabbenhoeft: Yeah, and on the network bandwidth, you're looking at… yeah… About 20% saved, because you can… Wait, sorry. Wait, never mind. Let me think about that for a second.

Jihoon Song: Yeah, because… I, I think that network… Bandwidth save is… 0.1%, according to your current data.

Pelle Krabbenhoeft: Yeah. Because that's what we… yeah, yeah.

Jihoon Song: So, yeah. Yeah, we'll see. Yeah. Looking forward to the update. In the next breakout call. Thank you. Alright, do we have any other updates? Alright, Ethan. We can just go ahead and wrap this call. Yeah, thank you guys for joining. Hope you guys have a great rest of your day, and see you guys in two weeks. Thank you!

Katya Riazantseva: Thank you, bye.

Mehdi Aouadi: Thank you, bud.

Pelle Krabbenhoeft: Thanks.

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