Post-Quantum Interop Call #2

Transcript

Hi. Uh, I guess this is the first public uh PQ interrupt call. I've got an agenda I will drop into the chat. Um, I feel like my recordings have a pattern of being a little uh atypical from everyone else's because I'm always sharing my screen. I'm going to be Trying to do that less so that I keep the gallery view going. All right, there is the agenda. Um, we have a number of items to cover. I guess first and foremost, you know, there's just some links. Uh, you know, we talked

about uh just getting some basic uh project management processes in place for being able to post collaborative documents. um keep track of meeting minutes, things of that nature. So we have uh this new uh GitHub organization, Lean Ethereum. Uh normally we we keep track of all this in the main Ethereum PM repo, but we've created a PM repo within the lean Ethereum org just so that we could have u a little bit faster turnaround in terms of like uh pushing PRs and and merging things. Um but yeah within that uh org you will find a folder at the top EQ interop and within

there there is a uh primary file that or link that is just the EQ interop PM document which I just dropped into the chat. And this will just be uh this is I guess uh on par with what you would find in the main Ethereum PM repo where try to keep a running link list of links to the different uh DevNet specifications as they get authored and try to note the dates that they're activated and deprecated. And then medium minutes below that just below that I just try to transcribe some of the things that we

had in that Google doc which are just a list of additional resources original proposals uh related lectures and notes. Um and then some of the the lean Ethereum specifications that have been coming together. Uh, also have a just I like to keep a list of contributors. Just I'm still new trying to learn people's names and things. This is helpful for me. I figure it's helpful for others. Um, happy to add to it as we go. And then uh I'll kind of maybe hand it off to uh O with this last uh link that I'll drop in the chat. This is

our first working pull request. So Evan had a real chance to look at the at the comments on this, but I just put together a basic template based off of what uh Pandops usually authors for uh a normal DevNet like we've done and a bunch of other things. Uh so I guess this is like the main objective for the rest of this month is to arrive at a shared specification and kind of parameters for this DevNet zero. Um I don't know O or Gajunter if if you want to speak to some of this. You know O I I picked up your comments that you had on

the agenda issue you know just trying to like foreground some decision- making and um some processes of you know if you want to speak to that that'd be great. >> Yeah. Uh maybe I can share the screen and um show um our review comments. Um just a sec. Um um this is not it just some problem. Okay. Um so yeah so these are the feedbacks that we have talked inside uh

the team and and shared as as a single comment. Um so uh signature wise I think uh we are pretty stable at like hashing like 64 hashing chain length 8. Um I think from Benex suggestion I think it looks like we can go with like the max lifetime of two to the^ 32 uh while introducing an activation time which is basically the the actual length of the the actual lifetime that we will be generating the keys for up to two to the power 18. Um so I think that's that's good. Um believe this is Ginder. Uh so that's that's good as well. He plus one on this um slot duration. Uh our team also think

you know let's go with the aggressive 4 seconds number and then if things get worse and then we can't meet this then I guess like we can adjust it uh over time. But I think like going with aggressive number first is probably more beneficial than using a more more more a longer timeline a longer longer slot time. Um this is something I think that we can we can discuss a bit more in this call. Uh basically uh I think I still I'm still not so sure what what the values would be out of like using TCP. So if if Camu can can illustrate that more I think that would be great. Uh good should be good.

>> Yeah. >> Cool. Yeah. Um gossip sub I think we can go for v 1.2 instead of like beacon chains one 1.1 right now. Um I think this is also another big discussion that we can take. Um basically from our previous call I think Justin uh suggested in the last few minutes of the call that we could maybe break down into four iterations or or four big iterations. First iteration would be the PQSC without aggregation. Second iteration we add the single subnet aggregation. Uh the third iteration we add chaining. So basically putting parents uh parent route into child root.

Um and then add SF at the end. Um we discussed this a bit in the team and um we are quite uh concerned with the timeline for the aggregation scheme. So um but generally we agree that like we can break down into into like multiple iterations. So instead we propose that we start off with PQ signal no aggregation. So that's that's as is um but instead of doing aggregation then maybe we can move up to chaining and uh consensus um maybe 3SF as a second iteration and then aggregation comes as a as a third iteration.

this one if a new one has some time I think so we haven't we don't have a consensus specs yet but um so we have already kind of like started thinking about like what containers what types are we going to use uh for the client and in eventually we have to agree this across teams and I kind of like feel that we are missing something similar to a consensus spec test where when we when we built our PC beacon client that helped a lot because it's basically the baseline of like what we have to do in order to to to to form the client. So I v I' coded this uh lean spec test up. So it's basically kind of like consensus spec test. The only difference is that in the beacon chain cons spec test the test vectors are already in SSC and

