FOCIL Breakout #3

Transcript

[Music] Thanks for joining everyone. Uh yeah, I think this uh call well I don't have any presentation to make per se. Um I do know there are some uh cool updates and some progress to be shared by by some of you guys. Um I wrote some stuff down on the agenda just based on discussions and what's been going on. Uh you can also like always follow what's uh happening on the Discord inclusion list uh channel. But uh yeah um maybe the first update we could talk about will be the

first Prism and G interrupt uh which I know yeah Terren and Jun have been working on quite a lot. Um I think it's very exciting. So I'm like really happy but uh I would actually love to hear some more about exactly the progress that has been made um how we are doing with tests ideas as well and um yeah uh if Terrence or Jun you can uh you can share what's uh what's going on that would be like super helpful.

Yeah I think I can start and maybe Jun I'm sure he has a lot more to add there. So uh what we did was I would say the basic minimum um testing scenario. So um I guess one week ago what I did was that I started overloading fulu with fossil. So meaning that um fossil is included in fulu hop forward that at the for transition from elytra to fulu uh fossil gets activated but then like as time goes on I starting to realize which with the feedback of parry and many people that I probably shouldn't be

doing that meaning that fossil should be its own hard fork that is EIP uh 7805 has its own heart for number and half version. And the reason that we want to do this is because of in the long term if you want to be more serious that um to generate tooling and to generate spat test you don't want some sort of dependency with flu and um meaning that once it gets CFI I'm not sure what the entire process is with the IP kind of forgot sometime but once it gets CFI once it's included for um inclusion for flu then we can u put that back into flu but right

But so it's it's basically it's it's it's its own halfwork on the prism side. I'm also happy to provide other branch if people really want to test fossil with fulu or test fosra. That's not that much work to me. In terms of testing um it's basically happy case right now. So what it means is that I made sure that inclusion list with the help of transaction spammer there are transactions in the inclusion list they are getting submitted and then those transactions are um essentially getting um sent from the CL to the E to update the blog process. What we have not done is basically some sort of censorship testing um basically to make sure that

um the transactions that the builders or the proposers are not um basically not putting in the payload that gets included through inclusion is somehow that's something that we have not verified. Um other things we have now verified are basically like different meu inclusion rule and then basically making sure that even though if there's like one um honest um inclusion dismember and then 15 of them are essentially ignoring transactions um that one um that basically one that that basically that one member is sufficient enough to say include transactions

within the first few um slots basically. Yeah. Uh Jiun, do you have anything to add here? Uh maybe if I can just ask one question. I was wondering what you guys think about the best way to like test the actual censorship case like should we censor like a specific sender address like like what what is like the most realistic uh test case we can we can make for this? Yeah, I can start. I'm sure Chinhun has a lot more to add there. I think there are two ways to test this and uh I sort of prefer the more na uh the more natural way. The first way to test this is that you add

another testing endpoint on the transensus layer which allowed any arbitrary party to submit transactions and those transactions essentially will get included through this inclusion this mechanism and these transactions may not exist for example in the public manput for example that's one way to test it do some sort of back door testing and but I'm I'm not sure if this is something that we want in the beacon API this can just be a testing endpoint Right. The second option is that you actually modify the EL behavior. So say today you modify the man pool to uh say that I don't allow transactions from the sender address and then you essentially um you basically have some mod modified version

for that basically and then you say okay I I want 15 nodes um maybe like 80% of the validators they essentially do not run uh basically run that modified version and then you allow certain percentage of the valve to just run the honest version and see what happened and based on that we can essentially simulate censorship behavior. Nice. Okay. Yeah, that makes sense. It feels like to test the one out of n property which is what you said about like only one is honest and the rest is censoring. Uh maybe the second way to test like actually modifying the main pool would allow this but not necessarily the first one if I

understand correctly. But I don't know maybe just a combination of both ways to test is actually like the right way to go about this right and there are another few test cases is amazing. I would just point out on the prism side that today we have this window that essentially they say that after 8 seconds that the inclusion transactions will not be counted from the tester point of view and then we actually do not do that. So that's definitely something that's missing in my implementation that I'm not consider that window right now. Another thing is that we haven't tested that um more than two more than two IIL scenario meaning that if there the two IS from the same sender the IIL should not be hunted

