Post-Quantum Interop Call #5

Transcript

Okay, >> everyone. Welcome to this week's PQ interrupt call. Uh the goal of this call series is to be to serve as a touch point for researchers and client devs during the iterative process of developing, deploying, testing, and improving a series of dev nets focused on aggregating postquantum signatures. And this breakout room supports the longer goal, the longer term goal of lean consensus vision. Um let's dive in. I've got the agenda in the chat. Um I think that there was some discussion around perfect consensus. Um Roberto, thank you for staying up to the wee hours of

Australia's evening. Um is there anything that you wanted to start us off with? >> Yeah. Um I think mainly just um probably repeating what they wrote in the message on telegram. So my idea was that um because of the scenario where we essentially essentially have synchronized clock we can essentially manufacture consensus by having each node each validator at the beginning of a slot to sign a message. depending only on the number of this slot. And

in this way essentially all validators always agree on what to sign. And in this way um we don't we don't run the risk that for example if we use some some some form of our choice perhaps some validators are a bit behind and they vote for a different block than other validators and we cannot aggregate signatures. So this was overall the idea behind what I wrote on telegram and enough theoretically the reason why we can do this is that essentially we have a trivial consensus algorithm meaning that essentially there is only one value

possible that it can be decided which is essentially the number of the slot that's why we we can do this >> um and Roberto Gzender threw his hand up pretty quickly. Maybe we'll take a maybe gadgeter, I don't know if you had a initial question on setting context for this. >> Yep. So, Roberto as uh you mentioned that uh u yeah so the consensus has to be pretty light and simple and uh clock is synchronized anyway. I mean that is the basic assumption behind the beacon protocol as well that the clock is synchronized and uh so that is what we

are aiming for. I what we uh discussed uh with dream and we believed that uh chaining is sort of important and once you have chaining so some sort of uh finalization is also important because otherwise the clients will become stable over a long period of time uh and it will become too. So, so with that regard uh we basically decided uh that we will go with just uh chaining basically you know having uh parent child relationship and validation of that in the uh uh in the consensus and for fork choice basically you know we wanted to go with 3SF mini

because it looked simple enough and Ze was able to implement it pretty quickly and I believe is also able to do that. So with regard to that I believe uh our choice of chaining and 3SF consensus is pretty minimal and simple with that regard uh to kickstart uh this uh DevNet where we don't think that a lot of time will be spent while running uh the consensus and uh it should be pretty trivial not in terms of implementation but in terms of a client running uh running uh you know proposing and uh basically running uh running the state transition function it

should be pretty simple uh and trivial for the client uh also it is simple enough for uh teams to implement I mean Ze and re both have it so uh in that sense we don't see any challenge over it uh and for block production definitely we will do a round robin based upon the slot So that has already been discussed. So in that sense uh we totally are on board with uh your proposition of keeping keeping the consensus simple and uh we believe that chaining plus 3SF plus roundroin uh uh block proposal is keeping it simple.

>> Thank you. So my proposal is essentially to eliminate consensus. So there is no my proposal is consensus is so simple that there is no message sent to arrive to any consensus um >> but but if consensus is if there is no consensus so that way I mean we won't be able to we won't be able to calculate which one is the canonical chain for example why is that because because it is important because >> uh for example if uh their aggregation is late or If uh voting is late then uh for example canonical chain would be different uh uh so there should be forking right so if you want

>> sorry to interrupt you but there is no chain in my proposal there is not there there is just no chain at all >> sorry to interrupt you because >> I understand but what I'm saying is that tracking chain is important to figure out how efficient uh the scheme is whether all clients are able to vote at vote in time and uh so basically taking all these delays and coming into an aggregate number of uh attestation effectiveness because uh headboard accuracy is the most important uh uh metric that we need to track and with that regard I think chain is pretty important to have >> isn't the objective to measure the

performance of the signature aggregation that that is the objective effective right? We want to see me maybe some metrics like how long it takes us to aggregate a given number of signature how of plotting some graph of right >> that we don't actually need a devet uh the objective of devet is to run uh postquantum uh signature scheme in entirety end to end and see you know what are the challenges and what are the metrics that are out there which include time for signature aggregation all the clients will be doing that but just for the purpose of uh benchmarking signature aggregation we basically don't need uh a

