Post-Quantum Interop Call #24

Transcript

And so we're going to try this week uh you know after the conversations that we had last week um actually I'll start again. Hello everyone. Good morning. Welcome to uh PQ interrupt call number 24. This is so I know I can trim off the start of the uh video and we can start from here. Um, so last week we went through, you know, just some high level like we've been at this for about six months and so we just wanted to level set some of the coordination and make sure that we were all of our async comms, our meetings and everything where we're we're really sort of matching the

the way of work, the rhythm of business that we're actually in. Um, and so yeah, we started a a larger Telegram group. I feel like, you know, we've consolidated a lot of activity into there. There's several threads. Um, and another component that we're trying to do, I don't know, I ship the the meeting minutes from last call, the agenda for this call, which is what I always do. I tried to break it up so that we're going to really try to be more intentional with these updates talking about uh DevNet in and then DevNet N plus one. So really that's like the devet that we're in the implementation phase on and then the dev net that we're going to be in the uh preparedness phase on uh in terms of specs and and research. So hopefully

this doesn't come across as redundant. Um we've got an hourong call so I thought we would spend the first part of this like doing a a review of where we're at with DevNet 2. Um, seems as if, you know, we're really concluding that effort. I'd love to hear from everyone if we could just I'll just kind of go through the normal uh client updates. Um, client teams, feel free to like talk about the DevNet status, any blockers, uh, anything that you've got going on there. And, uh, then we can take some time to talk about, you know, kind of more highle spec related tooling related things that relate to DevNet 2. And then we'll move forward to DevNet 3.

Um so again we'll just kind of kick this off. Uh the Zoom team. >> Hi Will. Uh thanks uh and uh it has been an incredible week and first of all my kudos and congratulations to everyone. We achieved DevNet 2. Uh and the cross team effort and collab was amazing and I'm sure we will even get better at it. And post achieving interrupt uh we further worked on client for bug fixes and stability. Thanks to ree and sharq for the PR for snappy frame issue and then we updated the API endp end points post a spec PR by colby and then PRs were done to improve the

client restart sync fix issues and further improve robustness. We we will probably see more work happening on that. On tooling front, lean point has been released uh which is analogous to checkpoint Z tooling for lean. It is being tested for collection as well as checkpoint sync and hopefully will be deployed to DevNet 2 this week. DevNet 2 long runs are already underway and I'm sure Katya will give further updates on it. And uh on DevNet 3 front, Kai has already started working on implementing the DevNet 3 spec on Zoom side and we hope to put up a PR for the same this week for review discussion and based

upon it if any spec feedback requires to be done. >> Awesome. Thanks so much. Uh Ram team any DevNet 2 updates? >> Sweet, sweet, sweet. So congratulations to all the clients on getting DevNet 2 interrop. Uh me personally, I've tested uh ream for quite a while against Ze, Qulene and Lantern. Uh I do plan to test it against ETH Lambda. Uh I was I was just trying I mean I thought four clients uh other clients would just like sync up. I I think it would just be fine. uh but I'm now going to test it against Lighthouse and uh Lighthouse, ETH Lambda and and any other clients

that are participating in this DevNet 2. Uh and Grand is participating in Devonet 2. Uh so we we we encountered some issues when we ran against Ze. We encountered some issues when we ran against Culine. Uh some of them were related to uh like syncing, some of them were related to uh like status API, status requests not being sent properly. Uh so we've got we've got all that handled. So re zeuline and lantern at least on my local build consistent consistently every time gets uh haven't tested sinking as much but uh consistently finalizes and justifies uh and uh beyond that uh we had a wonderful presentation by o this week uh we were

we were approaching lean multi-IG from a developers perspective uh rather than a cryptographers's perspective uh so somewhat high level uh somewhat digestible. Uh great work there. And uh moving forward we we're working on uh uh we we we use feature flags to allow for the further de for the next seven and for the current devet. So uh we we're slowly working towards uh removing removing the feature flags for devet one and adding feature flags for devet 3. So work on work on that front can begin and uh we'll be participating in developing the spec as well. Uh that should be all from the dream team.