basically people should ignore them uh for the new payload call for the next slot that's something that we are we haven't tested as well but yeah I had this documentation uh I think I shared that earlier and um yeah um yeah I'm definitely looking feedback for more test cases Nice. Yeah, thanks. Yeah, I feel like the equivocation one would be also nice to test with the um cases in which like uh you know or like second IS are like just submitted at boundaries where we expect like maybe the the the network to split its view. uh that would be like particularly like interesting to test so we can check if the timings we set in

the spec are actually like working and and like people have enough time to determine whether like someone equivocated or or not. But no nice thanks a lot for sharing. Um and yeah Jun do you have some more to share? Uh yes um um thanks for the great update. Um if I may add something to testing side. I think um it feels like we need multiple client variants like sensoring one and equivocating one and I think testing would be um would reside in CL side. So we could use curtosis and

oer tour. So I might try using also tour to uh uh uh to make the test cases uh somehow reproducible way and as Terren said we can modify E to censor certain transactions. Uh which type of transactions are censored doesn't really matter in terms of functionality testing. So we could just uh make sure that the proposer omits certain transactions in the EL sets. So yeah, that could be possible and um um or the interrupt work uh if I share my update. So I worked on based on

what Terren did. Um so I I've made that knife inter finally work and one lesson I want to share is that when HL tester verifies IL compliance uh they need to fetch IIL from the previous slot. So if current slot is slot n then they need to fetch uh cached IS from slot n minus one. It's quite obvious to hear it but it wasn't when writing code. So I hope this could save other clients time a bit and then uh yeah and I also have a write up regarding the interrupt.

Please take a look into the doc for other details. And for my next step, I will be adding tests using probably author based on test scenarios written by Terren. And um and I I think we need to modify Dora to display per slot. Um although I'm not sure which information we want to add to make dora for fossil but I think just displaying I per slot uh would be easier for us to test cases and yeah so that's all from my end. Um is there any question?

Uh yeah from from me but I don't want to okay well let me just ask uh for Dora like do you mean per slot is just like displaying every ILIL and every transactions in the for each slot in the explorer? Yes just like um just like displaying transactions of payload. I think we can display um unique set of transaction that are included in each ILIL or if you want we can display IIL of each ILIL committee members. So yeah, which one do you think is better?

Yeah, I feel like the row version of like per committee member will be great because then we can just do the simple union and and check like what was included in the payload. But having like the sort of like row inclusion list for me makes makes a lot of sense. Cool. Cool. Yeah. So I just wanted to add that it might be harder because of by looking at the blog today even after Fossil that you cannot tell which transactions came from IIL because since we don't have this like I inclusion this like uh summary we don't have that in block builder. So you probably need some sort of like I don't know like a well first of all beacon API

I I believe NC had a PR for the beacon API uh for inclusion this so we probably need some sort of streaming and pulling that as inclusion comes in it basically gets streamed whoever they subscribe to the stream I suppose this may be useful for useful for the builder as well and based on the streaming endpoint that Dora will know which inclusion this are for the slot and because of that you can kind the like tell uh like what transactions in the block are based on the inclusion this but yeah it probably needs more thought around that yeah makes sense okay yeah that makes sense yes

do we need API for implementing it in curses uh in Dora was a question by yes I Guess we need some streaming API as Terrence mentioned. Maybe Terren can um elaborate it a bit. Yeah, I think you need some sort of API to get the inclusion this basically like whether it's streaming whether you just like a uh rest get but yeah I'm not like an API person here. I'm sure yeah there are people there more well knowledge they can answer that.

Yes. So the beacon API PR has the inclusion list event already there and we added that in load stuff. Um but I'm not sure if Dora uses the events to populate data or I guess the alternative would be a OP poolool API where you would just fetch for the previous slot the data. Actually, I talked about this to Perry the other day and he told me that he can connect me to someone um some some maintainer of Dora.

So, yeah, maybe we can talk about this and then yeah, find a good way to implement it. I was see of course nice. Okay, maybe uh another question. I don't remember if it was included in your doc terance but like one test that feels important is looking at what happens during congestion. Um, so I yeah, we need to make sure like I don't know populate the main pool enough so blocks can be filled or stuffed and see what happens and how builders can then choose to exclude some