devet uh so camel basically is also running some sort of uh simulations right so we will have uh some benchmarking results even from simulation itself uh so with with that regard I think there are other paths to do benchmarking and to figure out whether signature uh aggregation is efficient ient enough or not or if for example there is some particular signature size what is the expected uh delay that we can expect on a simulated network and uh through network simulator and all these tools I think we will get a good idea about that but uh post post that we basically want an end toend uh measurement of what this postquantum

signature devet look like including and and now you know this is not just for example about signing and aggregating. It's also about for example uh genesis generator or genesis generation and key store generation because you know now the validators will start from a seed and they will need to uh generate uh private keys and sort of uh come to a public key uh and so so basically overall process right uh so it is sort of a in entirety this particular experiment that we uh that we and dream sort of thought about and we basically started on it. Uh so uh aggregation is I would say a

a part of it although very important part of it but what we are trying to go over here is basically you know see how it really works out in action. So which are the parts in addition to I mean like in addition to aggregation what are we trying to to measure sorry I missed that. >> Yeah. So, so we would basically you know we basically need to figure out what is the best form of genesis generation but but I mean although it is generally for test nets and for mainet it would be hardforked into but uh the point of that is how for example a postquantum key

would be generated and registered right so that that could be a later stage registration could be a later stage uh goal of see how it works out in the real but at least Uh for example, if you want to if you want to start up a validator and you have a key store, uh how much for example lead time you need to generate your private key and uh to basically start up the validator. I mean all these things are logistical things but they are quite important. Other thing would be measuring uh signature time uh measuring uh the bandwidth in the real scenario and uh as well as uh what are the delays uh that are uh happening right so measuring the latency and

measuring the hops whether we can improve gossip sub uh uh or you know what what are the delays what are the hops that we are getting with the current gossip sub is there another uh u another grid. For example, there is a square grid proposal that is out there. Is there another grid that we can basically have so that we can propagate faster? Then aggregation is definitely uh uh one of the points and the verification of signature is definitely one of the points uh in the entire scheme. So the so the consensus of chaining and uh uh 3SF finalization that is I think very small bit and we don't

see it as a computational or resource hurdle at all. So my my concern is that it's not so much about the complexity is that because it's possible that if there are delays on the network, different nodes on the network have a different view of the tree and therefore they they send votes that are different that cannot be aggregated and then if this happens then you don't know if the aggregation doesn't it aggregation if you don't get enough aggregation because the aggre aggregation process has has some problems or because the consensus protocol has some problems. So my main concern in all of this is

that consens that we have two moving parts. One is consensus and one is aggregation. And if aggregation doesn't happen, we don't know if it's because of degradation a problem with the aggregation scheme or with the infrastructure of aggregation or the infrastructure of consensus. I understand where you're coming from, but I we believe that consensus is pretty uh simple and uh simple to understand and implement uh with regard to just chaining and 3SF. So we don't see much complication arising from that to be honest.

>> So I'm not saying at all that is complex. That's not what I'm saying. I'm saying you implement the consensus and it's simple but consensus does not guarantee you that nodes will vote for the same block because if there is bad network condition you can end up on with nodes have a different views the chain and therefore they don't send messages can that can be aggregated you see where I'm not speaking at all about simplicity it's about >> the that you can have.

>> I understand. Buth having a consensus is not complicating that problem, right? So, so having a consensus will basically help us figure out whether the problem is because the nodes have a uh have a bad view of the network, right? So consensus will tell us whether there are some nodes who are for example on a fork rather than it would become more complicated and sort of more messy if we don't have a consensus and we just try to generate matric matrices based upon uh just signatures and signature aggregations right so I believe that uh having consensus basically having a

definition of canonical chain right why we need consensus because we need a canonical chain uh to figure out what is the head accuracy and uh when why why are we using 3SF again for the stability of the network it's not really required we can also junk it if we see complications in that but the basic thing is that uh this this is a very simplified consensus that we believe will actually help us differentiate between uh uh between whether you know this uh whether the performance issues or uh uh the degra ation in matrices are arising out of consensus issues or they are arising out of uh uh some some other libraries that are out there or uh

performance uh of the aggregation or verification. Uh so in that regard we believe that uh you know the our choice of this particular consensus will actually help us but if it won't we can always junk it and come back to it. I mean it doesn't stop us to do what you are proposing. Uh but I believe that it would be easier if we have a well- definfined canonical chain that we can track and we can uh basically define our metrics on.