>> Thanks so much Rick. Um clean team. >> Hey hey hey everyone. Uh yeah congrats launching the net 2. Yes. So yeah, on our side we were uh debugging syncing a lot with other clients like yeah we noted some kind of discrepancy between spec and the sync protocol for blocks uh yeah between spec zim and dream. So basically wanted to kind of uh clear this mess and uh yeah open the PR to the spec today. I think Tama created a new better PR and it is already merged. So please all the teams check it out so that yeah we are compatible. Yeah we we check the compatibility of sync protocol

against zim. So it's working. So now in case uh some accident like we had during one of the testing by Katia when the clean was restarted so that yeah we can actually synchronize with the network with no issues. So yeah now we should be good with that. So we kind of more stable. Yeah, just today we merged the DevNet 2 metrics as well and uh yeah, I think that's kind of all regarding DevNet 2 on our side. Thanks. >> Thanks Camille. Uh Lantern. >> Yep. Thanks Phil. Hi everyone. So yeah, congratulations on that 2. Um so I guess on lantern side uh mainly just been like bug fixing. Uh it's been really helpful

from Katya to get the feedback in the logs and I've just been trying to fix those bugs. Um I guess I did notice uh like this week I did notice some discrepancies uh from the lean spec and the client implementation. So what I did was uh added support for like legacy uh like if the if a if a response is being received from clients that is not compliant, I've still added support for like fallback handling of those requests. Um and as well as uh been improving syncing uh and yep as well as looking forward to demo 3 fix. Uh that's my update. Thanks.

>> Thanks Mayer. So just a question about this. So right now I I guess that the problem you mentioned is about like the SSD stuff with the signatures that we discussed beginning of the week or this weekend. I don't remember. But now you all of the clients are test compliant are spec compliant on this point or you are still in the older version. >> Yep. So, um I guess I guess in my local testing I noticed that uh for gossip payloads, no one was trying to process uh containers that contain the signature field. Uh it was missing offsets. Um so I guess uh it might be possible that

like other clients have fixed it. I can test it again. Um but yeah it's I've just added it in case you know to like prevent breaking the finality in the network. Um but yeah I can test again. Yeah. >> Okay. Uh anyone from Lighthouse on the call? Uh e lambda. >> Yep. Hello guys. Uh on my side [clears throat] this last week we add two support. Uh we we thought at the station aggregation I verification was

missing before. Uh as part of this we also implemented the RPCA API with a new endpoints uh the one with versioning and we also added most metrics from vmetrics with more coming soon. Also we added a DB so the memory consumption should be more stable and yesterday we shed our first uh we already had our first known finalization to debug and that at least the issues we found there should be fixed with the new image we just published. It mainly adds active block fetching through request response. It

also fixes an issue we discovered then on the status message. Um we were using the the wrong size on the on the payloads. uh we don't yet support inbound blog requests and that's what we'll be working next and with checkpointing following that. >> Great. Thanks. Congrats on joining the the DevNet. Um anyone from uh GE on the call?

>> Uh yes yes yes. So um we just rounded up uh working on the implementation of uh definite uh zero spec. Uh we're currently trying to catch up with uh uh support for for definite one this week. >> Excellent. Uh, >> Grand. >> Hello.

>> Hey. >> Yeah. So, yeah. So, we worked on the DevNet 2 integration. uh some fix some issues and so far I think u it kind of interrupts likely there is some some small details um needs to be fixed but yeah we are progressing >> wonderful uh and then finally anyone from Nimbus on the Great.

Okay. Um, so moving forward, do people feel like DevNet 2, are there any blockers or discussion items that people would like to discuss? Any spec changes? basically anything that needs to be discussed to conclude the uh part of the call on DevNet 2. I think on spec uh things are mostly frozen and uh I think most of the things that we will work upon will depend upon the long runs that we are conducting on it. So basically fixing issues and uh on stability but I think uh we can now move