already uh compressed in snappy. Um but that for me I think like it's really hard to to actually like um understand because like you have to decode and all that. So what I propose instead is that we actually base out of like Python um Python code and then only when we agree upon we can actually run a command so that it it turns that Python code into SSC data and then maybe press it if we need to. So hopefully we can then use this um kind of format to also discuss about like discuss and also confirm like the types and containers and possibly like the state transitions uh functions if you need to to confirm them.

the rest um I guess like the rest are probably pretty minor that we can actually discuss in in in offline. yeah so I think most mostly it's um up for discussion is yeah the networking and I guess like the the sequence of the iterations we want to do. So this first DevNet you're suggesting would be just the PQ SIG generation with no aggregation and then once that's working move on to DevNet one where we would add chaining and the 3SF um consensus and then go to DevNet 2 add a single subset of aggregation.

So here I would like to defer with RA and I would basically emphasize that we should have chaining from day one itself because uh if we are sort of voting we need uh the head that we are voting to and we at least need chaining to run LM cost and come to that head because if we don't have then uh it then basically you know there will be more and more bugs and errors to arrive at what was the correct head to be voted that and uh I think that would waste more time than what we are trying to save over here. Uh so chaining is not really a big deal unless that fork choice is a fork choice

writing a fork choice will be a big deal for it. Uh but I think it is pretty doable and we should go with chaining even if we don't want from the get- go. >> That sounds good. What kind of fork choice algorithm would you suggest just LMD goes or 3SF? >> Yeah. Yeah. So 3SF we don't need because 3SF is uh used for justified and uh uh for finalization. So we don't need to have source and target in the votes.

we'll just vote on the head and the head is basically you know whatever is the heaviest uh tip uh that that is out there right so uh heaviest tip or heaviest lens right so because they're so so what what really means is that we would still need to account for validate validators latest votes and sort of uh have the folk choice where we we alter uh alter uh the weights when we get new votes uh on the latest cycle and sort of decide what is the next head to be voted on and it is also important because our success criteria is depend upon the head accuracy. So um so that so we need a correct head and uh if we don't have

that then there is a lot lots and lots of scope for bugs. If we don't have 3sf but we don't have is that okay you know we'll have a chain that could be quite forky in the sense that one could try to create and a validator could come up that can try to create a fork out of uh an ancestor which is very old but we are running only 10 days long devet. So that should not be a problem. We can just even keep all the uh all the states in the head all the states in the memory. Uh so there would be no pruning because there is no justified uh or uh so we we can keep all the states in the memory and uh since it's just 10 days long

definite maybe uh we'll be able to survive it. uh but if we are not able to survive it in the first iteration then we can just run it maybe to 2 days or 3 days depending upon how much memory we can survive with uh so so if once we don't have the finalization then basically we can sort of lower the length of the devet that we are going with but we still need chaining I think chaining is something that we should not do away with >> right so we for example we will not going to test sync So we don't need finalization but um when we say fork choice here I guess it's beon chain fork choice right

>> yeah it's it's not really beacon chain fk choice in the sense that it is a very quite simple fork choice because you have a fixed value data set there are no moving through there is no epoch transitions you don't have uh any epoch transitions there is a fixed valid data set each validator has a weight of one but uh with respect to the fork choice mechanism that is out there, we just run it uh everything else except the finalization and the justification bits. Uh so we so we have uh so in the fork choice uh we need to track the latest votes of each validator and then bases upon that we need to keep updating uh the score. So we so for example Zim

already has this implemented along with 3SF but that you have a proto array like how we have in the beacon and uh you have the weights attached to it and then basically you know you run your update head uh on each slot to get what is the latest head uh and uh basically then what according to that so that is something I think is the basic mechanism we should not do away with >> yeah I think it makes sense but I I think um I think we want to have some sort of spec so that we don't need to uh we don't have to read each other's implementation to figure out how it's

implemented. >> Yeah. Uh I guess uh we can work on the spec because it's not going to be difficult. It would be it would be quite easy. So yeah, sounds good. We we can work on that spec. So we will have a minimal consensus spec uh act. So it's not like that we'll not have no consensus but there will be a consensus mechanism. Uh there will be a state route there will be states to maintain because all those are sort of part of running a very basic blockchain.

And uh if we for example also have uh uh block by root then we basically need to sync the parents to uh get a chain to finally uh if if a client for example goes down and is coming back up again because all these kind of things will happen uh even if we think that they might not uh but since you know we this is this happens even in the mature client so it will definitely happen uh to uh the new clients like us and uh while we are figuring all this out. So uh I think chaining we should retain and we can work on the spec for that which includes the fork choice how we find the

head for it. >> Great. Great. Um then in in your mind would it be like would it be like the first iteration would be just chaining with minimized fork choice and then we test aggregation or do you think we better do both of them in the first iteration iteration? >> No, we don't need aggregation in the first iteration because aggregation can come later. Aggregation is only there to save the block space, right? It is right. I mean the fact we we want to have P sign yeah P signature. Sorry P >> I confused.