Uh, Roberto, I guess in the spirit of doing iterative dev nets, are are you suggesting that we should it sounds like you have concerns about coupling the signature aggregation with consensus. Are you just suggesting that we should increment our way towards combining those two, like start with just consensus and then layer on signature aggregation? >> Um, no, I'm suggesting we should. So in a way you can if you can you can say that what I I propose on telegram is a consensus essentially another way to look at it we can have a predefined chain we can have a chain uh

with which we already agree on which is preminted we have a block for each slot and each slot you propose exactly the block that everybody knows uh or everybody votes for the block that it's already agreed up front like imagine at Genesis and I don't know we run this uh this devet for 10 days or whatever we already have a predetermined chain every node knows exactly the chain that they will they will vote for so every node already agrees that's the thing like there is consensus it's just it's just implicit and because of is well one one I think

it's simple but that's not the the thing is you are never going to not in a scenario where nodes disagree but if you implement yourself or whatever it is possible the node disagree and now if node disagree they cannot aggregate you can't aggregate the signatures >> gota um in that disagree that uh uh you know in absence of consensus it would be difficult to establish whether the nodes agreed or not. So that is my response to that. I think we should also hear from uh re team what their thinking is. uh and as O already

pointed out we will basically you know first make sure that uh we are able to interop uh just with our simplified consensus and then bring in signatures to it so that uh we can deal with complexity uh properly. Uh Camille uh yeah sorry maybe a stupid question but in 3SF mini uh are we going to have like multiple uh aggregations happening at the same time because like some nodes are voting for current round and others for the previous round. Is that correct?

Uh so every so basically the aggregators will basically aggregate based upon uh the head data right so this is how aggregation generally happens in beacon consensus as well that uh uh the votes are aggregated based upon the target uh based upon the data that you are aggregating on. Uh so similarly >> yeah but but some yeah but some nodes are voting for the source some nodes are voting for the target. Is this happening at the same time or >> so in mini3sf uh so basically the votes are generally for again for the head source and target as well. So I think uh all threes need to be the same for them

to be aggregated. Yeah, just my concern is that if it's happening at the same time then it's probably is that realistic how it's going to be eventually or we will have like different sets of validators voting for different rounds uh because if it if in reality like we have Yeah. >> Yeah. It will it will likely be the latter. So uh you know in in high latency situations for example like different validators will have different views on what these source target head triples are. Um and it's actually important for incentivization that even if for example your view of the head is incorrect but you still have the source

and target correct that you you still get a reward uh for for for testing. Um so yes uh the short answer is we we will be aggregating over over different messages. >> Mhm. Okay. >> Uh oh yeah. Um, so I just want to point out again what I typed that um, so we are planning to do the the mini consensus first and then mini consensus plus the PQ6. So hopefully that should the risk

like figuring like be being able to troubleshoot issues that are blurred between the two. Um, so that's the first thing. Uh the second thing is I I actually have a question on if we are going to go ahead with like Roberto's uh proposal is if we don't have chaining. So basically only have the slot number but without um the parent um then wouldn't we aren't we going to be only aggregating the uh the the latest view? But we won't be able to figure out whether it's the same chain like some validators might be missing some heads um some are not

right. So I think that might actually make it harder to to to to get a a shared view. Um and the the third point the last point I want to make is uh I think we can actually measure uh separately between the signature validation right that the signatures is correct we can actually measure that uh separate from the actual consensus. So um if we are concerned with just measuring the PQ signatures performance then I think we are able to do that even even though we don't have consensus on what the content of the attestation is >> Roberto.

Yeah thank you. So um if I understand correctly you're asking whether um what I'm proposing could be that there are I don't know the validators fall behind or they don't agree don't don't see the same thing right um but you know the probability that that's just impossible like we can we can have a chain we can have a chain we like imagine we we premp compute a chain We can have a function that for that for each slot gives us a block with a parent the block from the slot before and every validator knows exactly what to vote for

