PQ Testnet Roundtable: PQ Testnet Discussion

Transcript

[Applause] question maybe. Yep. Yeah. Maybe. Okay. Uh yeah, we just had a discussion uh with other guys like if we have 128 kilobytes uh of aggregation, I suppose it should go on chain and we suppose we have like 4 seconds slots. Uh this would produce a lot of how much per month 80 g almost 80 gigabytes of data per day for one month it will represent 80 GB of just for signatures

just for signature aggregation storage. Yeah. Is that a problem or is how we going to handle that from I don't know it might actually make life harder for light clients or um unless we have some smart proving scheme maybe I don't know just just to complete and today on the bit chain there is something called the week subjectivity which is I guess three months something like that and any node has to store all the chain for those three months and so in this case if we keep three months It will be um sorry 240 GB just for signature application storage. I don't know if we can shorter

this period for the big chain or not. I think that yeah so like why do we keep the the history right? because if if you've disconnected for let's say two months, you want to be able to sync up and kind of replay the the the chain. Uh but um once you've snified the whole chain, you can just sync to the tip just by downloading the proof that the tip is valid and then you don't have to to redownload the the history. So history maybe is something that can largely disappear, right? every time we have a new block that's produced, it can just be

in case of um yes. So um the the the snot that will prove validity of the of the tip of the chain will will still be valid regardless of of whether or not we finalize it. That's a big change. Yeah, it's yeah huge. In a good way. Good way. I did and so as equivalent of I don't know how it would be called or not so you won't have to keep any history at all or for this purpose I'm talking not for

archival purpose of course we have to keep but to be a good honest defender you won't have to keep any historical data. Yeah, it's a good question. Um, I mean, one of the the memes out there is that you can be a validator on a Raspberry Pi Pico and there isn't that much space to store uh uh history there. Um, I mean, one one of the things that needs to be done in addition to not find the chain is doing data data sampling on it.

Um maybe like we're going to need like some fraction of the nodes that store uh the the responses to the to the to the queries. Uh and maybe we can make a similar assumption uh it's a good question. Maybe we can make a similar assumption as um for the aggregators and the provers where 10% we assume 10% of the validators have the resources to to store that and because it's on this minority then it kind of it works off. maybe like as a compliment. Um right now I think that a paper a new paper from Benedict and Dimitry has reduced the signature size again from compared to

what is presented at there. It was not presented this morning but I think that this will not solve your problem from a stock perspective. I don't think that we can reduce the proof size that much. It is already ultra aggressive situation with like the classical situation in all the ZKVM is to use a wrapper at the end using G 16 or something like that to grab the the final stock proof into a much smaller proof because the G 16 is very small but we don't want that because this will not be postquantum secure. So yeah 100 kilobytes is already aggressive.

Yeah, one one note on that is we use an error type proof system right now and our proofs are only like 256 kilobytes and we have a method for getting them down to 128. So it still could be an option. Yeah. Yeah. But it's just like the word versus air like it still makes an option. Yeah. Yeah. Yeah. I just learned that this morning when you Yeah. And also also I think that Emil mentioned that this morning but we have strong very strong constraints about like the conjecture that we can use and all of this because for example that I know that in PL3 they are using the

conjecture of the start paper and we cannot use that because we are not sure about the validity of this conjecture and stuff. So we have all sorts of constraint to be really strict. We don't want to do that. No, no, no. Yeah, I know. I know. Actually, this is a question maybe for for Jacob. Um, the film foundation is considering doing the following. Uh, we would basically formalize the the semantics of these conjectures in in in lean. Um, and then we'd have a bounty for anyone who can either prove the correctness or give a counter example.

Is that something that um you think ZKVMs would want to, you know, maybe contribute to the bounty prize or help with coordination. Uhhuh. Yeah. 100%. 100%. Right. I think uh generally like we'd like to participate as much as possible but like in this case for sure. Yeah. This would we would participate um I think in the coordination uh first and like we can figure out.

Yeah. To quote to quote Jeremy while he's not here, it's like he won't sleep. was formally verified. So, we're we're on the hunt and trying to do everything we can. I mean, in this case, the formal verification is a little bit of a of a gimmick or, you know, just going the extra mile. But really, what we care about is proving those conjectures so that we can everyone can reduce the proof size quite is that supposed to happen before the test net like uh but no obviously. Yeah, this is a very hard mathematical problem that various people have tried to to tackle. Um but you know with the right signaling and incentives if many top companies say we need it then the

smart mathematicians like it would be great if we could get you know the top mathematicians to to think about this. Yeah. To maybe paint some light of like where we stand right now is like our conjectured security is not the best. It's like 97 bits. I think we've been very very conservative. We're actually paying someone right now to rewrite the conjectured security. I think we'll land above 100, maybe even quite far north of that. And then uh you know later this year, beginning of next year, we want to start moving to like provable 128 bits of security.

Everything is I think that we are going to target 128 bits of security for Ethereum. But turns out that even if we use a conjecture for this, if the conjecture turns out to be false or partially false, we would not lose every everything on security. We can still have like 100 bits of pro probable security and 128 bits of conjecttor security, which is okay. I'm picking up on an earlier thread around the proof sizes and whether yeah we can put it in D or not is it sufficient for the consense layer to be

