FOCIL Breakout #30

Transcript

Jihoon Song: Right. Hello, everyone. Can you guys hear me okay?

Justin Florentine: Yes, we can, Jihoon.

Jihoon Song: Thank you, Justine. 4 minutes in, I can… I think we can start. So, hello everyone, welcome to FOCIL Breakout 30. Today, we can share development and testing updates. Perhaps I can go first with testing updates. So we started EL and CL fossil testing. Nothing much to share that, except that we started, taking a look into our testing. So we are in contact with Steel Team to discuss how we can go about BL testing and other CL testing. I think we will mostly work on reference tests. Yeah, that's actually pretty much it. If anyone is interested in helping us. on testing, please let me know, and… Yeah.

So, does anyone have anything to share on development updates? Maybe, Justin, I have a question for you as well. Last time, I heard that Besu might start implementing fossil on top of Amsterdam. Do you know if… That work has started.

Justin Florentine: Yes, it has. I have a draft PR that I'm currently working on right now. It's very early phases. It's very rough, but, yeah, it started. I don't have too much to report, haven't really started testing or anything like that. It's literally just at the spec implementation phase.

Jihoon Song: Got it. maybe you share the link to the PR?

Justin Florentine: Sure. It's in my own fork, but yes.

Jihoon Song: I'm… is current… spec okay for… EL implementation, I think, like. It's a little bit outdated, especially when it comes to versions, like New Payload V6? Ding.

Justin Florentine: Sorry, good question. I'm basing it off of what's actually been published, not necessarily any PRs that are, outstanding. So, it could be, it could be a little out of date, this implementation.

Jihoon Song: Gotcha. Let me update those PRs, by this week.

Justin Florentine: I mean, right now, this is just me and an agent kind of grinding on it.

Jihoon Song: Can I expect that this PR… will… Be promoted to actual implementation?

Justin Florentine: Yes.

Jihoon Song: Got it. Cool. Nice. Any other development updates?

Mehdi Aouadi: I can give a quick update for Teku. Basically, we started merging all the Heze Fork, boilerplate code. And, we're planning to add fossil on top of Haze, so… Yeah, hopefully that won't be an issue when we start interoping, because I see some people are here, adding, FOCIL on top of Glamsterdam. Oh yeah, but for now, I won't touch the Docker I published, which is based on top of Fulu, but at some point, everything will be based on top of Hazy. Oh, yeah.

Jihoon Song: Awesome. Thanks for sharing. Do we… do we have any more updates? Alright, at least we have… one CL and one EL working on fossil on top of… Amsterdam, so… yeah. Looking forward to seeing more clients. Working on FOCIL. All right, do we have any other updates other than development and testing updates?

Matthew Keil: Oh, just as a note, we are planning on doing the updates, but we're just finishing up our Glamsterdam, now, so once we get DevNet Zero squared away, it's stable and there's no issues. We are intending to rebase everything on top.

Jihoon Song: Gotcha. Thank you.

Pelle: Yeah, I can… By leash. Where's their echo?

Jihoon Song: Yeah, please go ahead.

Pelle Krabbenhoeft: Sorry, there we go. Yeah, I can share… finally share some of the work I've been doing on the mock inclusion list real quick. Just need to have, like, 5 slides I'm just gonna run through. Anyone see that?

Jihoon Song: Yep, you're good.

Pelle Krabbenhoeft: Perfect. Alright. So getting into it, ayy… The main point of this research was to answer three main questions. We want to figure out what building inclusion list is going to look like in terms of redundancy. So, how many of these transactions that are getting added to the inclusion… the inclusion list, would have been included into the block without the inclusion list? We also wanted to see how much, delay of 0 to 2 slots affects this redundancy. It's definitely going to go up, but by how much? And also see what those redundancy numbers look like. for different strategies, in this case, just top fee and censorship-only I.O. So, top fee is how most of the clients, I believe, are building inclusion lists, where we just take the best transactions from our mempool, and then spend it up to the chain.

So, the way this was all implemented was using block-native mempool data from, from PandaOps's Quick House server. I did try to use the X2 data, but it's super noisy, and there's a bunch of spam transactions in there, so about 70% of transactions in that data never even make it on-chain. And it was very hard to parse for legitimate transactions, but the block native data is a lot It's been cleaned, and it also has some other metadata that allows us to do this analysis a lot quicker, as the X2 data, it takes about 30 days on my hardware, so I kind of had the… I need to use my laptop every day, so, decided to just go with this block-native data, which took about 3 days to run. But basically, we're gonna grab that data.