>> Sorry >> Got it. Uh yeah. So what we can do is we can have DevNet zero just with chaining and then we can do the DevNet one with PQ signatures. We can we can do that because uh that would sort of help us uh zero down to any issues that that are there. So that will be fine because in the meantime, you know, we'll also get our signature libraries ready and all that. So that sounds like a good plan. >> So am I writing down correctly that first iteration is chaining with minimal fork choice and signature will only come in the second iteration and then

aggregation after. >> Oh, I thought PQ was part of this. Thank you. >> Right. So, so chaining and minimal fork choice you can say it's an iteration zero. It's like you know we are just testing our clients out uh even before the real uh signature definite is happening so that uh we are basically we don't uh we agree on that uh particular chaining spec and uh we don't run into those issues. So I mean it's like a invisible iteration you can say that uh but yes I mean the uh idea would be to get over this particular iteration quite fast.

>> Just maybe quick note on that. I think I think um your last point Kinder was important like um if we can do this pretty fast and I think it makes a lot of sense. Uh but if we are planning for this to be by end of the year and only start doing PQ sick next year then that's probably I would I would challenge that but let's say that >> I think uh chaining yeah I totally agree with you chaining we should we can try even by next month end right so we already have it so we just need to agree on a spec and uh what we what what we need to do is we need to undo the 3SF that is not really a big deal uh to undo because it's like okay you know we we

it's like stop having 3SF uh and uh so so it's quite easy for us uh so the timeline is totally dependent upon what is comfortable with but I think we can do it uh by end of next month we can start to have an interrupt and it will be a good thing because we would sort of also get a good feel about interoping with each other >> yeah Sounds good. And I think with that we can probably still aim for like having PQ6 DevNet by by say defcon connect in in November. So I think that's that's great. Cool. So >> yeah. Yeah. So so I I don't I don't basically foresee that uh chaining to really impact uh the PQ signatures

timelines because once we have chaining and once we have uh the signatures library ready. So I basically again see it as a very simple step uh to go to the go from 0 to one. So um in that uh sense I think the major work uh sort of lies in uh in in the ktosis uh in ktosis or whatever is the genesis generator that we are using. Sois also uses another genesis generator. Uh I don't remember the exact name. Uh but I think we will sort of need to modify that as well as we'll see to modify ktosis. So this is something that will anyway get us uh

warmed up uh uh for for doing the dev nets. Uh yeah thanks June. uh in the chat Jun basically gave us the link for the genesis generator. So uh so so we basically need to get warmed up with uh the tool set so that we can uh we can basically I think that DevNet zero can help us get there where we will basically make sure we'll take few of the things in the tool set that are out there and we can start having a good feel about interoping with each other.

Um so that way I think uh the invisible definite would be a good idea. So >> um Mercy see you have your hand up. Yeah, I have a um kind of suggestion about the TSF. Would they be will it make sense if you have like added flight more like a minimal fog choice where we have the longest chain plus asensation tally for testing final latency even if you even if it's simplified we measure how PQ s impact justifications >> yeah so that is the plan when we say

that okay 3SF we'll add later on uh so that is what we are We are basically just doing chaining just doing the minimal proc choice and then the emphasis is on the getting PQ signatures and uh subnet aggregation. Uh but uh I think we should uh maybe uh by dev connect also at 3SF. I think it will be quite easy. We can just talk offline about this with team and uh sort of help them get there.

>> Okay. And then earlier I dropped on the chat uh happy to add some repos to the lean Ethereum one for consensus specs and for spec tests. Um so just let me know if there's any other repos that you need but I'll start with those. [Music] >> Come on. >> Yeah. I I think about like the spec uh repo stuff. Philipe is working also on like a framework on on our side. It's like I had some discussion with him and he he

tried to set up something according to like um Ethereum testing best practices and stuff. So I will also discuss with him uh in order to set up the the report properly. I know that he had something locally at least a couple of days ago. So yeah, I will discuss with him to to set up this. >> Okay, awesome. Thank you. >> Um and maybe I have a a second point that I want to bring up for discussion. Um it's the last one here on the success criteria. um 98% correctness attestation correctness I think proposed by by

Kajinder um so yeah so so my suggestion was based on not having any like force choice or or consensus um but yeah just maybe you want to ask a gender maybe you want to you have any any like elaboration on on this whether what could be for um the the Yes. So once we >> Yeah. Once we have the chain, we can just uh uh go by the correctness of the head. Uh so I guess uh that should be fine. I I think we'll be able to define success criteria when we get to that. So I'm not really worried about it right

now. >> Cool. Yeah. Um then I think I think um those are are my two big discussion topics. J. >> Yes. Do we know if we can have some help from DevOps DevOps team about curtosis or do we need to work on that on our own? >> On our own.