our focus to DevNet 3 specwise. >> Great. >> Perfect. uh on that front. >> Yeah. >> Yeah. Go ahead to >> um just I have sent like just a link in the chat uh with the PR that we have merged two days ago I think um just with new test vectors uh for a lot of situation with signature aggregation. So nothing is mandatory there. But I think that this can help you to to debug and maybe to find discrepancy between your client and other client or your client in in the spec. So just in case

this is helpful for you, we have added like a bunch of of new test vectors for you to consume. Thanks to Tom. Um, okay. Regarding the the DevNet 3 specification, the uh are there anything that we want to jump in with the spec? I was trying to I know last week we had the additional readiness checklist. Uh also did that get merged into the high level uh guideline for DevNet 3?

I'm not sure about the checklist but I think last week we had a breakout call on DevNet 3 and I think uh maybe tomorrow also we can have another breakout call on DevNet 3 spec and because we had a lot of confusion regarding uh how 3SF would work with basically our interval sort of sort of dedicated uh for aggregation and uh I think we need to sort of uh discuss this and take it to conclusion. So maybe we can have another breakout call tomorrow.

>> Uh I think we need to yeah just to give a context for everyone. And I think yeah last week we kind of had a call where one of the things that was proposed to uh change in 3SF uh inde u updating safe target from interval uh interval 2 to interval three to the last interval so that we kind of have more time for signatures to propagate also so that we can actually aggregate signatures and uh kind of have time to also broadcast aggregation so that we can update safe target based on the kind of a aggregated proofs. Uh however, yeah, as I said during the call on Thursday,

yeah, I I wanted to kind of consult with some consensus guys uh who were working on 3SF and they uh sent some push back so that they were against of kind of doing that. They said there are reasons why updating safe target or uh fast commit as they call it like should happen uh at the interval um uh interval 2 or sorry yeah basically yeah where it is right now. So yeah if we want to I think discuss this yeah we we need to discuss maybe at least Franchesca so that yeah he can explain the motivation on the other side yeah maybe there is some feedback from anyone like how much brain cycles we should actually spend on this considering that

there are ongoing efforts uh with some new uh consensus mechanisms. Yeah. >> Yeah. So as basically said we basically need uh safe target to be calculated before new assess stations are imported and those that needs to happen before the proposal begins for 3S to work uh correctly. H. So the simple thing I think we can do is maybe we can have five intervals so that uh the aggregation now happens in u I think in the second in

yeah in the second interval and in the third interval we do uh the target uh calculation and then in the next interval we import new words. So if we do that basically you know uh the interval is going to shift to 8.8 98 seconds which I guess is fine but as such uh the entire scheme will properly work. The reason I'm saying this is because in [clears throat] aggregation uh when you are reporting the aggregated uh destations then you could have uh imported adestations that you did not see earlier because uh maybe only aggregator saw them. So, so the so target calculation in my opinion needs

to be done after after after the test aggregated attestations are published. Uh so if we just go by this approach and if we just don't try to optimize it any further, we can just divide the slot into five intervals. >> Okay. Yeah, maybe uh let me write it down what you're suggesting. Yeah, I think I understand and then uh yeah, you confirm my understanding and uh yeah, I can check again with consensus guys. Yeah, I'll try to invite them to our chat so that yeah, they are on sync with everyone. Um >> yeah, so maybe on tomorrow's breakout

call if we can invite them and uh sort of finalize this thing, I think it would be great. Yep. Yeah. Let me check on that. Um, so what time you proposing? Like the same time as today's meeting. >> Yeah, I think this time works for everyone. So I guess it's good. >> Yeah. Okay. Yeah, let me check. Not sure how much they're available.

>> Yeah. Sorry, could you repeat who who's missing from the call? Yeah, it would be great to kind of have a call tomorrow with Franchesca, I believe, from EF. Uh, if he's available, he he has expertise on TSF. Um, Yep. >> Um, >> if there's anything this >> Yeah, I was going to say if there's anything that we could discuss uh here that might move it forward. Um there are some people Justin's on the call that might have context. um tamat you know basically I want to make sure that we make use of this time

