FOCIL Meeting #2

Transcript

[Music] um thanks for joining everyone to fil breakout recording stopped recording in

progress um yeah and so from noan I think the the idea is to go with a by weekly Cadence um like yeah meetings don't have to be like this packed uh with with news but uh would be nice to just have like a a regular meeting so that people can also like plan for it know about it and and attend if they they want to uh we have like planned updates and presentations from like a bunch of of you guys uh but before I wanted to just do a

small small like yeah short presentation about some ideas that have been popping up or that I had for the past month uh how can I share this okay and people see it nice uh yeah so one thing I wanted to fly I'm going to go like very briefly because I do want to have time for like discussions around

implementation but uh yeah some things I've been like thinking about lately are um what forel might become in the future uh and one idea was um trying to separate roles uh so we know PBS proposal Builder oration but like I was thinking maybe it would be interesting to also think as includers which are now I proposers or I committee members are just like a a very different set of participants um that could be rewarded by like an independent uh reward mechanism uh and whether that I mean that mechanism is not specified yet but

we do have some efforts towards this so if any of you has ideas or want want to contribute uh please reach out because I think it's just like cool to also think about like what the future of fil might look like um and so in in this post I I'm I suggested inclusion fees or like a new transaction fee that will just go to I committee members um but it could also be like redirected priority fees it could be issuance I think Tony had a comment on the post suggesting this um I asked uh Twitter and people were leaning leaning towards transaction fees but I think

it's like nice and there are like some almost philosophical U discussions we can have about like what should be used to reward uh people that contribute to improve ethereum's sensorship resist and properties so yeah if anyone wants to contribute to this effort uh I wanted also to flag osle which is also like about like a very um different way of rewarding uh I committee members or or includers we also have a grant uh a grantee from nether mine research uh that's right now working on like kind of trying to Define what transaction like a TFM might look like for for fil uh so

yeah all ongoing efforts but like uh we're interested to get also like contributions from from Outsider for anyone from anyone that wants to contribute um yeah I also posted this which I think is kind of nice to just take a look at uh which is like uh basically the percentage of uh uh honest validators which means like validators that actually like honestly include all transactions they see in the in pending in the public M Pool um for for all transac to be included if we had for with like various sizes of uh of

committee so you see that even with 16 uh but also like of course it improves as you uh like increase the number of of committee members but uh yeah you you just need like 15% of uh the validators contributing uh to be honest and to include on transactions for for all of them to be included within the same slot which I thought was was pretty nice and uh this is like made possible by the one out of end property just like the fact that you only need one uh Committee Member to be honest uh for the whole mechanism to to work properly so yeah I just thought it was it was nice to to to

show this uh we also had some um I boost or like the emergence of a market for uh ILS uh we had discussions on on Discord with that was initiated by by POTUS and then we had some some thoughts from from teren from from from Julian uh but also from people that are that haven't uh contributed to those discussions before like people that like Paul that is like really kind of deep into precom um and so yeah I don't want to get into all of it right now but it was more to like flag uh and yeah also maybe push people to actually go check

out these discussions because it's it's quite nice and it's important to to discuss this as a broader maybe set of of of people um and yeah that was pretty much it on my end uh reach out if you want to work on all this uh let me stop sharing and now we can probably so does anyone have thoughts uh about any of uh these topics or does it does anyone want to say something okay nice uh yeah reach out if

you want to actually uh contribute On Any of of these research directions maybe the last thing I wanted to flag is like we are actually also starting work work on like the Privacy or anonymity as ECT of ILS and what it might look like in the future with the linkable ring signatures and Anonymous broadcast protocols uh so if that direction that research area is also interesting to you also please reach out um but okay so the Highlight is more on the implementation side of things uh for today uh I know some of you have been working over the holidays on uh making progress on on the fil implementation and

and so I wanted to highlight this today um uh maybe let's start so we have a couple of people that have updates uh we can probably start with parents uh if that's fine yeah that's great one second let me share my screen um okay okay I presume you guys are able to see my screen let me know if you cannot see it also feel free to raise your uh hand and interrupt me if you have any uh questions so basically I don't have any slides unfortunately but what I have is I'm just like implementation notes that

