PQ P2P Aggregation

Transcript

Okay, nice. Um, yeah, let's get started. My name is Camille. Uh, today I'm going to discuss about the P2P aspect of postquantum signature aggregation. U, we are developing our client called clean. So um yeah we really uh I'll try to give like some general picture including like signature aggregation 3SF PP uh so yeah um just quick reminder what we have today is like uh we have very relatively small signatures which we aggregate that we switching to signatures of size 3 kilobytes and then we're also reducing our slot time from 12 seconds to 4 seconds

and Uh yeah, just based on that we can uh come up with the task. What we're going to do is collect and aggregate signatures from 8,000 validators in under 4 seconds. 8,000 is just some number to get started. Maybe in future yet it will be larger. Um and in fact we actually don't have even 4 seconds to perform aggregation except even less because we have other stuff to do during the slot. And uh the first approach that yeah we kind of get started with is just doing something similar with what we do with with BLS aggregation today is lead the network into the subnet. So uh validator belongs to some subnet and then among these validators we have some portion of that also perform aggregation and then they create local aggregation

which we call snark one and then we have another subnet which performs global aggregation where we actually create the final spark that goes uh to the block and um based on that we can actually even calculate uh given our existing requirement for the network. Uh how long it going to take to uh actually aggregate. Uh yeah, we have some numbers like uh our target is to have performance of thousand signatures per second aggregation uh and also 10 snarks per second for then recursive aggregation of these snarks. We have bandwidth from AAP EAP7870 of 50 megabits per second. So we can actually calculate that well for uh

local aggregators to download enough signatures to perform local ation it would take maybe 43 seconds. Uh and then once they downloaded these signatures uh they then they spend some time for aggregation. Uh given this rate it's like 0.9 seconds. And then uh global aggregators they need to download the local aggregations. Well enough of this local aggregation so that they can prove the majority of all signatures that's another 12 seconds and then perform final aggregation of the snarks uh with 10 snark to second aggregation rate it's another 6 seconds. Uh so so we can see that um this is kind of the minimum theoretical time like ignoring things

like latencies between the nodes like how many hopes we actually need to uh perform to distribute the signatures. Obviously we need much more than that. That's just some uh unreachable target but it's yeah it's it kind of gives us some u some some understanding of how long it's going to take for us to aggregate. Uh yeah uh and yeah we see obviously that the two main bottlenecks we have is validator bandwidth and the snark creation speed. Uh and yeah we need to improve on that. Um so to actually simulate uh this kind of networks we created our tool which is called beam

scene. Uh yeah we have a report about our work. Uh it goes very deep like into different topologies that we tested and into different assumptions like signature sizes validator uh number of validators in the network number of aggregators uh and checking like how how this different parameters they actually affect the aggregation speed. So you can go and check if you're interested. Um in this work we actually compare two main topologies is gossip is the most widespread topology that we use today uh for uh signature distribution for block distribution in Ethereum. The second topology that is not actually used in Ethereum today but yeah we just wanted to consider it. It's a grid topology.

It's a more structured topology uh compared to gossip because in gossip we basically create uh these random connection well this uh this mesh connections with some random peers. So the uh the structure is really random whereas in grid uh the structure is most it's more structured. uh we basically put our um uh participants into dimensional matrix and they send all their messages to all of their column neighbors the and row neighbors and then all column neighbors send their message to all of the all their row neighbors.

Um and this way we can actually send uh any signature any message uh to any between any pair of peers in at most two hopes. uh and uh the and at most we can have one duplicate per message. U there are some disadvantages and drawbacks for this topology as well. So we compared this topology. So in our simulations we observed for example for gossip sub aggregators they received 1.5 duplicates per signature on average and before they perform aggregation whereas for grid they receive actually less than one duplicate. So uh just uh in 50% of cases they basically receive just one duplicate and in most cases there were no duplicates. U

yeah there are some differences in diffusion mechanism between gossip sub and grid topology. So in gossip sub it is enough for validator just to sneak in and send just a single message to some neighbor uh and then this message will be redistributed throughout the the network in grid for the happy path. uh so which I mentioned which is just two hopes um yeah uh we need at very least to send the message to all of the row neighbors and all of the column neighbors so it's a bit more messages so there are some different assumptions uh that we make here and also for gossip sub the structure is really well the structure is random and uh to to add validators into gossip subtopics they

