Post-Quantum Interop Call #1

Transcript

All right. So, this is exciting. Glad to have this first call. Um Yeah, as I noted and you know, this is kind of like coming together uh bootstrapping this first uh call, but really the plan will be to migrate this to uh a public call on the protocol calendar moving forward. You know, we just wanted to make sure that we and right-size the meeting uh align on some objectives and artifacts. Excuse me.

And so, I went through and Pardon me. Uh pulled together a bunch of different resources. Uh this is all in the document that's attached to the invite. So, there's some resources here. Happy to add to it. Trying to document like who's going to be contributing to this effort. And really the goal is to use this call to first talk about the different proposals that were put out uh by the Beam team and the Rain team.

Discuss any uh takeaways from Beam Day and then hopefully try to converge on a on a shared uh work plan uh that we want to then socialize and and have be the the framework for what we do move moving forward. I'm going to pause for a moment, clear my throat. Okay. So, I you know, if maybe Gazender or uh O, if one of you wants to like kind of start us off by walking us through your proposal, I can pull it up and share my screen and uh

talk through it. >> Yep, sounds good. Maybe Jim can go, I guess. Yeah. >> Yeah, please go ahead. >> All right. So, you already clicked on the meme. So, the point is so meme is the main thing. This is a meme led development. And the meme says that we will not work in silos. We will collab. And Devnet is the right way to collab as we have already seen uh in the beacon development roadmap how various teams comes together and

they collab on the spec. They figure out. They try to run uh uh they test the the test are released on the spec. They everywhere tries to make sure that uh they are they can pass the test and then they try to interop where other issues are discovered. And the spec gets simplified. And this is what we are hoping from this particular series. And the aim of this series is uh uh to accelerate uh the post-quantum signature schemes that Beam {slash} Lean consensus is trying uh to basically position as the end end game uh for Ethereum

consensus because we know that quantum computers uh the development of that has really accelerated and uh it's basically high time to uh you know, iterate and to implement and to make and to prove that we have a scheme that works. And so that whether it uh whether it's implemented as a Beam Beam hard fork or it's just uh uh absorbed by the normal Beam uh research and development, it's a win-win for us in both of the scenarios. So, again, the aim of this devnet series that we are here for and

is to prove that the PQ the post quantum signatures work to achieve interop and aspect consensus to accelerate research and to provide basically a test bed for P2P research that we think will be required in in the in in sort of the larger signatures that we have and the kind of validator set that we are trying to target. So, and then the bonus outcomes would be to sort of build the tools around around this. And what we want is that we want to set a target for ourselves, which is like,

okay, you know, we have a stable month-long running uh devnet by the next beam day, and then and then we work backwards from over there and figure out the time the milestones that we need need to cover to make sure that happens. so basically, you know, this is a very simple devnet series as such because we are only targeting uh uh targeting that, you know, the post quantum signatures and uh to begin with, and then on a later stage we will also we should also be targeting aggregation of those signatures.

Um So, Will, if you can scroll down. So, so the scheme uh so there have been many papers published on the scheme and uh I think there will be another paper published on the actual parameters, which might be 64 hash chains with a chain length of eight. Basically, the aim is to minimize uh uh the signature very uh the signature very generation or verification hashes uh so that, you know, uh the prover and the verification uh when we do for signature aggregation, that is quite easy.

And uh the lifetime of so these are one-time signatures and then they are sort of uh they are created in in a multi uh they are they are uh so XMSS base scheme is applied on top of that to sort of make sure that uh uh you can sign multiple times and then there is the question of lifetime of the signature and for most of the series uh of this Devnet series, we think that we'll have a low low lifetime because, you know, we want to iterate fast and there is no point trying to have a tool which takes quite a large amount of time to generate the signatures because that is something I think is not contentious

that we can generate the signatures for a longer life lifetime. So, uh I think that maybe we should have a short lifetime to begin with and eventually go for a month long lifetime. And if we feel that since imperative that we show that, okay, you know, we can even work with signatures for like 500 years lifetime, we'll we might go for that. And uh again, as uh for the sig aggregation, uh we are starting off with unaggregated and we'll add them as and when aggregation library will be ready.

Uh on terms of uh blockchain, what Zim is proposing is uh minimum viable blockchain, which basically means that there should be parent uh child linkages and it's quite easy, actually. It's not really difficult to track uh latest block header in the state and sort of uh do that validation in the state transition function. So, I think it's it's basically, you know, it's very low-hanging fruit that we should just have it. And uh with regard to justification and finalization, we are proposing mini 3SF uh variant that we have implemented uh because I'm saying the same variant over here because we did some changes to make

sure that uh you know, we there is some special processing for the first uh block to make sure that the genesis is slot zero itself. Uh and uh so, I mean, all these are very slight modifications, and then there is translation of the various structures into uh SSZ containers. Uh so, so, it's not really difficult uh to map those things, and I think, you know, it doesn't really matter how we do that. So, I I don't think that it's going to be contentious in terms of uh how we map mini 3SF uh uh onto our implementations. So, uh for networking, uh