I have made some opinionated design Choice along the way when I was implementing fossil for prison some of those are probably wrong and um and uh I have to admit that my PR I think it's in a pretty good place to start testing for fossil but then again if any serious people that start review my PR will'll probably find multiple buds as well that's another my disclaimer but I can probably just share my notes um in this code and um just for the consensus layer fent team that's implementing F we'll probably run into do similar design decision that I run into but yeah so let's get started so I

kind of separated them into like block processing block construction syncing validator API category so for Block processing you have to make a decision on what you do when you sync a historical block that essentially doesn't have inclusion this right in the current inclusion this design it's kind of like goldfish it basically only remember inclusion this at the slot of so when you sync a block until the current slot you you don't really get inion this for those block and there's no way of getting it from P2P we don't even have we don't even have RPC request Point basically for that right so when you

code engine API new payload that you cannot have C an inclusion this and because of you don't know it right so I don't know what is the right API definition for that this is like I don't like basically API stuff I I just I I love working on it but I'm sure there are people are have like better expertise in terms of like basically what is the definition for that so I made this opinion choices basically says that if you're sinking a payload and that's not for the current slot for which I don't have to incision this I'm going to pass s empty inclusion this to the engine new uh into this new API P so

I assume the E client here that is given empty um inclusion this without check for inclusion this validation obviously that's probably not right but noting this is my uh this is my kind of design decision I feel like this is the cleanest for prison at this moment but yeah and this is this is the first one the second one is that as a note I have this memory of like unsatisfied inclusion this block rout so basically when I call new payload and and then a new payload by definition will return if it returns this status it says invalided inclusion this I will remember the block group for that and then the reason being

that uh when I C uh get head for validator Duty um if the if the head is the same as um this U the the previously cach blog route that's unsatisfying this I will essentially filter the uh the block R and get a remov that's the only reason I am uh basically caching is basically a 32 buy cach that catches the inclusion this um that catches the block rule that doesn't satisfy inclusion this and uh again this is pron design decision basically I'm sure some people will implement it differently and then uh I have a g as well that essentially just filters out

the um inclusion this basically sorry to filters out uh what is the right block rout to use for validator Duty so attest will use that to attest for B Block rout s committee will use that to vote for head route and proposal will use that to build on top of the parent route and um I haven't I added this to-do basically but this is not right I think there's a to-do which Michael correctly pointed out in the Discord that uh the spec should be more um cleaner in that regard that it should be using what we have for G proposer route uh just currently there is this helper GA which is used for reor blog we should be uh adding the stuff

there basically and then so that was for blog processing and for Block building uh how do you essentially alert um that um your e client that's already building a block given for update and payLo attribute how how do you passing the includ this to then currently I just have a background routine essentially so uh I have a background routine I think it's triggered at the 10c Mark or 11 second Mark I GA the current slot inclusion this I I I first check if there's a proposal for the next slot and then I passing the inclusion this essentially again this is dependent on the engine API and point what we do

currently the engine API PR that J open has this end point that I'm using it's called engine update p with inclusion this which you pass in the P ID and then you pass in the inclusion this and then you get a new payLo ID back basically and U so this is all depends on the engine API again I haven't worked on the engine API much before so depends on what engine API we're using here I I will have to change this design you can think of another way is essentially to passing the inclusion this in the for updates payload attribute and they use that method to update so this all depends on Eng API let's see and then so and then

for syncing I basically have the gos validation pipeline it's basically the same thing as what we know on the PTP spec for the inclusion this transactions it's a nasty bites and uh for the SS's perspective I it's a list so I just have them as a list as what we have ation payload and it's very very big but that's doesn't matter that's just for coming to consensus and we have I have this manual check they saying insures of transactions does not exceed 8 kilobyte and that's basically uh what's defined the spec and uh I think one my to-do or someone else can help is that I want to review the um the ordering of all the

