Post-Quantum Interop Call #13

Transcript

GM, uh maybe we'll give it one more minute and then we'll start. >> Okay. Hi everyone.

Um, we are at PQ interrupt call number 13. Um, we're about a month away from our self-imposed uh, ship date for DevNet 1. Last Last week we informally called that out as November 15th or middle of November. I'm just kind of tracking that on the issue. Um, so I guess we'll start with some client updates. Uh, Rem team. >> Um, yep, I can go quick.

So, uh, aspect is now working on uh, we are trying to develop in Rem that one big change it a lot. So, for example, we added validator container and uh, add the lean state. Um, uh, we are also uh, looking for some signature stuff right now. And uh, just before this call we are agreed about the container name, which is very cool. And I think for the for this week and next week, we're focusing on implementing the actual spec changes that will be proposed at

DevNet 1. And also, um Um yeah, I can finish this. >> Excellent. Uh yeah, Zim, go ahead and report. >> Yeah. Hey guys, I'm here. Uh yeah, so we have been sort of working to get ready for DevNet 1. And basically, we added some of the functionality, some of the more uh client syncing functionality.

And we'll continue working on it. Uh And basically, working on DevNet 1 spec as well as integrating uh integrating the signature API. So, yeah, that is what we did and sort of we'll continue pushing on that. Uh after after the PR for PR 67, which was to aggregate the signatures in a block signature field, it will be followed followed up by actual signature library integration. So, this PR is just about uh reorging the signatures and sort of activating various flows

uh regarding that. And then, there will be a follow up PR that I'll work on to add the signature bit to it. So, this basically should take us to DevNet 1 where we should be able to then interop with signatures. And then, we'll move on from there. >> So, those are the goals for Devnet one aggregate and interact with signatures. >> Yes, also signatures are right now just aggregated as a as a naive list.

>> Mhm. >> There is no actual aggregation. Because there is no lean VM right now. But yes, it's sort of a naive aggregation which basically opens path for lean VM aggregation. And but yes, we'll have actual working signatures in Devnet from now. >> All right. clean. >> Yep, I can update on the clean side. So, yeah, another side of mostly focused on cleaning the repo and yeah, ensuring it looks better than it was a few days ago. Yeah, now we have better read me with added some examples

how to start the node. We added shadow example. Yeah, we also working on on the script for the generating basically the shadow network with arbitrary number of nodes. Yeah, so that we can test for example, I don't know, like three SF with I don't know, 100 or 1,000 validators with different connection speeds and latencies all of that. Yeah, by the way, it's uh uh not really a clean side update, but yeah, for the for the REM here, we also uh forked Rust libp2p so that it is compatible with shadow.

Yeah, I I forgot to uh ping June about the this, but yeah, we opened a pull request to REM. Yeah, just as idea how how they can integrate this if they want to be uh yeah, also work on the shadow. Um yeah, also um just uh familiarizing ourselves uh for the with the uh hash sig library. I believe um yeah, last week uh the updates for the top bottom tree traversal were merged there. So, I think now API is stable and um yeah, just um playing with the library and then yeah, we'll proceed with implementing

the C bindings uh to it so that yeah, we can use it in clean. Um yeah, I think that's it for now. Oh, yeah, I forgot to say uh yeah, we also uh bit refactored uh how we deal with metrics. Yeah, with the help from Katya. Um yeah, just uh bit made it easier to add new metrics in future. So, yeah, also some progress there. Thanks. >> Thanks, Ken. Uh Lantern. >> Yep. Hi everyone. Thanks, Phil. Um so, from our side, we uh just recently finished implementing uh gossip sub V1.1. Um and currently, I'm at the stage where I'm trying to implement the uh

test intro framework for the gossip sub. that is in the libp2p test plans. Uh so, the goal is to basically uh make sure all intro test pass with go-libp2p and rust-libp2p. Um and I think uh that framework is using shadow. Uh so, that's going to be a good opportunity for me to familiarize myself with that. Um and I think if um like if I'm able to get the intro test passing with rust-libp2p and go-libp2p, hopefully, I should be able to communicate with the uh ream, zeem, and clean. Uh but basically, after that, the goal is to implement um uh basically, uh test with local PQ devnet repo uh that was used for running

