Post-Quantum Interop Call #12

Transcript

Good morning, Will. >> Good morning. >> Uh, Cambridge was nice. >> Oh, it was great. >> Lovely time. Very productive. >> Yeah, when I went to Istanbul, it was super super cool experience. Think I'm >> Oh, wonderful. think I'm going to go to Dev Connect this year again as well. >> Very cool. Hold

on. Um maybe we'll give it one more minute. Let people roll in. Okay, let's get started. Um, so this is

PQ interrupt call number 12. Uh, it's been a couple weeks since we last met. We had a really productive and fruitful and fun uh get together in in Cambridge uh just last week. Um yeah, so that that whole experience took place uh over the course of three days and then there was a a fourth day that was really focused on the lean VM uh design and discussion and yeah within the the PQ workshop component of it there were a couple of different uh work streams. So there is the the the PU DevNet devs, there's uh

PQ theory, postquantum cryptography theory, postquantum cryptography implementation and a formal verification uh work stream also. And so yeah, we we were able to all meet together and kind of start off the day with a touch point uh kind of setting the tone for the day and then there was some structured lectures and some workshops. And so we we started off with having two rooms and we were able to like most days grab a third room. And so uh there was a lot of different uh individual things uh taking place. I wasn't able to attend all three rooms simultaneously, but we were able to get uh solid notes and recordings

which I'm still compiling and hope to uh publish sometime next week. uh going to get that all up on the lean Ethereum um GitHub or and yeah, you know, I thought maybe we could first start with a couple of recaps. Um you know, O, you were the technical lead for uh the DevNet devs and Tomas, you were the technical lead for the PQ implementation, I think. Um, and so, oh, and then Benedict, you were the technical lead for the PQ, uh, theory.

And I don't believe that we have anyone from formal verification on here, but it'd be great if maybe we could just start off with a couple of uh, overviews of what was accomplished and, um, you know, basically your takeaways coming out of that event. Uh, maybe we'll go Oh, and then Tom and then Benedict. Uh yeah sure. Um so well quick disclaimer um technically this probably the the extreme term so I I like I prefer coordinators still um but anyway um so yeah I think for the DevNet track it was very um successful. So we had a few objectives namely first to um finish

off DevNet Zero um and talk about future DevNets. Um so in terms of net zero uh in the end of the third day at the end of the third day we managed to get three clients to interrupt successfully. Um so that's ream seam and clean. Um so well but what happened is that we were able to do this interrupt within first from Jun's machine and then we were able to replicate it on other other machines as well. um we didn't manage to get it on a you know a proper test infrastructure or on curtosis or anything like that because of a time constraint but at least right now we can confirm that the three clients are able to communicate with each other and also able to final

justify and finalize based on the 3SF mini uh and with some modifications to to 3SF mini um which you can refer to or anyone can refer to in the inspect repo Um and kind of like just overview of what were the main hurdles that we had. Um I think it was mainly around networking actually. So in terms of configuring the lip there were uh some some definitions that were not in the lean spec which is also my fault. Um but it was in the beacon spec um and it was kind of like paragraph based as well so

I didn't carry that over. So it was kind of um easy to miss as well. Um but hopefully with the Python specs that we are building right now, all of these whatever configurations um should be more um should be like clear to spot. Um and once we figured out the networking um the consensus I think it was pretty straightforward. most of the hard work that was done. I think it was by done by Gome and Jun uh who had to basically dump the genesis state um and the genesis block from each of the client and compare it field by field whether you know which field that we we got differently in order to to to interop.

So hopefully again like with Python specs if or once we have the test vectors generation available then we should be able to test these um conditions or scenarios um within the client itself and hopefully that would make interop for future dev nets um easier. Um I don't remember exactly but I think we we had um J correct me if I'm wrong. Um so we had two clients each on Jyn's machine. So two ream clients uh two ream instances, two Zam instances and then two clean instances um basically talking to each other. Um and we were able to um yeah basically

run it for for a big while probably like hours I think. Um and it was working perfectly. Um so that that's for for DevNet zero I think and then there's some discussion about devet one I think most of those um discussion points that we had are being incorporated into uh G um sorry Gajinder's um PR right now. So mostly I think the conclusion is definite one will focus on the single um signature first without any aggregation um and then for future uh definness then we'll we'll focus uh the the aggregation on on future def uh like after the net one but I think that is still kind of like up in