Filter out the transactions, so no blob transactions, make sure we're reaching the base fee, and anything that makes it fossil valid. And then we'll build a censorship Inclusion list, which we'll get to in a second, and that top fee, and then we apply that to the… N plus 1, N plus 2, and N plus 3 slots, and see how many transactions got included on-chain, and you'll see the day in just one second. Here's a better picture of what it looks like for the censorship window. We're just looking at the last 12 seconds. The reason for this is censorship is pretty low, so none of these censorship inclusion lists are ever getting to capacity, and also it solves the problem of

we're trying to build these mock inclusion lists on data where inclusion lists weren't a thing. So if we have a bigger window, then we're going to have a lot of overlap, and then it can kind of distort the numbers a little bit. And then for the normal top fee, we're just doing, as the spec says, from negative 4 seconds to 8. From our point of view after block N. So, this is for the top fee inclusion list. As you can see, they're about full. This is, this is from the block native data, only covering about half the mempool, well, half of included transactions, and not the full mempool and being significantly filtered. But… We can assume it's about full, and as you can see, about 92% of those transactions are essentially wasted bandwidth, and it goes up by about 2 percentage points, and doesn't change much after the second spot, delay.

And then, this is what I found a little bit more surprising, with these censored transactions, so basically anything, that was in the mempool when the last block was being built but never made it, and met, all the requirements, and we're also checking to make sure that there was a room in the last block. So, using this strategy, you can see we get a little bit less redundancy, so the inclusion lists are actually helping, with UX and censorship a lot more, but it is still a pretty significant amount of these transactions just aren't getting included. Those would probably fall if you're looking at a further back window, but as mentioned before, I think it'd be kind of hard to backtest that.

So with all that said, the redundancy seems pretty inevitable, and as some people were talking before about, oh, we should only, just… just use censored transactions in the inclusion list. Obviously, there's no way to fleece that, so we can just assume all inclusion lists are going to be full anyway, but the best approach is likely some sort of hybrid approach, because it's not… Doesn't require too much compute to find those, sensor transactions, but that is still up to the client. And then, I would strongly suggest trying to keep us at that zero slot delay, but worst case, one slot delay, depending on EPBS and the implementation, shouldn't be too horrible. And then, just as a… Just quick leaving notes.

It'd be interesting to see what happens to these numbers in a high censorship environment, so if it's a lot easier to see those censor transactions, can we see those redundancy numbers collapse, maybe testnet, future testnet and such, but, there's a lot of… I don't know how important it's going to be with deciding how we end up building inclusion lists, but it'd be… it'd definitely be interesting if anyone has more, like, block-building experience can come up with a more sophisticated way to do this, but… With that all said, let me know if you have any questions, and I can drop the full report in the… in the group… in the chat.

Jihoon Song: Amazing. Thanks for sharing. It's good to see that different I.O. building algorithms Already have different outcomes, even based on the past dataset. I'd encourage client teams to adopt different strategies. I guess it's more about coordination that we probably need to handle down the road. I have a question, so… When we… use… half the algorithm, it seems 6-8% of transactions Are not timely included. Do you know… Which delay after those transactions are included?

Pelle Krabbenhoeft: So the transactions that aren't here, I can pull it up again. You're talking about… These transactions. So… Yes.

Jihoon Song: So…

Pelle Krabbenhoeft: Yeah. I mean, there's no specific, reason for it all the time, but, I couldn't find a reason for why they're definitely not getting included. It's definitely another good thing to look into. I still have most of the data, so I could possibly take a look, but my best guess would just be, And not making it into the mempool for, whoever the builder is. It seems like most stuff does get included eventually, but some stuff that we can see from the block native data that sits for a while, or eventually gets replaced if it sits too long. But we are checking for fees and everything, so, there's definitely no clean answer to that.

Jihoon Song: Right, so are there… are there transactions that are not included forever, and they would… I mean. I'm talking about those transactions that are not included. In this chart, like, those who are part of this, 6-8%. So, is it correct to understand that Those transactions are either included, And after some delay, Or… not delayed forever? For whatever reason.

Pelle Krabbenhoeft: Yeah, the vast majority… Lock Native did some… they had a nice chart of this, but it's a very… And they also have a stale tag on the data, but none of the transactions I could find were, like, explicitly censored. They either made it in, or they were in the mempool too long and eventually became invalid.

Jihoon Song: Right, right.

Pelle Krabbenhoeft: Yeah. Sorry.

Jihoon Song: And… yeah.

Pelle Krabbenhoeft: Yeah, do you also…

Jihoon Song: have…

Pelle Krabbenhoeft: Yeah, go ahead, sir.