devnet zero uh to see if that if there are any issues there. Uh but at the moment, I'm just trying to make sure uh that test intro uh test pass for gossip sub uh before I can get started working on the devnet side. Um but yeah, that's my update. >> Thanks, Jeremiah. Um Manus, you know, I see you here from uh the Lighthouse team. I don't know if you have any updates or if any other beacon client client team members are on here and would like to give an update before we move on to specs.

>> Yeah. Um yeah, I've been just uh making slow progress on devnet zero spec, so yeah. Uh I've been handling other P 0 stuff, so yeah. That's mostly from my side. >> Thanks, Remco. oh, I see you dropped a note about the the test vectors. Maybe we could start with any spec updates there. >> Uh yeah, so yeah, so I want to bring this pull request into your attention. Like I yeah, so it's created wholly by Filipe and basically it's the framework for

generating the test vectors. Um I haven't finished reviewing the the the files changed, um but it's mostly Python like structure stuff, so I don't think I can can comment much on that. But running the commands that Filipe gave, um I think it's pretty promising. It looks like I think we can make use of this like ASAP. Um so basically, by running the command that Filipe gave, um it's producing a few JSON files very similar to consensus spec test vectors. Um but instead of like, you know, the consensus specs having everything like snappy compressed, um this is basically like a plain JSON file. And within that JSON file, you can see the like the

pre-state, um the blocks that you're applying to it, and then you get the post states, including um exceptions if you're expecting exceptions as well. So, I think it looks pretty pretty good. Um there's still some questions that I will pose in the PR. So, for example, like the pre-state right now is the entire state, but the post state is only showing looks like the own it's only showing the diff between the pre and post, and I think we probably prefer to have the entire post state as well. Um but yeah, I'll I'll I'll put that in a PR. So, I I think this is promising, um but it will only work if uh all the clients can actually adopt this for Devnet 1. So, I encourage

everyone to to look into it. >> Thanks very much, Joe. anyone else on spec updates or research? Toma, Benedict. >> Yeah, just about like this spec uh these test vectors.

As O just mentioned, like a perfect summary there. Like the the PR is quite big. This has made by by Felipe. We discussed that a lot together in order to have like a proper uh formatting for these test vectors. Since this will by pave the way to to everything then. Because this will build the test vectors that will be consumed by the client teams. So, this is very important that all of you guys agree with the with the framework, with the way of doing things.

This is mostly inspired by both the consensus and execution tests. As just mentioned, we just do the plain JSON format to make fully use of Pydantic stuff in Python and have something quite clean and and good. If you check in the PR, you have different examples of of tests that are made with this with this framework. For example, some tests related to fork choice or state transition.

Just small tests for now, just to show the concept that Philippi proposed. And then once this will be accepted by all the client teams, we will progressively like remove the whole bootstrap test and replace them by proper test vector stuff everywhere so that this can be consumed by the client teams and test against the spec. So, yeah, this is quite important that you guys have an agreement on this.

Also, like on the more on the cryptography side of things, um we made couple Benedict made couple of change last week on the on the sig like repo with a new stuff related to the to the the tree that we discussed in Cambridge that is now merged into the the rust that is the way that we to avoid huge memory requirement, we just store like a portion of the tree and then move forward in in time. That is merged in rust.

Uh we also merged recently a PR about like uh, testing structure in in the C I agree post so that now you have like an instantiation of the signature scheme that is perfect for testing without the very big lifetime that leads to huge key generation time. So, you have like this, uh, nice small instantiation that I should replicate on the Python spec, too. And, yeah, that's it about like the the stuff related to to the spec and the cryptography.