uh we I think there there needs to be a block by root request response apart from block and attestation gossip. So, we might just start with uh gossip so 1.2, and then iterate on gossip strategies. Uh but, I think we also need block by root uh if not block by range because block by root, for example, you got a gossip, but you missed the parent uh parent block, and then uh it will sort of become a deadlock scenario if you don't have uh block by root. So, uh if you have block by root, basically, you know, as long as you are not syncing you are not syncing from Genesis on a

very long chain block by root should be sufficient to sort of handle any syncing scenarios that we might encounter and we will encounter it because there is going to be variability and some sort of you know error misses and all that in particular in the devnets uh especially when we are starting something new. So this is a particular thing that I think we should require. Uh regarding using quick most likely we are okay with quick because we will be either using rust libp2p uh or we'll be uh using zig libp2p

uh bindings over some C library but uh this sort of remains to be seen and we are sort of trying to figure this out. Uh so without doing an actual experiment with the rust libp2p library integration I will not try to I don't want to commit over this but I think we can figure this out it it doesn't we will be able to uh uh figure this out whether we can do it over quick or we'll go with the Amox. Uh and other basic handshake mechanisms we might require for networking like ping metadata status uh all of these are quite simple in our uh in our viewpoint and uh should be okay to implement as a very basic needs

of our client and uh for encoding uh encoding for uh gossip and uh for request response uh we will basically go with snappy and snappy frames same as what is done on beacon chain. For other other basic functionality I think that we require is checkpoint sync uh from the last finalized because uh we don't we don't really uh care to support checkpoint sync from any any other checkpoint. And uh last finalize is good enough uh because then we have uh uh block by root that can help us sync post uh post the finalize. So, once if

we once we have checkpoint sync from last finalize and then we have uh block by root request response, uh then uh we are basically sort of sorted in terms of any syncing issues that we might encounter. Uh with regard to slot duration, I don't uh we uh are recommending to go with 4 second because this is uh what we want to target eventually. And uh I don't basically see a point where we should start with 12 second. We don't have any of the baggage that beacon chain has. And uh with respect to that, you know, we don't even have aggregation to start off with. And uh signature uh

we estimate that uh generating a signature and its verification could be very fast. Uh so, with regard to that, I don't see a reason to have a longer slot time. And uh we are uh again recommending SSZ with Poseidon 2 for consensus for encoding the consensus objects. Uh I think that is sort of uh no no no-brainer {slash} non-contentious proposal and uh most likely it is it has a widespread support.

Uh coming to uh the success criteria uh that uh we basically propose a 98% for any iteration, uh we propose a 98% average attestation correctness over devnet lifetime. Uh so, whatever whether the devnet lifetime is 10 days or it's a month. So, we propose that uh once we have this average attestation correctness, we basically say that, "Okay, this particular iteration of the spec works, and we can now try to scale it up, and for example, starting off with 10,000 validators uh two and 10x'ing on each of the iteration and going up to 1 million validators.

and if we can uh also basically inject adversarial actors that generate bad signatures or there are or try to generate signature collisions, uh I think that would be a bonus step. Uh censoring aggregators or uh since aggregation is uh uh is a is a sort of a ZK uh proof ZK verification, so I I I So, I'm not sure whether this is possible or not, uh because the instruction set would be quite limited, but can we have uh signature

uh killers in terms of prover killers? Uh this is something I think uh food for thought, and I'm not sure uh how much of this is the concern, but I'm just throwing it out so that everything is covered. So, these these are So, these are the adversarial actors that we think that, you know, we we should think of surviving uh in any particular devnet iteration, and and it is a bonus thing. So, we don't need to begin with this. We can just add it at later mature stages of the devnet.

Uh but if somebody has to work on sort of making these advert adversarial actors, they can start thinking about it. Uh for us, the next steps would be to finalize the signature params. Uh most likely, they are going to be what we have proposed and what what Rim has also proposed. So, so then what it really means is that having the releases of the signature libraries with those parameters and then having the binding slash API into that.

And once we have that, then basically we can sort of start experimenting at the client level and in the meantime we can also generate sort of generate the spec for Beam Chain slash lean consensus of the basic functionality that we want in terms of state transition function and in terms of fork choice because once we have these two locked down, basically we have locked down that the the more basic functionality of how we are expecting this devnet chain to

behave. And then I think we will need some iterations over coming to consensus over basic networking for different points that I raised, but again I don't see it as a major contentious issue. So that so I assume that we will reach consensus over there very fast as well. And then going by how the devnet is done on beacon chain, we should have sort of our first iteration spec.

And then we can on the basis of that we can have ETA and implementation ETA. and basically, you know, if we have all these things, what we basically then need is a genesis generator, which basically takes number of validators and lifetime and sort of generates the genesis state as well as public private key for the validators. So, this basically sorts of covers various points that we need to make sure that we can kickstart such a series.

Yeah. And I think yeah, that sort of covers most of the points from theme. >> Fantastic. >> Fantastic. Um O, do you want to go through the ream one and then kind of go over any all any overall questions or do people want to pause here and ask questions? >> Yeah, I I think it'd be nice to do a Q&A when when like things are still fresh. I do have a couple of questions myself actually. Maybe maybe I'll I'll start with the questions.