transactions from the y uh uh yeah I think that will just be like a very important test case to to look at and it doesn't sound like extremely easy but uh but we should definitely do Yeah, definitely. I think for crytosis there's transaction spammer. That's the service we're using. But then again, like we can probably fine-tune the transaction spammer to be slightly more aggressive. Just right now the inclusion is the transactions are not nearly as full as I like to see. So yeah, definitely I will make a note of that.

Okay, awesome. And uh I think related to this one other item on the agent I noted was an actual call for helping build a meool vis visualizer. Uh so you can check it in the agent that thing but let me post it here. It's been speced basically by if panda apps if I understand correctly. uh and will be useful for a bunch of cases. But I don't know if someone in the call like is inspired by this and and sort of wants to to contribute or or take this on uh it would be useful obviously for other things but for for soul as well. Uh so yeah just wanted to to signal this here.

And then we covered the fill being now its own uh its own fork. So that's good. Uh yeah. Um and now yeah, I kind of wanted to open it up to maybe other clients. I haven't talked as much to I have talked a bit to Matthew about load star but if there is some more progress on on your hand on your end that would be like super nice if you you could share where where you guys are at.

Yeah. So for low star we've made a lot of progress in terms of implementation for last two weeks. I think the basic implementation is 95% or pretty much done. We just need a couple more days um for some more internal review to see if there are any missing pieces that we've missed on the implementations. Um yeah, so we we're getting very very close to to be ready. Um and also yeah, I just want to touch a little bit on the beacon API spec.

Um yeah, I I post a comment uh about a more polished version has been opened on the public beacon API repo uh with some minor modification on uh some of the endpoints uh including produce inclusion lists uh should not be returning a list of inclusion lists but instead it should be just like a list of transactions only because I don't think VC needs the the additional info uh of the inclusion list including the slots or validator index or the IIL committee roots.

So I think only returning a list of transaction should suffice. Uh and also uh for the uh IL committee duty endpoint it should return the IO committee roots there. So V VC uh when it signs the inclusion list uh it should has all the in information uh it needs to sign. So it kind of simplifies the uh um the endpoints a little bit. So to that point um currently I think I still needed the IL committee route to be returned because um the current

signature scheme is over this object which consists of slot inclusion is committee root transactions and then the validated index right so the VC doesn't know the inclusionist committee root so Are you saying just have the signature over the transactions and that's it or Yeah. No, no, no. So uh the uh what I'm proposing is the inclusion list committee roots is not returned by the produce inclusion list endpoint but on the inclusion list committee duty endpoint but the okay but there I guess like but

are you calling the get duty endpoint every slot then because some clients only call the duty endpoint at the EPO boundary right and but then if you do that then you you don't know the inclusion this community rule stay for slot uh 15 so how lowar is implementing this is uh when when uh the beacon node is returning like uh the inclusion list duty along with the inclusion list roots the about that the client will just cash the duty along with the with the committee roots.

Yeah, but I don't think most client code this get duty point at every slot. Yeah, we're just doing it every epoch. But how do you but then the increasing this committee route changes for every slot, right? Doesn't it premputee? Doesn't it just depends on a shuffling? Okay. Okay. That I think that kind of makes sense. Okay. I will think more about that.

Okay. Yeah, that's uh that's pretty much all the update from OAR. Okay. Nice. And just maybe a stupid question, but like are you when you say it's like 95% there, like are you talking about interrupt as well with like an execution client or No, it's just like very very basic implementation. We're just like following the spec and just to code it up and we're still trying to see if there's anything we're we're missing.

Okay. Awesome. And is so is the logical next step is trying to interrupt or and tests I guess. Yes. So we have tested it locally a little bit. Uh at least the P2P side of things is working locally. Uh we just need to test more. Okay. Great. Yeah. Awesome. Thanks a lot for for sharing. Uh it's it's really good to to see progress on on your end as well. Um yeah, Jacob, I asked you and I know you've not looked at Lighthouse uh yourself, but uh Aan had some updates.