>> Any other spec or research related updates that anyone wants to give? Uh, we typically move on to metrics updates. Uh, I don't see Katya here, but does anyone else, uh, have anything on the metrics front? I heard Camilla, you mentioned something about, uh, just easy integration of of metrics. Um, I don't know if there's anything in terms of, uh, the dashboards or anything that anyone wants to mention there?

>> Yeah, nothing from our side. We just did some, um, preparations work, I would say, to to simplify adding new metrics. >> Okay. Great. Uh, so that's the extent of the standing agenda. Were there any other topics, uh, areas of discussion, concern, debate that anyone wants to table. >> Um so I I have one quick question about spinning up devnet for devnet one. So we should have validator private key

generated by hash stake library to feed the client. So is there any progress or is there any resources that I can follow to spin up a new devnet? Uh regarding the signature or the private keys. >> Uh so I you you mean in terms of genesis generation zone? >> Oh yep yep sure. >> Yeah I think I'm not sure who was to follow this on maybe our team was to follow this on but we want but we would like to integrate.

So there was the CLI that Mercy created in block blaze repo. I think Mercy can go to explain that but uh the CLI needs to be updated to PKs uh PKs genesis generator tool so that you know this CLI will first produce a list of uh uh public private keys based upon the config.yml uh and then those will be consumed by PKs genesis validator tool to sort of generate the genesis state because now we have we need to enroll those public keys into uh into the genesis.

Uh and I think once we have the PR67 merged basically this that will open up the way for it sort of in terms of the spec. So then we should be able to work forward on this. Yeah Mercy. >> Yeah I wanted to say I opened the PR for to integrate the hot sync into the Genesis the link quick start repo. >> Uh so is because Genesis generator tool already uh supports consuming these public keys list of public keys that are generated?

>> Yes, that's what the PR is for. >> All right, I guess then we'll basically check the updates and try to merge them. >> Thank you. I can check those PRs and uh the the research assistant you mentioned. >> Uh yeah, here I think we don't plan to update to the next version for Devnet one.

For Gossip sub? >> Yep, sounds good. Thanks. >> Devnet one we're using Gossip sub 1.1. Uh the PR Barnabas Captain Fusaka himself. Which PR are you referring to? 607? >> The the beacon Genesis PR. >> Gajender, could you drop a link to that in the chat?

>> Yeah, I will just find and coordinate with with you and share it in the group. >> Thanks. >> Um, does anyone know if we should be doing the top bottom caching for the signatures for the yeah, for the signing for the key regeneration?

>> Can you go again? >> Oh, so yeah, so so apparently the the PQ interrupt session in Cambridge like we well, I think Benedict and Dimitri introduced the top bottom caching or basically top caching for the for the the PQ key. And I'm wondering if we are we are just going ahead with uh which strategy for the key regeneration or we are we going to store the entire like all the leaves or are we doing the top public key caching or does anyone know which which way we should >> So this is >> For the genesis generate generation I

think sorry, Benedict you can go. >> Yeah, so this is implemented in the in the her stick library. So you I mean you don't need to do it yourself. You just need to use the new API of the of the library. Does it make sense? So so by using the new API we should already be using the the top caching. >> Yeah, exactly. So this is the pull request that to merge is sent in the chat that has been merged. And yeah, it introduces the new API and under the hood it uses this caching strategy.

>> Okay, thank you. >> Am I right that for the devnet one we need to define kind of what would be the uh activation or number of active epochs or active slots or anything like that to kind of uh generate the keys. >> Yeah, so every validator can pick that on its own, right? So, the >> Yeah, but >> time is per validator. You can choose it however you want. Of course, you can only sign in epochs that are within that interval.

>> Yeah, it's kind of um question. Uh W- w- what should be Well, for how long we plan to run devnet one? I mean, how many epochs we need to generate the keys? Um if it's like, I don't know, a day, 2 days, or week. >> Yeah, good question. It would also make sense to maybe have uh have different activations to see how that works. Like, you have a few validators with with uh short lifetime and others with longer lifetime or activation time.