>> Uh I can start a conversation. >> My understanding. >> Go ahead. Go ahead. So as per my understanding Barnabas is uh quite strong in ktosis and uh in writing star clock code and uh I think we will definitely need to them unless we have a star clock expert in this particular group. Uh but uh eventually I think yes we'll have to own and sort of own it and sort of run with it once we have the initial help from Barnabas.

uh most of I think uh most of it would be regarding uh the genesis generator tool that is where I think we will need to sort of dig in and uh uh help them out because they won't be able to generate the genesis straight for us as well as uh uh as well as generating uh the public private key pairs right so so this is so so basically genesis uh generation is the key step over here. But after that, I think uh we can get uh some decent help from uh the Panda Ops guys and u maybe involve them as well from the get- go.

That was great. I think it would facilitate our progress a lot. there other >> so what I will do is the genesis generator >> so so sorry just to add so what I'll do is we'll we'll look at the genesis generator tool and uh basically we'll sort of uh discuss what the gaps are and uh maybe see how we can fulfill them I think that is a starting point uh then we I can in the meantime also talk with Barnabas. Uh I think we'll might also have a conversation and we can talk about how we can do this uh

with KTOS. Great. Um, Benedict, uh, I had dropped a or added a note to the agenda about if you wanted to provide any updates or just overview on the, uh, uh, paper that you dropped a link to the the lean sig for postquantum Ethereum. I don't know if there's any technical updates on that or relevant libraries that you or anyone from the cryptography side want to uh, touch on.

Uh I can just give an overview of what it what it is. Um so we had this first paper hashbased signatures for postquantum Ethereum right and uh then after that we had this follow-up research uh that appeared at crypto with at the top of the hyper cube which was just an improvement of sort of the the trade-off curve between signature size and verification hashing and um yeah so the problem was that this thing was in a very written in a very textbook way so it was not really in the length language that we would use in the in the first uh paper. So it was more like a textbook kind of thing and not like a

practical thing. So now we translated that into the language of the first paper and integrated it into the library. So um yeah it's it's essentially just that. So that that the document is just taking the ideas from the second paper and integrating it into the framework of the first paper um to make sure that everything works there as well. And then yeah we updated the the library uh as well. So now you can sort of use the the new scheme. Um yeah that's basically it for for that document.

Great. Thank you. Um and then Gajender, I dropped a note on the agenda. You had mentioned uh maybe wanting to summarize a discussion that you had with Boxar and Tomagana, the need for SIG to bytes and bytes to SIG interface for the Rust library. >> Interface Rust library. Yeah, I I think these are just small logistic things but uh I guess we need I didn't see the interface for that. Uh from signature to bytes and bytes to signature. >> Yeah. So that just got added just added >> like half an hour ago. uh we implemented or Han actually implemented the the uh serialization stuff for signatures and

secret keys and public keys. So that should now now work. >> Amazing Benedict and Toma. Uh so yeah so that basically solves uh uh solve one one point uh that we raised. The other point we uh I think uh which came up in our discussion with Tamagna and uh Basker was that uh so what what is the format in which we will be generating the keys uh that we will consume uh uh so uh my opinion on that is that you know uh we don't need to uh sort of go all the way to u consume the keys in

the format uh the consensus the beacon uh clients do because it would sort of just add development time to uh the current pipeline. So we can just have something simple where we just need uh to identify uh public private uh key pair and uh again the private key I I assume would be uh quite big. So it would be sort of a file uh to which you know we'll have a reference uh so so once we have that then we can basically then the validator or if for example the will just have the validator running in the beam node

itself so there won't be a separate instance so it will so whatever is the reading instance will just read the keys and then we'll assign it the numbers based upon uh uh based upon the genesis or the latest state right? So you have the latest state and you would have the keys the public keys enrolled over there. And once you read the validator attached to validator uh list uh then you will be able to figure out okay you know what are the validators this particular node has uh that it needs to vote/generate produce blocks on. Uh so uh once so so the second part is basically you know we need a we can just come up uh with some format uh me uh we

zim and reim guys can come up with a format that can work uh and we can basically then uh sort of add that to the genesis generator uh so that you know we also dump the keys out while we are generating the genesis. Great. Um, the last item on the agenda was uh to go over some updates, Camille, that you wanted to discuss about the the simulator work.

And then uh the only other item that I before I forget is I'm in the process of trying to get a a Discord channel uh set up for this effort in the EF R&D discord server. So hopefully we can kind of migrate some of our async conversations over to that when it's set up. And Camille, floor is yours. >> Okay. Thanks. Um yeah, I want to share um results. Um yeah the work is a bit incomplete. So um if you need to access to this document you can DM me I can share with you but I would like to add some more things. Um for example just um I I talked to Emil who is working on