a valid like we don't actually need to know the votes if we have a proof that the state is valid right like could we move out the aggregation from the path and have it maybe done uh later if we just get a proof that I can advance the state and the vehicle state is pretty small anyways. So yeah, that's a fantastic point. We only need data sampling on the state, not on the history. Um, which is very is very small. Yeah.

Yeah. Well, right now we're not doing database sampling at all. Um, well, I guess we're doing it the naive way the blocks. Um but um one of the things that Vitalix wants to do is basically um remove essentially remove the notional blocks take the execution blocks all of it including the headers and everything concatenate with the whole consensus blocks and then do database template on everything. Um and so uh yeah but I guess we would also want to add in uh the the state to to that I just have a question when you guys

mentioned um the security I don't understand the um link or like the correlation to more security and higher proof size or if um someone can prove the conjecture security by how much the proof would be reduced in kiloby 2x 2x that's the max well there's different I think that is the There is first as mentioned the the edar conjecture which is the most aggressive one and then there is the conjectures about it codes. First one which has the everything is in the paper called the proximity gaps for it element codes and

there is they they have proven a result for the Johnson bound which can be used in we because the authors of we think that this conjectures this theorem sorry is also valid in the mutual correlated agreement setting and but and the real conjecture is this result but up to capacity and this is like the conjure that We want to be true to have fewer queries and smaller proofs and so if we don't if this conjecture up to capacity turns out to be false we we'll have to use up to the jumps and bound so more queries and probably like 2x factor 2x less than today or 2x more than that

128 kilob I think the 128 kilobytes uses the conjure up to capacity okay you can multiply by two if you if it's You want to multiply to 250. We're using the conjecture right now. It depends. intercep 60.

Okay. So, it's the it's the really lower. Okay. Cool. Okay. Uh, so thanks for a very smooth transition uh from Tom. Uh, yeah, I didn't get to introduce myself. I'm Jiannis. Um, yeah, thanks Justin for the short intro before. Um, I'm with the pro blog team and we're focusing on the uh B2P layer uh of of networks of or three networks. uh have a lot of experience with lipb but not only um yeah and of course we're keeping an eye to the pinch chain particulars

um yeah and could help in any way if and when needed uh so yeah I don't know this session was kicked off as I said thanks to the very smooth transition but maybe a first question would be um when would a test net be desired other than I don't know next week of course but um a realistic target just to start getting um yeah the session is about um postquantum test net so uh I don't know if we put our managerial hat on uh should be a target date some requirements uh what what do perhaps clients want to have done by then for those of them that are here uh I'm not

sure if everyone needs to be at the same level I guess not um but yeah and then what uh what would a successful test net look like? Maybe uh first kind of metrics of course things should not break but maybe we could go into a little bit more detail. Um okay many questions at once. So the first one like when is an ideal date target? Okay so this is just my personal opinion but let me answer the two questions. Um, in terms of timelines, the way that I see it is that Q3 is when we would implement and spec out the cryptography.

So, ideally, basically immediately after we would be able to boot up a test net. Now, what would the test net do? I guess we could the a natural starting point is just to look at one single subnet. Yeah. Um, of one of the layers um and In my mind, that's roughly of size a thousand nodes. Um, and you know, we could try the simplest thing possible, which is just plugging in gossip server as it exists and see if things break and see what kind of stop durations we can get and if the stop duration is just much higher than what we want, then start thinking of of optimizations to to bring it down.

So, so for example, interoperability between different clients at the um yeah at the networking layer having the signature aggregation and stuff would be part of the test net or or perhaps more small scale experiments in the runout to test net. I mean we we already have interrupt right? Yeah, of course it works. So I guess I would just reuse the libraries as they exist and um we could have as as many wrappers as possible around the library in various languages.

But those would be like absolutely minimal rappers that can do it that interity is really holding you back on that. So interop is is just introducing a bunch of edge cases which are which are really implementation related. So when you are testing doing that kind of test uh for the for the performance where how far I could arrive you really don't want interity in the middle actually uh it's better to to separate these two respects and do testing as one pilot and the kind of performance testing as another one

because about the thumbs here. You have a bunch of dimensions to explore. You don't put okay. Um maybe another question related to that maybe to client teams for the test net. I have seen that many of you client teams are trying to reimplement for example the XMSS signature scheme and stuff like that. How is it difficult like do you have cryptographic team for that in the future? Do you plan to use rappers maybe around like existing libraries or stuff or do you plan to

continue on the cryptographic effort because I know that this is not common for like for client teams to have like cryptographers at home maybe and so how do we handle this? So first signatures since it they are happening outside the ZKVM I mean they are separate ZKVMs in itself. So we will start off with uh using bindings for the rest libraries that you have created and then basically see whether at what point they get mature and the scheme is sort of fixed and see if there is some value in translating them into for example Z.

Um, actually that's a good point like on on the the bindings for the the signature libraries, one of the things that I've heard a lot is that the BLS bindings are a pain to work with. Um, and so if we could have the existing consensus clients tell us how they want the bindings done, uh, then I guess we could cater for for them. Any existing consensus client Dave here that wants to comment on the bindings? Is the goal to have just one?