the air to be decided depending on like the maturity of the the aggregation and also like the the timeline that we are hoping for definite one so uh that's still to be to confirm uh actually within this group actually and yeah that that's my summary unless I know Jin or G anyone else up and definitely >> awesome thanks yeah Tamar you want to give us your take >> yeah sure so yeah that was pretty big on my side uh because we had like first the the lin VM

day uh where we had one day of full content um about everything related to the minimal VM that we are building to aggregate signatures together. So yeah, the whole day of discussion around deep math and and stuff and then we had like the three days of um postquantum events. So we had a a bunch of amazing outputs especially on the primitive side of things about plunk history uh about we with like very nice discussion with Jako with Angus and with

all of the guys around this ecosystem of primitives and hashbased um hashbased proving system. So a lot of discussions and the whiteboard sessions around maths and how to make things faster. So we have kind of open issues right now about making the PCS faster um implementing some new primitives working on the sum check with the lambda class forks and I think that Emil also has a bunch of amazing outputs from this PQ events u working on the linvm side of things

improving a lot of stuff related to memory related related to the sum check related to the log up argument using the machine. So a bunch of amazing outputs on how to make things faster in general. And finally we had like this very completely different topic CL retreat for me where I I can also give like a very brief uh overview. I was like an inviteee here and I learned a lot of new stuff around like consensus and stuff that could be applied in the future for like lin consensus. We can experiment a lot with the new things like finality gadgets

like um rainbow staking a a lot of stuff that were discussed with the consensus team that could be applied and experiment in in the future in lin consensus. So that is also like a a very good avenue for future improvement and yeah that is basically it for for me >> that was great thanks to uh Benedict anything from the PQ3 side >> yeah so I think there were like three big blocks in terms of theory so the first one was uh yeah let's say posidon so uh we talked about posidon and how to formul ate and how to define the

bounties for the next year and how to like Dimmitri talked about how how like the budget should be for the Poseidon initiative next year because as you all know if Poseidon is insecure then we are all screwed and we can go home with our uh signature scheme. Um so um that was one big block. Then the other big block was sort of uh fry and proximity price. So as you all know the modern proof systems they rely on sort of proximity tests and one very popular one is fry and uh the analysis of these tests or these protocols relies on unproven

conjectures about read Solomon codes um and there's this sort of idea to have a proximity prize which uh says you get a lot of money if you if you uh prove these conjectures or disprove them but the rules are fully unclear. So we made a lot of progress of on uh how to define the rules for that price for that sort of competition. Um and uh yeah we also talked about these conjectures of course and then made some progress on the conjectures. Um and then the third big block was of course uh the the hashbased signature scheme XMSS and uh our XMSS variant and the different components of it and how to make it lean

VM friendly which is kind of uh tricky because lean VM is still under development. So uh uh it's kind of uh yeah the scheme is stable but one takeaway from the from the interrop is that uh there are some parts that may still change in the future even for the the basic signature scheme for example the encoding uh and and all of that stuff um or whether we have tweaks in the Merkel tree or not. And uh this is all still under discussion and I think we need to really uh make sure we we have a scheme that is not only leanvm friendly but also secure and also uh simple enough for people to

understand it and I think there is still uh kind of yeah some discussion to do there. Um yeah and maybe on that last topic we had two sort of uh immediate uh changes to the scheme that that uh were now implemented in the hashik library and I think uh I can talk about that later. I also commented on that in the in the agenda. >> Great. Thanks so much. Uh yeah, it was it was a very very productive and uh yeah, just felt like a a very fruitful get together. Um so yeah, I appreciate

all the the recaps from everyone. Um, so I don't know if it makes sense to just start with client updates uh on this bednet one if we want to go around the horn with uh re zam and clean. >> Yep. So I can give a quick update from the re side. So uh thanks to gazinder uh the devet one spec is now under construction. So uh we are just uh splitting our tasks uh to implement this pqd1.

Uh so currently I just added the validators field in the lin state uh which will not be um changing in the near future. So that's the starting point. And for the metric size uh Katya was trying to uh uh uh launch uh metrics for the intrade defet. So I just helped her about launching how to de how to u launch speed up a devet and we are also keen to implement missing metrics gauges in our client and yep and also we are um keep looking keep tracking on the hash library because uh

