Post-Quantum Interop Call #8

Transcript

that was posted yesterday in the uh in the GitHub. Uh we're going to start off Sorry, I just lost track of it real quick. Thank you. Okay, I got too many tabs open. All right. Um so we had a internal commitment to ship the specs for Devnet zero on the 31st, which was Monday.

Just curious if maybe Oh, or Gajender, if one of you could kick us off by giving us an update on on the status of that. >> Uh I guess I can. Yeah, I got I got it. Um so for VM, I think um so we are we're just waiting for the specs for the transition functions um that Gajender just mentioned in the in the Telegram group. So we have to review those um and then get them get them merged into the repo. And then uh trigger that into our our code base.

Um so that's I think that's like the the main uh remaining part. Then there are like some other small features that we are developing, but it's not really um it's not really a blocker for Devnet zero. Uh for example, like we are we are building like a persistent So basically DB on top of our client. Um generating like the secp keys, stuff like that. Um so I guess like for for us to in order to get Devnet zero ready, sorry, get the specs the remaining specs merged as soon as possible. And hopefully like we could trigger those down into our code base in you know um let's say like three to five days from from when it's merged.

Uh but on the other hand, the other update I can give is in terms of REEM itself, regardless of the specs, we were able to run the 3SF under a a local foreign node environment for a few hundred slots. So, that seems seems fine. So, it's only a matter of like refactoring our code to align with the the the specs that's being being submitted. >> Great.

Uh Guillaume or someone from the Zym team, are one of you able to provide an update? >> Um Yeah, I actually Can you guys hear me? >> Yep. >> Okay. Uh I don't know where the agenda is. Yeah, I don't have the full picture, but I can definitely provide some of part of an update. So, we we merged the the matrix thing. Uh the last like yesterday, I think. Uh yeah, I've been busy integrating some PRs, so we're we're getting ready. Um regarding the

What's that called? The test net, so itself like the Cartesi configuration and the and the config from Sorry, not the config, the genesis genesis generator. I am waiting to hear back from from PK. Uh so, I hope I'm going to to hear from him soon, but I think we're more or less good to go. We just have to um to do the Yeah, to to give it a give it a try. So, we're building the images. All we need to do is to have the Curtis configuration to check everything works.

If something is fails, we're going to start debugging. So, yeah. Okay, ideally, that will be done in a couple hours. We'll see, but uh but it shouldn't be too complicated given the simplicity of the of the Genesis. Um regarding the graph, sorry, the Grafana stuff, I haven't done that yet, but I'm going There was on in my plan to do it today. I was a bit held back by some debugging, but yeah, I will I will do it today. And we can also make some progress on that.

There's probably a ton of other things, but I doesn't come to mind just now, so yeah, that's that's it for the update so far. >> Sorry, I was muted. Got you. >> Yeah, hello everyone. Question to Guillaume, do you mean any specific metrics by this PR? Or maybe just in general >> No, it's not related to No, no, it's just about the ability to export metrics. So, we're we're not specific specifying any metrics yet. It's really just the ability to post them somewhere so that they can be loaded into Grafana

so that we can do some basic debugging during the the post quantum test net launch. So, nothing Yeah, nothing as advanced or as organized as what you're doing. It's just a capability. >> Yes, thank you. Got it. And that's great anyway. >> Meno, you had in the chat I think also something related to metrics. Maybe I don't know if there's anything you want to say, but you were also thinking for a moment that you needed to have specific metrics in mind?

>> Yeah, so it's it's basically what Guillaume said. Um, both I think like both we even seem are able to export the metrics now. It's just a matter of like defining where exactly do we want to measure and make sure like we are we are measuring like the the exact right same moment. So we we have metrics that are usable across clients. >> Okay. Great. >> I think that yeah, so I think that that would be best after we merge the remaining specs for the fork choice. Um, because I guess like most of the measurements that we want to do or for devnet zero at least is probably somewhere around those like those like consensus and fork choice.

>> And having kurtosis would be great as well. >> Uh, can you elaborate a bit having kurtosis metrics? >> I mean, no, just running the clients uh, on kurtosis. If I got it correct, it's not possible now, right? >> Uh, I think Guillaume is working on that, right? >> So, um, I'm not sure I understand the question. Like, yes, it's possible to get metrics on kurtosis. They have containers to to collect them.