Is the goal to have like a single implementation from the security kind of perspective like you had with BLS or is there value in like people having their own implementations instead of the bindings slow? We we we have two cases as well because we have CKG was choosing a centralized approach like BLS. So blast in my opinion for this kind of things would make sense to have like a strong cryptographic team implementing that and then bindings rather than have like scatter implementation of cryptography sense but so far for BLS and KZG we follow this approach.

So KCG library itself has bindings subdirectory where you know various bindings are being released and client teams themselves they basically go and maintain those bindings as well. Yeah I would go with one and just put much effort in security especially for more verification which should be possible given the simplicity of the design. So like the the so the bindings are what are important and the actual like logic is just one super optimized thing that's been hardcore verified and that's it don't touch it but for example we have also seen the alternative implementations of c of kg come up for example in all that right so

kev for example created a library that is in I just sort of verified that it was working interoping well with libraries. I mean I know this because I did this more for that. Uh so yes I mean but we know that okay you know they there would be one major library which will be sort of reading everything the prod one right and then people will come up with their own versions and make the happen. Cool. Okay. So, um yeah, going back to the beginning, uh if we assume that we that uh there could be a test net in Q4

of this year, um maybe we could go around the table and uh see what clients would want to have implemented by then. Does that make sense? like I've seen throughout the various uh presentations today more ZKVMs um integrated implemented um u or having interoperability with other things would that be something useful to start setting perhaps the road map uh team could you rephrase your question also so I from from my perspective uh getting

a test net a single client test net makes sense to start off with first um because then we don't have to worry about like each ops um I think and also like if you want to measure that there's like you can see the delta between like different performance of like different test different clients and then you can optimize by that um but in terms of like actually get tested up running I think uh important thing is like how much of the existing specs we going to reuse for example like the P2P layer is one of them. Um what else is there?

So yeah I I think for doing like a test net it would be really achievable. I think right now it's like not really well scoped out. So it's a little hard to like comment on a lot of this. Uh but I think if we're like reusing like the gossip stuff in the PP layer, it should be like fairly minimal and then we'd be like reusing Rust libraries. So, I don't see a reason why we couldn't achieve this other than like it being not really well scoped. And um yeah, then uh following up on the B2B thing, um we've seen a presentation this morning from Camilo about the uh NS3based simulation uh simulator. So what would be the studies that you would

like to achieve either you or I don't know perhaps you know give it out to the community to carry out tests um no tests like what what is the actual simulation experiments that you want to run in order like what what are the things that you want to verify using this simulator? Yeah. Well, first of all, we need to kind of make sure that we Yeah. Yeah. We have uh 4 second slots. So, yeah, we need to make sure that uh yeah, we can fit uh to kind of perform this aggregation within this period of time.

And actually, the period is is not 4 seconds. It's actually smaller because yeah, there are other things that we need to do uh during the slots. So, I would say maybe even 2 seconds or 3 seconds at most. Um so yeah so far our tests showing that u uh well for approximately like uh yeah we need to conduct more tests for larger networks but for like 500 peers per uh subnets yeah within it takes approximately maybe a second second and a half uh to perform the aggregation. So it should be doable. Um the bandwidth requirement well put like the cables well kind of the peer connections uh

with of with bandwidth like 20 megabits per second and uh well the network works well. Um yeah so for for us it was just to test the assumptions that increasing the number of the size of the signatures increasing the size of the aggregations so uh everything works. Another thing is that uh as I said like there is a design space like how we propagate for example the snark uh proofs like we cannot simply gossip sub them uh as they're too large and if we do like I want announcing pit field then uh requesting the snark then this kind of creates another round of communications which we

do not have right now. uh yeah we need to test this a bit more thoroughly like if it's also delays uh the aggregation so much but so far we results showing that yeah even with gossip with standard mesh of size six like seal connecting to six random beers um yeah it should be good for for the snarks yeah for the snarks for the current signature a recreation scheme okay yeah um there are things however like if we perform like three SF I assume we running multiple rounds of aggregation in parallel. Um yeah maybe this another thing that we also need to test which we

are currently not doing. Um also would be great to check like first we once we perform this aggregation um yeah I I would add maybe and uh try to test like how but this aggregation the final snark should be broadcast to every peer in the network so that it could be included on chain at least it should be sent to the blog proposer uh of the next slot I assume um yeah so there are still few parts that I I'll test more but the most important thing is like with current aggregation scheme I think yeah we we do not really impose a lot of

requirements additional requirements for the network bandwidth and uh throughput so yeah the scheme should be do like should be okay and we should be able to aggregate within less like less than two seconds or so yeah okay so the the simulations that you want to do is primarily to verify that things are going to work Okay. Yes. Yes. And this is the normal gossip, not any 2.0. Uh yeah, it's a gossip. We used gossip sub I think 1.2 because we also have I have messages reduce duplicates. Um yeah, it's 1.2, right?

One thing. I don't want one thing. Yes. Yeah. I have is 1.1. Yeah. So, so what I wanted to add is is more of a methodology thing on on these tests. So, if you set it up like this, like you take the minimum requirements, then you run it. What you get is a sums up. It's working. If you run many inations, you might get percentage like it fails with 10 tous 3. Still, you learn little. So, it's much better if you if you do it in a different way is that you are searching for ways to let's call it scenarios which will happen like during the night it's working during the day it's not