for a given slot. But this is a con. It's just that it's predetermined and we can do this because in this in what we are building we don't care about having actually actual transactions. So like we can protoerm the entire chain and each validator knows exactly what to vote for at each slot meaning it's they they'll agree by default like it's impossible they will disagree. So I have a question for so this is my question is if we can have a perfect consensus where at every slot you are guaranteed despite even if there is complete network

asynchrony very high delays that all all validators will vote exactly for the same chain and you have another consensus that doesn't guarantee this property. Why would you not choose the first one? >> So in can we actually did have this as a proposal. Um and so that was for ECC and you know it is definitely possible to have a devet with this this perfect consensus which is super simple and then move on quickly after. Um, my my take is that I don't have a strong

opinion on on on on what we do, but if if we were to have this perfect consensus, then uh we probably don't need it for very long and we can move move over to something more complicated pretty swiftly. Um, and it seems like the the teams that are building this like Re and Ze basically have a preference to just go directly with with something a little bit more sophisticated. And you're you're you're right that if you really want to isolate the the testing of the signature aggregation then it's possibly better to go with uh this perfect consensus. But I think you know as Gadin tried to explain is that there's all sorts of other things that we need to test related to

to consensus and folk choice rules and and whatnot. So yeah, I ultimately it it has been considered a couple months ago and uh I don't think it's a super important uh kind of decision at this point. >> If if I may, I want to respond to Roberto a bit. Uh so on predetermining the chain um I would actually kind of question whether we'll actually need interop for that. It sounds like something that each of the client um would be able to run on their own and give us like the the performance

measurements there. Um but however um I think it might be a good precondition before going into actually running the the interopet uh that you know each of the client is able to sign and attest to their own like predetermined chain or or even like a predetermined chain that's shared between the the two clients but run separately before actually committing to or or like start starting to like interact with them. Um I mean I think uh it could still be a value I mean from or interrupt even if

you go to this perfect consensus as you might want to see how you know the signature aggregation implemented by different teams they combine together potentially there could be a reason uh still to check how yeah how different implementation of the signal aggregation algorithms work together. Well, I dropped a note in the chat reminding folks that, you know, we sort of self uh uh

self self assigned this net zero to be due August 31st. Uh that's two weeks from today approximately. Um is there anything that's been brought up in this discussion that sort of undermines that set of objectives? It looks like in the chat uh O is saying signature chaining is uh sort of infers I think we met parent chaining. Okay. And then there's significant work we need on tooling genesis generator curtosis. So this looks aggressive. Um, yeah, maybe on that note, let's uh put a pin in this topic for right now. And Gender and

Barnabas, I believe you guys had a conversation about some of this tooling uh yesterday. If you could maybe give us an update, let us know where we stand with with that as a dependency. Yeah, me and Barnabas had a discussion over this uh as well as some discussions with the party uh async and uh yeah, so I will let Barnovas take the lead on >> Yeah. Hi guys. Uh I'm Baras from the Ops team. So I will give a quick update on what we need every client to basically uh get up to speed. You need uh do the images for every single client that want to participate in this uh dev zero and

uh we can add support for our automatic e client docker image builder and we're going to be able to build it apps images for any of your clients. We're going to need a fork of uh Ethereum genesis generator. This fork will be able to uh uh create the genesis files for uh whatever file format uh you're proposing to have. Uh the underlining uh library here that also needs to be updated is the eat beacon genesis. Uh I'm including links for all of these. So

the eBacon genesis is basically the underlying library which creates the SS v SS format for uh the CL client. This SSD structure is probably going to be different for uh this demo zero. So this fork has to be created and in order to support the different uh val key structure we going to need to have a different uh fork of the E2 val tools. So E2 val tools is the one that generates the current uh private and public keys uh the BLS keys for uh all the different CL validator clients.

Ideally, we need to figure out how long does it take to create this postquantum uh signature. Whether we want to generate all the validator keys in advance and shove it in the S3 bucket and pull it on demand or we want to uh generate them on demand with uh curtosis. Uh we can come back to this later. And then lastly, we probably want to maintain a fork of uh the Ethereum package which will uh give us support to test all these clients locally on your local machine.

But yeah, if if you want to have visibility, uh we probably also need to have a fork of Dora. Uh this is a go project. Uh likew explorer can probably uh have a fork of this and uh yeah the whole world infrastructure is going to be different uh post quantum. So it might be quite some work to get Dora up and running. We might just have to use the promeus metrics for initial uh devet zero and maybe have dora support for a later net. But all the other ones would be a prerequisite uh in order to get them a zero up.