>> Yeah. >> Sure. >> So so I guess I I my personal view first because we haven't really talked to the team based on themes point of view yet. So um this is my personal correct questions and opinions. Um I think 3SF is definitely interesting. I think we discussed that in the team but we are not so sure how like we we have the rust implementation based out of Vitalik's prototype but that's basically without any like networking. It's only simulating in in one process right? So I guess I at least my concern is I'm not so sure how much effort that would be to actually turn that into an actual client implementation that you can run in in in a in a network setting.

So that's one. Um the second thing is I think we yeah we didn't put down anything about like signature killers. I think like introducing bad signatures would be would be interesting to you in that sense. Um Uh I guess it's probably not difficult as well to introduce uh you know, a few clients that randomly produce like invalid signature from time to time. So, those are the two things. I do have some questions. Um So, first thing is the 10,000 validators.

Um so, I guess like our like the estimate of the current actual nodes right now on the Ethereum mainnet is around 8,000. So, I wonder whether like 10,000 validators might be a stretch and also um I guess like the effort to to to set up like a 10,000 validator um network that could be quite challenging or or not trivial. Just something like >> Right. So, I'll sort of go one by one. And uh so, first talking about mini 3 SF, I think uh in any case, you will sort of need to generate an attestation and vote.

Uh so, doing it over networking is not really difficult in the sense that you will basically serialize the data and just publish it and the others will get it deserialized and sort of import import it into your fork choice. Uh I don't I don't see any challenge with regard to that. Uh and when you are just packing in it in the block, uh again, you know, it's it's it's basically uh SSZ that does all the magic. So, I I don't actually see any challenge over there, but uh we can definitely, you know, talk uh talk about this offline uh of any concerns that you think uh can come up.

Uh from our estimation from our uh development that we did, we have sort of integrated. It's not really a standalone library with us. We integrated it as part of the Zink client and uh so so so the thing that you will deviate most will be when you will try to, uh, you know, s- uh, do the fork choice of your blocks, right? Because uh, the way uh, for example, Vitalik's, uh, uh, implementation is, is not the way how fork choice is, for example, implemented in the beacon chain, but it's sort of essentially the same thing.

You you are trying to uh, have, uh, view of the latest votes and then you are just applying it, right? So, you are making the changes. You are removing the weight of the previous votes and then applying a new vote. So, you have sort of a vote tracker that says that, "Okay, you know, this particular validator voted at this particular block previously." And now you have a new latest vote coming in, so you will just apply those changes, uh, when, for example, you're trying to find a new head on a new slot. Uh, so, so with regard to that, I think you can look as look at our implementation, uh, and basically, you know, we can discuss it and sort of, uh, figure this out together. So, I I don't see any issue. I think we will be able

to figure it out. Uh, second thing was regarding to 10,000 validators. I mean, uh, when I see 10,000 validators, I don't mean 10,000 nodes. Uh, what I mean is 10,000 keys because uh, because even if you have 10,000 keys, it will be, uh, for example, uh, you know, your genesis generator will have to work that hard and uh, will have to sort of generate all those keys with this particular lifetime. And then you have the votes coming in that will generate traffic on the network. Uh, so, we will try to see how much we can, how many nodes we can actually have on the network and sort of,

but in any devnet, we don't have that many nodes, that is for sure. But maybe this will give us some insight into what is the kind of traffic that is being generated. And going to 1 million validators is again for uh for the same reason. Again, I hear mean the keys uh because we want to see what is the kind of traffic that will be generated and uh how to uh optimize gossip sub to handle it the best, right? So, uh we have So, the aim of this signature testnet is okay, first prove uh PQC signatures work and then basically to aid in the uh in the research uh to make these uh these signatures viable at scale uh

for for Ethereum. So, with regard to that, we we'll basically need to scale up the validator keys and basically say that okay, you know, uh this is how we'll handle the traffic because uh we are trying to keep our chain length small. That means the signature size is going to be big. And that basically uh is a critical difference that we have and when we have aggregation also thrown into mix. So, uh so, once we have the basic signatures working without aggregation, we should throw aggregation into the mix as soon as we have the aggregation ready.

With regard to signature killers also, uh I think bad signatures is doing bad signatures is the easy thing as you have mentioned. But uh when I was mentioning about signature killers, I was mentioning about aggregation killers. And that is something that I'm not sure whether they can even exist because the instruction set is quite small over here uh that the signature prover will need to generate proof on to sort of aggregate it. Uh but I sort of leave this open question to the uh cryptography and research teams to answer whether this is actual problem or not. So, as of now, I'm not sure.

And what was the last thing? >> I I think that that was it. Uh I I do have one more question, though, um on the attestation correctness. Like, what do you mean by the correctness? Like, is it like all validators receive the attestation and validate correctly, or um yeah, what what's uh to calculate that in your mind? >> Right. So, so when, for example, you are voting on uh beacon chain, right? So, you are voting on source, you are voting target, and you are voting on the head, right?

uh so these thing three things is basically So, if your head is correct, uh basically, which is what is matching with everyone else, then other things are correct. But, it could also be that, for example, you you your inclusion is also delayed, right? So, we have all those parameters where we basically figure out that what is the effectiveness of a particular validator, right? Attestation. And that is something that we should take the same target because that is where the That is how the rewards are distributed to the validators. And that is something that is relevant to everyone who wants to stake. Uh and is uh