checks for the gossip to ensure there's no potential do concern because I want to kind of group them into you do the cheaper check first and then the more expensive check L and then how do you cat the incision this here again this is my design like I'm sure there's better way of doing this I just have a key of mapping of slot to valid dat index and and then the value is essentially The Nest bytes of transactions and then a special flag that just saying scene twice do we see this did someone try to uh send to inclusion this and then if and then basically here are the gathers and if if the add is adding the inclusion this gets called twice on the

same slot Val index the same twice flag gets flaged true and then but then there's one design consideration if that worst case the memory usage for this is probably eight four megabytes per slot because you assume 8 kilobyte of inclusion this per validator and you assume there's not much duplicates in the worst case scenario so you probably want some sort of of like nice Printing and stuff like that so they are typical ways to print it and then last but not least for the validator API stuff uh so prism has its own like grpc API that's used for validated Duty so I mainly work on the grpc API I didn't work so much on the Bon API I know ni's working on the

Bon API so we'll probably should make his is the default look at his is but again I feel like it's pretty similar the only thing is that when you get in the inclusion disc um there's a design decision to make on what is the input right currently I just have the input slot and then I check whether it's a current or previous slot and then I return the inclusion this transactions and it's incenting index but there are multiple ways of doing it you can also input the validator index as well and stuff like that and then return that and for valid changes it's fair simple as well you a validator you assign to a duty and then if you know if you're performing a duty then you're performing

Duty you f inclusion this you sign inclusion this and then you send it but yeah this is what I have and I'm happy to share the notes in the chat or after the code and yeah questions work thank you yeah yeah sorry I'm yeah yeah it's K uh I have a question about the cash so uh you store in the cash uh inclusion lists and what about uh transactions from execution payload so I think that for slot n plus one the ATT testers also um store or check the transactions uh being included in the execution PL

load if I got it right or not yeah yeah so uh to clarify this is the inclusion this cach for catching for the next slot proposer specifically so I know the so I I know I so basic so I know if you're I'm proposing for the next slot right so so um hold on one second no no let me uh okay no sorry this is the cat for the net slot propos and also for the net slot attests as well so your question is basically how does the net slot attest use that essentially to know whether to

vote on the right head or not right so uh so for the attrition payload transactions you get that over the network essentially so so at so say at t uh a minus one I get the inclusion this I add those to the cash and then at the next slot which is N I receive the payload and then I process the payload and I use that cash to process the payload for the new payload code so at that point you have the transactions already from the payload because you just receive over the network so it's basically compute on demand yeah yeah I got it thanks so on the next slot you you you don't write in

the cash right no you don't write in the cash okay nice maybe um more like a high level queue of like uh yes there are like different design considerations and and different efficient like you can consider different implementations for for finding like the most efficient ones but like have you encountered like any blockers or like What's the progress been like and and where are you at in generally like I have

I I haven't gone to a blocker but then again as my disclaimer earlier is that there there are some portion of the spec I wouldn't say this the spec itself engine API and consensus spec which is the two thing I'm looking into I will say are not like 100% complete as well so I'm just so the idea of this implementation is that given the knowledge I know today I go as fast as possible I have a prototype and then I can start testing it and then use it as a feedback loop to update the spec right so I think like we're getting pretty much we get we're getting start getting pretty good feedback these days on for example uh the beacon API definition

that nich's working on and then Michael suggestion on using get proposal head and then I also have another um documentation which I point out the other day is that how do we essentially get an inclusion this committee do we want to uh cat do we want to use something that's like shuffling basee or do we want to use something that's like G aggregated base basically that you don't know who the inclusion this committee over ahhe so I I so I think yeah so I I think design uh writing code is probably easier then figure out those Minor Details of the spec which we probably want to spend more time on okay sounds good and then so I guess uh testing is is also like uh something

you are like looking into and and maybe that's a good transition with the Jun because I I know you have uh tried to work on this if there are no like any more questions for for ter uh maybe one sorry yeah go ahead okay so um one was related to the peing apis that NC was working on so uh there might be the case that you have two validators in the same slot which have to produce an inclusion list how do you handle that right now because I see you also only pass the slot when you get the inclusion list so you just get a single one