don't even need to expose their addresses whereas for grid topology to come up with this two dimensional structure and to be aware of the addresses of of all the row column neighbors. Yeah, we need to be aware of their addresses of the peers and we we need to be able to punish them somehow maybe reduce the reputation or do something in case they did not actually follow the rules of the grid topology. So uh yeah uh and that creates some risks because well we validators or participant of grid they actually expose their addresses uh and that's something that we don't have today for gossip.

Um yeah then uh uh just looking into the future uh and trying to uh see what actually what and how we can actually improve uh uh in aggregation. So assuming that uh well we have niten law saying that yeah every year kind of the bandwidth limit increases 50% maybe assuming like in four years uh instead of having bandwidth limit of 50 megabits per second it could be 200 megabits per second and that means yeah now aggregators can download their signatures and snarks four times faster and now at theoretical minimum time drops from 2 seconds to 1.6 seconds.

Uh another thing is but yeah that that's kind of yeah great we can increase the bandwidth we maybe can assume that in four years uh bandwidth will be higher band uh limits uh but it's not only that because uh in our simulations what we did we actually checked how well gossip sub and g topology actually utilize this bandwidth and what we observed for example gossip sub topologist this is uh green and the red lines. Uh once we for example switch from 100 megabits per second limits to 200 megabits per second there is not really much improvement for go whereas for grid topology uh if we go further increasing uh the bandwidth we

actually still gaining some improvements here. For example, here once once we switch from 200 megabits per second to 200 megabits per second, grid topologies they were able to aggregate like uh half second faster which is significant. U so yeah we should be well yeah we can can rely on increasing bandwidth but we also can need to choose proper topology that actually takes advantage of that. Uh yeah another thing it's uh probably arguable and uh but yeah if we can u assume that if we have really really great P2P layer and uh uh for example we're making assumption that at least one aggregator in the network or at

least one one aggregator in the subnet actually runs GPU instead of CPU so their aggregation time actually 10 times faster um yeah we can actually take advantage of that as well and yeah also make calculations so in future if you for example can make 10,000 signatures per second aggregation and also increase bandwidth limits then actually this time drops to 83 seconds uh which is really nice but that's again another assumption maybe worth discussing like whether we can actually uh consider that in network someone can run GPU >> if we use a GPU we could also use them to aggregate and so the 0.6 would go down to 0.06 06 >> uh well I mean yeah previously it was a thousand signatures per second so it

took 0.9 second now it's point >> yeah but we will also get a speed for the snark aggregation >> ah okay that would be really great yeah I did know that which is why here [clears throat] I'm learning yeah then if we can improve this this also can drop significantly uh yeah maybe all of that all of that I said yeah what is great developing a client is now we kind of we see the full picture. Uh so it was really uh helpful for us to learn about CSF and actually one thing uh that we also need to take into consideration is actually uh how consensus works. Um we're not really sure 100% that we're going to use 3SF uh hold for consensus eventually but for

now we're sticking with it and we're testing it. So uh yeah let's consider what's happening in 3SF. In 3SF we really split our slot into four intervals and the first interval first second um is just spent for proposed stage. So someone creates a block and distributed to all all validators and then uh we have voting stage. Uh this is where this these stations actually uh being produced and this spread to the network. And the next stage is fast confirm. And uh for this stage uh every validator should be able to observe at least super majority of all signatures. And this is the problem because um

yeah if you if we see this structure where we actually split our network into the subnets uh well validators they do not really absorb signatures from other subnets. And uh this is something that we actually need to take into account when we design the P2P layer which we didn't which we was not doing actually during BMC simulation but now I think yeah we should uh do this. Yeah. Uh but yeah this uh and and then yeah at the end of the slot we should have the aggregation which will actually be included uh into the block. What? Well, the thing here that uh the important

thing is that validators should observe all the signatures. They not necessarily should have already the aggregation but they at least need to see super majority of all the signatures to to be able to fast confirm as I understand and then have uh well this fast confirm will be used in the next slot to have bolt target. Um okay uh this actually leads to some more questions. Maybe maybe we can then even not to have if this structure with subnet doesn't work maybe we can get rid of the [clears throat] subnets right uh that's just again throwing some ideas but yeah uh in that case for example let's say again we have the case with 8,000 validators now validators need to

