Post-Quantum Interop Call #26

Transcript

All right, welcome. How's everyone doing? Um, >> pretty good. >> Great. >> So, let's get started with client updates. Uh, Zoom team, I think, uh, Gadgeter said he was going to be out. Anel, I believe you're going to take the lead. >> Hey. >> Yeah. Hey. Hey, everyone. So on the theme side we fixed a couple of issues that we noticed during the uh longunning defnet. Uh so these issues weren't critical because uh the zam node was panicking and was able to restart on its own but uh we we figured out the bugs from the logs and have fixed them. Uh

apart from that like uh our work on devet 3 is on track. We aim to merge the PR hopefully by the end of this week. Uh and apart from that like there have been some housekeeping work related to the client and the upgrades that have been rolled out on the ziglang. So uh we have been working uh updating uh as per the latest releases on that front. Uh yeah that's about it on the uh on the client side of things. Uh apart from that like uh I had discussed this on the spec group as well like I'll be uh taking a lead on uh rolling out a spec for DevNet 4. So as soon as like MIL comes up with

a lean VM uh update that supports recursion. So uh I'll uh raise a PR with the aggregation stuff. >> Brilliant. Thank you Angel. uh Ram >> uh so as for DevNet 2 uh over the long running DevNet we had finality for 3 hours uh the and uh so we have we have we have found some minor issues with stability uh from the logs and we're fixing that uh ASAP uh and and that should be all for DevNet 2 uh from our side as for DevNet 3 we gotten committee

aggregation implemented in reh. Uh we got all the networking stuff done as well. Uh we we're doing some minor stuff on the validator and chain side. Uh and then we should be ready to interrop on DevNet 3. Uh and yeah, we'll be uh although although I'm I'm in favor to finish all the stability issues and get like at least one uh good long running DevNet on DevNet 2 before we jump to DevNet 3. uh introp uh however like we we're good to work either way. Uh as for uh and then we got we got a PR merged into uh the lean spec for uh for SSC test vectors uh and then we tested it

against our client in Dream and uh that that seems to work pretty fine and we got we got spec test implemented with DevNet 3 uh as per this as per the spec and that works fine as well. So, uh, yeah, we should be good for D3 in, uh, uh, I mean by next week hopefully. Let's, let's do it. >> Awesome. Thanks, Sh. Uh, clean. >> Um, yeah, hello everyone. Uh, from our side, yeah, the most mostly we're focused on Devet 3. Uh, yeah, we currently have a PR. Uh, yeah, just uh checking it for stability. I mean just running our own u networks. Um I think

soon we'll be able to uh also kind of start interropping checking uh like how we work with other clients. Um so yeah uh aside from that yeah we're doing some work on uh checkpoint sync. Yeah it is still uh kind of also in the form of PR. Just want to run some final tests and yeah merge that as well. Um yeah and just also yeah you're doing some some some work on spec yeah it's still missing uh uh aggregation propagation uh so and uh some tests were skipped during my PR with committee aggregation so yeah just u I'm skipping these tests and yeah uh soon should be ready uh I think

that's all from our side yeah just quick side note uh I might not be available on the next call maybe call after the next call. Yeah, I'll be in Argentina for two weeks. So, don't don't lost me. Yeah, then I'll be back soon. Um, yeah, that's all from our side. Thanks. >> Awesome. Thanks, Camille. Uh, Lantern. >> Yep. Thanks, Phil. Hi, everyone. Um, so yeah, basically have been um fixing intro bugs for DevNet 2. Um, basically noticed uh issues in fork choice. Uh there were some minor spec discrepancies um and as well as there were cases where lantern just um couldn't sync uh new

blocks. It was essentially just stuck in a sync mode. But I've uh fixed those issues um and uh currently I'm focusing on implementing the committee aggregation PR uh and as well as uh making sure tests implemented. Um and then once that is done basically the plan is to run u local devet 3 but with only lantern nodes to check if like the chain can justify and finalize uh before releasing dev 3 image. Um yep that's the plan for this week. Um thanks everyone.

>> Thanks Mir. Um, EAM but >> yeah uh okay for our update this last week we were mostly working on more fixes to the issues found two we changed the file we load the validator set from so it's the same as the other clients now we use configmo we also added a sanity check for embalist stations duty safe target uh we noticed SIM had some handling for that and now we do the same as them. We skip those slots and just log warning which helps with defining those cases. We also