right so uh so there will be two separate call as well and I do not have some sort of cash basically to basically so the second code so the second code I will essentially Cod the E so I will cod the E once and I will cod the E twice so the question here is what does the E return me does the E return me empty for the second Cod or does the E return me a different inclusion this or the same inclusion this then again I think this is another interesting aspect of what the API definition is so I can see like three different like correct answer here

right whether it's returning you nothing for the second returning something different or you the same thing as well but from my prison perspective I am treating them as two separat yeah because it could be similar to produce attestation data and then the Val data just signs twice over the same uh inclusion list but I think here it would not add any value right because exactly yeah yeah I think from the philosophical point of view they should be different data then again I think this is something the client diversity might also be nice if client one does something slightly different than client two then it becomes harder to G CH so you had a question uh yeah I had

a question about the the second section you have no remembrance of unsatisfying uh list block route um like in my mind you should not need to remember anything about previous inclusion list or whether or not they're satisfied so I was wondering like are you using this uh at all or like in what way are you using it so this is just remember one uh one block route and that's only used for uh current slot so this is used for uh a testers that's voting for essentially for the tester that is voting so I need some way to essentially to filter out uh the head

rot basically knowing the current head rot cannot be used for for lmd G VT and then I have to use the parent route so this is just for uh the current slot testing okay yeah that makes sense uh I was looking at this spe right now about this and I wonder if it would be useful to actually clarify this in get a tester head because in get tester head there's nothing that says that you're only doing this for the current slot um like I I think in principle if the like I don't know there were a bunch of empty slots and the head is still like some older block that didn't have a satisfied I at that time then you would still be applying this kind of filtering which I don't think we really want to do so

maybe yeah know maybe like just hading in the spec this like only for the current slot to kind of do this extra thing and get a tester head or like only the R from the yeah I think so as well I mean I think it's even better to uh I think like also mention the get proposal head because Michael was right to point out that currently there's a two ways of like it's kind of weird that because of late slot reor or late block reor that there is another way of choosing head but there for for proposal Duty or valer Duty and here's another way so like will be nice to combine them into one single

function I mean I don't know I guess I have to see how that exactly works but I a bit skeptical about this just because get proposer had shouldn't really take into account the the compliance information in my mind it's just like for example you can imagine a case where um the proposer happens to be on the side where they saw the I uh too late maybe or or sorry they they saw the early enough they think the block is compliant but like most other people haven't seen in um most other people don't see that the don't think that the block is compliant um and I I really think that the proposer should just decide based on votes and not based on

their own kind of local view of iil compliance so I don't know how to like homogenize the two if I mean it feels to me like the I compliance really belong only to a testing behavior and not to any other kind of behavior okay that's something we probably can settle offline with micro nice uh yeah great uh any other questions for for ter or should we move on to move on to Jun how more of a general question I guess um on if there's uh in the

implementation or in general if there's any ideas for uh deterministically seeing how the final block is being built right because you have different pipelines you have inclusion uh you have transactions that are being Force included and then you have um as you also showed in the diagram earlier you have transactions that are going through the regular Mev boost pipeline um and so when they all meet in the final block is there some deterministic ordering mechanism that's being used or if part of the block space is reserved for fossil based uh transactions versus those that aren't right uh yes so no in in the current spec uh this is all kind of uh yeah you can go back to the IP but

basically the block producer which is well either the Builder or the proposer is free to include uh fossil uh transactions wherever he wants uh in the block so there is no enforcement in terms of and ordering um and yeah no ordering and no position specifically so we let it free to the block producer to include transactions whereever uh they want as long as uh they're included that's like the only condition we enforced uh yeah and are there any pros and cons to uh