because during the day there is a football event. Uh so you have to search for these nasty scenarios typically with one parameter that you can tune and then you find the breakage point basically. And when when you when you have this kind of you manage to map out out this like bandwidth scale down uh partition network these kind of scenarios then you have a much better view of kind of what's the robustness of your solution than we're trying to say let's say everyone should have 20 and then we have a sample because on average in one second everyone is getting it. So it's just try to think in the the terms of of like scaling down

the results available and then seeing how robust is my solution to these kind of just nasty scenarios. Then we can also speak of attacks but this is just a nasty network behind it. And what would you stress this? Yeah. So uh just if if for example learning uh that thing I would I would use the band bits uh like it's nice to say everyone should have 20 megabits uh but there will be scenarios when you don't uh cases when you don't network doesn't have it uh partitioning is a typical good test so you say uh the bands between nodes in in Asia and not maybe in the Americas is is limited uh and then then you see how your

nice thingy transforms into a basically. Yeah. And oh yeah, I was just question approach to chop the proof the same as we do with the box or Yeah, it's a question for like how do we propagate it to every participant in the network? This question.

Well, maybe I can. I guess we can. Sorry, maybe I sent this to the question, but um I thought the question was going to be um can we do datab sampling on the signatures? I think the answer is no for that. You do need to download it and verify it locally. Uh but maybe what we can do is this fancy eraser coding to to to gossip faster. Maybe like a more general topic. What would we want to test during this test net in the general? What what are the biggest fear on my side? Maybe I would be asked by because I I work all day long on postpandum cryptography. So I see this big picture where we have like

maybe a minimal ZKVM then a prover system then a PCS and I want to test that all of these work in real situation with the P2P layers that we are able to receive the signature to aggregate them properly to propagate them to the network. But about all of this, what do we really want to to test on the test net? What need to distress test? Yeah, I just have a comment about test net. I don't know if beam client seems are aware of it. Um the apps has a very nice tools called curtosis. Maybe everybody everybody knows.

So it lets you to just spin a death net on your computer or more big network like in seconds. You just can specify okay I want to bring client to the clients and give you a number of validators and you can very easily testing either yourself or your client or interoping with the different plants and you have nice UIs to check if everything is okay. We really he really use it before launching any net any real and so before launching any test net it it really helps to speed up by a big factor um the development process. So on your computer you can know okay my client is not compatible

with another client because of that that yeah but it needs to be adopted right sorry it needs to be adopted for yeah yeah I mean I just think that we use it for chain and exection layer very useful. There is huge improvements before and after use usage of crypto and I think you should use it as well for big clients and you can ask Barry or Baras. So sorry just a comment on this uh crytosis is a very manual process like to create the configuration you need to do a lot of coding. So that means if you want to if you want to use crytosis as a test bed, which okay, I agree is a good

idea, but we're going to need to get kind of ops on the on the case because no one else knows how to use it. In fact, the company that that created it gave up on it and so they had to maintain it themselves. Um, yeah, I'm I'm just saying that that is probably going to add quite a lot of delay in the in the yeah, timeline. It could be like automation and like guideline on how to use. Yeah, actually that's true. However, I I can talk for prison. Um I had to modify I wanted to add some modification to the prison support in cities and I did it

myself. It was not so hard. So I guess everybody here we should be able quite easily to to do it for their own clients. Just you just take an example of another client. You see how it is done it is in star which is kind of Python language and it's not too it was not too too difficult but yes is that's a good point but it's mainly configuration management and synchronization of configuration client configuration management is when you when the adapter is done for you when the adapter is done for your clients then you only have to configure with some files yeah yeah that's fine the the the is mapping the your configuration to

Yeah. Yeah. And that's kind of it's still a little bit of work to do still, but it's not it's not infeasible. Yeah. to the amount of work required like to adapt that to the beam chain if it is really specialized toward like the Bitcoin chain if this is a completely rework of the system or it's not specialized here it won't be a simple translation because we have new signature schemes that would need to be uh you know you will need to generate validators and their public keys in a very different way and set it all up. So it might not be a small task

but you need it for testing for section anyway, right? So when you test one to done, you would have to build a tooling eventually. Yes. Yeah, you do do have to put it into the framework. But I think just if we for example starting with just two clients, we don't actually need ktosis to start off with. We can just you know two clients can very easily come to terms and figure that thing out. uh in and the main question I think was what would you want to stress test if uh what we are trying to if we are trying to incorporate a new grid mechanism so that you know we have faster uh delivery of signatures like if we have that grid thing where you can deliver signatures in two hops I think that is something that that needs to be

stress tested because otherwise gossip sub is already stress tested it's just that the payload has increased a bit which means that okay your bandwidth needs to go a little a bit higher or a lot higher but in terms of the systems working together I think it those things can still happen it's not really a big challenge but if there is a new grid that is out there in terms of uh distributing the messages that would need to be stressed so uh if I understand correctly man you just volunteer to write to you can ask they don't have the time to But if you were fan