signature aggregation and um few days ago a ago he said me that I expected aggregation rate for snarks is going to be something like around 10 snarks per second and previously I assumed it would be 50 and uh yeah now I have to rerun a lot of tests and this takes a lot of time. So yeah, this is what one thing that I want to do and also considering um yeah our intention that uh um yeah we want to use quick instead of TCP. Uh so yeah we want to also consider how to integrate quick into our simulator because we currently only use TCP and uh yeah quick also can give some improvements. Um uh but other than that I think there are some things that worth

discussing and uh maybe sharing. Um yeah that's a future thing that uh will be relevant will be when we'll be discussing like kind of how to integrate uh aggregation um so yeah uh basically in our work so yeah I already discussed several times about our simulator so yeah we trying to aggregate signatures uh we using two-tier approach where when we first kind of aggregate within subnets and then yeah uh uh subnet aggregations they also being aggregated Um so yeah we tested gossip subtopology and grid topology. Uh yeah we currently tested only gossip sub 1.1 because yeah that's kind of what is

being used uh by clients today for aggregation. Um yeah the idea here is that yeah well basically whenever well first in the beginning of solot uh each validator produces a signature then they have a set of mesh peers with whom they are connected to then they share their signatures to these peers and then these new peers they also continue sharing the signature and so on until everyone gets the signature. Um so yeah we have these testers who produce a signature and subset of these attesters they are also aggregators. Um and then these aggregators whenever they uh collected enough signatures enough uh we defined by parameter snark one threshold. So

basically uh like we put it by default 90%. So when any aggregator collected 90% of signature it starts aggregation. Um aggregation rate is by default we took like parameter thousand signatures per second. Um again uh just information that I took from Emil. Um so yeah and then yeah when we have this um uh aggregation um when any of aggregator from the subnet has an aggregation they kind of gossip their bit field to global aggregators and if global aggregators they need uh the aggregation they actually request this aggregation from the uh subnet uh aggregator um yeah uh

just some details of how it's done. So yeah, we have gossip and also additionally we implemented grid topology. Again I went several times what grid is but basically it allows you to uh reach well to send any message to from any pier to any other pure within two hops. We also don't have a lot of duplicates because this very structured topology. Um but yeah logic is the same here. So basically just set of gp up we use grid um as an alternative. So just to have something for comparison. Um yeah, we use NS3. Uh it's a discrete event simulator. So all tests are reproducible.

just yeah uh let me quickly go through some default params and explain them. So um yeah for the group count like number of subnets that we considered we took eight um simply because it was a bit faster for us to simulate. uh if we kind of increase number of peers higher then yeah it's gets more complicated and actually considering that we have group count of eight uh subnets if we do simple math so Emil said that yeah we need actually we have an aggregation rate for snarks like 10 snarks per second so we already kind of consume 800 milliseconds only for aggregation uh of global snarks actually not necessarily

eight because yeah we kind of need to prove to store plus one signatures it's actually maybe six uh aggregations would be enough but yeah from 600 to 800 millconds will be consumed uh I will have more detailed math like for the theoretical minimum time how much we need for aggregation yeah later um so yeah for group validator count but we took thousand,24 um I think it was just yeah uh mentioned multiple times that yeah that's kind of the number that we are targeting Um also for the number of local aggregators again I emphasize that these local aggregators they are also these validators but yeah they also perform

aggregation. So it's a subset of uh validators that also performing a testing uh at the session. So yeah we have 10% of we put basically parameters 10% of group validators they are local aggregators and for global aggregators we just took number 100. Um but yeah just to make the same number of global aggregators as number of aggregators in some subnet. Um yeah for latencies we took RI 8 to 8 atless database. It's basically the uh information of real world latencies. Uh and then for the max bit rate we consider EIP7870 um and so b so basically we set the

download speed to be 50 megabits per second and that's actually very important point because uh uh after the simulations yeah we realized that it's actually not not enough uh so hopefully when the beam chain goes live yeah we'll have higher requirements for validators I will explain later again why is that uh for signature size we took 3 kilobytes. Um for snark size 128 kilobytes. Snark one threshold is basically how many signatures per subnet we need to collect before we send an aggregation. It's 90%. A snark two threshold is like how many signatures we need to prove before we actually create the final public snark the final snark proving the uh enough signatures. So it's basically two sort plus one of

signatures or 66. Um so basically for if we have eight groups uh and thousand validators in each group um yeah we need to prove like this around five,400 signatures. Um those are aggregation rates I already mentioned um thousand signatures per second per second. Uh PQ signature verification time is 30 microsconds. Um I think I took that from paper. uh uh and for pro verification time I took 2 millconds but maybe it should be different time yeah I don't remember why it is 2 millcond but yeah we use that um yeah that's and here's actually actually