there were a couple of discussions or a couple of proposal about the changes in the API. I so yeah we are keep track keep tracking um that's it. >> Thanks J. >> Um someone from the Zoom side. >> Yep. Hi Will. Yeah, first of all uh congrats and kudos for a great interrop and for a successful interrop for DevNet zero and uh I thank everyone uh involved in Ze as well as ree and kudim clean I think they are now called clean right Kamil

>> yeah we haven't decided you let's let you can call it whatever you want >> from the people >> right right okay so let's go with kulin right for now. We'll change it when you make it ourselves. So uh yeah so we we have achieved the interop and uh thanks to the participants over there and uh so I think the focus now is for devet one for which we are working on the specs and hopefully we'll have them soon. Uh the idea for DevNet one is to uh have the signatures which are not aggregated but they are sort of uh uh separated out from the main block body

into signature field. So you know it feels so it's like aggregated into a nave list rather than aggregated into one single signature. Uh so that that is the plan and uh I think uh by mid November we should be able to interrupt uh for DevNet one that is what we are targeting. Uh and uh then basically we can go to the next step which would be to uh aggregate uh the signatures with lean VM. So yep, that is the plan. And with regard to metrics, there are several PRs that uh Zim has right now and I basically need to review them and

merge them. Uh so we should be catching up with that. uh I think with regard to uh uh with regard to test uh uh format that that is something that uh uh we are basically excited to see it move further and I hope uh uh in today's discussion Philip is going to uh push that uh uh topic forward. So we are basically looking for that. Uh and yep that's all from z side.

Thanksg um clean. >> Yeah everyone I'll try to be short. Uh yeah on our side we basically uh cleaning up the clean repo. Yeah, because uh we kind of had everything working for the interrop but a bunch of things were introduced there kind of in hackathon mode. So uh so yeah trying to uh yeah review changes properly now and uh uh create proper readme uh yeah also working uh with Katya to to introduce metrics properly. Um yeah in parallel uh also working on

uh testing the uh integration with shadow which I maybe can talk a bit more later. Uh yeah have some good progress there. So actually with the good thing yeah we can simulate networks much faster than in real time. So yeah, it would be easier to make sure that uh yeah uh everything working on a kind of on the longer period of time. Yeah, I think that's all from our side for now. Thanks.

>> Thanks so much. Um, Benict, there's a PR that you added a comment on the We're going to jump to spec updates. Uh, maybe we'll start with this PR that you have in flight regarding the hashtags. >> Yeah. So, uh, yeah. So we discussed in in uh in Cambridge that um the the hashtag library or like the signature scheme needs an API change because uh as it was before this PR um you just generate the entire tree and then you store the tree in the secret key which is fine for small uh activation periods or like the lifetimes that you have. Um

and it allows you to have a very fast signing algorithm. But um of course if you now go to the the full lifetime of 2 to the 32 this will just be hundreds of gigabytes that you have uh in your secret key that you would have to keep in ROM and that's like not feasible. So uh what we discussed in Cambridge is a is a change to that where we um only store parts of the tree and this PR implements this change. Um, and because we only store parts of the tree, we need to provide a method to the to the clients or like the users of this library to uh go to the next part of the tree. And we discussed how this API should look like in Cambridge. And this is sort of now uh the the result of

that. Um, yeah, I think Camille, you raised your hand. Uh yeah, just a question out of curiosity, not a request for feature or anything, but yeah, I think we discussed in Cambridge that it would be possible to kind of instead of storing like gigabytes uh of this key data in RAM, you could just reduce it to two megabytes if I'm not mistaken. >> Yeah, something like that. >> Two megabytes. It's I think we were a bit too optimistic there. I think it's like maybe for the trees now it's you store at most uh four at the same time and uh it's like of the size two to the 16. So I think if

I'm not wrong it's like 8 mgabytes or something. >> Oh okay. Okay. Yeah. Because my question was like whether it would be possible to even shrink it further uh for example to I don't know less than 500 kilobytes because I'm just asking because I remember Justin was mentioned somewhere that well that in future yeah we might be even able to run some uh validators in something like Raspberry Pi Pico which actually has around this like 500 kilobytes just again out of curio in principle it is it just means that you need to do more work when you regenerate things. But this implementation would just split the tree into two parts. The top part that you always store and the