>> also >> right so the thing that we want to discuss is this uh five interval solution so that uh we don't really need to change anything structurally in 3SF and uh have an extra interval inserted in just for aggregation I think this is the simplest solution Sounds good. >> So, anyone uh any of the researchers want to weigh on that?

>> I don't have a strong opinion. I think talking to Franchesco is a good idea. >> Yep. Same same on me. And also like um maybe we have to keep in mind that 3SF is not probably the final solution and we all of the research that are happening at DF with Franchesco and other other people we will probably move to something else in the future for shorter slot and faster finality. So probably the good idea is to take the simplest solution for that knowing that we will move to something else in the future.

Are there any estimates maybe you have in your head to like uh when you think we can integrate new consens? I'm just asking because like the changes that we're doing now if uh we just doing them for short term while we are not testing the dev nets of size like thousand validators or more I think we're good with any solution but if uh yeah we kind of want to I mean if we implement some solution and we stick with it for a long time and we already want to scale for many many nodes then yeah it gets problematic kind Uh yeah, if we chose the wrong wrong approach, yeah, we could end up like so that uh scaling is

problematic. >> I guess that's probably Justin like you have a a better sense of the timeline there. But from what I know from the theorian guy at the foundation, I think that we will have like kind of a fast finality paper solution in a timeline from six months to one year from now that we can implement something like this. No. >> Yeah, I agree. It would probably take months. Um, one piece of good news is we have a B Edington that joined us recently. Um, and the idea is for him to kind of product manage the first

finality and it's going to take some time just to get him up to speed. Um, maybe maybe a month or two. Um, and uh, yeah, I mean I I lean much more on the six months than the 12 months. I'm hoping that we can move fast, you know, maybe four months even could be possible, but yeah, um I'd say nothing faster than than two, three months. >> Mhm. Okay, cool. Yeah, just so that uh for example if we introduce five uh intervals in our 4 secondond slot then

each interval is8 seconds and for example if in in some point in future we have subnets of size thousand validators and we considering the aggregation rate of thousand signatures per second then yeah we can already have interval smaller than the time available for for an aggregation. Um just just an example of how yeah some changes in design could affect uh when kind of yeah sc make scaling more harder.

>> Yeah. I mean maybe, you know, going back to Tomas's point in terms of keeping things simple, maybe we could just cheat a little bit and increase the slot duration um in in the short term because a lot of the slots optim slots optimizations will only be meaningful once we have a good picture of how to decompose it. So I sort of agree that if we need uh to increase the slot inter slot uh uh time a little bit we can do that but I think uh even before that we can start running devet on increasingly number of

validators so that we can see how the performance is also I'm assuming that the performance of uh leanvm will go multiffold in coming months and uh we can at least for now throw a a little bit of more hardware if that is a requirement but uh I mean as of now I think uh let's just increase to five intervals and then start increasing the number of validators and see okay where is it that we hit the road block and then figure it out okay good uh yeah let me just propose to Franchesca the five interval solution Uh

I think yeah it should be good enough even uh and if he agrees yeah maybe we don't even need to have a meeting I can update the spec for committee aggregation and yeah get rid of this uh global attestation topic which I think people are not very happy with. So yeah it will make a bit simpler uh the spec. >> Yeah I think that would be great. Yeah. Yeah. Yeah. I'll work on that. That's >> that's great. Um and I'm always feel free to nudge me. I can make sure if there's someone that would add value to

unblock the group to, you know, try to see if they can make it to this call. So like Franchesco in this uh example, I could always make sure that we get him on this call rather than taking another hour of your time tomorrow, which is uh sounds like we'll we'll be able to move this forward async though, which is great. Um great. Any other like open discussion topics on DevNet 3 specifications?