interesting part so yeah we can we can calculate theoretical minimum aggregation time uh considering these default parameters hopefully they're more or less reasonable um yeah just ignoring putting aside some things like latency between peers or the time we consume for signature verification or like uh how many hops we need for any signature to get from any atttor to aggregator. Ignoring this these parts uh for example yeah we need for example to each subnet needs to aggregate uh 90% of its signatures which is 922. Uh if we calculate and how many bytes that means each aggregator has to download it's 2.7 megabytes. Um and with our uh EIP7870

um bandwidth limit which is 50 megabits we can calculate that each aggregator at the very least needs 43 seconds to actually download uh all enough signatures for aggregation and then having thousand signatures per second rate we need another around yeah 900 milliseconds to aggregate all these signatures. So for local aggregator aggregation uh at very least uh we should expect like 1.3 seconds just for local aggregation for a single subnet and then we also have global aggregation. So um yeah to have to prove super majority of signatures we need to aggregate six out of eight subnet aggregations and um uh first we need to

download them again having this bit rate this would take like around 0.1 uh second and then yeah uh another 600 millconds would be consumed for aggregation um and then yeah we can calculate that for global aggregation we consume another 72 uh seconds. So and in total um considering that yeah local aggregations they happening in parallel and then we have global aggregation at the very least u theoretical minimum is that with current default parameters will be like around 2 seconds we consume for u signature segregation and that's important I think because that's only theoretical uh actually because uh if we

have for example in gossip we have a lot of duplicate duplicates. Well, not a lot, but yeah, some of them. I think uh Yanis he did a report last year about number of duplicates in gossip subab. I think it's something like around uh I don't remember between three and seven duplicates for each message. And actually, if we have more duplicates, we need download more data. Um well, not we don't not like we need to download, but we actually downloading a lot of data before we realize that what we downloaded is the message we already had. And that actually increases a lot and the simulation will show like how much um and uh also we should take into account that I I think around 1 second will be spent to actually distribute the block among validators and another

second to send to propagate snark between all validators. So actually I consider personally that two seconds is absolute maximum how much we can spend for signature aggregation for the entire process. Uh so we should kind of I think optimize for that. Um uh yes that's more details about how we about default parameters that just in having them in one place and uh yeah then uh in my report I kind of focusing first on local aggregation and then on global aggregation. Um so first uh yeah we we basically took this uh default parameters that I described and then we just changing one parameter and checking how much uh it actually affects the

aggregation time. This is only for uh this plot they only for local aggregation and um yeah this dashed line is um theoretical minimum uh again just calculated kind of the same way as described before but for uh different signature sizes. And then yeah we have grid topology and yeah uh gossip sub topology this is gossip sub 1.1 so it actually maybe not as efficient for handling duplicates. Uh again we want to introduce 1.2 to kind of check if things will get better. Um but yeah uh here with gossip sub 1.1 we see that having three uh well if we have each signature of size 3 kilobytes yeah the gossip sub

actually takes around 3 seconds to aggregate only local aggregation that's obviously too much um yeah grid is doing around 2 how much? Yeah 2.3 seconds. Um so yeah it's uh it's better but yeah we need to go faster. Um then we have um like uh here we are again setting default parameters and playing with uh bandwidth limit. So actually this is turns out to be very important uh as we see uh like with 50 megabit megabits per second yeah we have uh we spend around for gossip sub again around 3 seconds

for grid about 2.3 the comm minimum 1.3 and if we increase it to 100 megabits so it actually drops for gossip sub from 2.9 to 2.3 uh and for grid it actually goes below 2 seconds which is very nice Um and yeah the the more we increase the bandwidth the closer we are to theoretical minimum. For example here if we have 200 megabits which is like very it's a lot of bandwidth uh then yeah the difference for grid topology uh is just around 300 milliseconds between uh grid aggregation time and theoretical minimum just for our at least in our simulation.

So yeah uh then yeah we were playing with this is only for gossip up it's just changing the number of mesh pers um again actually increasing mesh pers in theory should kind of decrease the uh average distance between any pair of peers but at the same time it introduces a lot of duplicates. So it actually might be not very efficient uh to kind of have huge mer size which is basically fan out factor uh for gossip sub and actually the having eight pers which we have today um well here we had the the best results um so yeah but still it's around 3 seconds so it's it's a lot um and then subnet size um so here we just

checked how how much effect would have If we have for example smaller subnets again having default parameters three kilobytes per signature um and here you actually if we want to go below 2 seconds for grid topology we can afford having around 680 sorry 668 validators and for gossip to be less than two seconds it's actually yeah we actually can go around 500 validators yeah then uh yeah there is a parameter like how many validators sorry how many aggregators we having per subnet. Uh we played with that as well and actually um