lower part where you sort of iterate through the the uh trees. >> But yeah, in principle it's of course possible to just store the seed, right? But then you of course need to do much more work when you want to sign or before you want to sign. >> Mhm. Well, as the tree is not confidential, in fact, it might be possible for such really lightweight validators to just delegate the storage of part of the tree to, I don't know, to aggregators, for example, >> if they do that.

>> Yeah. >> Okay, great. >> That's something that that you could do in the future. I think we currently don't plan to integrate that soon into the library. So >> yeah, >> uh Verun, I pasted your question from the uh PR or sorry from the the agenda issue into the chat. I don't know if you wanted to follow up. You were asking about do we need instantiation using these test parameters.

>> Yeah. Uh so so for context uh we were upgrading or we were updating our hashig uh dependencies in re and like Benedict said that there were a few API changes and those are breaking changes. Um and we were initially using uh a custom scheme using these parameters which is from the lean spec and after the recent changes uh we can't create custom schemes uh because of I I'm I'm guessing because we don't want to uh make all the components public but so I wanted to know whether this uh whether this scheme would be added to the hash secret rate uh I mean these parameters would be added to the hash secret rate or not or

whether we actually need them at all. >> You mean like the the one from the linspec? Oh yeah, >> but they should they should correspond to some some equivalent in the >> there are two right so in the leanspec there are these there are two sets of parameters one is the real >> and then there's this linked right the test whatever they alas are clearly insecure so I don't know why we would do anything with those um I mean it's a smaller signature size so why would this doing tests with these

parameters mean anything to us that's not clear to me so I would just screw them and like just use the real parameters >> got it I just wanted to make sure that we whether we need that or not at all >> no I think that it was on the lin side of things it was just to to be able to run something because if I run like the if I run the key genen uh with the production parameters then it will take ages or we cannot put that in the CI for example but you you you don't need to consider these ones like these are just like mocking like >> got it okay the we we'll scrap the test

parameters and just work with the ones that are already there in the library. Thank you. >> Yes, >> yeah, this sounds good to me. Just use the real ones. Uh I'm realizing when we went around the horn doing client updates, uh I failed to ask Lantern. Uh Mahir, I see you on the call. I don't know if there's anything that you wanted to add. Um, yep. Hi Will. Hi everyone. Yep. So, uh, I guess from our end, um, we we're actually just working through implementing Gossip Sub, uh, version

1.1. Um, and basically, uh, once that is done, we'll just be like trying to interrupt it with Golia P2P and Rustly P2P. Um and I guess once that is uh once that is passing all tests um we'll be uh trying to implement the lean specs um and then uh see if we can join devet one. Um yeah >> excellent thanks mayor. Uh I guess we I would like to continue talking about spec updates. Uh, I don't know if there's anything that you want

to add. I I think I heard someone mention earlier you might have something you wanted to discuss. >> Um, yeah, I can I can update. Uh, I I' I've been working on my on my side of things to um try to leverage our pyantic models uh for creating test vectors. And um I've started with some framework changes there. Um basically introducing the concept that we use for the execution specs.

Um so we don't really have a design in mind for the test vectors yet. So I'm working on the framework changes and uh my goal is to put up a PR so that we can uh discuss uh what these vectors will look like um in this PR and yeah obviously I wasn't there in um this event and it's it's really exciting to just hear all the updates too from from my side. Congrats everyone.

>> Great. Thanks, Felipe. Uh I don't know if the if you had any other spec related updates or or anyone else. Um on my side for DevNet one, I just um pushed a PR at the beginning of the week just to remove all of the code snippets from the markdowns. I just let them through for devet zero to avoid confusion. But now that we have in we are in this inde one we just have to rely on the python code inside the python files and the dogs folder is just here to add some precision or had more information about very tricky stuff but

no more code in there. so that we have a cleaner spec. Otherwise, I I I I think I will work a bit like with um with Felipe after he submitted the the very nice PR with good good test vectors and then trying to uh update more files and all of our files to provide test vectors for the the client teams uh to to consume. Just to add what we can do is we can also create releases for for example DevNet one like how do we how we do on consensus specs so that uh you know uh