Regarding the open questions uh mainly the validator key generation whether we want to do this in advance or on the fly. Would anyone have experience in generating these uh valator keys with this new library? How long does it take to generate one? and how big the key is and how long would it take to uh to generate 20,000 locally on the machine and how big they are >> any takers I mean I I don't know for sure but uh I

think the longer it takes well it it all depends on how long we're going to run uh the curtis chain basically if it's a just few minutes we don't need to spend a lot of time generating the keys right then it's done on the >> so the size of the keys is about 50 bytes if I'm not wrong so it's like uh one merkel root plus some five field elements maybe. So it's like yeah 50 bytes.

>> Okay. So it's a tiny file but how long does it take to generate the key if you want to have time of >> order of hours to generate one key? >> Four to five hours >> in the order of hours. I'm not sure it's >> order of hours. Okay. Okay. But also I mean that you are flexible. If you generate the keys uh you don't have to go to the maximum lifetime which is 2 to the 32. If you do that then it will take you not hours but days. If we all agree that we do two to the 18 then I suspect you can do it in uh a few minutes but I would have to rerun the benchmarks again. And if you want to have like one hour runtime because for crytosis it

doesn't really make sense to run more than an hour then it could be done >> one hour to generate one key or to >> no no one hour runtime not 10 days but even less slots >> for single key >> uh yeah I can I can check that but >> do we have a tool for this like the key generation tool we have like a docker container for it so we can like start playing run with it. >> No, I mean there's a a Rust library. That's all we have. >> Rust library. Okay.

>> But I can check the the key generation time. >> Yeah, it would be nice to have some metrics. >> Yeah, Benedict, maybe you know out of your head like we just need if if we need to run an chain just for an hour. So it's just uh every 4 seconds it means 900 slots. If we just need the key for 900 slots, like how long it takes to generate such key? >> Well, that will be extremely fast. If you just want 900 slots, that's not even two to the 10. So, yeah, >> I mean, if you I have some old numbers and numbers should be better than that.

Uh so for that lifetime two to the 18, so that's already much more than 900 slots. That should be uh 200 270 seconds maybe. Yeah, that's a few minutes. So, >> can it be paralyzed? Can we generate >> it is it is already parallelized. >> No, but you're talking about one key. What What if I want to create one million keys to >> Of course, you can you can do that independently, but already generating one key is already internally parallelized.

>> Okay. Okay. So in theory it should take uh the same amount of time if you generate 10 keys if you have enough of course. >> Oh sorry I that number that I gave you was for a different hash function. So let me revisit that. Yeah still three 330 seconds for a single key but that's old numbers. So right now it should be uh even faster for lifetime 2 to the 18 because we improved the code since since then. Um yeah so I can I can give you more accurate numbers after the meeting. You can just pin me.

>> Yeah. So ideally what we want is we want to have a new validator uh key generator where we can set what kind of lifetime we expect uh cuto system to have and then we can probably generate them on demand. And if it's really just takes a sub one second to generate it for like 900 slots, it makes sense to just have a new key generated for each run. And then for larger DevNet like DevNet zero when we're talking about longer lifetime, uh it probably going to make sense to have a beefy machine. Uh we're going to be pre-generating all the keys. We're going to shove it into an S3 bucket and we're going to be calling uh we're going to be basically pulling the valer keys on

demand when we spin up DevNet zero and we don't then have to wait uh multiple hours to generate these longer lifetime keys. >> And Barnam is just to be clear this is not work that Pandops has the bandwidth to do. We're looking to assign that to this group. Yes. Uh so currently our primary focus is on uh Futaka work. Uh we can do uh basically no work uh before we can ship Fusaka and we're going to have best effort after Fusaka >> but yeah feel feel free to uh you know fork any of their repos uh and ask for input and then we're going to try to get

back to you. Um, Camille in the chat, the Telegram chat just prior to the call, you'd mentioned, you know, maybe joining the party with uh building a client implementation. Um just curious like hearing this I don't know like I'm just kind of thinking on my feet but would would you be in a position to help set up some of this like overarching infrastructure uh in lie of doing that and then or would you or would we prefer to have a third client implementation and kind of disperse this uh this work amongst everyone?