Uh I just updated the existing pull request uh so that all the tests are passing but as we just discussed yeah uh the PR might be updated so it actually might get simpler. Um, great. I also wanted to just take a moment and see if there's any new client onboarding questions from ETH Lambda GE Nimbus Grand Dean um teams that are you know

sort of newer to the to the DevNets um specifications if they had any questions that they wanted to you know try table get answered from the rest of the group. Uh yeah, I think for June uh the specification has been very uh readable and you know self-explanatory. So um so far so good. So it's uh the spec has been helpful for now. All right. Um,

so I think we're maybe winding down. Uh could people just kind of quickly like some of the team leads give us a sense of what the plan is for the next for the upcoming week um in terms of any additional study sessions or uh milestones that you're hoping to complete. I think you know shipping DevNet 3 is obviously a little premature between now and and then like what are the incremental steps that you're all you know really focused on?

>> Uh so our number one I can I can go first. Our number one focus uh we were we will continue we'll continue debugging issues that arise on DevNet 2 and uh and hopefully we reach uh finality with all all seven clients. Uh we have yeah as we have tested with some clients uh locally we will continue testing uh and ensure that DevNet 2 finalizes everyone is syncing uh beyond that uh we we are uh we are uh fixing we we're improving our code base to work for DevNet 3 so we can uh we can start uh implementing and shipping DevNet 3 once the spec uh matures a little bit.

Uh as of as for study sessions uh we do not have one planned for this week. Uh but we do have we do have something in the works for Koala Bear. So I would keep an uh for uh yeah for overview of Koala Bear uh the prime fields I believe. Uh so I would keep an eye in the ream chat for that. >> Amazing. uh on Zim side. Uh so adding to what Sharik said apart from uh DevNet 2 long runs and debuggings uh and fixing issues uh related to that uh I think uh we are trying to bring up the lean point tooling for checkpoint sync and uh

hopefully the clients uh who have uh implemented syncing and who have also implemented providing uh checkpoint finalized checkpoint states uh they will be integrated to it and hopefully syncing uh through checkpoint sync uh could be tested on DevNet 2. So that will be up to Katya and uh Partha to take it forward. Uh we are anyway uh working on DevNet 3PR and we hope to finalize the spec uh uh post uh Tamil gets an update uh on the interval and hope to make a significant progress on

its implementation and apart from that uh regular updates uh the regular work that is happening on further improving uh the robust robustness of the client. So that is going to be our focus. >> Yep. Um so on the lantern side, um focus going to be on dem 2 stability. Um I'm basically going to be implementing some optimizations in CPU and memory usage. Um and as well as uh because in my local testing I could get the checkpoint endpoints working for justified and finalized uh

routes. Uh but yeah, I'm eager to see any feedback from uh the Zam team when the lean checkpoint tool is used uh on lantern. Um so yeah, that's on our side. Okay. Yeah. For clean uh yeah so now DevNet 2 scope is finalized and yeah we have actually running clients uh yeah we will take clean as kind of last time so and use it for some networking analysis to kind of um simulate some larger networks than we have in our DNET environments. Um yeah in parallel there is some ongoing

uh research and development going on uh by our team members. So we exploring Ritz Salmon uh propagation for uh proofs like we already wrote the small simulator u I'm just when my time permits yeah developing some beautiful uper notebook so that yeah uh the results are kind of uh beautifully visualized but yeah uh so that so that we just can have some direction uh what else to introduce on networking level so that when we scale we kind of know what to Um also some of our team members exploring things like proof of validator so that it actually will be helpful at some point in also long future so that

uh in our gossip sub networks we actually only deal with validators other peers like syncing nodes they are not part of the gossip subtopic and we actually reduce number of hops required. So uh so many many directions where we exploring on the networking side um but yeah once any results yeah I will share them and for grandia as this is um the client is um just a side project for now we don't have a dedicated people working on that so we for

near future I think we will just focus on minimal u stuff that we need to do in order to participating in the dev nets so yeah that's our so far that our approach um if lambda is still catching up. Uh our focus right now is mostly D2 stability and um uh implementing checkpoint that's