being ambivalent about the ordering just because um you know if there's certain Atomic batches that need to be ordered in specific ways or have those guarantees yeah the the whole idea is to try and and avoid the emergence of an i Market uh if imagine like the worst case worst idea I think at least will be to say uh fil transactions uh will need to be included uh at the top of block and then all of a sudden all the me transactions are going to crowd out like potentially sensor transactions uh just because they want to get uh the top of block spots so since we don't want that uh uh like actually like giving some

unconditional block space and like specifying an exact spot at which I transactions need to be included uh should beo avoided understood understood thank you yeah of course uh are there any other questions okay nice uh so maybe Jun if you here uh yes okay yeah you are great yeah uh let me share my screen R uh sorry I need to change my setting

so I need to rejoin um okay no worries we can uh is Jacob here yeah you want to to give some updates as well yeah I can do that um let me it's going to be much more high level than terence's doc but um I have some notes Here let me see if I can share okay I'm assuming you guys can see this um yeah just some quick notes and then I also have some links here to the diffs of my repos against the uh upstreams

um so yeah we got some support on Lighthouse from Eton of the sigma Prime team who I believe is on the call and we also have some others who have expressed interest uh to help on Lighthouse as well so my plan is to shift the majority of my focus to wrath uh on the El side and also help out um yeah getting things mered into my house maybe ultimately will that fork uh into Sigma primes re um and so and the

plan Onis devet with I think pris is uh further along as of now um so the initial plan would be to um launch some percentage of the El clients with a modified uh mle that would filter transactions basically not insert them into its own mle based on something like the call data which I think would be maybe the most straightforward either that or a particular Cinder um and uh we can configure this uh

transaction spammer that you can configure in uh kosis to uh broadcast transactions that are quotable defined however we defined this uh mle logic um one thing that came up or it's come up before um but um is whether to use reuse the fork Choice updated engine API or to go with API in point I think we called it update block within version to allow the consensus layer to signal

to the uh execution layer that it sh in its view of the current uh Global inclusion list um so that the execution layer can incorporate that into the payload that it's building so in ref it's much easier to do this with the existing Fork Choice updated however that would require some changes on the calling pattern from the consensus layer because as I understand that the consensus sler is only calling Fork Choice updated once after um it sees the block for that slot and so it would not in order to

incorporate the inclusion lists that are coming later in the slot uh you I'd have to call it again or the um first and only call until you've pretty high confidence about uh seeing all the inclusion list um but yeah and then I shared some links uh Alloys is just kind of a collection of rust grates that the W uh repo uses quite heavily and then there's wrath and Lighthouse and then we also have uh Fork Cho Fork Choice PR from Eon so yeah if you're interested in uh collabor please reach out uh try to be

responsive and and find some some good issues to work on sorry um but yeah if any questions be to take them but yeah this is a little more high level than terence's bck otherwise that's great okay cool um ah can you put it back on maybe oh sorry yeah okay okay nice uh all right so what's the the plan

exactly with the with curtosis like when when do you think like what do you have like an idea of like where where you guys are at in terms of progress on on on R and and trying to get that working with the prism or on CIS yeah I think I'll go ahead and implement this update block with inclusion list uh because that's how ter has implemented it and I think that should be doable within the next uh day or two at least I can wire up some um some kind of dummy method just to make sure that prism is actually calling

this API at the at the proper time uh we can and start collecting feedback there and that I could probably get done by the end of the day um but yeah once that's done then we can yeah start start iterating much more quickly at least uh yeah with with the prism okay awesome great okay uh does anyone else have uh have questions okay uh and then yeah I mean again ites nicely with I think jiun has been

working on on curis as well recently for for prism so Juna if you're already Yes um let me share my screen sorry for the um this commmission config issue yeah um so before I start this let me share the links to the write up and GitHub um can I see this yeah so you can see the detailed

instruction for running curosis in this acmd and you can find all the necessary scripts in this repo so um yeah so today I will be talking about how to configure and run a local devet using prison and get prototypes um I prepared the write up and so in this presentation I'd like to focus on um delivering a high level overview but please feel free to interrupt me if it sounds to hand wavy or if you have any question uh before we begin um just like many other cor devs I'd like to say