is a benchmark that is quite important. So, so we will basically define what the correctness is directly or as it is defined on on the beacon chain, and we'll basically sort of track it and figure it out. Which having 98% of that correctness means that most of the validators are able to follow the chain and are able to sort of correctly vote onto the chain at the correct time. So, this is what it really means, and uh having 98% correctness means that, okay, you know, it was a successful devnet. I think with regard to devnet we can even say that maybe even 80% average is uh average is good enough. But here

we want to establish uh other things that okay, you know, you can uh you can sign it on time, you can aggregate it on time, you can publish it on time, right? So, there are so many factors involved and keeping a high bar to as a success criteria will sort of expose various challenges that are uh underlying in that in this particular devnet and uh that is what we hope that we will discover and will be able to iterate and fix it. >> Excellent.

oh, do you want to oh, Camille, you have a question? Uh yeah, everyone. Just uh also had some thoughts about this proposal. Yeah, I actually I'm I'm more like idea of having maybe less validators also because uh as far as I remember uh during beam day uh there were discussions that uh yeah, we kind of first uh trying to test uh just one subnet even if we currently doing this without aggregations. Uh if we have for example not 10,000 validators but maybe 1,000 validators, this would kind of give us uh room for um uh for validators to kind of optionally enable aggregation even if

they do not publish their final snarks uh to the network. Uh still it would be great for them to kind of have this and just check like how long it takes for them to um generate this aggregation, maybe then share to some public telemetry like hey, I generated a snark. This took so this this this period of time. Uh and so on. And if we have like 10,000 validators, this would be kind of complicated to do because current expected uh aggregation rate for signatures is around 1,000 signatures per second.

Uh that's and with 10,000 validators, this would take like 10 seconds. So, with 4 seconds slot, this kind of uh this this is too much. Um so, yeah. And and and it's just in general more easier for us to um and yeah, if we have 1,000 validators, uh this would kind of give us more insights of what we can expect in future if we have uh subnets we and each subnet would be size of 1,000 validators or so. So, yeah, more fun of like having maybe around 1,000 validators. Uh for for the testnet.

yeah, another thing about quick quick would yeah, it's great to have it, but it's kind of uh would this would give us kind of a a more optimistic picture of what we actually have. Uh quick is better than TCP for many things, for streaming, for kind of delivering messages faster and so on. Um but yeah, we should kind of maybe optimize for for the most pessimistic case. I mean, kind of expect that if we know like how long our uh consensus aggregation works or like distributing signatures among the uh peers works with TCP, this would kind of

give us pessimistic picture which we can then know that we can optimize using quick. And if we just go with quick directly, then it would be harder to kind of estimate what we can expect if we have TCP. Um so, yeah, I would go maybe with TCP first and then try out quick at some point. Um yeah. And uh yeah, and yeah, that's just my two two points that were once out. Thanks. >> Thanks, Kamil.

Okay, let me just uh yeah. Uh so, I think yeah, it makes sense so that, you know, we start off with 1,000 validators so that, you know, we can have a behavior uh so that what to expect from a particular subnet. So, but yeah, we can again follow the same process of 10Xing uh that uh again. And for quick, yeah, I would sort of uh delegate this to uh experts like you and others that, you know, what is the best protocol to follow over here for sure.

>> Great. Uh any other questions on this proposal? If not, oh, you want to walk us through yours? >> Uh yep, sure. Here are the >> the ream levels. >> Um maybe can I can I share just my screen? >> Let's do it. >> Okay.

Um yeah, so for us, this is our view. Basically, um well, we we treat this view as sort of like a recap of what was discussed um in its like entirety during Beam Day. So, it contains both like our like opinions, but also the the kind of collective opinions from from the day as well. Um so, and by no means um that we think that this document is definitive. Uh we hope like this is uh like a good starting point to formalize a plan. Um happy to, you know, um happy would be would be happy if this gets used as a starting template, but also happy if you know some parts of it get dropped, get edited and so on. Um whatever makes sense the most for for the entire

collective to move forward with the devnet. Um so a few things that I can mention. So first of all, um like we think like it's a devnet um test that is probably a bit misleading because I think to you know to be a testnet the the features should be more complete. I think this is more of like a you know one-off potentially a lot of like throwaway things that we're going to use here for the first devnet and then and so on and so on for the next uh the subsequent ones. Um so we think a devnet is probably the more appropriate name for this. Um some of our views in Korea we favor multiple iterations of incomplete devnets over waiting to build a complete testnet. Um we think our first inaugural devnet is

probably more like apart from like validating PQ signatures. Um I think it's going to be a lot of like lessons to be learned on you know how the lean consistent effort overall can be coordinated um both between the client teams but also like with the researchers. Um we think the devnet is probably not intended for public use. Um maybe the infrastructure is not even accessible by the public. the features should be limited. Like we prefer to time box it and complete it by the end of this year um potentially before devconnect so we have some uh demos to show and also some resource that we can show uh at devconnect as well. And also in