>> Yeah, so I think what we should do and what we can do is basically uh generate different set of validators with different lifetimes and sort of reuse them over and over again uh just for the purpose of doing uh non-public interrupt, but uh devnet one should have a public interrupt as well, and uh that is when we should basically we'll also generate a fresh set of key. And uh I think for our local testing, week one day is good enough.

Then, when we do uh non-public interrupt, then we can basically go for 10 days. And uh going for further, basically, you know, then uh for the public uh interrupt, again, 10 days might just be fine. >> In theory with the new API even if we generated keys just for some very short kind of activation period, we can then extend it.

So, basically just putting activation epoch not zero but some larger number like I don't know, 1,000. >> Great, but you still need public key to generate the public keys to run it all all through. So, once we probably have this >> Once we have this set of validators, definitely, you know, you don't need while running a validator, you don't need to regen them. So, they can be on the fly generated. but, yes. >> Yeah, maybe it's a good exercise for client teams kind of I don't know, come up with a mechanism

of how to kind of extend the keys of the activation period like if >> Also, there's maybe one thing I should say here that if you choose a activation interval that is smaller than 2 to the 17, then it will just automatically pick a larger interval. So, with this new API change, we also sort of have a a minimum activation period because you have at least two bottom trees. So, it doesn't really make sense for you to use a smaller activation time because keygen will still take as long as 2 to 17 like uh time. So, I would recommend to use I

don't know, 2 to the 18 as something as a starting point for the size of the activation interval. Because if you use something smaller, then we also don't see whether the the uh top-bottom tree traversal thing really works. Uh any other discussion topics?

>> I did want to share a couple pieces of of of of good news. Uh these are a little tentative. Uh so just uh keep them within yourselves for now. Um the first one is that it looks like we made a dramatic breakthrough in performance for um hashing so proving hash functions. Um so we're now two times the target that we set ourselves. So we've we've uh beat the target by a factor of two and that's on an old computer, a 4-year-old computer. On the more recent computer, we're 4x uh the uh the the the target.

the other piece of good news is that 2 weeks after the completion of the post-quantum workshop, we have our very first paper um that has been birthed at the workshop. Um it will be presented um as part of uh link uh so E-Proof score number six. Uh Emil will also be presenting some of his performance improvements in EIP proof core number six. And then there's another thing that I wanted to tease, which is that uh there's been quite likely a very significant breakthrough on the proximity prize and the proximity gaps

results. And that that will be presented during EIP proof core number number six. All of these things are are things that the devs shouldn't really worry about because they're all contained and abstracted away in as part of Lean VM, but basically both the performance and the security of Lean VM have had significant breakthroughs in the last few days and weeks. >> Incredible.

Uh speaking of Cambridge, I'm very close to having all of the videos, transcripts, and summaries ready to push. it's about the equivalent of seven beam days of content. So you guys didn't make it too easy on me. Um but yeah, I think it's all coming together really well. Uh trying to have it be a a useful resource moving forward. So bear with me. It might take another couple days, but hope to have it out by the end of the week.

>> I I do recognize that I've been I've been very quiet about the the Cambridge workshop and like all of the all of the progress that's been happening. This is for a couple of reasons. The first one is that there's this marketing videos that are being worked on. Um secondly, the first anniversary of the the introduction of the Beam chain is is coming up relatively soon. So, I'm hoping to use that as an opportunity to to make some noise. But, the TLDR is that we have made an absolutely humongous amount of progress in 1 year, much more than I could have ever hoped for. So, yeah, congratulations to everyone.

>> Beautiful. If there's nothing else, that seems like a really nice fine note to end on. Okay. Um, and also, yeah, once once the Cambridge stuff is up, I promise I'm going to get some of these most recent PQ interrupt calls processed and up to YouTube also. So, hopefully, those will be there soon.

Thanks for bearing with me. Take care, all. >> Thank you, all. >> Thanks, everyone. >> Thanks, too. >> Thank you. Bye. >> Bye.