yeah we see that having just 10% of aggregators is good enough. So if we go above then the picture is not changing much. So um yeah uh just having uh 10% because I think it's very likely that one of aggregators would be close to any other pier. So they yeah we can perform aggregation uh relatively fast. Um so yeah that was for local aggregation. Um for global as I said we I didn't really I I didn't have a lot of time for doing a lot of tests as yeah just some parameters changed recently and I need to rerun a lot of them but basically the picture we have if we put everything together and we perform in addition to

uh so we have like eight uh subnets each of them in parallel perform an aggregation and then whenever any aggregator from the local subnet has an uh final aggregate sorry local aggregate then it submit basically gossip the it bit fields with the snark and then yeah global aggregator they fetching the uh this local aggregation and then if they collect enough local aggregations to prove super majority signatures they produce a snark here um basically the blue dotted line is the so yeah above we have on top we have uh gossip up and below we have grid topology so here it's basically the time the blue dotted is

the time uh when the sum of very first global aggregator actually produced the snark um the final snark. So uh again with default parameters that I described previously. So is for gossip it took around 2.7 uh seconds and for grid is around um uh 1 point ah yes sorry I didn't have a lot of time so yeah I had to reduce number of validators. I forgot to mention that um it is for here we have like 500 validators per group otherwise tests they would took a bit more time. So yeah uh in final version of this report yeah

it will be with thousand relators to group uh but anyway yeah here we see a picture um um yeah uh what we see actually for example for gossip topology this red line is the moment of time like when some uh how many uh basically how many first snarks we call them snark ones these local snarks how many local snarks uh we kind of have at the moment. So how many signatures they proof already? It's only the moment basically this when you have an incre an increase this a step in this red line means that some subnet actually performed an aggregation but didn't yet

uh this this aggregation not hasn't yet arrived to global uh aggregator. Um so yeah here we actually see that uh for the gossip sub uh the this range of times of when the aggregation actually happened it's a bit wide so it happens between like 1.3 and 1 six seconds of time and for grid it's more this line kind of more straight that because uh yeah uh for for grid it's more predictable and more this time is more consistent because yeah For gossip up, we have this kind of random graph. Uh and for grid, it's very structured topology and we have um two

hops. Uh so the aggregation um happens a bit faster. Uh so yeah, here um so yeah, this is why this line kind of looks like that for grid and like this for gossip. And then at the moment when um some uh this green line is basically the higher the highest amount of local snarks that some global uh validators uh have at the moment. Um so when someone some global aggregator collected more than super majority which is super majority is this green dash line. So when they have more than super majority the snarks that prove super majority of signatures.

Yeah. uh then uh uh they start aggregating the snarks. So this takes another time and then yeah when this final snark happens yeah this blue line happen. So yeah here hopefully this gives some picture like uh what we can expect from aggregation and how much time this would take. Um yeah for some conclusions I think um I think yeah we should try our target should be like to have to perform an aggregation within less than two seconds and there are some changes that we should do I think to our kind of expected default parameters that we kind of have at the moment. Um for example, yeah uh we should definitely go

above 50 megabits per second uh requirement. Um so yeah otherwise it's just not feasible to even theoretically to go beyond below than 2 seconds. Um yeah we also observed that grid topology is usually behaves much faster than gossip. So that's another uh way of how we can kind of speed up our aggregation. Uh so if we can realize that gossip up is no way. Um the main actually obstacle that could be using that could prevent us from using grid could theoretically be that well some peers they kind of theory they behind net and they are not reachable but yeah we have this beautiful report by probab which actually suggests that

um yeah most of peers most of the peers they are actually reachable already in Ethereum like 90% of them. So that means uh uh yeah we can put them into grid and um yeah maybe take advantage of more structured topology if we need. Um again this work kind of is not super complete. Yeah I want to add gossip sub 1.2 to check like if we decrease the number of duplicates uh then yeah maybe gossip sub would behave faster hopefully. Then yeah we're adding quick support. Luckily NS3 has quick extension so yeah we will include that. Uh another thing actually to consider yeah um in in our tests we we kind of performed an aggregation by

just well each aggregator each local aggregator kind of expects to uh collect 90% of subnet signatures and only then it performs an aggregation uh and this is not the optimal strategy because uh well uh we could maybe parallelize that. So um instead of uh um uh again again this requires some some some research like how to do this but in theory if we instead of all aggregators they're just waiting 90% of signatures we can split these aggregators for example into four groups then uh each of them like has waits for 250 signatures then they aggregate them then uh in parallel so it's like in theoretically 250 millconds to aggregate uh almost thousand

signatures but we need to aggregate now these four snarks and this takes another 400 millconds. So we actually go from uh 900 millconds to around 600 milliseconds for the aggregation. Uh but maybe there are some yeah I don't know more optimal ways how to do this. Uh but yeah this kind of requires research. Hopefully by the time when it is needed for us to kind of include aggregation yeah we kind of have we we will perform already simulations and uh yeah we will know how what is the best algorithm how to do this. Uh that's another area we're exploring now. Um yeah that's kind of all ahead. So hopefully just give some picture and expectations for the um aggregation.