order to kind of like speed this uh complete this quickly so that we can take the knowledge and lessons learned from here um to to do a fresh start in in next year. Um I think the critical questions that we need to answer in the first few calls are the objective of this this devnet. Um we discussed in the team and I think like we actually kind of like um going to be going over a few steps in order to get this definite like multi-client definite up. So, I think it's important to be able to answer both to ourselves and also like to the wider community that why does definite actually exist and why does it need to be like, you know, multi-client interop setting. Um, if most of the stuff that we are or if all of the stuff that we

are going to be doing can be done, you know, under a single client or under a single client um um definite, then um then that also kind of compromise our uh legitimacy, I guess, for for for building this multi-client definite as well. Um, the second thing that we need to confirm is the timeline. Um, again like I think we we can aim for for end of the this year. Um, and third thing is who needs to be involved. Like right now we know that Seam is fully committed, Ream is fully committed, but we need other key persons as well, uh namely the PQ signature researchers who

uh hopefully like could provide us a sub spec so we can implement on and also networking and also I guess the big question mark is are there any other client teams, either new or existing ones, that would like to participate. Um, we should uh include them as soon as possible so they they they get involved early. Um, so those are our general views. Um, then I can go through the our detailed uh plans. Maybe I'll I'll just like glance it over cuz uh for the sake of Um, we broke down the objectives into primary objectives and secondary. So, basically primary ones are the ones that we should complete, we definitely should complete, and the secondary ones are you know more of like good to haves, but you

know, these are the things that if we're able to include them as part of this definite, then uh we we are able to to get a lot of benefits up. Um primary objectives, you know, approve PQ signature viability, validate our multi-client interoperability. I think this is also important where um each of the subspecs I believe are being developed in like independent from each other. So, this is probably like the first time that we are we are combining the different subspecs and also um combining the two clients. So, uh there is going to be a lot of gaps that um hopefully we if we can discover uh within this devnet, that's going to make our lives for the consequent subsequent devnets and and testnets a lot easier.

Uh validate resource requirements. We talked about this during the during the Beam Day that I think we can keep the specs at uh EIP 7870. Um so, we need to validate that whether that's feasible or not. And then obviously the the vital specification gaps of what actually are missing uh in the subspecs for us to actually implement um the the clients. Um secondary objectives include um establish common metrics. I think we talked a lot about like performance. So, for this devnet, I think um being able to kind of come up with like at least like a temporary standards on how do you want to measure things and at what points and being able to actually um

share that into a common infrastructure where we can analyze at the whole as a whole. Um that's going to be very important. Um again, multi-client coordination protocols. Um you know, good have implementation challenges from just implementing say PQ signature, 3SF, key generation, and so on. That's going to be helpful for both our teams right now, um new teams and also existing teams, existing beacon client teams as well. Um reusable testing infrastructure. I'm not so sure if we are able we are going to be able to achieve this, but if we can or if we can reuse it uh somehow for the subsequent devnets, that's going to be uh useful as well, but these are secondary.

Um target features, I think we are pretty much um um on par with Zeam. Uh 64 hash chain, chain length of eight, uh max lifetime of 2 to the power 18. I think these are basically the numbers that we kind of like generally agree upon from the Beam day. Um signature aggregation, um no signature aggregation, but I think mostly it's because I think the the the readiness of the aggregation suspects there. Um so we should exclude it for for now until we we see clearer suspects.

Um there are types and containers that we need to agree upon, but I think we can skip this for now. I guess like our view that is different from Zeam so far is um the the block um that we we don't include the parent root inside uh the the the child block here. Um this is basically based out of the discussion during the Beam day as well that I think there's going to be complications with like, you know, block syncing and missing blocks and we have to to to get um all the validators up to speed on that. So um avoiding that actually helps a lot things.

Uh for example, not having to implement the APIs for uh block by root and so on. So this simplifies a lot. Um attestation uh is pretty much the same side attester index signature. Um serialization and hashing uh use the SSC that's being used in the beacon client. I know that there are some improvement proposals to SSC, but for the sake of, you know, focusing on like PQ uh devnet, I think serialization we should use something that's like already, you know, tried and true, uh which is SSC. Hashing definitely needs to use uh Poseidon.

consensus. Um so this is also where we differ and I think it's also based on the conversation on beam day that that we we haven't really like decided on what consensus. So we think maybe just like go with no consensus, you know, just sign the blocks. Um propagated or tested block propagated and everyone saves their their their view of the world. That that could be enough and then the the but the only hard thing is that we we don't have a single view of of the chain, right? So the only way to actually verify the chain is is progressing correctly and everyone has the same view is probably by this way is probably having to to go inside each of the validator and actually compare whether you know,

they are actually receiving all the attestations and receiving all the blocks or you know, what what is this is being missed. Um networking quick on IPv4. Thanks for coming for the suggestion. So this is basically based on the assumption that even the beacon clients are moving to quick right now. So if if And I think the the rate right now is probably around like 68 to 70% that are already supporting quick and I think TCP YMAX is is being deprecated soon. So we see no reason to actually try out with TCP at this point.

Um gossip sub we didn't put down a version before but my assumption is that we we want to go with like V1.1 which is what the beacon client is actually using. Like V1.2 I'll need to talk in the team whether whether that's a lot of work to to actually to actually implement. Um success criteria we are a bit um I'll say like more not as aggressive as as team. So we put down you know, if we have like two client implementations the network is able to finalize at least 300 blocks.