the releases itself will have the list of PRs that would for example apply for devet one on the lean spec repo. Yeah, we could do that starting from devet one. Let us say like devet zero was like such a draft that maybe this is not like good for release but starting from divet one we could make that for sure. Yeah, >> you want to give an update on on metrics? I saw you posting some things earlier.

>> Yeah, sure. So currently um I built metrics locally for clean uh and I'm trying to test them uh like running small interrop with the rim client uh and the sim client will be the next one. Um so um I hope to merge this uh initial PR with DevNet zero metrics uh by the end of the week and switch to the DevNet one um in case if researchers um have some like um uh some metrics on their mind I don't know like byte-size of signatures etc.

So please share it uh into in the PQ interrup chat in the telegram. So probably some things might be interesting for you to look at. So currently I'm doing it uh kind of intuitionally following the specs but maybe you are interested in the specific um you know numbers and values that would be great to hear from you as well. Um yeah uh I will soon reach out to Zim team about uh yeah running locally and small intro. Thank you. And I'm going to push the dashboard soon. It's kind of ready just uh tiny fixes and uh the dashboard will be also there um in the

metrics repo currently. >> We'll just share the update in the chat. Yeah. >> Yeah. Just to add on top of it uh keso yes one thing that uh you can basically do is you can integrate your work into lean quick start. Now uh all the uh nodes are spin with the metric ports which is uh a mercy added and uh basically if uh we can add uh your infra or your work over there I think directly that work will get propagated further.

Yep. Sure. >> All right. Thanks, Kata. Uh, Camille, you want to take the screen and show the demo that you mentioned? >> Yeah, let me just quick quickly explain what is what is this. Uh so basically uh yeah we integrated uh clean into shadow. What it allows us to do is uh well we can set for example the time that we want to simulate for example 5 minutes.

Uh we can set the speed in the network. Um yeah there there are also more parameters like we could uh basically create explain like what should be the latencies between the peers. uh or what should be the bandwidth all of this and uh yeah just taking existing binaries uh yeah simulate the network uh a good side effect effect by the way which I believe uh client implementers would find useful is that uh in simulated time it actually simulated time starts from always the same like because shadow actually replaces system calls so uh instead of

just uh always updating our what should be our genetics time. We just can set it to be like uh uh January 1 of uh year 2000 0 uh a.m. and uh yeah it always will be the same because that's the time when shadow starts. Um yeah um so once we create this uh shadow yl file yeah we also made some changes to the clean itself because uh shadow actually doesn't support all the uh system calls for example some system calls that some quick libraries use they are not supported um so we had to patch this a little bit uh but yeah for clean it

actually works fine I believe just let me like remove if we have any shadow. No. Yeah, we can just run it. Yep, I think this should work. Yeah. And uh so yeah, we basically have here running network. And here you can see kind of the uh simulated time and real time. You see that simulated time in case of if we have just in this particular example we have four nodes running and u you see that in like I don't know less than 30 seconds we actually simulated about 3 minutes of the simulated time um and the whole

simulation took I think I don't know takes around around 40 seconds for five minutes that's for four nodes uh once we have more nodes This time actually uh might be slower because uh yeah obviously we have like more connections they grow exponentially in their size. We have to keep more things in memory to make it work. Um yeah uh but overall it works. Um yeah it's uh yeah in in clean logs we see that yeah target is growing. Um uh yeah 69 source is growing. So basically consensus is 3SF is working uh which is cool. We actually even

um yeah we also tried interrup um it's uh kind of works. Uh but yeah we had to make a small patch to rim to make it work. We might open a pull request uh to rim repo if they don't mind. Um yeah, we basically had to update uh how quick works there. Uh yeah, I just had uh yeah uh I probably misconfigured it somewhere because um yeah, I think it's not two std out.

So yeah uh the they seem to be working which is good but uh I just noticed before the call that yes source and target oh source is not growing so u might be some issue with how I configured the network but anyway so yeah we can even try interrupt in this environment it might be convenient maybe while we don't have the uh curtosis or something this also could be an alternative in some sense I don't know Um yeah and simulate different networking behaviors like slow network and so on and or just if we want to simulate uh something much faster than real time yeah this is also possible when we don't have too many nodes and why we don't