fix the parsing of of pure ids. Previously we were only receiving inbound connections. Now that's fixed. Um lastly we finished adding checkpoints in with lambda. We added some improvements to the backend doic. not noticed some bugs there and also other support for multiblock requests. We also started work on DENA 3 uh which should be finished this or next week. >> First of all, uh G.

>> Yeah. Uh hello. Hello. Uh yeah so uh basically uh we're currently uh wrapping up our implementation basically for integrating uh linseek uh for definite uh one uh we are currently lapping up uh working basically uh uh on the ros and also I've been uh go bindings uh for uh uh basically uh integration with linse for key generation uh message signing and also to um signature uh verification uh alongside uh also delivering uh other requirements for uh DevNet uh one. So yeah, basically uh that's it from my

end. >> Great. Thanks very much. Um I'll just kind of do a a general call for Lighthouse Granding or Nimbus. I don't know I see any contributors on the call, but feel free to speak up if you're here. Very well done. Um, excellent. So, any uh retro or anything that people want to talk about with the long running DevNet?

I was out last week. I I don't recall if that was uh for DevNet 2. I don't recall if that was discussed. Um I know that there were some efforts around uh setting up infrastructure and things of that nature. I don't uh if not we can move on to specifications. Uh Kacha >> uh yeah hello everyone. So regarding DevNet 2 um I'm going to restart uh the DevNet today. I see the fresh image from rim. So I'm going to test the sync as well because we're soon uh will switch to DevNet 3. If anyone wants also to test their sync uh let me know me in the tooling.

Excellent. Thank you. Okay. Um moving on to specs research. Is there anything uh Tamar Emil that uh you guys want to table and kick us off with discussions? >> Yeah. Um we have on my side I have continuously working on uh on the spec adding some test uh simplifying some stuff um working on fixing bug for the minimal client.

Uh last week I we had um interrupt test working inside the the CI meaning that uh the lin the lin Python client was able to interrupt with itself which which was like a pretty good step. Then we had like the the DevNet 3PR that broke a bit things but this is totally normal and now we are I think that Camil is fixing this so that is very good. So we are making progress on this. Um same with the book uh we are making progress on this as well. Um we had also a bunch of podcast and stuff um last week to discuss a bit

more what we are doing. So that it is good news also that the public is taking care of everything we are we are doing. Um on the linvm side of things I let you em comment. Thank you. Hello everyone. Um on my side I am been working a lot on of recursive aggregation. It's not finished yet. So I don't have a stable IP API yet. uh it's quite tricky in practice. The best idea I think um at least for from an efficiency point of view is probably uh the following API. Uh there will be

something like a Merkel hash of all the public keys and uh probably a list of um indexes of the public keys rather than a bit field. It's equivalent but uh when passing the data to the uh EKVM would probably be on the form of a list of public key indexes rather than a bit field and probably a hash of a list of public key indexes. Uh anyway, it's not finished yet. Uh but I hope it will be for the next call. Yes. Thanks.

Awesome. Thanks. Yeah, Tom was just watching your uh block interview. Very, very cool to see. Everyone should give that uh a review if you have time. Um to with the minimal client, you said it's self interop. Naive question, but are you sort of working that through the progression? So would that be sort of like on par with DevNet zero where that was just kind of like the minimal viable uh interfacing between multiple clients and then you'll make it more and more spec complete? Um >> no because it should be directly um compliant with the latest version of the

spec because I use like the the fork choice and everything directly for the spec. So this directly beneficiate for all of the improvement from the spec. So this is directly linked to the spec. And when I say that it interrupts with itself is that in fact we already had this subspec folders with the fork choice rules the finality the XMSS and stuff and I just added on top the required components such as like the peer-to-peer layer uh some syncing mechanism some CLI and so then it interrupt with itself like that but it will always be uh the latest version of

the DevNet. That is cool. >> Very cool. Uh, and I see that the DevNet 3 highle design doc got merged. Um, and Mercy, I believe you still have the a checklist open. Is that uh something you're trying to get feedback on? Yeah, I'm still waiting for it to get merged or for client seems to have a take on it.

>> Okay, great. Um, yeah, if people want to give that a review, here is the link. Okay. >> Any other uh discussion items that people would like to >> uh I was hoping I could demo the leanpoint tool. I couldn't do it last week uh but I could do it now if uh everybody are okay with it.