So for two clients that's roughly about like one at least like running for 1 hour without like crashing the entire chain. Full block pipeline should finish within 6 seconds seconds and this is like not a a hard criteria. This is basically you know once we we run the chain we have all the telemetries and then we analyze them all the blocks should be done within 6 seconds. Block proposal I think this based on Justin's information in the beam car each block is signed within 1 second probably within 1 second attestation same thing 1 second 1 second.

But yeah the important thing is we are not only measuring just the success of the chain that the chain is is proposing and testing. I think the most important thing potentially most important of all is actually getting all the metrics for for for actually running each block and proposing and attesting each block. These things are pretty straightforward. These are just like project management stuff that there are actually a few steps before we can actually set up the devnet itself. For example the paper like the sub specs have to be published reference implementation published the specs for the devnet itself has to reach consensus with at least you know

say two clients or or more. The clients should already implement the devnet specs and passing with if we are going to to have some reference test which I think from the lessons learned from beacon client having reference test before we actually initiate the devnet is very useful to everyone and and saves everyone a lot of time and only after we are able to complete all this then we actually set up and and try out the the devnet.

Instrumentation instrumentation and metrics I think these are pretty straightforward. Most of them are actually kind of like copy pasted from from beacon client even um, but there are some some new stuff as well. For example, um, tracing overall like the start and the the and the the the finishing of of a an an operation, for example, key generation, block signing, validation, attestation signing, validation, uh, entire block pipeline. Um, some logging, um, block created, publishes, um, uh, attestation created, validated, so on. Um, these are going to be, I think, very important to kind of like set a benchmark of like what's the bare minimum of the beam client that's able

to achieve and also would also help with like troubleshooting things once we get into more like more complicated features that we introduce to to future devnets. Um, yeah, so I think these are pretty straightforward. Um, there were also some suggestions to actually include like all these like hardware metrics as well so that we are able to know whether we can how far are we from from um, saturating the the hardware requirements. timeline. So, hopefully, um, this is pretty aggressive, so, you know, by the end of this month, um, PQ stacks, which is already out, our reference implementation is already out, so that's that's good. Um, by the end of

August, we should have the devnet specification itself agreed upon the team, so we have like a bit more than 1 month to work on this. Then, for the next 2 months after that, that's client implementation. Hopefully, um, by end of November or close to end of November, each of the team that are committed to running this devnet are able to run their own single client devnet. Um, and by all participating teams. Um, and then by end of the year, end of December, we are able to successfully run the multi-client, uh, devnet.

Uh, the rest are more of like housekeeping items and some of the rationale, so I probably don't have to go over the details here. Um so, yeah, this I think this is our our view of the the devnet so far uh without incorporating the the seams uh view uh that's published today. >> Tom up. I Yeah, Tom. Yeah, so thanks for the presentation. I have like a question about the spec, so basically, what you are waiting for is the Poseidon spec plus the signature scheme spec. I think

that the expectation for both of you is different maybe because on the Rim side, as you are using Rust right now, you you don't need like a spec for the Poseidon, for example, because you can just import any Poseidon library, like Plonky2 history Poseidon, or anything you want, and almost the same thing for the signature scheme because you can just use the scheme implementation that we have in Rust, and just call that, and you you don't need basically any specification.

I think that on the on the Zim side, things may be different because you are using Zig, and so maybe the call maybe Poseidon I think that Inacio did the Poseidon implementation recently, but maybe you need kind of a spec to be able to use these kind of things. The good news is that we have just started with internally at the EF an effort to push like uh a minimal spec forward, uh and have like we started to set up a repo with a whole like Python framework to have uh uh, some specs sub spec and tests.

And so, we wanted to start with Poseidon plus the signature scheme. So, that we could have quite soon, let us say, a working, like, Poseidon plus signature uh, scheme specification. This should be quite straightforward on our side because this is basically just us taking the Rust implementation and transforming it it into a minimal Python spec. So, that is So, that are two things that we could have quite soon.

I think this is all you need for this devnet, right? You don't need aggregation stuff, you don't need the minimal ZKVM, and you don't need all of that. Correct? >> Yep. I have to start off with our first devnet, we don't need any of the aggregation bits. And, with respect to, uh, spec, we definitely might need Poseidon to spec because, uh, that is something that will directly integrate with our, uh, SSZ hasher. And, but, for, uh, uh, for the signature bit, we will also try to just use the Rust library using Zig bindings. So, that there, I mean, we

don't need the spec right away. Uh, so, our first focus for the spec would be Poseidon. >> Yep. Uh, this is my first target, also. I will share with you as soon as I have the repo set up and stuff with the testing team internally at the EF, I will share on the group the repo where I will first try to spec Poseidon. This will be my first work. >> Um, Thomas, one question on the hash sig, is there a latest version available? I believe uh, reference implementation that was released a while ago couldn't be used out of the box at least by us because the Merkel 3 was not I

mean available for exposure. We could always spoke it and use it but we would prefer using one that is I mean that you from the EF team released at least for the initial >> Our our official implementation is the one that I just share. Maybe you you should aware of. Yesterday Yeah, yesterday we merged the new encoding scheme. Benedict Benedict and Dimitri should like release an explaining paper soon. Hopefully next week I think but yesterday we merged a big PR with the new encoding scheme.