Um, but >> I mean, just in general running on kurtosis, uh, is it possible already? >> Yes. Uh, sorry. To run the devnet on kurtosis, no, it's not possible. Uh, that was what I tried to convey during my update. Uh, this is something that I need to work on with PK, but I'm going to do it this week and see how far we get. >> Okay, great. Thank you. >> Um, do I understand correctly that but eventually for like to complete devnet zero, we'll still need to run that on kurtosis?

>> Most likely, yes. I mean, if we're going to get any support from uh, the ETH 2.0 ops this is their favorite tool. Okay, maybe favorite is a strong word, but this is the tool they inherited. So they've been maintaining it and all their infrastructure is done from from this tool. I've I personally hate it, but that's because it's very good for running an environment that is quite stable. When you are doing debugging it's it's really really difficult, but I have some updates to it that I hope I can get them to merge. So yeah, it's not going to be used it's not going to be available for this devnet unfortunately, but yes so as a result

expect that we will be running Curtois' configurations and I mean we ETH 2.0 ops presumably will be running those Curtois' configurations and we we just provide them with docker images and this is what Curtois' does. It downloads the images, runs the clients, initialize the genesis um the genesis block and all the genesis configuration for everybody and then supposedly that avoids the situation where you know everybody runs their node in their little corner and someone forgot one switch and another one.

So it's supposed to save time and according to them it saves a lot of time when you're deploying testnets and things like this. So like I said probably all my horrible, but when it comes to actually running a testnet it's a very good tool. >> Great. Um So I guess before we move on was there anything that I don't know from either the Remus team side or the Prysm team regarding updates to the spec for devnet 1. I know that that was sort of like the fast follow both things were being done in parallel.

>> Yeah, I've joined in. So yeah, I would like to add that uh I think specs for devnet zero are mostly there. Uh so me or and June we had a conversation uh following up on uh the fork choice as well and uh yeah, so it was I mean a lot a whole lot of it was simple translation from what Vitalik has done in his 3SF mini uh P2P and sticker uh code and uh uh so what we just need to clean it up and I think uh we are good to go on that.

And we we should be able to translate it uh to our clients easily as well. >> Excellent. Good to see you gadgeter. so I know that tomorrow we were going to try to do a walk-through of whatever we can with the uh multi-sig spec uh before we jump to that uh Mercy I saw your comment that you wanted to talk through this PR that I'm dropping in the chat right now uh regarding the hash sig.

Could you maybe key that up and uh let people know what you're looking for feedback on? >> Yeah, um so there's a concern of merging it to the hash sig or using it as a separate tool. So that is what I need to know. Are we going to use this cuz on the last call we again I did mention that we still need it on the hash uh sig repo. So I don't know if Benedict is here if he he would be the one to show more light on how this is going to go down. >> I think that right now Benedict is is on holiday.

I think he will come back soon and once he he come back I will discuss that with with him to check. I have the problem in mind and yeah, I definitely need to check with him if we will include that into the repo or not. Great. And tomorrow while we've got you is there anything that you could do to kind of help help us walk through and learn a bit more about this multi-sig spec?

>> Yeah. Yeah, I can do that. Maybe Guillaume you you had a question before like you raised your hand so >> Yeah, I I have a hopefully quick question. So that tool that Nurse is working on, do we need it for the testnet because my understanding is that it's going to be run run Robin so we don't really need any validators so yeah. My understanding is that we don't need it for this testnet and we can take our time like there's no rush. Is this the correct assessment? >> Yes, we don't need it for devnet zero but even in devnet one the proposals will be run Robin just that now the validators will sign it. In devnet zero there is no signing of proposal or votes.

So that's that. >> Exactly. >> So yeah, let me go through through the code base. I will share my screen. So that we can all see together. So can you see my screen? >> Yep, perfect. >> Perfect. So, what I I did so basically my work was about like migrating the the spec to Python file.