>> Yeah. Okay. >> I'm uh sent through a I'm hoping you can see my screen. Yeah. >> Yeah. So, this is like I believe I was reading like a checkpoint sync. >> Yeah. Uh can you see the entire desktop or just the browser? >> Uh we see your console or like your ID right now? >> Okay. Awesome. So, yeah. Uh LeanPoint is uh the lean Ethereum's equivalent of the checkpoint Z tool. Uh the idea is uh for a tool to serve uh the latest uh finalized uh slot that other clients can

consume. Uh we've always had this problem with longunning devets that when we running a devet suddenly uh one of the clients crashes due to out of memory error or some other error and uh we had to restart the entire devet and we cannot uh really uh restart one single client from uh a particular slot where the the actual failure was. So this tool will uh hopefully help us solve that problem. Uh right now I'm demoing this with uh uh all Zam instances. I have five instances uh of Zam which I had spin up and this is the validator config. I'm using lean quick start to spin this up. So when I do this um run

this command you would notice that there would be four instances of Zim that would spin up here um each uh identified by a particular u I mean validator ID. I presume you can see orb uh um I mean u stacks uh thing console right now. So you can see the chain is still not initialized but uh I'll leave this running for a while and u I will show you uh the current. So this is the local instance of uh the UI. This comes with a a basic UI uh which would continuously pull all all of these uh uh clients every 5 seconds to determine what is the

latest justified and finalized starts. Obviously it has uh the clients have to implement the necessary uh endpoints for these cases. So I had left this running for quite some time. So it's there. But I haven't uh so let me restart uh this container and then you would see in this uh just a moment. Yeah. So this has started up again. I'm waiting for the chain. Uh it's still so yeah uh you can see the latest justified slot is six and we are waiting for uh the finalization which should hopefully happen after slot 12. Uh I'll leave it running for a bit longer.

Uh but you you would start seeing uh this tool report the latest uh number after it receives at least 50% uh um yeah. So yeah, so the latest uh finalized slot is now 12. Um I'll leave it running for a little bit more for it to pick up. So yeah, so it started to report the latest finalized slot after it has uh received consensus from at least 50% of the nodes. Now my intention is if you notice here there's a separate validator client called Zen4 which I did not start at the beginning. Uh now what I will be doing

is to consume this um endpoint the checkpoint um Z endpoint with and try to initialize the state of this particular client using that. So which is what I've done right now. If you notice, it's automatically uh initialized this with 8 18 and uh it continues to pro process everything as uh it's supposed to be doing. Uh there are some errors which we have to address here where it still says unknown block sender but it's initialized from uh the last finalized slot it saw here.

So uh we are hoping once all clients implement uh this checkpoint syn and they have support for this uh we hope to provide this uh under this URL leanpoint.leanroadmap.org or and uh if at all there's a crash sometime of your client on the DevNet, what you could do uh is reach out to either Karta or me, we would stop your container alone on the DevNet and you could probably test this using the checkpoint syn um URL that we provide here. Uh this would be the endpoint essentially. uh you could test this locally on at your end and once you're happy that uh your fix is working as expected we could then restart uh your

container on the devet uh from the point uh again where the current chain uh is supposed to be in. So yeah that's uh the demo I wanted to show. Thank you. Uh can I ask like uh yeah I probably missed that. What is the URL like we should use uh for the maybe that we can use basically to check or to test our checkpoint sync.

>> I I'll just share that uh in this chat. It's it's leanpoint.leanroadmap.org. >> Yes. But this is the this points to the website. It's >> Yeah. Under that at the bottom you can specify the finalize. It'll provide you with an SS hash. >> Yeah. Thanks. Yeah. Great. Any other questions? I'm happy to respond. so just curious what the uh if you have other features uh enhancements that you're thinking about building out for

this uh additional information that you want to track. >> Uh not immediately. I mean uh the idea right now is to make uh leanpoint um a bit more stable. There are certain uh issues that I noticed while testing this specifically on the local devet. Uh hopefully once we start doing this more on uh the longrunning DevNet when all clients have uh implemented checkpoint sync we'll have more uh features that we could think of an add um and I I was hoping another tool which would be nice to have for uh I mean lean Ethereum is probably our own uh block explorer uh I mean extending what Dora does uh but

yeah that's probably for sometime later. Dora. >> No, he's trying to say lean. >> Oh, yeah. I saw I got it. I got it. >> Skinny Dora. Very cool. Anything else? Anyone have any other topics that they would like to uh discuss?