have like some crazy RAM requirements u so yeah uh oh yeah I see the question can I ask different compared to simulation single machine only yes it's single machine only uh uh also curtosis requires docker here we need native builds uh on machine uh also it oh yeah one inconvenient thing is that uh it to make it work we need uh AMD 64 uh platform basically we cannot run it uh in yeah silicon MacBooks for example and um yeah uh yes it's actively being used today in

Ethereum yeah to basically many clients I mean existing clients support it. Um yes and uh yeah but here we also can kind of create the config file and um yeah this should work. Yeah maybe also I don't know I I I never worked too closely with curtosis I suppose in curtosis we can just create uh some config file with the number of peers and so on. Here we actually have to create the shadow YAML file ourselves. But uh yeah for example we did also integration with shadow in some other networks and there we just uh created a simple bash script which can create all these configs for you. Here

we have like lean genetics generator which is useful for for that purposes. So I think yeah we can use this um yeah we're all just convenient tool uh to test different kind of networking behaviors and yeah simulate networks faster than real time. Yep. Thanks >> and yeah we also we'll check whether we can also in integrate zim into that uh and yeah might open the pull requests there as well. Um, yep.

Cool. Yeah, thanks. That's all I had. >> Great. Um, thanks Camille. That is the extent of everything I see on the agenda issue or have been asked to to bring up. Uh, were there any other topics that people would like to table? Uh yeah, maybe a quick one. We're currently discussing I believe the uh just storing all the signatures in the block uh for the DevNet one. Uh yeah, like uh do we plan to keep it this

way or for in future for is it only for DevNet one? I mean for DevNet 2 and next uh yeah we will replace it with some aggregation data. Um because I believe here in Cambridge we discussed that we might actually yeah use uh res coding scheme to actually distribute the some aggregation data that we get from the signatures but currently I I don't think it's kind of makes sense to do this for uh aggregated or not aggregated but just uh the array of all signatures because the assumptions will be different I mean the aggregation size would 128 kilobytes

and here the size is basically 3 kilobytes times the number of validators uh so I mean for do basically the question like do we want to have uh this coding distribution for the devet one or yeah we want to do this next time just any thoughts on that or we just distribute blocks as as before uh using coip sub and oh sorry not go yeah I mean we don't have a record coding distribution for for the signatures right for the aggregations I mean for net one

>> I think answer is no and we plan it further for the next the dev nets maybe. Yeah, just something to keep in mind. Uh just if we have yeah my concern just was like whether we should yeah introduce the record coding in DevNet one or we do it next time because if we do then we have to do some aggregation uh we have to store aggregation not maybe the all the signatures. Yep.

Okay, >> my personal opinion is that uh we can just focus on integrating PQ signature as defin uh so that uh we can iterate as fast as we can. >> Mhm. Yeah. Okay, let's do this. Is there a an ETA for shipping DevNet one? >> I think we can target uh interop mid next month

>> before Ste connect >> I guess. I mean uh who's whoever are attending defconet they might get together or we can do remotely or a mix of that. >> Um do we need uh to use this top bottom tree traversal that Benedict is proposing I think uh for the PQ interrupt or sorry for the definite one or we just stick with existing schemas.

I think we can I think we can uh if the library gets ready fast enough then we can probably use it because uh >> then basically it's just integrating the new API. >> Uh so I think we can take the call by end of this month. >> Okay. Maybe if Benedict is still in the call. Is it realistic to have it this quest merged? I mean by the mean >> I think so. I mean there's Tomar just gave a a review. I will address the reviews the stuff from the review and then yeah maybe Dimitry can look at it as well or or we just merge it. I guess it's Yeah,

I guess that's realistic like end of the month for sure. >> Okay. Uh I I didn't check closely but are there any bindings in this uh repo already which we can use or we have to make them ourselves? Uh, no, it's just the rust. >> Okay. Yeah, we'll take a look then. >> Uh, in the chat, June posted, I have a question regarding pecking block and proposers at his station. So, proposers can sign only once in a slot. Yeah, I want to I wasn't at the Cambridge interrupt, so I may be missing