So, basically if we open like the the spec repo, here we have some docs from the clients where we have markdown file. This is what was presented last week by Gajinder. and and other files that will be merged, but this was this was the goal there. So, my my work is in the source folder. Here we have the lean spec folder and inside we have some sub spec. So, we have different folders then that contains each of them different different type of sub specs.

Uh also we have a type folder that contains very basic types such as I will just show you one for example just you you in 64. Maybe at some point we will like just import an existing type of another Ethereum library, but this is not a problem. This is just a very minor change. So, for now we just defined a very simple type. And so you have other types for that. So, for example like the output of of a hash function or any small types defined in this uh folder. So, we can add any type we want there as we go.

Uh this is just like uh a separate folder. Um the only constraint there maybe just after I I will move to to the main spec is just to have like very typed structure so that we don't have any possible confusion. Uh always puts some types in in the in the in the stuff we define. In the sub spec, I have different folders. So, I have a chain folder where I define some very basic devnet config constants.

So, just all of the constants are there. For example, just to cite one, the slot duration and anything. So, you have all of the config Then, I have a folder contains containing all of the containers. So, for example, we have a block file in there and we have specific class for specific objects. For example, a block body or a block header or simply a block. And so, we can just reuse these basic objects all around the code. For at the moment, they are very simple because we base everything on the simplest possible things. This is always linked to the some docs that we have in the

markdown files. So, this is always very simple, very lean, containing only the minimal info that we want and we can update these classes as we go. So, we have one file per point. For example, we have a one block file, one checkpoint file, one config file, and one state file to contain everything that we need. So, that is about the container. If we speak about then we have also the networking. So, again, some constants, some gossip sub stuff, and some messaging stuff. So, at the moment, these are just all the

basic defines. We can update, remove, modify anything that we want, but this contains, let's say, basic config for the networking layer. That is all about the generic stuff, but now if we talk about like the cryptographic layer, let us say. We have first defined like the koala bear, that is our prime field. So, for those who are not aware of a prime field is This this is a prime that will dictates how we operate over our finite field.

So, this is a prime number, this one. And we define the This name is name is koala bear. And then we define the finite field operation over this prime field. So, just basic operation like addition subtraction, points negation, multiplication pow, so that we can use any element of this class with just a plus to define the addition. This All all of this function overrides the different operators, so that this is very easy to use.

Just to show you there also we have a test folder at the root of the repo where we have also test for all of the subspecs. So, if we take for example the koala bear subspec right here, we have test for the the field. And if we open this test about the field, we have very basic test. For example, we just test addition, we test subtraction, we test point negation, we test multiplication, all of these with very basic numbers.

So, that for example, we check that a multiplication is equal to an expected values and anything. So, very basic tests just to check that everything is okay. after defining all of these basics finally we just have the finite field defined. And what is very nice in there is that if at some point we want to change the prime field, we just have to change the prime there and the two or three constants that are there, but the rest of the class remains the same because this will always be the same.

Of course, like the implementation there are not defined in optimist optimized way. This is just defined like to satisfy the needs that we need in the simplest possible way, but this is not optimized so that if we if you look at Plonky 3 version, this will be obviously completely different and a much longer implementation. Then if we go to the Poseidon, there you have the Poseidon implementation that is more complex than Koala bear, so we will not look into the very easy details of this one, but basically this contains some constants that are there generated by search script from

the from from the paper. And it also contains the main file that is the permutation file. And so basically the functions that we expose to the user is just this one, the permutation. This is what the functions this is the functions that the user will use when using Poseidon. Inside this function, we have a call to all the other function of the file to generate this permutation, but the user will only interfere with the permit function, nothing else. A user shouldn't call any other function of this file.

And so inside this permutation, we just call the round constants, do in fact we have we can decouple that into a different steps that we have a first step there that is a an initial layer of the of the hash. Then some full round, then some partial round, and finally some other full round. So, this is basically the decoupling of the of the function, and there you have each time some utilities. If you want to go deeper into the function, I tried to put EV comment on each line so that the user is aware of what we are doing each time

and can follow the steps line by line. But, roughly, the step is processed by layer, and so you have an initial layer, another layer, another one, and a final one. This is the step of the function, and at the end you just return the final state, and your permutation is done. And this is what the user will want to call. And so, the same if you look at the testing file there, I just put a test on the permutation. So, how I generated this test, I just took random inputs and I computed the expected outputs using Plonky3 library, which is already