so I guess another thing that I want to know before um starting out the test net is um the hardware specs. Are we sticking to the current uh the ERC of the hardware specs or are we going to upper or lower down the the specs? For me, I I think that this is almost the same because as we discussed like at the beginning with Emil work particularly like on a GPU version to have like the target for the signature aggregation throughput but at the end we kind of figure out that the CPU should be enough. So I don't think that we need fancy thing like to do uh to do the test

and that is my my current opinion. Maybe just you have like a front one. Yeah, I agree. I wouldn't increase the requirements, but what we could do is for a very large subset of the nodes decrease the requirements. Uh so we can have them run on like the weakest machine on the cloud for example for 80% of the validators and see what happens. So that would be for the test for the test. Yeah, because we only need on the order of 10% of 10% of a thousand being 100 100 aggregators doing the work. I mean 100 is even like more than more than enough.

Maybe another question related like to to crypto with with Emil. We have talked like about the minimal ZKVM that could be enshrined into this consensus. Are you particularly afraid of having like a new VM of because I know that each time we are talking about VM we can have like thousand of tweets about this. We have particular concerns, questions. H have you considered the possibility of using like a defense in depth and having two systems to to aggregate the signatures? maybe keep the old BLS and introduce a new start one with less

virtual security so you have another one anyways or something like that because that will also address a concern on the CKVM. We said you go with two for a while and then when we are really confident on the new one we can just ditch the old one um and keep it. I think that this is something that At some point we consider because I I remember Justin you told me briefly about this in Sicily like this is a possibility that we could go like starting from BLS but I'm not sure that this is the best idea right now because

as mentioned in your talk just in this morning the best is maybe to start with the state of the art like and and and go like trade for that. So I would say that the the test net should be a good idea to stress test this minimal ZKVM and also we want it to be really minimal. So not like a risk five complete VM or something like that. So we really want to put it to the minimal so that maybe let us say simplify ZKVM. Yeah, that is that is my point. I don't know if Emil or Justin you have like complimentary point on this.

I mean, one thing that we're very much leveraging in the context of the ZKVM aggregation is that we can merge two bit fields that that share bits. That's something that we can't really do with BLS. So, actually it's an interesting idea, but BLS in that sense is strictly less powerful than what we would with the the permission based aggregation. I think that maybe the question was that for first net we could like test all the other components that are let's say less risky in the for the chain and then when we have more confidence about like the let's say one year later then we can add

it not I think we should be functional from day one in the sense that we have all the components over there and keep it running on rather than saying that okay you know we delay the scale parts to a different timeline I mean I guess there there could be like multiple layers within a single subment so for example there could be just the the gossiping of the leaf signatures which is kind of separate from the aggregation of them so in theory we could start to today uh with what we have uh for the gossiping and then only

do the recursion part the aggregation part once the recession. Okay. Um and if as was mentioned before uh would that be uh the first test net going back to that um would it be a one client test net? I I thought the target would be to have more and actually test the interperability and everything but uh yeah yeah yeah I think it would be fun to like interact with like Z or any other existing team what's ready uh from like what has been discussed none of it seems like too hard to achieve so I'm fairly confident that we can do the very like cloudy thing that was

described I think the main point here will be to freeze what we want to test and then basically come and say that okay you know this is for example these two teams can attack on it and come to come and figure that out. Just advocating a little bit for the one client test bed uh not in the sense of one client but but something which which like for example so that every single client can can do its own testing because then you have full ownership of of actually what's happening and you can go in and and find problems. The problem is if you only mix it with the interoper debugging interop thingies and you have no idea what's happening.

Yeah. So that's kind of the so before interop yes you do self interop right. Yeah. Yeah. Yeah. So just that is definitely the step that you will do before you will start interacting with a different system. Yeah. I just uh when when you are doing this larger scale I think it's better to architect in a way that maybe the rotation even different clients are going on the on the bigger infrastructure if I think maybe panda ops can sort of uh you know guide this process as well because they have been doing interops and they have been churning out hard folks and uh yeah so they have had some learnings doing all that so if we have that we'll have we'll get all the wisdom that they currently have And yeah, I think they they don't have this

learning yet. I'm trying to discuss it with them. That's why I'm saying I would like to add if you're going to interact with two clients. Uh so probably it's time to think of would you like to standardize the metrics. So if you want to measure the same things, so it's the earlier the better. So uh just think about it what you want to measure and for two clients you can standardize it and out of the box you will see the same results and you can compare things just to consume just to add a bit uh I think uh in terms of coordination it actually might make sense to focus on interop uh because then we can work backwards on our own

death nets and you know like testing single client test nets I think that that could be like each client's own timeline but I think the important thing is we once we we talk about interop we have to agree between teams on on when we can actually be ready to test together. So when we talk about that we also needs to figure out okay this is the spec and that is why it's very important that we talk about the inter but then this needs to be done beforehand right uh so each team would have to do the testing before the actual test night um yeah okay I think that also for this kind of test

net, we would probably need more observability on new things. For example, the validator sets, the validator keys, stuff like that on kind of a new kind of block explorer where we need outsource of like the proof that could be published, the proof size and also have information about like cryptography. Yes, that ties in a little bit to Kobe's point, which is that the test that is not well defined. I guess the most minimal thing that I can think of is that we have exactly 1,024 validators. Um we have round robin so we just rotate through them and then a block is just the slot number the parent hash and the