special thank you to Perry um there was some issue with um curtosis um so like for instance if you go to Dora repository clone it and run it at the latest commit you will see that it fails um the reason is there was a release changing minimal conflict preset following the spec and some client teams haven't reflected yet um and it Panda team noticed it uh last Saturday and I uh connected to uh Perry this Monday after Str struggling about that issue over the weekend and um anyway he saved my tons of time and and um shared many

tips to play with curtosis so yeah let's get started um so we want to build Docker images of the prism and get prototype and use them to run a local devet with CTO with cortosis so let's go step by step so how can we build Docker images of prman G and you can just copy and paste this command at the root of uh each repository but this is already over 10 L of code so I prepared a script in the hope that it may make your life easier you can find a script at the GitHub that I shared at the chat so let's say if you are working on prism

then you can put this script at the root of prism ripo and then excute it and then you can see that it will give you darker images like this and here is our curosis config and you can see that it refers to those doer images that we just build locally so this enables us to make changes locally and then test it against the local dep net so I think it's cool so how can we run curtosis you can colone this repo and then go to cryosis directory and then just hit make run but um some might just interested in running a local devet

without building darker images so I also made Docker images based on the latest comments and published doer Hub so in case you want to just Fetch and use them you can just hit make run registry instead so once curosis command is done it should look like this and if you go to Local Host 65500 you can see Dorado Explorer the number is just maging number um and let's say that now we want to see what each node is doing then we can print all the logs of Json RPC communication including engine API Bon API and execution API but this might be two varibles to follow what one specific

node is doing so instead we can specify a note that we want to track and in order to do that we need to know the identifier of the node and in curtosis there are services and each node is running in a service so we can get the list of service names using this command cryosis inclave inspect fossil fossil is the name of The Enclave that I orded in that repo confict um and let's say that we want to track um here like snooper engine one prism Gap and then we can specify that service name here and we can see all the logs that it printing

um yes so this is a brief introduction of how to run curtosis and I'd like to share what we found so far so if you just CL the Ripper and run it then you can have a definite of prism and G prototypes and it works well on D but it Miss it starts to miss all FL after Electra Fork is on and in the in the log we found the suspicious log complaining that when a new engine API new payload V5 is called uh it complains that um UNM Maring array of incision list B1 failed so I'm

not sure if this is if if this bug lies on prism or G maybe G I guess but nonetheless we found a bug and we have a starting point um since we are using Main config we are able to modify seconds per slot but we cannot change slots per Appo so if you don't want to wait for one EPO to see uh what's going wrong you can just simply set Electro Fork EPO to zero and it maybe save your time a little bit and also if you want to run a deant using different client such as red and Lighthouse then you can just replace

this participants field of curus is confict so let's say that if you want to use uh get and te instead of get and prison then you can just specify corresponding uh Docker images here so yeah this is all from my end and here are the links to the write up and get up again and thank you for your listening awesome thanks a lot uh there is a question by by teren yes please um not so much of a question just a comments that probably so there are a lot of engine API related changes

happened over the last few weeks so depends on where the Gap your rebase is on whether and then just right now for testing Electra or death5 we're using specific costume branches I think that's either on Cena or like client's re so depends on that you may see some issue but yeah we can sort that out offline but I do have a question it's probably rather a like slightly difficult one that we probably won't get into for the last 12 minutes but I just want to throw it out there that having the ketosis is very great right because it allows us to test the happy path and um we can transition from say d to Electra to Fossil hard for but there is still this

problem that we need to figure out that how do we test that fossil is inde working right because when you run kosis there is no censorship so even though if you run the additional Service as as the transaction spammer all like like you like basically you will see all the transactions including the blog but you're not kind of sure whether there is a mle censorship and then we're using the fossil committee to include the transactions so I think I find it difficult that how do we essentially see that part like V like I think either visually or do large or something so yeah do you um do you have any thoughts on