audited and performing already in production. And so, I just compare my Python implementation with the Plonky3 implementation to be sure that I obtain exactly the same result. The same for the two widths of the permutation, 16 and 24. That is my Poseidon implementation. And finally, let us say the most complicated one, so I will not go into the detail there also, but the XMSS nature.

So, basically, it mimics exactly the Rust implementation. So, you shouldn't find anything new because these are the same tests, the same functions, the same implementations, the same interface as the rest implementation. And just as as a note, we don't want any client teams to develop this primitive themselves because we we just provide them the code and we just want them to to use the code. So, this is not needed for you to re-implement that for security reasons because we think that this is quite complex to have every single detail perfect.

And we prefer for now client relying on like common future audited library. I will just present you this file that is the interface file. And in this interface file, you have like the main interface the user will use. So, in the either of the file there, I put like the specification high-level function which are key gen, sign, and verify. These are the three functions the users should use to generate the key, to sign a new message, and to verify a signature.

And so, this the three functions are provided inside this XMSS class. So, you basically initialize the class with a couple of parameters that comes from the other file. Then you generate your key. You generate your key through different steps. As you can see, you have an activation epoch because no matter what your lifetime is, you can generate a smaller activation time. And so, you can choose to have for example, a big lifetime but a smaller activation time. This is what these arguments are about.

And you just basically generate your key. So, you go through the procedure generating some random parameters, generating some some Merkle tree to build your XMSS, your XMSS stuff. This is like the theory of XMSS and I will not go into the details like to avoid over-overloading my talk, but at the end the goal is to generate this. These are the public key and the secret key. This is the final output of the key generation.

So in the public key you have for example the roots of the Merkle tree and some parameters and in the secret key you have a bunch of parameters. So you have the tree, you have some PRF key, you have some parameters, you have your activation epoch and the number of active epochs that you chose. Now that you have this, you are able to sign a new message. So as you can see the secret key should be one of the parameters as well as the epoch as well of the message that you want to sign. So through the sign function you can sign any new message. Again, this goes through a procedure.

Be careful there. I put a warning that should be also in the Rust implementation from Benedict. A secret key for a given epoch must never be used to to sign two different messages. And again we go through another procedure that you can study, but at the end the important stuff is that you generate a signature. This signature contain the pass that will then be used to to verify your signature, some hashes and a randomness root.

And finally the final function, the most important one to verify to to spec because the verify function is the one that we will use into the the aggregation of signature. So, via this function you can verify the message. So, via the public key, via the epoch, via the message, and the signature that was generated there, you can just verify the message. And so >> If you could pause real quick, Gajendra had a question. Gajendra, is this specific to this a section that was just covered or >> Yes. So, basically when you mentioned about the API of key generation, which is basically there is active activation

epoch and there is uh um uh there is lifetime and then there is how many epochs it it is to be active, right? So, in this activation epoch for us would be zero. Yep. Correct. >> Or max active epochs is a lifetime, I mean. >> The Here, the activation epoch is the starting epoch for which the key will be valid. And the num active epoch is the number of consecutive epochs the key will be used for. So, I think that in the constant we define for the devnets, there is a lifetime of 2 to the power 32.

And you can define a smaller activation range for the key generation to be faster. >> Yeah, that's the clarification I wanted. Um and so then so you have the sign and you have finally the verify. And so the verify function is able to verify the signature of any message and at the end it just output a boolean. and it will just verify the pass and check that the roots that it obtained by rehashing everything is just the expected root. If I just show you

this verify path function there, it is in the Merkle tree file. At the very end, what is important is just It means after iterating through the entire path of the Merkle tree, the final computed node should be the root of the tree. And if it is the case, it just output true. uh the verification succeed. So, that is basically the interface and then you have a bunch of file uh to do some different stuff. We can of course simplify these files. Some of these files are just here to make some randomness, so we can just simplify them or anything, but

the important stuff to to remind is the interface. Another important stuff about about the constant is that here I have the constant file where I define some constant parameters about uh the signature scheme. And we can instantiate a new signature scheme by modifying this file. For the Devnet 0, we agreed on this parameter based on the benchmark done by Benedict on easy implementation. This seems to be the best one we have for now.