aggregated signature and I guess the signature of the the block itself and and then that's it. And then the block explorer can also be do we want like the proof to be on the block explorer for example this is something that you don't the proof being the aggregated yeah for example that you currently have on block explorer so instead of that we'll have aggregated and that's exactly what we currently do in z right now in three in our state transition function minus the ths that we implemented that you have this only basic thing where you

just build the chain and then when you add signatures on top of it then you will get to this point where we can do this test there won't be any deposits or all that mechanism so I if you pre-generate uh all these validators uh then then basically if you do around block production I think uh that would be pretty simple to handle and demonstrate uh the signature aggregation. Okay. And in your current developments like the client teams do you develop also like observability tools like graphana or stuff like that to have more feedback on your test on the test when

we launch to do where it takes time or stuff like do you develop this kind of stuff or this is too far from from now? Thank you. Uh I mean like adding for a fun metrics is uh fairly straightforward because normally you would just have like a global like Prometheus like object and then you could just like inline those where you need them. So I think for metrics we could get those done like super quick if needed and where like so that wouldn't really be a bottleneck.

I think your means tracing. Yeah, like tracing what in particular like through your stack where where your performance bottlenecks are. He's not just talking about Oh, yeah. Yeah. That that shouldn't be that bad as well but you you can do it in graphana as well. You can keep keep observing and it will just generate the graph for you and I mean we do this for example you used to do this in load star. I used to lose low star and lots also does this for quite a lot of things where you can just look at the graphs and you can see okay you know these are the way points so as KBY said that it's really is it that hard do you have this kind of tool in Z or uh I'll need to check Prometheus

integration with Z but I'm not sure as of now but maybe shouldn't be that hard I guess it's not going to be a problem because Z interfaces with Z the hard thing about open tracing We have to agree on where exactly like you want to trace things. I mean that's what K capture said that once we define what the metrics that we want to capture uh that sort of do you want to brainstorm ideas on the metrics if you have any ideas? I mean I think right now it's a little premature to talk about metrics because we can figure out this quickly what we need. I think the metrics I mean even if we just want to give a rough thought on it the metrics would be okay how many hops that the signature is taking to you

know get aggregated and then uh so what what is the aggregation time apart from that uh I mean these are the relevant metrics that come to my mind okay you can say that this is the bandwidth and how it scales when you keep adding more and more validators on this step we can already create a repo and an already done. Um okay and um yeah I wanted to to get back I can't remember actually if it was uncert

um what would define a successful test net things not breaking obviously u finalization. Sorry, finalizing test. Yeah. Yeah. Um I mean this would be the first of many. So I guess uh there would need to be some uh kind of you know um KPIs of sorts you know like what should be successful in order because otherwise there wouldn't need to be any second testing be okay ready.

is 4 second slot is a must for I guess so. We have lots of it's a different thing. I thought you wanted to say something. Um yeah, I mean uh just a quick point. Um if we have this minimal test net that only does aggregation then there wouldn't be a finality gadget on top of it. So it would only be to to benchmark the performance of aggregation. And I guess um you know the ideal outcome would be that we have some relatively large number of validators maybe 16,000 32,000 and the slot durations would be very short as well um I mean this ties into

the next round table but um the new meme that I have is um speed of light slot so o like like salana but not salana speed of light um and like like ideally we have some sort of first principles approach to the start duration. So for example we have some number for example 250 milliseconds which captures time it takes to do the worst case ping between any two geographies and then we also have the worst case number of tops which might be I don't know eight or something and then we can calculate okay based on that our

start duration is to be 2 seconds um but yeah as a starting point um I think 4 seconds seems very doable And if we can get I don't know 32,000 validators in 4 seconds that would be fantastically successful test from my perspective. Nice. I mean but in terms of uh the actual uh you know running of the blockchain right you still need spark choice. So it would be uh beneficial to have I think maybe mini 3SF or something like that so that your state tree also also doesn't go too big and uh otherwise you will have to have very small test nets because uh if you can from anywhere then I mean so you will have to have

defined some of the rules that okay you know this is the depth maximum depth that you need to keep uh for your uh your states for and all that. I'm just thinking of health here, but one thing we could do is not even have a chain, but just have like individual blocks and the message that you're signing is just the slot number. So you're signing one, two, three, four, and then you just do the aggregation part and then you you somehow log it on graphana or whatever, but you don't have an actual chain. I'd love to test the key regeneration as well. Um like you said like probably like it takes like six years until

regeneration but I wonder like if the chain is running and you have to like proposing and testing and all that and it reaches that point where you have to regenerate all your validator keys um whether the the specs the minimum hardware specs will actually it's from from what I know it's something that from the last news that we had takes around two to three hours on like a MacBook Pro. for like yeah so I I would want to kind of test in a in a like a long running environment where you're producing a testing box and also have to like regenerate the keys at the same in parallel what would that be for test net one but I was of understanding that the key

lifespan would be like 100 years or something and we wouldn't be regenerating not to it's it's not the two or three hours like key generation are not for something like 10 years or something like that. You don't need to run it down. You can run it in a completely different process and just choose to broadcast your own public key. Okay, so there's a few things. Um the first one is that there's there's two concepts. There's the maximum lifetime which indeed would be over 100 years even if we have one second. But then the default in the clients more likely not wouldn't make sense to to be a 100 years just because it would it would take