still missing for us. Yeah. Um yeah. Um Jin, uh the priority right now is uh catching up on uh definite one. So, um that'll be our priority for now moving forward. All right. Um I'm going to be out next week. Um so, Tamar has been kind enough to offer to lead the call, but yeah, sounds like everyone's got a a full slate of work between now and then.

Uh Camille. Yeah, just before everyone go um just want to ask an opinion like uh we introducing this checkpoint sync uh thing but uh do you think that uh on the longer term like we need to introduce some proper sync protocol on the on top of lip because currently checkpoint sync as understand it kind of works on top of HTTPS and usually it is used for kind of users to check I don't know the health is to health check or um check the state of the peer uh so I don't think this is kind of the right thing to do on

the long term so that peers are using like so we are not using P2P for the uh syncing but we're actually using this HTTPS um I don't know so just any thoughts on that uh does it make sense to consider implementing sync protocol on top of lip P2P or we want to stick with this. >> So just to add uh my two cents over here this will use lip on top of it because checkpoint sync will give you the finalized state and then you will need to use uh block by roots to come to head and uh basically then sync it. The reason uh in my opinion other sync

protocol or a sync by range is not required because most of the clients actually don't do it. They if you look at what is happening in beacon consensus you always have to start uh your node using checkpoint sync and then proceed forward on that. uh long range syncs are not really effective especially because uh when the data availability gets expired you can't really even sync beyond that window. So that li that window is already small uh from the point you can actually forward using range sync and uh so inance of running the mainet nodes I

mean even for example syncing starting syncing from behind thousand slots on the mainet network has been a bit very problematic. So uh in terms of practical usage I always try to use checkput point sync whenever my node restarts just because pas and data availability has sort of put lot of uh strain on this maybe it will improve in future but as of now I think for us we don't need to complicate our syncing scenarios checkpoint sync uh basically the aim of having checkpoint sync is that you know the node restarts and All these things are are managed easily and even if for example your node goes down it can be

put back up and we can keep having finality on the devets. So that is sort of uh the main reason behind checkpoint sync but checkpoint sync by itself is not the final solution is not the only solution. You still need to do block by roots P2P sync. >> Yeah that's true. just assume at some point in future maybe uh yeah I'm not super deep you know the ZK stuff going on but uh I assume yeah uh we might take advantage of that somehow so that we actually once we connect via P2P protocol to the peer we just I don't know um yeah

>> special kind of in fact >> right in fact with zk proofs you you don't even want to do long long range things because you would just want to do a checkpoint thing because the proof of the correctness will be available uh >> and basically you know that uh this particular state is correctly constructed. So the checkpoint set is correctly constructed. So in fact it would not even it would not make sense to actually go back to ranging at all. Yeah, I'm just I don't know for some reason I'm not super happy that uh we kind of use uh API for both P2P communications and kind of

userto communications I don't know like when user asks I don't know sends transaction or asks for some state u >> right so it could happens that uh the checkpoint sync could for example move from an HTTP API to a lip P2P API in the sense that uh peers can start serving use state on uh on the format of how it's done for uh snapsync right so so there could be a point where we would have snap sync sort of a thing for uh for the CL state but uh the state is not big I mean but we can still expose state API on uh only P2P RPC I mean even

though the state is going to be huge not for us lean clients but for let's say you know mainet clients whenever we go to that so we will have to basically think what is the correct solution for it and I am sure uh even in the mainet beacon consensus people are thinking over it and I think one of the proposed solutions could be to adapt apt snapsync to this but uh I mean I guess that is a problem I would let them solve first and then we'll adapt uh unless we have something to leverage on lean consensus to basically provide a solution.

>> Yeah. Yeah. So there are yeah so long term uh yeah we could use slippp I'm just thinking so yeah if we spin up https port yeah we need to manage like another secret another certificate and like we when you are node operator you already managing your lipk uh your uh xms key and now yeah they also to set up a proper CTPS yeah they there is also another thing to manage Um and yeah if they don't need to do this because some for example validators today they don't care like uh about exposing their uh API uh so that anyone can access them they