Gotcha. >> Um yes, regarding Devon 3 metrics, I'm working on on it. Uh we'll share the PR soon in the tooling channel uh this week. um hopefully tomorrow or um and I have a question to the teams. So I opened the PR uh for to delete annotated validators YAML but it turned out that uh Lambda team uh uses it. So I wonder if any other clients use this or or we are moving to deprecated. Um, >> as far as I'm aware, it's used in Zoom as well.

Okay, I will check it. Yeah, if other clients if you need just to check it, uh, please let me know in the tooling channel. Uh, I have a discussion there. Thank you. That's that's it. Yeah, I doubt Re uses it. Uh I just want to know for sure because uh yeah if I don't want to damage any clients like uh if someone needs it. Uh

so we will leave it here. Yeah. So on the lantern side, we're not using it. Um All right. Um I think sounds like maybe

that's it for the day. >> All right. >> Yeah, maybe just Yeah. two minutes. uh just it's not really asking anything or um yeah just won't like uh yeah last week I shared this analysis it's basically yeah we tried to use uh some simulations using clean under shadow and uh yeah basically here you can see that uh what network's parameters we choose like uh basically it's very similar to EIP7870 where we have like uh 50 megabits download 25 uh upload. Uh so it's very very similar to that and um yeah just

for everyone's information so we couldn't scale further than 64 validators. Uh the reason is uh I I assume it's too large the blocks are too large and it's very hard to propagate them u fast enough. So basically we see for example there is a correlation that uh sometimes we have uh the block is is too large we cannot propagate it in time and then uh because well it was not propagated then uh well the finalization didn't happen as as expected and the next block would actually have multiple aggregated proofs not just one. This is definite two by the way. Um so we see for example because of that in slot 13 we had uh block with basically three

aggregated proofs. So like uh no it's actually even four I assume. So because yeah the size is 1 megabyte and yeah we see that it's propag to reach 90% of nodes it's took almost 3 seconds. Um that's just something to keep in mind. Uh in yeah you can read more. Yeah I can share the link if you haven't seen it yet. But uh yeah, basically we see that yeah we need to if we want to scale yeah to either I don't know update our um uh assumptions about the bandwidth yeah I'll try to run more tests with maybe increased bandwidth maybe two weeks 3 weeks from what we have here to

see how better it is in that case and at some point maybe I don't know devet five devet six to u start working on Yeah, some better uh better like propagation logic for the proofs and also for the blocks. Uh yeah, I I saw a paper by I think Benedict Denbon and some other guys about the ERNC encoding and how to sign messages in that. That may be something interesting to explore. Um yeah, just sharing an update. That's something I think worth working at some future if we want to scale I mean beyond just uh 60 validators. Um

yeah >> I have a very basic question uh why is there why are there multiple aggregated aggregated proof on a single block? >> Yeah that's I think something we introduced in DevNet 2. uh maybe Ansha is better to explain this but basically if we for example we we try to uh collect all that's my understanding but Ana can correct me uh so we try to kind of uh if for example I'll proof only proofs uh signatures for 90% of validators for the remaining 10% of validators we try to attach proofs from the previous blocks

uh maybe at some point we can get rid of this logics we can make blocks smaller. But this is how it is in devet two and this is how it's going to be three. >> If if this is important to have proofs of different block levels, I don't know, we can always aggregate those proofs again and again to keep it as lightweight as possible. >> Yeah. But uh right now we don't have recursive recursive aggregation that's why it has been made such that >> yeah of course yeah >> yeah with devet 4 we'll uh we'll just have a single proof so uh we'll get rid

of this and uh it was like just a temporary thing I think we'll get rid of it in the net for >> okay perfect so in the future the the like the size of a block we mainly be the size of one aggregated proof if I understand correctly. >> Yeah. >> So basically you in the simulations we could assume that the block size is 256 or even optimistic optimistically closer to one 128 kilobyt maybe >> we can try to reduce this. Yeah we actually in our simulation we used fake XMSS and fake XMss aggregation. We can play with like signature sizes, uh,

aggregation sizes, aggregation rates for signatures and for proofs. So yeah, it's pretty flexible. All right. Excellent. Um, if nothing else, we will call it a call.

>> All right. Uh, looking forward to what? DevNet 3 later this week. Sorry, Shereek, cut you off. >> No, no, I was just saying amazing. Ah, >> cool. All right, folks. >> All right, have a good one. Have >> a good night.