several days to generate the keys. So from my perspective the reasonable thing to do is for the defaults to be just generate eight years of of keys and that will take three hours for example I think but even for the test net we don't need the eight years we just need eight weeks or something. Um the other thing that I wanted to um talk about is um the the the the key rotation. So this is one of the annoying things about uh having stateful signatures is that um you need to signal your intent to exit as a validator early enough to cover the worst case. And the worst case is that

there's no finality for an extended period of time because you can't exit until there is finality. Um, and so if the worst case of no finality, for example, is 3 months because that's, you know, how fast the leaking happened until you get finality again. Um, then you want to exit three months before you your keys actually expire. And the When you say exit, you mean actually exit or rotate? I don't understand why you you wouldn't be able to publish on chain that in a thousand slots your public key will now be this and not that or in a registry or yeah I guess one downside here is that

introduces a bunch of complexity on chain. Um, and also there's like potential attacks where you know on one fork A you you say I'm going to do key A and fork B and keep B. The simplest thing is just you exit and you you you uh redeposit business waste money because they have to exit enter the queue and then join a new queue to become a valid. Yeah, it's a good question. Um, so what I expect will is that some of the validators will just choose to to do a key gem over let's say one day and that's going to cover their lifetime and that might be you know good good enough

um yeah I mean that that's the simplest thing the other answer that you could give is that um you could calculate what is the exact loss that they will have to do to to the impact if they have to withdraw and redeposit And one of the things that we're looking to improve is the speed of the withdrawal and deposit cues. Um, and you know, my guess is that the loss is on the order of a few hours relative to eight years and that would be less than the basis point.

If every validator is faced with the same problem, their rewards are equally the same. Just not a problem. Then you could have an event where few intersect at you could have like a huge mind taking and then they have to rotate like 100 million one billion. That's a good point. One thing we could potentially do is um have the key generation be slightly randomized. So it's eight years plus or minus two years.

Okay. Speaking of keys, in terms of security, I think it's important to to have excellent tooling to avoid to sign this with the same one time signature to the uh I think it's an issue with a security perspective. Yeah, that would be a slashable message even today. Um if you sign two messages with the same number and we do have what we call anti- slashing. So that's already infrastructure that's been built and the way it basically works I mean the existing clients can comment but basically I understand they they store uh for example the latest slot that they

sign and they'll always always make sure that whatever they sign is greater than the one that was last yeah so one of the assumptions of beam chain is that doing the transition from BLS to post quantum signature is very hard and so that's why we should blend up the change of consensus mechanism with it. Um I believe we shouldn't block the consensus mechanism on doing the transition to postquantum signature. And so I feel like something that would be helpful to know well in advance is exactly how hard this transition is from BLS to postquantum signature. And if the transition wasn't so hard or we could

find ways to make it lighter, it would probably give us confidence for instance that we could ship the new consense mechanism before we ship the postquantum signatures. And I feel like test net might be a good place to early derisk the transition from BLS to to postontum. I think that would be like a very valuable piece of information to decide whether to bundle or not the consensus with the signature change. When you say when you say hard you say about like state-ofthe-art cryptography and stuff. This is that you mention hard or not hard.

Just like the simple fact that validators use some signatures into it and we block from the other signatures. Yeah. Yeah. Okay. Can you repeat what is the consensus actually? What is a new consensus gadget? I just realized I don't know. There is free is one propos we some of us believe that we should go even further because there are there's a new class of cons mechanism like Adam and other that were published in the last few months that seem to be even more optimal give you even shorter slots and just more perform generally speaking so

yeah we might want to accelerate on this so what you're saying is to yourself is completely separate from from um XMss. Yeah. So you could start with the 3SF to go with the hardest hot swap and no you just I'm saying there's a consensus change and there's a signature. So we should unbund them. I don't know. But I think if we knew that the transition of the signature was easy, it would make sense to Yeah. So the the story that I've been telling folks at the that um my intuition is that changing the signature scheme is going to be very

invasive to the whole uh become chain because it changes uh the way we do deposits. You know, we're no longer using the deposit contract. Uh it changes the the pub keys and therefore the the validator objects and the attestation objects. We changed the aggregation um strategy to allow for recursive aggregation. um all of the sizes in the in the peer-to-peer messages all change and so it might touch let's say 50 to 80% of of the code base and it's potentially a very similar story for um for the new finality gadget as well. Um, and so if

we're going to have like these two extremely invasive changes, we might as well bundle them so that we only incur the pain once as opposed to incurring the pain twice. And there's all sorts of other benefits to that. Um, you know, one is that we get an opportunity to clean up all the technical debt and the long tail of other features that we want. And it's also an opportunity to on board a fresh cohort of teams where it becomes socially acceptable to only support the future as opposed to the whole history from Genesis to now as a man for instance if I was told if I was told I can get faster in two years but then that delays the post signature by three years let's say and

so that comes only in five years and bundling was putting them both together at like 3.5 years. I would pick doing the faster first and then the bending later just because I really think we should get faster much faster than let's say five years or four years and I think it's probably possible and more possible with BLS because it's lighter so there's a lot of constraints that just become so much easier to to deal with and I'm I'm not a quantum cryptographer but I also feel like within two years we might not have the pressing need to change to this PQ scheme. So yeah, I'm just like throwing a bunch of like hot takes in in