So things should have changed since maybe the last time that you you checked But this is definitely the let's say for now the official implementation that we have at the EF. Yep. >> Great. So it seems like the Oh, Justin, you want to go ahead? >> Yeah, I just wanted to share a few thoughts. Um I mean the first one is that I'm super happy that all of this coordination is is happening organically and I think almost all of the

the the the points can basically be be settled among the devs. Um but I I am happy to to share some thoughts from the presentation if if if that's helpful. Okay, great. So um one of them is that you know on the devnet versus testnet nomenclature I would agree that devnet is better because we want to under promise and over deliver and one potential way of thinking about it is to basically start with a a proof of concept and then iterate fast on top of that. So there's like multiple axes where we can simplify. So one is only having the leaf signatures and

those no aggregation. The other one that I identified was having a single subnet as opposed to multiple subnets. Yet another one was having no chaining versus having chaining with the parent and then another one is whether or not we have three SF. And I guess what we could do is just start with the the minimal thing and if we're going to have these fast iterations which makes sense, you know, if you guys are suggesting suggesting you know every 10 days or so then we can just incrementally add these these features and and work our way up. One question that was asked is whether we want a single client or multiple clients and I think this is this is a very good question.

On the one hand, you know, we want this effort to be neutral to be to be open and I think there's going to be like real value to having multiple teams be involved. So for example, one of the efforts that we want to do is make sure that we have a very friendly APIs and bindings to the to the crypto cryptographic libraries and here having multiple languages will will will provide different perspectives. I think it's also good to make sure that all of the reference and unit testing infrastructure is is friendly and here we're trying to innovate a little bit. So we have Felipe here on the call but it be someone from

from the testing team who has prepared the spec template and uh it'll be good to kind of iterate and polish it. It's meant to be all of the best practices kind of condensed into one place. All of the learnings that we've had from both the beacon chain and from the the EELS program. And then I think you know, a good point was made that this is not just purely about de-risking research in in a sense the research has been de-risked. It's it's it's it's about greasing the wheels from a coordination standpoint.

And here having more than one team I think is is is valuable. Having said that I I think we need to be extremely mindful of not wasting time unnecessarily and and developer resources, especially when the existing consensus layer devs that are focused on these short-term strategic objectives. And so like maybe like one possible outcome is that we have in addition to uh Remmezzine one additional existing consensus layer team.

and having this third team could be valuable for several reasons. One is that they they have a lot of experience and wisdom that they can they can share with with some of the newer teams. They also have like production grade you know, libraries and and like SSD and and and networking. So for them it shouldn't be too much work. And I think it would also be good from a social bridging perspective, because the the existing consensus layer teams that they're used to working together and I think it it'd be good to avoid the the silo between the the new teams and the existing teams. And so having at at least one existing team could be could be a a good bridge.

another note that I have here is that it's looking like we won't have a bean day as I originally envisioned it, but instead it's looking like we might have a a whole beam week in Cambridge. So, the idea is to potentially in September have a a workshop um where uh you know, some researchers and devs all come together in Cambridge in one of the colleges for for a few days and we we try and accelerate as much as possible the the post-quantum cryptography uh testnet and and and the underlying uh as well. And we're also considering having um a little bit of a

uh different foundation architecture thing. So, like we have the architecture team and the consensus team and basically having everyone around the whiteboard to try and and come to to rough consensus on on what we were going to do for for the the finality gadget and the fork-choice rule. So, one um kind of very recent development is that there's been various innovations at uh at the consensus layer for consensus mechanisms that are extremely low latency. So, for example, Alpaca Go from from Solana.

And the question here is can we incorporate some of these latest ideas uh so that we have ultra-low latency bridging um and and deposits from from sexes and things like that. And one of the potential research directions here is basically to a little bit of a hybrid construction where we have a ultra-fast fast path um which is a little bit like a a safe head uh confirmation rule uh that that depends that will work like by default almost all of the time assuming you have a synchronous network which you know, should should be the default and you have honest majority and

then there's kind of a slower finality gadget that takes a whole three rounds of attestations that does kind of a trailing. Um that would be I I guess my favorite approach, but the consensus team, especially Jan, who's new to the consensus team, is is looking into some of these these newer newer designs. And so together, both the post-quantum pseudonyms in Cambridge plus the architecture and consensus would form kind of a a whole a whole beam week.

Um another thing that I have noted is the slot duration. Um like I think my personal preference would be to just try and pick a a reasonable number. You know, I had this meme of like speed of speed of light slots. It it it's hard to tell exactly what they will stake out to, but to me 12 seconds just feels very long, especially that there's proposals to bring it down to 6 seconds. So kind of just from a mindset perspective, I I would kind of aim at a little bit more aggressively, something like 4 seconds.

and in terms of the the signature killers, the good news here is that pretty much everything is constant time, meaning that every signature is takes the same amount of hashes to verify. Uh and every aggregate signature as well is, you know, the same size and takes the same amount of time to to to verify. yeah, the the good news is that there's because you have this recursive aggregation, there's there's also attacks and censorship attacks that that don't don't become meaningful. So I'm not too worried about the signature killers, but if if someone um you know, wants to