But, the problem is that if you try to use that into the the Python spec, this will be way too slow because the activation time is long. The Python implementation is not optimized and Python is not optimized, so this will be really slow. The key generation will take couple of minutes or hours. This is not good. So, I just created another test configuration where the parameters are not intending for production use case, but are really, really small.

And so, we can just conjunct our test and run our test suite in a reasonable amount of time. Yeah. And so, this is finally it. At the moment, this is just the specs that I have, but we will iterate with time, and I think that my next step will be to implement the state transition function and everything around 3SF, basically. So, yeah. That is basically it. And also, I will may I will probably do a more extensive presentation of this during the lean consensus call on Friday.

>> Yeah. Just to echo what Camel said in the chat, can we also sort of in the constraint put what exactly is the signature size in bytes? As well as what exactly will be the root of Merkle tree in bytes if it's not 32 bytes and is different because we are using a different hasher. >> I think that this can be configured into into the the constant. This is something that we can change, but I am not exactly sure because this is a constant that we have from the beginning inside the Rust implementation. So, I am not exactly

sure about the consequences if we modify this constant. >> No, not asking to modify the constant the constant, but for example, you know, if we have that okay, signature size equal to these many bytes, so we I mean, it's basically for the reference very clear to the eye that okay, you know, this is what we need to create the type for. And similarly, what is the public key size in bytes? >> Ah, yeah, yeah, yeah. Yeah, exactly. Yeah, yeah, yeah. Yeah, so yeah, the the public key and all of these parameters are constrained by the constants that we chose in the Yeah.

>> Yeah, I mean, can we just put the final calculation out there so that, you know, we don't have to derive it in our own way. That is >> Yeah, we can put So, you mean having the the signature size calculated directly into the the Python spec as a function of the parameters we have, right? >> No, no, even for just say const signature size is equal to this and const public key size is equal to this. >> Yeah, yeah, yeah. Yeah, yeah. Okay. >> Maybe just have a comment there with signature size, etc.

>> Yeah, yeah, I I think yeah, I just saw your comments. I think it's what's Oh, just mentioned is 3,000 bytes for the production config. For the constants that we chose in the product in the production config. The test config is not relevant at all because this is just to run some tests. So, this is not relevant at all. But, for the production config that we chose for the devnet, this is the size, yeah. >> Uh Thomas, fantastic presentation. Really great stuff.

Earlier there was a a question from Giacomo in the chat. I don't know if you saw those. Do we perform domain separation in the XMSS signatures? Is this part of the spec? >> Yep, this is part of the spec and we perform domain separation. I can link you to the specific part of the spec about this, yeah. >> Yeah, I will send you the link afterwards, but yeah, we do some domain separation.

any other questions on >> Knowing also that I I have heard by This is an another topic, but I I have heard by Hamish and Justin that the encoding that we have right now at the top of the hypercube that was the last work of Benedict and Dimitri was maybe not not the most optimal one for recursive aggregation in the minimal ZKVM, so maybe this will change in the future, but this is just a parenthesis.

Don't know if you you or Justin want to add something about that, but for the moment in the spec I just put the hypercube stuff because this is the latest config that we had and the latest say the most performed one, but this may change in the future. >> Yeah, so just to provide a little bit of context, there's two parts to the the Wintermute's verifier. There's the the verification of the of the chains, and this is just like very simple hashing, and that determines how much hashing is involved, and also how big your signatures are.

And then there's this other thing which is called the encoding, which basically takes the message that you're trying to sign and encodes it into a point on those on those chains, what we call a point in the hypercube. what we've done so far in the papers is that we've assumed that the encoding is free, and we only looked to optimize the signature size and amount of hashing. But actually, you know, in practice, the encoding is not free and it needs to be snarkified. And right now, as it's defined, it's not snark-friendly.

And so, one of the things that we're looking to do in the workshop in Cambridge in October is try and co-design a an encoding which is maximally friendly to the the ZK VM that we're developing. So, on the one hand, we have Emil, who's has this new ISA, which we call Lean ISA, which which has eight four opcodes and four precompiles. And on the other hand, we have Benedict and and and Dmitry and and Mihail that are you know, experts in encodings. And if we get all of these people in the same room, then hopefully we can we can have a good outcome.