the middle. What what are your maybe what are your opinion about like everything related to this new consensus mechanism as opposed to BSF like you just mentioned that there is a possibility of other consensus mechanism that are even more performant. Do you think they are possible alternative in the time wise that we have or not? What what is your take on on this? I think free is already very good. So I I do want to say that it's it's proven like we have papers, we have prototypes, we can probably have specs fairly soon as well. So we shouldn't say like oh this like already yesterday's news because I really think like it's it's an

extremely attractive um option that we have. It's just that maybe in the last three months like we've seen all of these new papers and so if we are already saying well we are going to do all of this transition in like a couple of years from now and we have right now like an inflection point in terms of this consensus mechanism. It would be a shame not to take the opportunity to like leaprog even further and ship something that's really state-of-the-art like this year and not state-of-the-art maybe two years ago. And so I've talked a bit with the consensus team which Roberto Luca and Yan and Yan in particular is a new hire who has like quite a bit of knowledge on this new

generation cons mechanism because he's actually been working on this for his PhD thesis. Um and my sense is that they would want to let's say take a couple of months to understand like just how much of a piece of work it would be to come up with something that might improve free even even further. And so so it's not clear yet like how much work it is but the upside would be be huge. And so that's that's kind of where the thinking is. Yeah. In terms of simplicity they are the same or kind of more complex complex. Um it's hard I think to project them on just that single axis but they make slightly different trade-offs. Uh they have to be understood in the context of

our consensus which is very idiosyncratic because of the dynamic availability. Um, so there are like tradeoffs we could make where it's not exactly dynamic availability that we're looking for, but like the ability to restart quickly when we lose livveness as opposed to yeah, something like Tenderin that just blocks when it doesn't have liveness. So yeah, there's a few questions. They seem simple enough like you can whiteboard them in a in half an hour perhaps at least or the other ones that came out. um yeah they just feel like positively high upside and I think that's just the reason to to look into it but but really even

separate from that like even if we had a shot at shipping uh in two years free SF with PS signature I think we should do it to be honest yeah because it's just such a huge improvement compared to what we have today uh that it would be yeah it would be reasonable to at least consider that alternative Yeah, one thing I've been surprised by is that um although we have a proposal to reduce the slot durations, we don't really have a proposal to reduce the number of slots per epoch. And that would be a very easy way to improve the time to finality. And if we do both sixcond slots and 16 slot epox, that's a 4x reduction over 12.8,

which is like 3.2 seconds. Sorry, 3.2 minutes, which is What do you think of 3.2 minutes? Is that anything is kind of Oh, I see. Okay. So, you really want it to be and fast. That's what we're hearing from that. That's kind of the solution. That's like the seven to 10 seconds. I mean even in principle I mean even in principles is like if if there's something that you can ship faster and get out issues to it there's just I I I agree with what you're saying as well just like um want to like get more social

awareness on all the streams of work but there are two unrelated streams there is an advantage of paralization like you can see which one goes faster if you get it done go to production In this case, your optimizing function is time to production, not necessarily, you know, trying to get more people just sort of aware and involved. I don't know if you have it if you have it in your hand, right? Like it's like whatever they say in your hand versus one or I'm I'm like a train l Yeah, I think the aggregate work is probably much smaller in London. The distribution of work can be very different and you can get like nicer And then

yeah, I mean I mean it always comes down to the final project plan of course like if you actually write it down and you're like oh yeah both of them are they eat off of each other in terms of energy or resources. More complicated decision to make but if it is more straightforward get it done just get it done. So to me that really revolves around figuring out how diffitioning along this line I think can I ask to what extent VS is I don't know not hard for that but it feels to me that uh if in some proving systems you can in some provers you can it's

just a trait to replace a blake by Kjak. I know it's a bit dumb for it, but I don't understand what is blocking us to encapsulate PLS behind the abstracted endpoint and such that it can be hot swapped incredibly simply by by XSS sign. And I know it's a bit naive, but I wonder what is blocking us from this. just seconds of time, right? Yeah, it could be a parameter instead of something kind of like hardcoded into the consensus itself.

Yeah, I think the current staking mechanism is just so dependent like we have a million validators, we could go all the way to 4 million like that's the upper bound that we have today. There's no cap just like a lot of things would have to change at the same time. We just like hot swapping. I mean like doing for example doing 3SF with BLS in a way that BLS is not a first class citizen. is just a choice such that you can hot swap it not even to maybe XSS or maybe Latis something in two years or any just anything at this point.

I think these kinds of directions to be very good because they give us just more I mean a couple thoughts here. Um, one is that VLS doesn't have the exact same API where you can't where you can't do the the recursive application. And two, one of the risks of kind of going as fast as possible with BLS and then saying, hey, we're going to move to post quantum is that we might have the slot durations be way too short, for example, and then we'll have to go back to longer slots or maybe to fewer validators or some sort of trade-off that that we will want to make. Um, we're actually out of time for this round table, but I thought

it was very productive. Thank you so much for your participation. Uh we're going to have a quick break and then the second round table on shorter starts.