Sorry I didn't read the uh comments. Yeah. Oh, I had a question in the chat uh or suggestion to bump up to 50 bits per second uh only needed for 10% local global aggregators. Correct. Uh to bump up to uh 10% I kind of consider this to be for I I I had this requirement. Yeah, we took we put a limit of 50 megabits for all uh participants. Uh so um yeah not only aggregators but only who only behaving as a testers. Um yeah so um but yeah for it's a good point because uh actually a

good question is whether we need to um uh distribute uh the local snarks among local testers. If not then um uh I think we can optimize that uh somehow. So basically peers instead of just sending uh instead of everyone instead of putting everyone into a single for example grid uh we can only have grid among a tester sorry among aggregators and the testers they send signatures directly to them. Um that way we actually don't need to put a lot of uh bandwidth requirements otherwise actually uh the testers they also contribute currently by uh broadcasting all signatures that they observe. So

that's a lot of traffic they create and u yeah we put yeah in theory I think for just a testers yeah requirement should be less than uh requirement for aggregators but currently yeah we just have one requirement for everyone >> and with I don't want messages what what do you think how how much percentage the traffic would come down just your guess work >> I don't know uh honestly we have uh we just had today our very first implementation of I don't want and the results got worse uh may I don't know uh so I need to verify and double check uh

uh maybe because messages they are too large we kind of uh I don't know it's I don't know I need to check um >> yeah And uh this 1 second uh latency that you are taking that should already be multihop right? >> Uh 1 second latency what is that? Uh >> what is that? >> So you in the latency calculation where you added 1 + 1.65 65 something uh in the document >> and you mentioned that with multihop that it will grow worse but I but shouldn't this already be a multi hop latency >> because as such peer-to-peer latency

should not should be just 70 millisecond between any two peers anywhere in the world >> yeah you mean when I calculated the theoretical minimum uh or what when >> um >> yeah in the document I think uh you had mentioned there and uh I was referring to that point. >> Maybe I'll read the document uh I'll get get a document link from you and we'll take this offline I guess. >> Yeah. Yeah. Sure. >> Yeah. Yeah. >> Cool. Um yeah, that's all I had. I'll I'll try to drop it maybe early next week. Uh but yeah, um if someone wants to read it now, yeah, just feel free to

DM me. I will share the link. Great. Thanks so much. Um, yeah, feel free to let me know if anyone has agenda items that they want me to add right away. Um, otherwise, I'll just kind of collect it as we go and >> maybe I'll try to get some Panda Ops people to attend the next call and so we can ask some questions and get them looped in. >> Yeah. Can I have a quick question just uh yeah we we kind of went all went through through this document in the beginning of the meeting. I noticed that we actually never mentioned how we're going to performing pure discovery there because currently CL clients they can

rely on execution clients and for our test net we don't have execution clients. So um yeah if you need any I don't know ideas suggestions how to do that you can also uh think of that because we don't have >> sorry >> but do we >> what do but do we rely execution clients for for peer discovery >> I think so >> you say I didn't get your point >> uh I thought yeah uh can we have discovery with my protocol which is implemented uh execution clients and the consensus clients they just basically consume that. Um and here we don't have execution client. So how we discover?

>> So so consensus current consensus clients have their own discovery running which is totally independent from the discovery of the execution clients. Uh so basically disk 5 is a discovery mechanism that they use and there is >> some bin and uh then basically you reach out you try to make sure that uh you have some particular peers in a particular bin. Uh so so uh so basically consensus have their own uh discovery mechanism running and you start off start off start them off with uh some uh uh boot uh boot peers to start off with and then basically you know the discovery gets built on. Uh so as such uh yeah consensus clients don't depend

upon uh execution clients for discovery but even then we will not be doing discovery in this particular devet because we know all the where all the peers are and we'll basically you know uh in the genesis generator itself we'll basically generate uh the peer file as well. So with that regard, we again want to minimize all these extra bits that are out there in a normal consensus client so that we don't spend time on something that is already well figured out and it's already working well and something that we are not going to iterate upon. Uh so we will just go with for example as uh uh Partha mentioned that we'll just have whitlisted peers

that will be distributed uh to all the nodes and they will just connect on it. Mhm. Okay. Cool. Yeah. I mean, as long as everyone aware about like every other peers, then yeah, I think this should work. Um, cool. Yeah. So, everyone could still be aware about each other peers and still do some sort of a topology. So, basically not have a start apology. Uh, that I think gossip sub will anyway take care of. Uh so yeah as you mentioned that uh if basically the information is there uh PA should be able to form a good network.

>> Okay. Thanks. >> Thanks Paul. >> Bye. >> Thank you for the call. You >> will. Byebye. >> Thank you guys. Byebye.