don't do this and uh I would not if possible yeah longterm I would not create such a requirement for validators to kind of uh manage if you want to do this if you want to do this P2P then probably you need some sort of snapsync adaptation. Obviously, you know, you can't just uh expose an API endpoint where you need to serve heavy data and state over it. So, in that sense, I'm I I'm not I don't think that this can just directly be ported to LIP2P.

>> That's fine. That's fine. I mean, in Polot, we do this. We actually uh there are states of size of multiple gigabytes and we download them over the lip when we synchronize. Yeah, we call it warp sync. So yeah, we download all the proofs of the blocks and then we download all the uh the actual state and then we build the mer and compare it. So uh I assume yeah uh CL clients or E clients they do something similar. adaptation. >> Yeah, it sounds like an adaptation of Snapsync to me, but yeah, I would need to look at it. Proger. Yeah.

>> Yeah, it's it's very similar. Uh so also considering that there isn't going on ongoing work on EP2P yet, there is also that that's also something that one of the use case that that we need to keep in mind. So yeah, we need synchronize some huge amount of data. Yeah, I would actually >> and if some and if some peers they actually don't want to support this protocol, they can just disable it. So, for example, only archive nodes can actually uh use this protocol. But yeah, the nodes need to be able to find them and that's the beauty ofp you can actually check which protocols are supported by any nodes. Um, so yeah.

Yeah, I would actually be in highly higher favor of being able to serve um some sort of checkpoint state uh past a certain range of roots like before that the data is pruned. So like all the roots cannot be quered for sort of like weak subjectivity. Um and but like thing is in in consens uh you have uh centralized providers um that are hosting servers and you can download the checkpoint state checkpoint object from their server. Um so but like if we made it so that um you can like checkpoint sync using lip P2P uh with some solution uh then even if all the providers go offline it'll be possible to sync the

node with the network. So yeah I'm definitely in favor of something like that. I mean this is definitely something worthy to consider in long run for sure but uh I mean as of now I think in let's say for the next devet I don't think this can be our focus. So I mean I'm not talking about devet 3 and now I'm talking about devet 4 because I'm assuming devet 3 is now under implementation.

Yeah, I agree. This is not a small piece of work to implement this protocol properly um on top of lip. Yeah, I'm just uh trying to get some alignment of on what we want to see uh long term. Yeah. >> All right. And on this note, uh I mean now that we are talking about DevNet 4, uh so can DevNet 4 be based on recursive aggregation? My question to a male Toma >> sorry I I didn't hear the hand of your question. Can you repeat please?

>> Yeah. So now that uh we are considering that DevNet 3 implementation is underway. Uh so let's talk about DevNet 4 and for DevNet 4 my proposal is that we do recursive aggregation. Yeah, I think that's um I'm not sure that Amy is there but I think that it is under like recently we merged with the announcement of the new team Emil merged the simple branch on the on main on Lin multisig and so I think that with this even if some improvement speed up and stuff are work in progress

Uh right now we can have like 2 to1 recussion. Um so this is something that we can definitely integrate I guess uh into DevNet 4 by then. I guess that Emil will be able to achieve some speed up since he he works full time on this. So yeah. >> Awesome. And just throwing it out there, can DevNet 5 be based around improvement of the finality gadget?

>> Um, this is in the space. >> This is also possible definitely. But I guess that for this we will have to sync with the um the consensus team at the EF. Uh, of course my my goal is also like to implement it as soon as this is written on a paper. Uh, but I think that right now they are iterating on the design. Several stuff are under investigation with various protocols and so yeah but as soon as this is finalized at least with a theoretical paper then yeah definitely we will spec out.

Sounds good. And I just wanted to throw it out there because uh I mean just to short sort of align things whatever we need to uh in the meantime. I guess also like this will be easier when we have the paper for the fast finality thing to spec into the lin spec rather than specking into the content spec because the content spec is more larger and like much more complex. Um, so yeah, as soon as we have the paper, we will definitely uh plan this for a