Jihoon Song: Yeah, so, yeah, I just wanted to ask you about, like, do you have, like, rough data Indicate that, Like, on average, like, they get included after, like. For example, like, 6 sulas, for example. did I… Yeah, so… My question is, like. If they are included after a certain delay, did they get included, like… I don't know, like, maybe… Like, 6 or, like, 10 slots, or, like, do you also have any insight on that delay?

Maybe you're on mute?

Pelle Krabbenhoeft: Yeah, my bad. Yeah, I did some per limit. I did some, like, smaller queries when I was looking into it, and I didn't see anything alarming. Most transactions, like, 98% or so, maybe even higher, were included in the next 5 or so blocks, or became invalid. So, that's my best answer for that. But I didn't see anything in those investigations that led me to look further into it.

Jihoon Song: Right. Maybe it is also worth to see, like, If there is any common… Characteristic of those transactions, like. Maybe those transactions are the ones who… touch Tornado Cache, for example. Yeah, it's just an idea.

Pelle Krabbenhoeft: Okay, yeah. And just another note on this, too. It would be a lot better for, like, further expe… data collecting and such would probably do a sidecar method, but you'd probably want nodes across the world, just because it's… it's tricky to figure out if something is actually valid without this state. You can do some stuff and If a transaction makes it into the mempool, it's supposed to be valid in most cases, but it's definitely… A lot of this stuff is not clean-cut to figure out if it's actually being censored based on the historical data.

Jihoon Song: Got it, makes sense.

Justin Florentine: Do you need access to an archive node?

Pelle Krabbenhoeft: Yeah, that could be useful. Yeah. Yeah, if anyone has… Any ideas of other stuff to look into, or resources, yeah, feel free to reach out to me.

Jihoon Song: Do we get a different dataset if we have an access to some archive node?

Pelle Krabbenhoeft: I haven't looked into… I looked into it a little bit with my… oh no, not a… or… running a node and just following the chain node archive node. I haven't done any work with archive node, sorry. It would be pretty simple to just follow the chain, and but if anyone has any experience working with archive nodes. I'm not quite sure.

Jihoon Song: Okay, I can, I can take a look into it. I mean, I can ask around, like. If I can provide you any access to some archive node. I mean, if you are up for it.

Pelle Krabbenhoeft: Yeah, that'd be great.

Jihoon Song: Yeah, okay. about, I mean, when it comes to same-slot, enclosure list. post a PBS. It's still an idea, but there's an idea… To make… Balls. Be propagated separately to payload. And set ball's deadline much earlier than payload deadline, such as 6 seconds into the slot. And… With this, we can allow… Intellectualist committee members to… Update their state earlier, and so that they can build Fresh IELTs. Even when they receive payload late. And don't have enough time to… Executed… To have the latest state. So, I think… we would be possible to have same-slot IELTS even after EPBS.

Pelle Krabbenhoeft: Sounds good.

Jihoon Song: Alright, yeah, so another good thing is, I think. IL building is not specified, and it's not part of consensus. So once we have FOCIL on mainnet, maybe we can also analyze real-world data to fine-tune IL-building mechanism. For instance. So in this simulation, currently censorship window is set to test 12 seconds, and, you know, this is because it's a, IATs are hypothetical, but… It'd be really nice if he can have, if he, if he can have this effort. be continued after we ship FOCIL, then it will be useful for people who are interested in you know, elaborating their IL billing. algorithms, whether it be researchers or client teams. So, yeah, it's great work.

Pelle Krabbenhoeft: Yeah, or if there's any MEV potential for your… I can't think of anything off the top of my head, but I wouldn't be surprised.

Jihoon Song: Yep. Yeah, makes sense. Alright, cool, thanks. Do we have any more updates? Yes, Katya?

Katya Riazantseva: Hello, everyone. Not an update, but I have a question. Do we currently have a single source of truth, like the Cortosis config and, The client's images, whenever they're ready. Just to quickly spin up.

Jihoon Song: We still have some Kurtosis config for… On top of Fallu. But I'm not sure if it's still working. And… Nowadays, client teams are working on FOCIL on top of Amsterdam. I don't… yeah, we don't have cartosis config for post-Chall Amsterdam.

Katya Riazantseva: Okay, got it. Maybe later in the channel.

Jihoon Song: Yep. For sure. Any questions or updates? Alright, I think we can go ahead and… wrap up this call. Thanks for joining, and hope you guys have a… Great rest of your day, and… Let's catch up in two weeks. Thank you.

Katya Riazantseva: Goodbye.

fdifabio: Excuse me.

Jihoon Song: Love it.

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