FOCIL Breakout #39

Transcript

Justin Traglia: Good morning.

Jihoon Song: Hello, guys. Let's just wait for a few more minutes.

Alright, I think we can start. Hello, everyone. Welcome to FOCILL Breakout 39. I think we can talk about client development and spec changes. Can we start with client status updates?

Nico Flaig: No update from Lutzer said.

Fabio Di Fabio: Yeah, also on the Besu side, I… And FOCIL on… other Amsterdam priorities, so… I still need to implement the storage side. on the EL… Schedule.

Jihoon Song: No worries.

Mehdi Aouadi: Yeah, Teku's FOCILL branch is rebased on top of, DevNet 7, so… If anyone, want to test, they should use, branch the rebate on top of, difference.

Jihoon Song: Nice. Do we also have anyone from Lighthouse? I guess not.

Marc Harvey-Hill: For Nethermind, we're also based on DevNet 7. And last I checked, it seemed like all the tests were passing, but… I'm not sure if they've been updated to the latest specs, so… need to check that again once they're updated.

Jihoon Song: Right, so that's… that… I mean… ACDE WISE. The ELS is currently rebased on top of… I think it's closer than Devna7. But… it hasn't… reflected the latest spec changes, especially EnginePIs one. So… I'm gonna bring this up again so that we can have the latest, spec test for ELs. Gotcha. Do you have any more client updates? Alright, I think we can move on to spec changes.

First off, The EnginePIPR has finally merged. Okay, it's right from there, and thank you everyone who helped merging the PR. Next, there have been a bunch of changes made to the IELT store. So this is the PR. So the name of the size limit constant is changed. It was max bytes per inclusion list, but now it's changed to max Transaction Bytes per enclosure list. This is because the previous name was a bit ambiguous. People asked how the size is defined several times, so I hope the new name removes the ambiguity. I'm just gonna keep iterating. The EL store functions are also improved. They were written in a Pythonic way, which might be not super readable for non-Python developers. So 55.7 aims to improve its readability.

By using typical if statements and for loops. We can, of course, iterate more whenever we find a better way. If you have any questions, feel free to just interrupt me. I'm gonna just drop the link to the PR, and then explain what the changes is. So, next PRs are gonna… be related to request and response. If I remember correctly, Nico pointed out that IELTS store cannot respond to requests and response, because it stores just the message, not its signature, so this 5487 addresses that issue by storing signed intelligent list. Also This PR is based on NSS findings. NC found that IELTS obtained via request and response should be fed to on-in collision list, and on-in collision list doesn't have

sanity checks for the IELs, so he was solely relying on PRB checks. Regarding these changes, No, except… but this constant name changes, because I think EL also share the same constant name. I think I need to check… I don't remember correctly whether ELs use this consensant name, but I can check it. So, for EL, the change is just name changes. So, going back to this… 55. 13. This pure adds some basic checks, and it also replaces the IL committee root field inside IL with dependent route.

This is because you should be able to check whether this IL is coming from I'm sorry, you should be able to check process ILs coming from different branches. then you should be able to tell whether this validator is actually an encoder. So you need to get the shuffling, so… You can fetch the state using dependent route. This PR is not merged yet, so if we have time, please give it a review. And then, next PR… is… 5512. This is the last pair that I'd like to introduce. This combines timeliness and inclusionliness into one field in the IELT store. The RAN is because they are always coupled.

I guess, and since… Not here… So… Yeah, I also… Just want to ask people here. About, like, what people think about this proposed to change. Maybe it's easier if I… Join my screen.

Nico Flaig: Yeah, so don't we store for blocks and, like. Other stuff, the… it's a separate field, right? That would be my only thing. But I would need to double-check.

Jihoon Song: You mean in the fork choice store?

Nico Flaig: Yeah, why do we fold it in here into one thing, and then for blocks, we have, like, a separate field, right? Tracker?

Jihoon Song: Yeah, I also had that question, and from my understanding is that in the fork choice store, there are some cases that we fetch Like, time linear payload time lineage, work block time linear separately. But in the EL store. at least with the use cases that we have today, we always fetch inclusion list and its timeliness together. Like, when we are calling Get InCollectionList transactions, or… Like, whatever. Like, we always handle them together. Not sure if this is gonna be changed in the future, but that's the main… Reason of this proposed change.