Uh yeah, you mean uh this kind of infrastructure? You mean curtosis and all of that stuff or? >> Yeah, curtosis, Dora, the signature generation or all of the things that we're going to need. Um basically to be able to bootstrap the first DevNet. >> Uh I don't know. I never touched the COS, so I need to check it out. >> Sure. Sure. >> Uh by the way, curtosis would be like step five. And that is the part where I can actually help quite a bit on uh all the other like the underlying libraries and all the prerequisites would be the main heavy lifting here.

>> Am I to genesis generator? I I think uh I and the game has uh some experience in dealing with that and uh maybe we can sort of take a look into it uh and come back whether we can support it. uh but I think uh coming back to the logistics of key generation uh what I suggest is that we have that as a separate step which is not really integrated because uh then for example somebody in the chat noted that we can maybe try to use the same uh generated keys over and over again for local testing and I think that is a very good idea because we wouldn't want to wait minutes for a local devet to start

up it would get frustrating So in that sense, I think it would make sense to sort of separate it out as a two-part process where the key generation happens prior to the genesis generation and and the genesis generator can just use uh the generated keys and the generated keys config to generate the genesis and uh those generated keys can also be easily distributed among the validators or validators. validators can just pick and choose and this would also tie very well into uh the long 10day long running devet where uh we would just uh generate the keys and pull them uh from the buckets. So uh so I think uh >> just to to chime in here the I just

rerend the benchmarks for the most up-to-date code and for generating two to the 10 keys because you said 900 slots it took like two seconds to generate one key, >> right? But we would probably want to uh run around 120 to 250 keys at least. Then you just take that number and multiply it by that. >> Right? But that's the question like how paralyzable is it to generate 200? Like how long does it take to generate 200 keys parallel?

>> I mean the key generation is internally parallelized. So I'm not sure how much you would gain from just from parallelizing over the different keys. >> Right? That's that's the main question here. Uh I think because if it's you know 2 minutes uh that's too much. If it's 20 seconds, that's too much. If it's two seconds, then that's something we can deal with. Uh I think anything over two to five seconds is too much. >> But I mean, if we if we at any point go to realistic lifetimes, then it will for sure be much more than that. Like >> with these schemes, you for realistic times, you expect like hours of of key

generation, >> right? And for that we can always use the pre-generated keys. >> I see. >> I'm I'm I'm just saying that fetching on a cruis's network fetching a file from remote might take longer than generating it locally. Then at that point we might as well generate it locally and that is going to allow us to also work offline. uh like right now one of our main selling point is that we can basically run a whole crytosis enclave offline. We don't rely on any external dependency.

We don't rely on the internet. So ideally we want to keep it that way especially if it's uh fast enough. >> And and this is why I think we need an independent tool that does the key generation where we basically take uh two or three inputs. One is going to be how many keys we want. The second one is going to be uh what kind of lifetime we expect and the third one could be like where do we want to store the key files and that's it. >> Okay. I guess that can be created just from the the library. I mean the key gen function already has this >> yeah exactly parameters.

>> Yeah. So just have a have a library for it. add a docker file and add that tool to our image builder and then you're going to have a pendops post quantum key generation tool and then from that point on we can integrate that into all the other uh testing stack as well. One thing worth noting is that um if you pre-generate the keys, um you can have the the public key be pre-generated and all of the private stuff can be subsumed to just your your your seed and then you can basically regenerate it in in in real time. So, you know, it's not >> true. I mean you can generate the actual

secret stuff but the stuff that you need to sign fast you should not like you cannot generating that would take as long as generating the key in the first place. So I would not throw that away. I would store that. >> Well you can store basically maybe >> uh a layer that's halfway through and then that's like square root of size or something like that. >> Yeah. my on my right. How big is the >> In practice, I would just store the entire key. >> How big is this key for one? >> The whole thing.

>> That again depends on your lifetime, right? >> Oh, the lifetime. Yeah. Yeah. So like one to uh two to the 18. >> Yeah. Times something. >> Okay. >> It's a it's a an entire mercle tree of with two to the 18 leaves. >> So it could be actually gigabytes of data. Yeah, for sure. For sure. >> Yeah. >> I mean, you can throw it away, but then signing is incredibly slow. So, and I guess we want signing fast. >> Yeah. So, this is where the the square root idea comes in. You only store let's say 100 kilobytes and uh and that's enough data and you can still sign every