something. But I want to ask people about the the idea of packing messages into one so the proposer can sign once in a slot. I agree that this would be good enough for the upcoming few devets. But if you were to adopt this PQ signature effort in a production level protocol, I think we need to tackle the problem of signing multiple times in a slot properly because um signing multiple message means that there is only one deadline within a slot and I think this is not flexible enough to meet all the needs of the protocol.

Um so in my opinion I think we can find a proper solution for this problem. So we can sign multiple messages in a slot or we can just adopt the stop gas solure like this for this dev nets like packing for example and if you were to I don't have a strong opinion which way we should go but if you were to go for the letter maybe we can go with a simpler solution such as adding a rule that proposer just don't vote for example.

Yeah, >> sorry. >> Go ahead. >> Yeah, Justin, please go ahead. >> Yeah, so I have been spending a bit of time uh thinking about this and I think I do agree with you that um bundling the two might not be the best idea. Um you mentioned the different deadlines, right? So attesting and proposing happen at different points in time. Maybe they can be smoothed out, but it's kind of annoying to deal with. The other disadvantage that comes to mind is that the slashing conditions will be more complicated because we have to make the special case for

um for the proposers at the station. And then Gatender, I believe in the chat a few days ago, also made a good point around making it more difficult to include the proposes at the station if if the block is orphaned out um and and having it included at at some some some future point in time, you know, just for incentivization purposes. Now the question becomes um what is a potential solution?

One that might be possible I quite like is is the idea of introducing an invariant where no single proposer will sign twice within some proposal epoch for example within the look ahead. So if the look ahead is let's say 128 slots and no proposer will appear twice within 128 slots um then what we can do is generate 100 128 times fewer um one-time signatures than for than for attestations and so it's it's less than a 1% overhead in in

in key gen uh but that that hinges on us being able to to enforce this invariance, which I'm optimistic we we we can we can do it. Um I guess another solution which is I guess quite ugly is to to have a a stateful signatures just to sign miscellaneous messages. But now we have two two different types of of signature schemes. Um, yeah, I'm curious if others have have any thoughts here.

>> Maybe Kajinder, you want to say something? Yeah, I basically most of what I wanted to say Justin covered it and definitely this is a bit ugly and uh ugly sort of solution and even what the what we have currently proposed in PR67 it's going through some iterations but yes we might be able to work it uh for uh for the proposal voting as well but then uh you know the lean VM uh signature VM needs to be much stronger to handle different cases in which you would you would want to aggregate uh the signatures and saying that okay you know even if there is a aggregated block signature it might

represent so many valid objects that were in the block uh and it also basically goes when you want to do back slashings etc and say that you know these these validators are to be slashed because these signatures because these signatures were there and uh they belong to this particular validator uh and so so I I mean yes so there there will be a little bit more uh complexity for lean VM and maybe we don't want it uh so in that sense uh yeah I think we'll iterate and figure out what is the best uh protocol to go about it for devet one definitely we are going with the uh with the proposer at

test station and uh proposer uh proposal as one uh object. Uh but what we have now decided is that okay uh that the vote of the proposer is a bit bundled with the block. It's not inside the block body. So that proposer can create the block and then it can create the vote independently. Uh so basically it has simplified a bit. It has it has been simplified a little bit and uh we will update the PR. uh but apart from that other concerns uh are definitely you know there in terms of uh whether this is a good design or not.

I think my question is about um so if we confine this discussion to the upcoming dev nets I think it doesn't really matter which solution we adopted to be honest like yeah whether we bundle proposal vote into uh their blog or not I don't think it's that matter I'm asking a question about like if we actually want to adopt this effort into production level protocol that like for example Ethereum already has many committees. So what I have in my mind is in the world where a proposer needs to sign multiple messages whether it be

block a test station or I don't know maybe a sync committee message or whatever like then do we want to bundle all of them into one message or do we want to find a solution that a proposer as a validator can sign multiple objects in a slot. Yeah, I think one of the things that we should ask is that do we need multiple signatures because we discussed this before and we came to a conclusion that we actually don't need multiple signatures. For example, sync committee is not going to be there. Uh so so so the question is do we need multiple signatures and if we do

need multiple signatures then the solution is sort of easy which is a nice solution is that you enroll multiple keys into the validator uh validators uh object into the state. uh so that way I mean it is a easy way out but it will definitely increase the time comp the time complex comp complexity of uh spinning up the key generation as well as uh you know generating new keys uh but for example if we have uh uh if we have the uh the new mechanism in which uh uh that the new mechanism and the new uh key generation