download uh super majority of all signatures u uh they can do this with this 200 megabits per second bandwidth limit in 62 seconds uh theoretically minimum time uh in fact it's a bit larger and after they do this they already able to fast confirm this is the next stage of consensus uh and then yeah they can spend the the remaining time of the slot to actually to aggregate the signatures u yeah and here to do this without subnet we need to have really really fast signatures aggregation like 10,000 signatures per second uh for example which we can have but for that to work

yeah we need to have GPUs obviously and that's again like yeah the assumption that we should make uh if we cannot make this assumption uh yeah there are some other alternatives like we can uh have very large uh single subnet for all validators but in for them when they spread their signatures they do not only send them to their neighbors but they also explicitly well they they know the address of at least one aggregator uh for the subnet Well, subnet is only formed for the aggregators. So, uh uh validators they uh send signatures between each other uh for the for this fast confirm that we need and then they also send to at least one aggregator uh

which then uh performs this two-step uh aggregation step. Uh well, they can use grid topology for that. uh uh the aggregators for example then uh they can really see all the signatures really fast. Uh if we do this then uh basically we have two steps in parallel like first is gossip up where validators send their signatures to each other uh that's like 62 seconds to be for them to be able to fast confirm and then yeah we spend another time uh well like 83 seconds uh to actually create the final aggregation that goes uh into the block.

Yeah, that's just some thoughts, ideas, numbers that we had, yeah, during simulations and tests and calculations. Uh, overall as I see it like the path of segregation first two points they kind of no-brainers like we need to increase validator bandwidth. Hopefully we can do this. Um, then accelerate accelerate signature and snark processing speeds. That's ongoing research which everyone is doing here. And then uh my third point is like my personal opinion is that is that we should somehow integrate the structured topologies into the aggregation pipelines. Uh something like not necessarily grid.

There are a bunch of other topologies but yes the topologies where we can actually uh take advantage of structure and probably rely on some random connections which we actually do today for gossip. has its advantages but also uh given our very uh well our requirements for 4 secondond slots and this large number of signatures which very heavy uh yes then yeah we should do this I think uh yeah that's all I had [applause] >> thank you for that um just two questions um perhaps missing from questions u first what is the current topology style of the beacon tree.

>> Yeah, we use gossip sub. So basically we have uh I think 128 I think I will speak more about this later today but yeah 128 or so uh subnets all of them use gossip sub and they kind of perform this two layer aggregation as I said but they use BLS >> basically we we have uh the difference is that uh we we don't make an assumption that they should have very heavy machines to be able to aggregate in this case uh yeah we aggregators we cannot just randomly select some valator to be an aggregator.

I think they should somehow explicitly say that they want to become an aggregator because they need to have uh well some other requirements than just some common validator. So yeah uh there are some differences. Um so for the structured topologies did we consider using the uh braided chain web which uh is based on the best known solutions to the degree diameter problem and would that maybe be useful? >> Uh we can consider this I mean we can integrate this into our simulator if you yeah you can maybe elaborate more about this later. Yeah.

Um in the past there was uh some research around AP sub and also uh improving gossip sub to diminish bandwidth requirement via choke and choke algorithm. Um have you simulated this as well? We were not simulating this but honestly all the improvements that I see for the question they give some improvements. Yeah like maybe 10 15% but we need much more. Uh for example, we tested in our simulator, I don't want messages uh like to reduce number of duplicates and it didn't really help because once we send like I don't want the message that someone sent to you, it's already on the wire so you receive it anyway. Uh yeah, I don't know. We can explore this but

personally I do not expect much improvement but yeah. >> Okay, thank you so much. [applause] Okay. So now we're going to split into uh at least two groups. We're going to have one group uh stay here to discuss the proximity prize. Uh that's a very fairy oriented group. And then we're going to have another group in the board room which I believe is straight and right. I guess follow ladders. Um and here we're going to have a discussion about death specs. Um and if there is a topic that you really want to discuss as a small group um do advertise it to the

telegram and then others can join you and there's this space in various places. >> Okay.