future DevNet and spec it out hopefully in a couple of months like we mentioned with Justin. One piece of context here is that there's been a very significant effort internally to the protocol cluster to integrate lean with all of the incremental upgrades. So, you know, we've been talking within the architecture team, but also in collaboration with the whole protocol cluster. Um and you know one of the artifacts as part of this exercise is a a straw man road map that kind of tries to place everything um on on on a on a single timeline. Um and you know this

exercise has been hugely helpful. Um so that um you know like the all of the various teams for example the the consensus team the the networking team the the steel team can all feel like uh you know the the the lean fork uh plays a plays a part in their work in addition to all of the incremental changes. So this is something that we're still actively um working on and trying to reach, you know, uh full alignment within within the the protocol faster, but I'd say it's been a a super helpful exercise.

Um, one of the things like I I guess I could share share tentatively is that there's a little bit of a coincidence where um it looks like the Lstar fork uh might be the the top candidate for the for the leader fork. So that would be you know around early uh 2029. Um and um you know I guess another useful thing is that we we have all sorts of of of new hires you know very strong hires coming in. So I already mentioned Ben at the consensus with the consensus team. Um we have uh you know someone coming in uh from from from PSC to talk to work exclusively on on

private transfers. Um, so that you know that's that's going to be integrating with the the lean VM. Uh, we also have a potential cryptography hire and the and the potential networking hire. And I think all of these hires kind of from day one will have the the the lean consensus context. And you know this the meme if you will of of lean consensus is very fast seeping into the the entirety of of of protocol. And um one of the other outcomes of um you know this exercise is kind of realizing that you know lean VM is a a potential tool

that helps harmonize not you know this the CL with with the other layers the DL and and the E. So in some sense, what started out as a tool for the consensus layer might be an essential tool for for all of Ethereum uh including the the private transfers as I as I hinted at. Um so you know I've been quite quiet uh in in January but u you know expect uh expect a a lot of um lifet uh you know February onwards at least internally within the foundation.

All very exciting. Um, yeah, Gender, thanks for prompting those questions about F4 and five. Um, and if there's anything that we can do to like, you know, think about that finality gadget and, you know, try to frontr run some of those conversations with some of the consensus researchers. um you know always happy to help uh make that connection if it needs to be uh made. Um just maybe a final word on this like on the fast finality stuff just like for your information during the Christmas holidays I have started to run like um a fast finality playground Python stuff

uh just to start speaking um for now we have like five to six algorithm and this is private because uh this is not published results yet so I need to wait before these uh results are published uh on the paper before making it public. But just to keep you informed that I already have like a spec in Python with those multiple algorithms. And so yeah, this is this was the first step toward like specking before we were at Mercy. you dropped an

link to the poll request with the readiness checklist in there. Is there anything that you wanted to uh voice over on that? >> Yeah. Um good afternoon. I just I made a PR so that we can take a look at um the checklist we have and then if there's another update I need to make on it, then I can include that and then merge this. Then I have like um a template for each of the um dev net. So as time goes on it will be updated if that is okay. >> That's perfect. Thanks very much. Yeah I if the team leads could and others could review it just make sure that the content is correct that would be very helpful.

Kaja. >> Uh yes, hello everyone. Just quick uh to coordination. So we are in the tooling chat right now uh in the tooling challenge channel and uh we are going to restart uh the devet not like maybe once a day until we don't have like stable finality for long-term devet. So um I'm posting a message. So if if the client is ready, if the image is ready, please let me know. So we will coordinate it there. So like once a day.

So uh feel free to let me know. Um I hope everyone's happy with the graphana and etc. And now it's visible for all of the clients and uh logs etc. And uh the downloading logs will be delivered soon. Thank you. All right. All um any last thoughts before we call it a day? Excellent.

I will see you in the trenches. >> Thank you. Have a good one. Thank you everyone. Byebye.