I guess that was the last item on the agenda. We I don't know, Gajinder uh oh Yoham, June, I see you. Some activity on the project board. Is there anything that we wanted to go through on the project board with open tasks, anything any blockers uh at this particular time? Uh Ladislas. >> Yeah, so before we get before we get there, I have a quick clarifying question for Toma or I guess for the group. Um uh and Gajinder hinted at this already. Um I'm just curious, do we do we have a I guess benchmarks or a bit of an uh intuition like how activation time,

like shortened activation time for the key generation, um sort of relates to the to the lifetime. I think we we were as as my understanding is that we only need this indefinite one, but so like how I guess a concrete question would be like how do we have to set or should we think about activation time with a constant lifetime of the key? >> I think that may maybe I I have seen like Dimitri in this course, so maybe he will better answer than than me, but this question but my my point there is that at the end like the key generation

algorithm could be long. For example, if we assume like 2 to the power 32 lifetime running the key generation could take 1 to 2 hours, I think, using the Rust for that, if we want to use that, we will use that in devnet zero and devnet one. We can just say that we will use this lifetime, but we want our validators to have like a much restricted activation time.

So that we can just put in into the input of the function smaller activation time so that it will reduce drastically the key generation and we don't need 2 to the power 32 at least for devnet. And I think that this is also currently under investigation if we will we will have this also needed for the final mainnet because maybe we will give the opportunity to new validators to enter uh without having to do like the full key generation if they want to opt in for a smaller activation time, for

example. This is the point of having that, I think. >> Well, what is definitely possible is to have this lifetime sort of dynamic so that the validator may start with a shorter time like show smaller tree like 2 to the 20 or something, but then the tree can grow. Well, the public key may change, but at least for the beginning we don't have spend that much time to activate it. We can start with 2 to the 20 and then by increasing the the tree size we can go up to 2 to the 32 incrementally. We just have to update the public key on the fly.

>> So, that would be some sort of an epoch processing where you will say that okay, you know, and every epoch I will enroll the new update for the key. But, I mean maybe we could move to that sort of a scenario, but in that sense basically if the clients will have to continually generate the key for the next epoch as >> So, there are complications if we allow for key rotation. For example, slashing becomes significantly more complicated because you might need to slash someone on a already rotated key.

Um So, I think the the the suggestion that I prefer is to have a very long maximum lifetime of 2 to the 32 and you know, that has a minimal impact on the signature size. And if you want to generate fewer keys then you just generate fewer keys. And then everything stays fixed size across all of the devnets and and also across mainnet. And you don't have to any key rotation logic which doesn't complicate the slashing.

>> And apart from this just in what do we think that for different uh kind of signatures we will enroll different keys into the validator or uh what what kind of scheme do we think for example for attestation and proposal? >> So my my thinking is that there's basically uh one uh pub key per validator and it's fixed for the lifetime of the validator. and are you asking about the the the complications with the the proposing and the attesting? I mean there's various solutions here. Like one is

in in the slot where you're proposer you just don't attest and your proposal is of includes the the attestation uh implicitly. And then another way to do it is to to basically split the um the keys into two groups, the proposer keys and the attester keys. And then the the main trade-off here is that you basically uh have to have to spend uh twice the time to do the the key gen. But yeah, the the first proposal seemed to to work fine.

>> Uh just one quick question follow question. So what uh do you mean that uh proposer can include the vote uh implicitly in the block when he when he propose? So uh I just want to uh be more clarified about your first suggestion. >> Right. So, we have a a container for the motion of a vote which has the source and the target and whatever other things. And that object can literally be part of of of the the block that's that's being proposed.

and so the the main kind of thing that's a little bit exceptional is that this particular vote is not going to get aggregated with all of the other votes because the message that's being signed is is different. Uh but uh otherwise it it it it's just mixed in with uh with the with with the other votes kind of as part of the state transition function. >> Right. But uh if for example, I mean, this might just work for proposer and attestation coupling, but it might not work for other key types where we might have to then enroll them into the