Nico Flaig: I mean, it's probably fine, right? Like, it's just a refactoring, so…

Jihoon Song: Yeah. Of course, we don't have to make a decision today, so… Just wanted to introduce… What are being changed, and why, so… We don't have many CL devs here, so probably it's better to just leave this PR open and ask for more feedback. Yeah, so… That was… Yeah, that was it for… merged and open PRs.

I have one question that I wanted to ask, but before… We move on. Do we have any questions or comments? Right, The question that I wanted to ask is about how clients, I mean, CL clients implement the ILT store, so… EL doesn't need to retain IELTS more than two slots. And currently, the key is IL commit root, and you can derive this from a pair of slot and dependent route. But, in terms of pruning.

I wonder if it's going to align the spec-in implementation more if we change it to SLOT and dependent route. So, for instance, if IELTs are accessed by slot, and then dependent route. Then you can easily prune all values accessed by current SLOT minus 2.

Nico Flaig: Yeah, I'm pretty sure we do something like this for proposal preferences, so… Opinion makes sense.

Jihoon Song: We don't have… like, pro-poser preferences were in the spec, right? That's, like, open for implementation.

Nico Flaig: Oh, yeah, yeah, that's like a scene cache we have on the client.

Jihoon Song: Right. I think my question is. if you were to implement the IELTS tour, I guess, you were gonna make it somehow accessed by SLOT. For printing purpose. Because we… we had SLOT. I was too full of SLOT and EL coming the road, rather than… Two layers indexing. But we removed SLOT, thanks to ANSI again, because it is very not likely to have a coalition between IL committees within an epoch. But… I was thinking, like, how this pruning can be actually implemented, and just having it keyed by IR commuter Road is… Probably not the way that it's gonna be implemented.

Yeah, okay. I think I can… open up a PR, and then just ask people to chime in later. So… This is it for the spec changes that I have. That was the top end. Is it a… Is it a tuple, or… SLOT and the pender group is like a… Do you have, like, two indices, or just one? bad. Yeah, so…

Nico Flaig: Always, you look it up by slot, and then you have another map, which is, like, the dependent route to the proposal preference. And then, when you prune, you just… I mean, then you… it's indexed by SLOT, right? So you can just do this. Not sure if that helps. My dear. Finger to move.

Jihoon Song: guests?

Nico Flaig: development.

Jihoon Song: Yeah, I guess this is better than just… Adding some kind of, like, a timer or a listener. are in college at least, to… Get called after two floods.

Nico Flaig: Yeah, I mean, for us here, we just call this array slot, right, and then we check if it's below, I mean, in this case, if it's below the current slot, proposed references are basically useless, so we delete them. I mean, the logic is for… I guess you want to keep two slots, right? So… so slot minus 2? If it's smaller than current slot, you can prune.

Jihoon Song: Gotcha. I'm gonna take a look into how other clients handle proposer preferences, just for reference, and then… I cannot put up a PR. Right. Thanks for sharing. Hmm… Yeah, so do we have any other comments or questions? or… the first… Arsenal-only DevNet. as we discussed before, I think we can just, based off

whatever the latest stable claims for DevNet or Testnet, and… Whatever the latest FOCIL spec we have. Not sure when we were gonna… work on this FOCILLDEFNet. actively, But, yeah. Which version is the latest spec release? Is it Alpha 12?

Justin Traglia: What's, Alpha 13?

Jihoon Song: So we're already on Alpha 13. I think we can make another release, because we already have some changes made after Alpha 13.

Justin Traglia: Yep, we could make another release.

Jihoon Song: Yep. Right, thanks for sharing this. References? Mehdi? An Nico? Right? That's it for me from my end. Do we have anything else to discuss? There. I think we can go ahead and wrap up this call. Thanks for joining, everyone. Have a great rest of your day, and see you in two weeks!

Marc Harvey-Hill: But…

Mehdi Aouadi: Thank you, Ben.

Jihoon Song: that beta.

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