block by computing a little bit locally. Is it such a problem if the secret key is that big? Why do we care? I mean, validated space anyway, right? >> No, but like if you run up a a for example local network and you need to fetch each time you run something, you need to fetch 500 GB of uh data, then that's going to be a while. Like sure we can do it one off but I'm I'm thinking here local test on your home network for example you want to run 500 validators you're going to need to

fetch 500 GB that's >> that's significant >> okay great I will do my best at sympathy izing this conversation into like a preliminary like DevNet readiness plan of things that need to be accomplished and try to socialize that so that we can get people to volunteer for who's going to take what and try to assign some time to this and see what sort of impact you know this is going to have on the

overall schedule. We've got um you know a lot of people are gathering in October for a small interrupt and we've got about seven weeks from now until then. So I still think goal is to like get the get this uh infrastructure in place and have already done a single DevNet prior to that uh that gathering if possible. So I will try to get this pulled together here in the uh immediate future and then we've got 12 minutes left on the call. O I will drop uh the links that you

had on the comment the two PRs that you wanted to talk about if there's anything here that you want to call attention to. Oh yeah. Uh maybe quick update from our discussion last interrupt. Um I think >> I think Yom mentioned that Zam uh was using um union for the optional fields on the SSSE but uh I think I looked into like seam implementation and looks like you're also using zero hashes instead of the optionals. Um so would love confirmation there. And if you're using zero hashes, I think that's great because because uh we is doing that too and it's a lot a lot less complex to

implement. >> Yeah, we are also using zero hashes uh on that. Uh basically we had a discussion on this and uh sort of got clarity on what exactly you were asking. Uh so uh but uh with regard to uh your uh PR for containers I can we sort of have that MD file like we have in uh in the moon consensus specs and basically go start uh the container definition from there. Uh and uh yes uh right now I think uh you are uh basically we have some comments over there but we can do

with uh we can do on the PR once we have MD uh container definition file because uh uh commenting just on uh the Python code doesn't seem appropriate for the discussion. Uh yeah, definitely I can I can do the MD file. Um but maybe a question to Philipe. Um do you have any thoughts on that? Cuz I think you you wanted the specs to be in in Python and follows your framework, right? The specs framework.

>> Yeah. Um, I don't have a whole lot of context on how we want to organize this. I think we need to make a decision um, kind of as a group. Um, I kind of came in just to make sure we're using all the uh, same tooling across the specs, but I'm sort of new to how we want to organize it as well. So, something we need to discuss together, I think. >> Okay, cool. Mixes. Um I think like uh in that case I I'll I'll create the markdown files and for re and zam we can agree on the markdown files and once we agree on the

the specs um happy to try out into put it into like Philipp um frameworks but yeah let's I I'll sort out the the markdown files. Yeah, I did make a comment this morning on there. Um, and I, uh, yeah, I I reached out to you, Tomas, um, just to see if you had any opinion there. But if we could move them out of where the Python is and maybe into docs for now, and we can think about how to organize it, uh, beyond that as well.

Great. Um, >> yeah. >> I was just going to throw it back to you if you want to discuss those PRs. >> So, so I'll I'll get back to the PRs. um turn the code into markdown files and then I'll I'll let everyone know in the interop group. Great in the chat let us last dropped the note as far as I know we discussed minimum thousand validator dev nets in can given the key generation constraints should we consider lowering that number to low hundreds China I guess we could start with 100 at

least initially Does it matter when you could have 10? I don't think the number matters much as much as like just getting the basic steps out of the way figured out. Changing one or 10 or 100 doesn't really matter. Yeah, I think once we have all the tooling in place, uh, we can easily sort of experiment with this and scale it. >> Sounds good.

Um, in the remaining time, did anyone else have anything else that did anyone have anything else that they would like to discuss? Okay, great. I will, like I said, work work to a synthesized notes and a first draft of a readiness plan. I'll probably run that by you, Barnabas, and maybe Gadin and O first and then just open it as a PR so that everyone can comment on it and get a sense of who's going to who's going to take what.

All right. Thank you all. Talk to you soon. Thanks. Well, you will. Thanks everyone. See you guys. Bye. Bye.