study this, I I I I'd love to to chat as Now, in terms of like a few other updates that I haven't mentioned yet, um one is that Um and

another update is that uh there's been a ton of progress uh by Emil and and and and Tomar on the the minimal ZK uh VM for for recursion. So, there's now a document that kind of uh explains uh the the key ideas and and and design of this ZK VM. It's super super minimal. It only has six opcodes, um two of which are per say the opcodes of of different input widths. So, it does almost nothing. Like And And two of the opcodes are add and multiply.

And then there's a there's a jump opcode, and then there's a a memory opcode. So, only only six opcodes, super simple. And uh it looks like it it's powerful enough and and uh efficient enough that that we could potentially go down that route. You can think of it as being uh Cairo but taken to the extreme in terms of minimality. this bodes well to us uh being able to to fully formally verify uh lean sig. Actually on that point, we now have a a suggested um uh you know, branding and terminology for some of those things.

So, you know, we have uh Poseidon at the at the very base and then we we have lean sig, which would be the one-time signature plus XMSS, and then we have wear as a building block. Um and then on top of that we have a lean snark, uh which would be what we're currently calling world away, but it will be rebranded to lean snark. And then on top of that we have the lean ISA, which is the the six up code minimal sig EVM. And then on top of of the lean ISA we have lean multi-sig, which is the the multi-signature scheme that kind of wraps everything together.

And we have a new a lean Ethereum GitHub organization that has been uh uh created and we're uh we're hoping to put all of the Python specs, but also the the efficient um and and and reference implementation in in in Rust, which I hopefully will be able to formally verify at some point. >> Awesome. Very exciting.

So, we're just about at time. It seems like we got a lot accomplished today going through these uh proposals, getting a lot of questions answered. Um in terms of the agenda for the next call, is the goal to just continue to try to arrive at a shared specification for the devnet, or are there other things that we want to sort of uh feed the agenda with. >> Yeah, I think we we could just uh push this further and we have to achieve consensus and sort of figure out

whatever unanswered questions we have. so that we can definitely come to consensus by end of this month that uh what is the first uh devnet one spec that we are going to go with. >> Yeah, also if it will be helpful I can share some insights from simulator. Uh so yeah, I'm doing a lot of experiments right now. with different signature sizes uh uh bitrate like number of aggregators.

Um yeah, all of that I think should be interesting. >> It's great. >> On that note, one quick update is that Quadrivium has uh is basically the third client team that has received a grant from the Ethereum Foundation. >> Beautiful. Uh and then also Michael, you're on the call from Protolab. I don't I don't know if there's anything that you wanted to say about the Protolab role in this process. >> Um I mean we are partly collaborating a lot in the Pushaka devnet, pretty much monitoring that um each of the client

implementations is fulfilling what the spec defines. I guess that we could do similar work ensuring that everything or everyone is on the same page, but yeah, it's just still up to define how can we collaborate monitoring all of this work. All right, keep an eye on that. >> I think one question that also asked is that do we have any idea or do you want to ask is that do we have any idea which is the third team that we are targeting because I think it would be good to get them early on into our discussions and sort of get their viewpoints and expert opinions.

>> Yeah, I don't know Justin. Do you have anyone that you think that we should target or anyone else? Um like basically who's going to add value and be maybe has the largest team we're not going to like cannibalize resources from something more timely. >> So I don't have a strong opinion and I also must say that I don't have a strong opinion that there there has to be a third team. I believe that Will has started talking to the various existing consensus layer teams to to do a temperature check.

I mean I can think of like multiple pros and cons for multiple teams like for example if I were to pick lighthouse one of the pros is that I believe they they made a higher specifically for for the beam project. I guess one of the cons is that we already have one of the clients room that that that is in rust and so we we wouldn't learn as much in terms of the cryptographic bindings for example. but um if I don't know if Ladislas is here but maybe he could take responsibility for for trying to find such a team.

>> Yeah, I have I have reached out to a couple of of folks but yeah I guess generally I I would I would say it's I would leave it I would like to leave it up to them whether they want to join or not like it's not like we can only demonstrate like that we want to move forward and so on on on them to be in or out in terms of being mindful about the resources they they want to spend on this. And of course that we can like even if after one call or a second call or a third call like they are at least we we um we keep them informed as as good as we can. So and and this is a bit on us as coordinators. So yeah, TLDR I will I'll reach out to them again I guess we will

share this recording here as well and probably also a summary of it and then um and then collect feedback from from them. >> Great. Um yeah, and then the final thing the standing call moving forward will be I just want to make sure I have this correct. It's going to be Wednesdays at 2:00 p.m. UTC so this same time but on Wednesdays. I had a question or you you had a question adding a PM repo to the lean Ethereum uh org.

>> Yeah, I was just uh sort of responding to all's comment that where is the best where is a place where we can sort of share documents and sort of collaborate on plans, publish specs, and all that. Yeah. yeah, I I will I'll work to have something proposed for the next call on that front. Great. Uh this has been fun.

Have a great weekend everyone. >> Thank you. >> Bye. >> See you. >> Goodbye. >> Thanks guys. Bye. >> Thanks Will. >> Thank you guys. >> Thank you everyone. >> Bye-bye. >> See you guys.