Do you can you just share where things are at if you're here? Yeah, I didn't get any uh super specific updates from Eton, but I think uh we're just moving that fork over into the Sigma Prime repository um and where they will take ownership of it and kind of drive it forward. Okay, nice. Yeah. Yeah. Okay, that's what I I had in mind. So, because before you were looking at it and now there's is there like a dedicated person even in

the call for lighthouse or like are they just like planning on just taking this on? I don't see that anyone from lighthouse is in the call but yeah my understanding is that um Nan will be taking it over. I'm not sure that he has 100% bandwidth allocated to it, but my understanding is that he'll have at least 50% bandwidth allocated to it. So, um nice. Yeah, that's great. Thanks.

Uh and you've been also working a bit on on the rest side of it, which is also quite nice because correct. Yeah. I'm uh yeah debugging some interup stuff with Prism. Um and yeah getting some help from Terrence there. Um but yeah. Okay. Okay. So the goal is like interact with the between Prism and and Re uh until there's another CL that is right available to test with you.

Okay. Awesome. Nice. Thanks. Uh are there any other updates? Uh Ka Ka I saw you um you you you did share some things in in the discord channel and as you have been working on this so I want was wondering if you had anything to share. uh I started working uh so as as far as as as the curtosis works now uh I started working on the dashboard so today I just worked uh with the current metrics I found uh in the fossil in prison um yeah and I'm going to proceed

um with it as soon as I have any updates I will share in the chat the one proposal from me is to as we're going to standardize metrics. Um um can we just standardize the names something like bacon inclusion list uh every metric should begin with it um for consensus clients um if you don't mind this is how we do on the for pas uh for execution client um I'm not sure yet I'll ask Perry uh uh I think that uh execution clients don't have any standard for metrics names.

Maybe someone knows if not um yeah I will propose something like exec or something. So I think uh for for the next call I will have already something dashboard. Thank you. Okay, great. Awesome. Uh yeah, I'm not sure about like the standards and everything, but uh feel free to reach out also if you uh have questions about this and maybe we can make some standards uh from from this effort. That might be like also like a good way to do things moving forward.

Yes, great. Thank you. And any Yeah. Does anyone else want to share updates? Um I don't talk to all clients so I'm not I'm not sure. Yeah. Yeah. Yeah. An update from from tech team. Uh we made some good progress on for uh basically we have implemented the peer-to-peer layer and uh we're working on the RPC side of it. Um, basically we we still don't have a a working implementation, but we are left with the uh fork choice changes and probably from this week we'll have some more people working uh on fossil. So we might go a little bit faster uh to a at least a

minimal working implementation hopefully in two weeks or so. Yeah, that's okay. Awesome. Yeah, this is great. Okay. So, yeah, we have a couple of people that are kind of aiming for working in implementation by the next school, which is cool. And then we can sort of like I guess try different combinations or of CL and Y clients uh with all the tests and like actually like get some metrics uh with KA and how things are doing. Uh that sounds like a good plan honestly. Uh it's it's really great to to see some progress. Does anyone else want to share something?

Yeah. Then we can probably keep this one short to be honest. Uh and see how we are doing next. Cool. Uh yeah uh I'll also have like probably something to present I want to get feedback on about like uh trying to get privacy for for for IL committee members and what you guys maybe think of it. Uh, I was also like, okay, maybe one idea I wanted to share is like what do people think of um um having transactions?

Well, okay, maybe I'll I'll wait until actually I was just like a do a cliffhanger and maybe I'll actually share like more details on the next pool, but I was like trying to see how we can evaluate for once it goes on mainet mainet if it does um and maybe like trying to to have ways to see who is censoring and and and who is not censoring um by uh by including some transactions in in the main pool to to check uh that everything is going well but that might be for later on and I can share more like well-formed intuitions and thoughts maybe on on the next call.

Um if if that's it for everyone uh we can probably call this meeting and get half an hour. Uh thanks thanks again for everyone that came and for sharing the updates. It's really nice to see progress on like a mini clients and and now that we have interup I'm actually very excited to get like some results and and tests and see how we are doing with all the different scenarios we can kind of think of. So yeah thanks uh thanks a lot and and see you guys in in two weeks.