validator, I guess. >> Sorry, it wouldn't work for what? >> So, for for example, for signing slashing messages or uh So, I mean, if for example, some node wants to submit some slashing or I think in that they are signing rate. >> So, in a in a slashing message mind signing is that you you have previously signed attestations from other validators. Like you as the entity you know, putting slashable messages on chain, you just have to sign

your your block that contains the slashable messages. I mean, right now we do have uh randao which uses signatures, but there's a way to do randao with just commit reveal that doesn't doesn't rely on signatures. >> Yeah, basically >> And the other >> whistleblowers are thinking that a whistleblower might be signing so that they will get the rewards, but right now we don't have whistleblower rewards uh I think.

So the the the the problem with whistleblower what is if it's an entity other than the proposer receiving the reward is that the proposer can just steal the reward uh for themselves. Uh they can just look inside the what's being whistleblown and and just copy-paste and and sign it. if I recall correctly on the beacon chain today maybe I'm wrong, but the there is no signature for for whistleblowing. You you just provide on chain the slashable messages. And then there there is indeed a reward for the current proposer, but it's not a reward for someone else and and here again like the the proposer

signature will will handle that. I mean one thing we have today is the um the sync committee, but um that will go away. So I as far as I can tell the only two places where we need to do signatures are proposals and attestations. And for proposals we just uh handle it as a special case where you don't attest directly, you just attest indirectly for through your proposals.

Camille, did you want to share your screen and do a quick update on the PQ aggregation simulation work you've been doing? >> Uh yeah, sure. I can do it really quick. I already once left uh the support button needs being all time ago and since then actually uh yeah, we performed a lot of a lot of more simulations. Um basically we were not really satisfied with some results like uh well, we noticed that we just if we use our standard assumptions like EIP-78 70 uh restrictions like 50 megabits per second per node and have we use standard gossip sub, we basically can aggregate in around 3.9 seconds, which is not

acceptable considering 13 4-second blocks 4-second slots. So, ideally it would be maybe having something around 2 seconds so that we have some time for block propagation and global slot propagation what is aggregated. so yeah, we conducted more experiments. Uh so yeah, repeat apologies. Uh oh yeah, maybe I'll add that yeah, we also for the last time we also added tests for the well, what what we call aggregators only grid. Uh this is basically a grid topology, but the grid only uh is among the aggregating nodes, whereas non-aggregating nodes we have any signatory basically the signers they uh

send their signatures directly to uh uh grid aggregators. Uh so uh that way uh we actually we basically don't need to expose the well, the requirement for uh all attestors to basically expose their public addresses because uh well for whoever participates in grid will basically need to know their IP address and this is breaks some of system privacy assumptions. I have a small section about privacy discussions here after some discussions with Raul and others from the P2P group. So, yeah. There are still some privacy concerns. For example, the aggregators they might actually learn

the IP address of validators who sign the message. We basically don't want to avoid this, but there are ways to avoid this. I provided some ideas, but we but yeah, it requires some additional investigations. Basically, yeah, also starts Since last time we also tested GossipSub 1.2, basically GossipSub with I don't want messages. Really briefly, yeah, I can say that GossipSub 1.2 really doesn't give a lot of improvements because basically what it does is once some peer receives some signature and wants to advertise that people already

has the signature and sends the I I I don't want message. So, basically everyone else is not sending this signature again. But usually the the other duplicate signatures they are already kind of in the wire. So, the message was already sent. So, basically duplicates already received. So, yeah. We also tested this topology as I said with the uh aggregators only grid, uh which is on graphic as a label this uh uh grid signature count direct.

Or that means basically, well, each signer sends to four random aggregators. Uh it actually provided some worse results compared to classic grid, but that's because we kind of have one more one additional hop. but overall, yes, still better than gossip sub. yeah, there is other also like plots for number of duplicates for different topologies, if anyone's interested. And uh yeah, then for global aggregation, so for uh standard gossip topology, we basically yeah, in this simulation 100 megabits per second speed for nodes using standard aggregation rate of 10