uh uh uh uh API that uh has been proposed and that PR will be merged by end of this month where you can basically uh look ahead and compute a part of the key set. I think that will help uh in terms of managing the complexity of running a validator not complexity basically logistics of running a validator where you you won't have to generate all of the uh all of the keys together. uh but as such you might still have the complexity because to generate your public keys you might still need to go through the entire tree. So I think all those challenges are there and uh if we try to minimize the number of key pairs that we need for

a particular validator that would essentially be a good thing. So question is do we actually need multiple messages if we have a dynamic uh lean VM lean signature VM which can basically consume these different kind of signature paths and basically says that okay you know uh these are all valid signatures and here's the signature proof for it. Yeah. So I agree we we need to look at just the individual messages on a case- by case basis. The good news is that uh the sync committee should go away. Um even the withdrawal signature should

should go away. So the the idea is to just have withdrawals be triggered from the from the L1. now during the uh the Cambridge workshop for the the consensus layer part uh we've been discussing all sorts of designs uh for for finality uh fast finality and one design that seems to be very popular is to have uh an initial small committee for example of site 256 um that would uh basically come before the uh the the finality the full fin the full

economic security uh gadget. And so there there might be this other type of signature scheme um sorry signature type uh required but I guess this is still you know very much active research and so for now I would just uh stick with 3SF mini. One piece of good news is that um right now when we do key genen we we're not using CIND and so key gen should just get four times faster uh on on the on on both the the Mac and and non-MAC CPUs.

Um and so that should hopefully simultaneously um reduce the overall burden of key gen but also potentially allow us to have you know more than one signature per slot. And it doesn't mean there has to be two. It could be like one and a bit if we have these invariants where um you you you don't you don't have to sign every single slot. Yeah, I think um it boils down to a question that whether there will be a case that you need to broadcast more than one message in a slot and if we

strongly believe that there will be no such case and that constraint would still be able to satisfy all needs of the protocol, then yeah, maybe it's Okay, I'm just like a for me it sounds like a very strong um or opinionated decision and maybe it's a bit early to make such constraint because it's like uh it closes some doors for design scope because like committee was just an example there might be other committees in the future. I'm not sure if you will going to have fossil in future but if we have it then there will be I committee

then maybe yeah we are thinking about in a very long-term vision so um like rainbow staking there will be included which is different responsibility to like a test station for example then maybe we can design it very well that you don't need to sign more than one message in a slot but Yeah. Yeah. That was just my concern about like are we really okay with that constraint I mean having that constraint in this early phase.

>> Yeah you you you make a good point. Um, regarding the includers, uh, one of the outcomes of of Cambridge is that, uh, we might also be able to use the execution layer for that. Um, so the the signatures wouldn't come from consensus participants. they would actually come from uh from if if uh execution layer addresses uh EOAs. Um so just like an EOA can trigger a withdrawal, you could have an EOA uh be responsible for for an inclusion list

and effectively the inclusion list is just a set of execution layer transactions. And so it kind of makes more sense to have it at the execution layer. Um and the only thing that the consensus layer would be doing is delegating to execution layer addresses. Um but yeah that is a very it's a very new idea. Um but yeah we it's tough because there is a solution which is just to have the stateless a stateless signature for example Sphinx. Um, but now you're just adding adding complexity. So I

think we need to let the dust settle a little bit and then we can make a more informed decision. Okay. Thank you. So I I think we can um I think it's correct to understand that we were going to uh go with this way. I mean uh like design once in a slot. Um but like still like I'm not 100% convinced that the current approach would be the ideal solution. Like I I want to understand what hap what could go wrong if we just add a rule that a proposer just doesn't vote for example

because I think that added like a proposer a testation data thing adds kind of like a complexity that might not be necessary um but that's kind of something we can discuss offline so yeah thank you for all the answers um Justin and Gajinder thank Excellent. Um well, anything else people want to bring up? I know we're few minutes over.

All right. Uh I guess we'll call it here. Thanks all. I will see you next week. >> Thank you. Thanks. >> Thanks everyone. >> See you guys next week.