 I'm cool author of one paper on signature aggregation and I'm going to give you some other reasons why I'm not. So, some context first. Okay, so we know that DLS signatures, it's a scheme for cupid signature aggregation and it's something that is quite used in the term too because of the specific property which is it can be aggregated. It means that you have two signatures, you aggregate them, you've got a single signature. You have one thousand signatures, you aggregate them, you've got a single signature. Okay, aggregation. Because of the drawback, the verification is quite slow. It's a few milliseconds, so that's a thousand times slower than many specifications. So, we've got this in the term too and by simplifying a little, the way it's used in the term too, you've got validators, they sign attestations, you've got thousands of validators, they sign thousands of attestations. But when you're going to check those attestations when you're receiving the block, you won't have to check all the signatures. You won't have to, you won't get actually all the signatures because the block order with someone will aggregate them and what you will have in the block is an aggregated signature and not a rule block. So, it means that it's much smaller and even if one verification is slow, you're saving thousands of validations, so you're quite good. More details on what it means when you aggregate. An aggregation is most commutative and associative, which it means that you can do that in any order. Okay, that's very good for parallelization. You can have one set of signatures aggregated by someone, another set aggregated by someone else and then take this, you aggregate the resulting stuff and you're done. You're done except this small part, which means you have to set the same signatures. When you aggregate, you will have something bad which is basically twice the signature, which is a little bit complicated to verify. So, if we simplify, when you aggregate the signatures, you don't want to aggregate twice the same signature. Okay, if I simplify. And it stays so. The fact that you can aggregate them means that there are aggregation protocols and all. Just use one of them and I will be done. And there are, I'm not saying thousands, but dozens of aggregation protocols. But one of them is Byzantine tournament and fast. Some of them are Byzantine tournaments. Some of them are fast. But none of them is fast. So, if I ask what Honda is about, you can guess that it's aggregating the signatures being fast. And we say fast, it's thousands of signatures aggregated in seconds. Byzantine tournament, so you're going to aggregate between thousands of nodes and some of its nodes. We'll try to put the protocol down by the minute. Okay, definition of Byzantine. Whatever they want. And in your life, which we have, of course, nodes that are just dead and not responding. And we want something to be versatile. I mean by this, that in a network, you will have thousands of nodes with different capacities. Some of them are very fast, some of them are very slow. And with different network capacities, some of them will be very well interconnected. There will be some wraps, of course, that will be connected. Wires and nodes will be somewhere in the middle of nowhere. So, we'll be back at the same stage, you want to aggregate before business. What does it mean for Heterom? A possible plan to use Heterom in Heterom could be visual. If we look at the specification a week ago, what we added is basically in a chart, we target to have a committee size of around one on one. But we can have up to 4,000 nodes. So, the idea here is, okay, if you can aggregate quickly, you don't really care about the size of the committee. In this one, it will be basically around one second of the time. As well, in Heterom, you've got this become-shared committee. So, here, everybody is trying to aggregate for the become-shared. But at this point, what you want to have is still safety. A possible way to do things is let's select a subset of a node from the committees, 16, and let's ask them to do aggregation for the become-shared. And you will have at this point an aggregation between 16,000 nodes. And you want this to be fast because the plan is if we can be very fast around one or two seconds from this whole aggregation to above, it means that in two blocks, you've got your priority. So, that's what we want to do. And we said that it doesn't exist to them. We don't have such protocols, so how do we do that? So, when you have such a problem, basically, you're looking at complexity, you're looking at time complexity and message complexity. And you will be more or less on this side if you can, and you're going to be on this side of this part. Okay? And we will see that some protocols, as BLS signatures are quite easy to aggregate, it's very easy to mobilize. So, time complexity is easy to get. Our message complexity is much more difficult to have, and it can become totally crazy very quickly. So, the first thing to look at is just a simple gossiping solution. By simple gossiping, okay, you just... the fluid-basic gossiping stuff, you're just sending your signature to everybody. Everybody does that. And I'm someone I can get. Okay? And it's not that bad, actually. So, it's very simple. And it's not absolutely bad. You will have this time complexity in block N, basically, because it's a peer-to-peer network, and you explain that some definition. So, the time complexity is good and cheery. And the message complexity, if all the nodes in the network want to send one signature pitch, if all the signatures between the V and square, minimum, depending on... with the floating protocol, complexity will be in two, but with a constant, a little bit large, and then you get some optimization of some kind. And add currents went this way, for example, and they aggregate with 2,000 nodes. It's a fixed size, much less than what we do. And they're around 12 seconds, which is another magnitude slower than what we do. And they're probably at that point, but they take eight pairs, which is not a lot, especially if there are some bad nodes in this. And they clearly say, okay, guys, that is a future work. And we try this. So, okay, we've got these issues, too many messages and so on. So, what we try in the beginning is, can we continue on a worshipping network, but can we kind of compressing things like if we can aggregate. So, as a peer, if we receive a signature, if we can aggregate, we will. And instead of sending power signature, we'll send something aggregated. Good enough. It implies that you verify at this point because if someone sends you a bad signature and you aggregate without verification, then your own signature will be bad. And that's like that. So, when you start to do this, you have to verify what you're doing, the aggregation that you receive. And you really want not to overlap because if you're sending something that is aggregated and someone else has aggregated and if there's another app, you're dead, you can't agree. Okay, so you need to solve this. So, what we did at this point is, okay, actually we know all the signers. There's no list in this committee. So, we can give them an ID just by using the public key that we know. We just solve this and the position in the URL will be the ID. So, we know that we've got now a set of nodes with no poles. That's perfect. So, here, in this example, that's eight nodes. ID 0, 1, and so on. And we're kind of organizing the aggregation by saying, okay, but not 0, we aggregate the signature from node 1. And that's it. So, if you receive the signature from node 1, you can aggregate. If not, well, send it. Send for 2 and 3, 4 and 5, and so on. And you can go back to the next level. If you have aggregated 0 and 1 and now you receive 2 and 3, you can aggregate it. So, what's your strategy? It's nice. It's nice, but the problem is, the more it goes, the less difficult, the less possibilities to aggregate. Basically, what you will receive is something difficult to aggregate. So, you start to tune things and, okay, I will wait a little bit longer and so on. So, you can do things, but to feel quickly that it's not going to cry so you need to do something better. And at this part, we introduce a set of techniques. So, actually, there's someone who worked on this in the non-Byzantine context 10 years ago. And it has exactly the same logic of, okay, you've got this, you know all the nodes, you know all the ideas, and you think, instead of kind of hoping that you will get the signature from one at a part, you're just organizing things, and zero is going to send its signatures to one because it knows that one will aggregate it. Okay, so that's the kind of first one, first level. And at this level, zero sends its signatures to one, one to zero, two to three, three to two, four to one, okay? And then we can aggregate. So, it's aggregated. And it means that at the next level, when zero and one we exchange the aggregates in each other with two and three, the aggregation will always succeed. Because, so three and there's no overlap by definition. And then you go to the next level and so on and so on. So basically you've got locked in levels which is good for time complexity. If one node is down, it's okay, this level by aggregation is zero and they will aggregate with two and three. And that's it. See, and if you cut more nodes down, it's the same thing. Nothing will happen at the first two levels and it will happen later on. But still, a little bit of issue when I say it's like how do I know what node is down? Do I have to wait forever? And actually I can't know what node is down by definition of the distributed system. I can see that I don't receive anything or that it does not reply, but I don't know what to do. And it's worse because it's a violent context. It can pretend to be there but not really be there. It can send out a signature, a third of a signature, whatever. Okay? So, the way we do that, first we push the information. We're not querying someone to send us something. We just say, here is our signature aggregated and second, everything happens in parallel. So we're not waiting for an answer from node one or we're not waiting for a signature from node one to start the other level. So zero at the beginning is going to communicate with node one but as well with another two and three. Of course, at this point, it doesn't have a signature from one and in this case it will never have it but it's okay, it starts. So, zero will say, okay, you can aggregate my signature so at this point, maybe two will have zero through three. And if we look at the other it will be the same thing that we started with the three and then we'll have updates potentially that will give them the full data. So we can represent it like this, communication all over the place in parallel whatever level. So it's organized but to communicate with everybody without waiting. Which is obviously an issue if you have thousands of nodes because what I'm saying is let's communicate with everybody right. But if I don't want to kill the network I have to organize things a little and the way it works we basically have a dissemination period which is 20 milliseconds and every 20 milliseconds we contact a new set of nodes and we progress in the level. Then we contact the new node. Answer, answer. And that's it. So at the point it will reach the threshold we just don't know when but we continue every 20 milliseconds to contact another set of nodes. So does that has a assumption that all LB nodes has other nodes over here? Yes, there are good points. Yes, you know the difference between a pure seedling and this one is this one will know where is the node. I will have a lot of slides at the end of the fact that you know where is the node. So you know it's hyperbolic. So you know all the nodes? So in a term you know the list of the members of the committee. But in the productivity it actually has a limitation of the nodes, right? So the way it could work is at the beginning when you're a member of the committee you say, oh actually as an aggregator you speak at least of us and then you're not doing gossiping connection you're doing a direct TCP connection where we need to be but it's a UDP message or a quick message I will have a lot of slides on this but you understood correctly basically you're doing if I simplify you're sending a UDP message the node knows the UDP address of this one and this one, this one UDP addresses are known and 0 is sending a message directly to this node I will have more details on that so if we do that basically we will have a login capacity each step you're sending to login messages and I will have some slides so actually the part is how do you know that you're not going to contact all the nodes that it's going to finish that and that so that's the test that I represent and as well as the proof that it actually works and that you need to send a login message to which which version just for some stuff and from a mathematical point of view it's based on concentration and inequality to be sure that you won't have a set of nodes that won't reach it the question is are we sure that we won't have a subset of nodes that won't and if you're very lucky you're still part of it and everything is one of the best just to say that it's not that complicated and the last level the last thing that I'm going to present is ranking and rendering so the point is we said we want things we want to support very different kind of nodes so some nodes can be very slow and we said that the BLS signature verification was very expensive and we said as well that when you aggregate you need to check that it's correct if not you're just going to create a message so because of this some nodes won't be able to catch up to the number of verifications that they receive and they may check signatures that are not very interesting while you've got some aggregate signatures that are much more complete because they receive it late so because of this you just have a scoring mechanism improving the signature that I have already so we've got a score when you have a score in the Byzantine context you can have Byzantine nodes that you can verify it and actually this signature it's invalid so you will have wasted 5 milliseconds of your verification time which can be a lot so the idea is to have a ranking of the nodes and we talk almost us to say at this point we should be contacted by those nodes and we've got a window that seems more or less logic so we look into this logic into this window and we take the best start inside this window and if it seems that people are nice here we increase the window size and if we see that some signatures are filling we say oh someone is likely trying to compare with us and that's basically the main mechanism so under this fact that we're contacting the nodes directly we've got a three based organization so we we are sure that we don't have any overlaps in our aggregation we do verify our signatures and ranking plus score now if we text this we don't have any sponsorship for Amazon so we run it on 10 different regions in Amazon so some of them you can see that it's quite fast you don't have to go from Frankfurt to Dublin like it's 12 milliseconds but if you want to go from Frankfurt to Sindel it's 282 milliseconds and so we do this we used the small nodes from Amazon so it's one core and one gigabytes of memory and we put we wanted 2,000 of them and we put two nodes on each two under nodes on each Amazon node so obviously when you do that they're fighting for our resources because we have a single core for sure but when verifying our signatures one is verifying and the other one is waiting for the nodes so we consider that it's a more critical context than the real one but it has an advantage of being much cheaper because I'm using 2,000 of big Amazon nodes and on this we compare with we just send the signature to everybody and we add basically what was expected is a lot of data and a lot of time because you start to lose messages and so compare to Undone which reaches for 4,000 nodes because a full signature 99% actually in a little bit less than 1 second same for this one in terms of data we can see that we have 50 kilobacks of data exchanged forever but that's fair and we tried on Amazon if some nodes are not responding and so we compare the time to reach the agreement depending on how many nodes you have available so if you try to reach 50% to 1% pressure why all the nodes are there it's obviously quite less around 600,000 milliseconds and it's getting a little bit slower it's missing some nodes because basically at this point you have all the nodes and you're around 0,8 seconds so we tried on simulations more complicated things like attacks so for example this one is the case of we've got Byzantine nodes sending you a signature while you're trying to do a project with a signature with 90% of the nodes being Byzantine so 5,000 it's a gap in scale so it's still around 10 seconds in this context which is reasonable of course in this context you just want to make sure it's 100% pressure so that's in the paper now the point that you are mentioning the fact that it's a direct connection that's an interesting point and let's try with a few of the IPRSS so if you have a gossiping network you do have IPRSS and then actually you can get an access to them but it's a little bit easier you can pretend that you don't have a network and other nodes that you actually participate in it's a lie but it's quite easy to find who is actually on the gossiping network but it's a little bit hidden while here it's not even at all it's in style so a lot of points on this and for example DOS there's a key point which adds a little bit of complexity but the fact that you're pushing the information and you don't do queries so you don't have to answer like a TCP query or something, you're just pushing things which means that if we manage to have a single packet that goes out we're happy so we think that because of this an attack is still possible clearly but it requires some hard work big question, anonymity we know the contributors we know their IP address and we know their wallet so we can do the link IP address wallet, that's that it's pretty bad but don't forget that even on the gossiping network you can actually guess who is who because validators will move from one committee to another so you just have to follow which IP address are in which committee look at what are the wallet speakers who are supposed to be participating after one hour or two you'll be quite sure that you'll have to one-to-one management it's a real issue but it's not purely specific and we can actually we pushed the proposal a few weeks ago to remove this link by adding a set in the middle and this set allows us to say ok we're known as a validator but you can't know which validator we are so it's basically on the CTP playing with a member of the set but I know one of the public of the private keys but I won't tell you who I am but I can't do this twice so that's it for gossiping it's nearly independent and then you've got the issues of this IP address stuff and I don't think that's the enemy rival but it's how to hide your IP address the solution is an underlying protocol like Tor the problem in this is ok it's going to be more expensive because Tor is adding and your protocol is adding loops in the middle so we can't really try it because if we try to do this we will wipe Tor but we try it in the simulator to look at what it means if some nodes, 20% of the nodes are behind our next volatility there is we're still a gap mic and we're still raising the risk with 20% of nodes behind that's a simulation conclusion the idea really is if you can aggregate very quickly you can get finality very quickly in our opinion it's something with three different components and I would say well defined there's one component in charge of invalidation there's one component in charge of having this cryptographic anonymity that we don't follow your public key and there's a network anonymity which is a unit of the system that doesn't exist there or not exactly but could be done and it's anywhere in any network system what these issues are we don't talk about what we use for invalidation is available and what we use for the simulation and time is up make a question so in the ptc chronicles did you mention at all on which part of the beacon does it fit so actually it's funny because like it's a Artemis client is going to implement it and the way it's going to be implemented is by using it on the separate smart process the things to aggregate you will have one under process per by default the idea is to have something decentralized so the fact that it can work with very small computers decentralization you will be able to have one big node that do a pre-aggregation of 1,000 signature for you so that's the main thing that's a tie-up even if you know that people will use it so I have a few questions what is the the push that you want to convert it do you need to assume that the idea is around it same thing do you need to assume that the idea is around it no good question the ideas are much better but we shuffle them you need to assume that you need to shuffle them exactly we need to shuffle them you have a protocol for that good point as well yes we rely on a shared source of randomness to do this which I haven't decided because it's not new and I already have this in the future work that we don't depend too much on randomness but we haven't had this part yet because even if you can if you don't have randomness it means that you can choose your position in the tree for example you can say oh I don't like this guy there so all the Byzantines will go next to him and we refuse to participate in your location we can tour or whatever however we do that it means that they are not in another part of the network versus dependency under analysis under randomness I'm not sure that in real life we depend so much on randomness okay so the second question which is kind of a matter of protocol but we'll look back at the time what depends against broke easy use of UVS application so we don't we consider it as a part of our application that we have to like we do in the terrain we have to do a proof of position you've seen the proof yeah it's not clear that all of this can be the thing but all of that is just a bit there will be a proof of position on the main chain alright that's all I have to say