snarks per second. This is the rate that I asked Emil who kind of what is the expected rate you might expect you might get. And using 1,000 signatures per second aggregation rate for signatures, uh yeah, we basically got these results. So, basically, yeah, we need approximately 4 seconds to aggregate a lot. And as for 8,000 validators split into eight subnets, so each subnet has 1,024 validators and one of them, 10%, are behaving like aggregators.

And if we use grid, results a bit better, 3.2 seconds, but still that's a lot, I think. Uh and then we started kind of exploring what we actually can do, what we can expect to uh reach our target basically to 2 seconds. Uh first thing I think which we can test is uh aggregation only topology which also gives uh well, just share how this topology behaves. And here we obtain for grid 3.4 seconds. Uh a bit worse, as I said, because of additional hop.

Uh but yeah, yeah, some other things that we yeah, we kind of expect is that well, according to Nielsen's law, we might expect that the yeah, bandwidth limit grows kind of 50% per year. And if current requirement is megabits per second uh according to EAP 7870, we might expect like in 4 years uh we maybe can put through bandwidth limit of 200 megabits. And if we do this, uh yeah, results got better, so we with grid topology we go below 3 seconds.

And then if we actually increase our compute power from 10 snarks per second to 20 snarks per second, that's kind of optimistic assumption. Uh but if we can do this, then yeah, basically with grid topology uh aggregation could happen with in within 2.3 seconds. yeah. That's uh that's kind of the results of our simulation. Uh some other things that we actually wanted to check that but we just weren't capable is kind of we here we used TCP, uh but instead we could use Quic. Uh we actually integrated Quic into our simulation, uh but the simulation time kind of increased exponentially. Uh yeah, we

basically need to optimize a bit how Quic works. Maybe instead of doing uh this uh actual encryption, we can just replace it with some uh artificial sleep uh and do some other stuff. Maybe we Yeah, if we spend more time on this, yeah, we can test how uh Quic would improve situation. I So, uh it definitely would we will improve, but I don't expect it would be like a drastic improve. Also, we kind of tested a lot of different ideas that actually didn't provide much improvements like uh distributing signatures. Well, first hop kind of happens to uh uh uh with large fanout to many neighbors, and next hops happens well, uh like using

standard gossip sub. Uh just too few neighbor neighbors that didn't help much. It Yeah, it actually created a lot of duplicates. yeah, there are also some optimizations that we applied like uh for global aggregators it doesn't make sense for example to propagate SNARK from each group more than once. So, if we for example already observed some SNARK from group one and then we receive another SNARK uh assuming it kind of proves the same number of signature it doesn't make sense to propagate the second SNARK again uh the second SNARK again. So, Uh another optimization we can we can do is kind of for example early announcement so we kind of send bit field not uh when some aggregator created a SNARK but

actually when it started the aggregation process. Uh and that way uh global aggregator kind of can send their I want message and once the SNARK is ready yeah, local aggregator already knows who to send their SNARK. So, yeah. Ideas like that yeah, we also checked in this report and uh yeah, maybe there are other ideas yeah, if you uh if if you want us to check them yeah, we're happy to implement them in our simulator and check uh if they provide any improvements but yeah, that's the yeah, that's kind of the final set of this report. And yeah, I'll share this to everyone.

feel free to uh you know, comment or uh DM me if you have any questions. >> Excellent, thanks Kamil. Um curious, have you shared that with some of the other network people that are going to be in Cambridge with uh Yiannis and Raul? >> Uh yes, Raul went through this uh I don't remember if Yiannis was in the groups where I sent and discussed that. Probably he was there. But yeah, anyway I I maybe I'll send to the team Raul but send to both of them.

>> Very cool. Yeah, I'll be interested to see what type of performance we are hitting at the conclusion of of that workshop versus now. Um, great. Were there any uh, I guess final items, anyone blocked on anything on the project board or related work? All right. No news is good news.

Uh, that I give it for for this week. Uh, I'll hope to see all of you on Friday as noted in the chat earlier and by Toma, uh, we've got lean consensus call number seven. We're going to be doing an even deeper dive into uh, the multi-sig spec and I know that we're going to hear from Philip and Emil and Justin. I might talk a little. Toma, it's been a good time.

All right. >> Thanks, Will. >> Bye, guys. Thank you. >> Mhm.