that um I think that's a really good question um so in current implementation of prism we have submit inion list and that is called by Von client I validate client right so I haven't read that so that's one thing I can do is to add that casting end point uh I think that's one way right and then I yes I think that kind of helps because now you can just submit transactions to that point and to make sure those transactions are included so you know it's working another way is to I guess like uh I don't know how to do in get but like um uh just uh add some censorship I guess like um don't include transactions from

this address when you could get payload or something and then yeah and then see whether it works to inclus this mechanism yes I think that would be simple we can U make another branch that imposing some censorship and then we run two different types of G so one is censoring and one is not censoring and we can see which one is censoring um by the service name and we can see if all blocks produced by that node is not accepted if it makes sense yeah I think

we can yeah that makes sense intuitiv yeah we can probably uh I think something to chat about offline because we only have 10 minutes but yeah this is awesome thank you great thank you nice thanks a lot any other cues or I I think maybe uh we move on Cu uh NC do you want do you have like update or or something something to share as well yeah so for low star I think we are about halfway there in terms of the full implementation um we have finished the uh the gosip topic gosip validation uh

the work resp and also engine API definition uh yesterday I also posted like a first drop on beIN API uh spec and also I think Nico uh did some implementation on the beon AP lar uh so the remaining big bigger items will be the for choice and also the IL cash uh which I believe uh could be done uh within a week or maybe two weeks and and uh yeah and we um and also uh we probably want to write like a

design decision uh hack MD similar to what Terrence did with prism uh when we got there but so far uh we we just been following this back and just Implement them awesome yeah that's great uh cool okay so there is not much much time uh remaining but I guess I would love to hear from anyone that's been working on it and I haven't really necessarily been in touch with like does anyone from other clients uh I don't know does anyone started did anyone start work on this yeah maybe yep uh an update from the te team actually we started also working on for sale uh

we had separate Branch uh we started working on it since last week so uh we did some progress um we still don't have a working version of it but yeah since things settled down a little bit with Electra uh we have some bandwidth so yeah we're we're we're making some progress there okay awesome yeah great to hear um um yeah I've started uh prototyping and implementation of this in the nethermind client um I'd say it's still pretty early stages like I need to um test if it works and everything um but actually I'll just paste the pr in

the chat in case anyone is interested nice yeah thanks uh okay so that's great we it looks like we have quite a lot of clients that have started working on this it's awesome to hear um originally so no first are there like any outstanding questions like does anyone have other questions related to implementation yeah K uh yeah I have a question about um um the number of inclusion lists uh propagated uh so in the abstract I see

that one uh validator can gossip one e and the in the equivocation um I can see that it's no more than two Els uh so is it discrepency or how it works no no it's like the if the validator just like follow follows the onp then he should propose just one I but like in case of equivocation we want to propagate uh the two lists a single validator has generated just to so everyone is aware of uh that uh I Committee Member having equivocated and

we can actually monitor it and ignore that I Committee Member uh but yeah you should all always just propagate one I if you're not if you're following the spec and and honestly yeah g it thank you and uh I would like to share that uh I've started working on metrics for for so it probably would be also helpful for monitoring um I'm going to raise an issue in bacon metrics uh and discuss it there so uh probably it will be interesting for researchers as well uh what what would you like to measure or Monitor and uh yeah the cortosis part

was helpful Jon thanks so that's it yeah thanks that's great yeah we can definitely also take this offline we have definitely ideas about like what things we would like to monitor for FAL and and I think since like Dev Nets are like happening relatively soon we can we can use uh that data to to start this uh right so yeah I think that was I guess the last Point uh which was coordinating I think the last meeting which was quite a while ago with said um we are aiming for Dev Nets uh end of January it does seem like uh a

few of you guys are like right on on track uh do we need anything else in terms of coordination like uh yeah do you guys have all you need to to make progress and catch up are there like any questions about coordination per se here okay that's great uh I'll take this as a no everything is is good and we are making progress which is awesome uh yeah if no one else has uh other questions thanks a lot for for

attending uh looking forward to see you guys uh regularly now and feel free to reach out to to us I think Matthew said he was going to also post notes with like all the links and the progress that has been made uh until now so yeah thanks thanks again and and see you guys soon bye