Post-Quantum Interop Call #9

Transcript

Everyone, welcome to PQ Interup. Uh we are just kind of wrapping up the specs for DevNet Zero. Uh making our way towards specs for DevNet one. Uh hoping to have a live DevNet zero here in the near future. Um I think being or sorry June, we're going to start off talking about lean view. Um yeah, walk us through it. What do you got here? So can I share my screen?

>> Yeah, go for it. >> Uh so >> yeah. So can you uh see my screen as well? >> Yes. >> Can you zoom in a little bit? >> Uh okay. Okay. So all right. Uh yeah. So I'm Jun from RE team and I'm building a Rust client for upcoming PQ DevNets and also I'm interested in building a tool uh that can be helpful to devs and researchers uh in this PQ intro calls. So uh I uh last few days I

spent some days uh making some architecture and uh how to integrate those things into a web app called link view. So uh and also for the naming uh I'm also welcome to any feedback about this naming and uh you can DM me uh when you have some great idea. So uh this tool is um uh so in this demo um I'd like to show the live app on the live network which means I have to bootstrap uh deaf net uh for this uh app. So there is a

uh so yeah uh rim uh already supports uh uh bootstrapping a devet from scratch. So uh just running this kind of um command this will run a node with the four validators on it and it uh continues getting consensus uh with three asset mini consensus mechanism. So uh there's lots of uh things going on here but I think they are well going well finalizing justifying uh etc. So on this uh node uh there is an RP send point uh on this node. So this uh node

can feed data to the web app. So I'd like to uh also run a lin view app with this comment. So here's the lin view uh project. So it's basically a simple fullstack web app consist of back end and front end. And you can see uh the repository back end is written in Golang and the front end is written in react and typescript and uh I'm going to skip some details implementation just showing what is going on right now. So uh all those uh back end front end is dockerized. So which means I can just use docker compost to run uh a fullstack app and there's a lots of things going

on here. So uh the one of the core component of back end is indexer which uh continuously fetches uh the data uh every slot second. So in this our setting it's a 4 seconds. So currently uh there is a page so in my local host yep this one. So uh the front end is mostly built uh by AI. So you might be familiar with this kind of UI. So I can uh uh the design can be also improved but uh let me just focus on the this functionality. So the first part is more kind of live things. So uh how does how does the endpoint is uh is working well

or not. So it includes some kind of uh slot the hat slot informations with the block number uh with the block route and it might not be healthy if the endpoint is uh not returning well. So this kind of is a live things and the below thing is the table. So it's kind of a historical thing. So the first part is inspired by the fork moon and the below part is inspired by any other blockchain explorer like Dora or ether scan. So uh one thing I'd like to note is that um there uh uh I'm aware of some additional features uh that can be built upon this

app. So uh there's a database indexer and also some live uh fetcher. So uh if you have any um idea or feature request, you can just share or raise your opinion on the chat or you can also DM me about the features. And I'm also uh this is just a very very basic uh dashboard very very basic explorer but I'd like to uh add more features uh on my own but uh I also need your help about the ideas and uh what kind of uh things you want to see in this web app. So yeah that's it.

I can uh get some questions if you have >> and also you >> Yeah, I was just going to ask um if you can if you can hear me. I'm not sure. Um Oh, yes. >> Yeah, I can hear you. Um yeah, I mean uh what do what do you need from us uh to also add us in uh in the thing? So that's my first question. Uh I think you already uh I mean Mercy has already been working on this but I didn't quite follow. Uh sorry. The second question is what happens when you have like let's say uh 5,000 nodes on the on the network. Okay, maybe not

5,000 but 20 uh 20 20 nodes. like isn't that getting too over overwhelming like the first part where you only have three clients at the moment? >> Yeah. So this is so so the first question was uh uh the the what what do I need for uh you guys right? So >> yeah that and also because I think I understand it's based on HTTP request uh can we just mock like give you a first interface and you know answer we don't know yet uh what will happen uh if that uh if that occurs.

>> Um yeah so I think this visualizing things uh can handle some crazy scenarios because uh we might face some scenarios on that. So uh I'm going to add some features uh that can be also seen in any other blockchain uh any other uh explorer but uh I guess there are some features spec specialized for this pqdevnet. So uh we don't have signature right now but uh at the PQENTE one we will have signature and at the PQ net 2 we will have aggregates uh and going on and on. So I guess uh I I can

think of those features but uh if you have any ideas just yeah raise uh any opinions uh to me that I can add on uh these features. Does that answer your question? Um yeah, no I I I just mean like u you know I just want to see Z added to that to that rope. Uh so my question is just like >> can we just craft something very quickly so that at least we can be in there and see how far off we are from being fully functional in your in that view.

>> Yeah. So uh it's if you are familiar with uh if pandops config it's just like this one. So um uh just you just I need one endpoint or several endpoints uh that run zoom node uh which is uh also compatible uh of the RPC structures and response. So yeah I can just add this end points >> right. So that's my question like we currently we just open an issue to to discuss how we would implement this. My question is if we just create the the endpoints right the HTTP endpoints >> um but they say you know like they return an empty JSON payload

uh what what should we start with basically what should we what what should we provide that's not going to take the whole thing down and uh you know we we're not immediately ready clearly but um we're going to build up we'll build it up over time we just want to to see if what what happens if you know we return like an empty result. Um all right so if I understand your question correctly um so your question is about uh what if the one node return uh empty response on the request right?

>> Sure. >> Yeah. uh yeah so in that case I guess uh this explorer will determine that end point on healthy so uh yeah that's that's the logic >> and so uh and al could you repeat the second question that I don't remember Yeah, sure. Uh the like you have cards for every every node and right now you only have you only have three so it's fine. But all right.

>> What when you have 20? >> So uh there's a or key app. uh this is the is is also built by uh if pandelops is about uh fetching about I don't know 20 nodes I I guess and they are using zatu uh as a data source so it is quite optimized but uh we don't have that kind of data source right so uh I guess that needs more optimization and also uh I added all the components is just one page but uh I'm planning to separate this uh monitoring page in another page so that uh this request can not be too

uh uh too burden to any other clients. So yeah, the optimization is not yet uh well done uh in this project, but it should be. >> Yeah, I mean that's fine. You know, you're just starting a a blog is for from scratch. It's it's a lot of work. Um all I'm saying is yeah, I just want to see uh how we could make it more readable. That's uh that's all. >> Yeah. Thanks, uh Mercy.

Yeah, I wanted to ask um the three end points you pointed out for um zero is it just the three end point that we need or are we going to expand um on that also? >> Uh yeah. So um so so I I put it three end points uh including block block header and versions but I guess uh fetching a state will also be needed I guess because uh that's what uh that's what explorer has and yeah I guess those four end points is

enough for this phase and if we have uh another feature per request, we can uh add a new endpoint that can serve that data. >> Okay, >> this looks great. Uh but John, if we can add uh the fork moon kind of a thing, I think we'll be needing that because if there are forks in the network, uh my question is how will you figure it out over here? >> Yeah, that's a great question. So uh zapu has some uh emits events on the fork reorg thing. So that's what this forky uh works by receiving the data

from zu. So uh currently uh those there is no um UI for the handling this reorgs or fork but that should definitely be in the def in the dashboard. So uh my my knife thinking is about just um batching the those end points and compare the uh block header or something to determine the forks. So uh I have to think of more uh algorithm about this uh fork things because 3s is another consensus uh that I have to figure it out.

You might not need to figure it out. I think maybe just uh figuring out what what the head of everyone is because everyone will give you head according to 3SF. >> So you might not need 3SF in the in this particular tool as such. >> Mhm. >> Yeah, I understand. >> So I need these three APIs. I mean even if for example there is the version is not there and but what is version returning? uh like this one.

>> Okay. So I mean I don't see a big uh you know issue in just adding blocks and headers or states for that matter >> as such. I mean it we should be a able to handle it in that sense. We should be able to come around on this. Uh yes. Uh could you repeat the last sentence? I said yeah as such Zim should be able to come around on this and implement the APIs because we don't see uh much basically you know >> uh I can share some uh clean document

about the the definition of the endpoints that I'm using right now that that can help uh for implementing the RPC. Yep. Uh I can send uh in the Zoom Telegram chat uh maybe tomorrow or after this call. >> Yep. I I think that would be helpful for the team for sure. >> Yep. >> Excellent. Thanks, Jane. >> Uh okay. So uh I think uh if you have any question uh you can raise uh you can DM me and yeah that's it. I can stop my screen sharing right now.

Uh real quick, so you also working on forkindora. >> Uh no, it's uh as fork indora might uh have a lot of code chains I guess because uh there's there's a totally different uh consensus uh using in those chains. So actually the the app what I showed uh right before is just uh uh act as just a uh role of dora right now. Makes sense. Great.

Um then next item that I put on the agenda, Guom. Um if you I know that you opened uh an issue with DevOps and I think that they're like spinning up a a an instance of Graphana for this group. >> I don't know if there's any context or update you could provide on that. >> Uh there's a very short update. So yes, the instance exist. We even have uh excuse me we we have a Victoria metric DP intake uh which is the same thing as Prometheus I mean this they should speak the same protocol at least that's what I've been told um so that's done uh I just need to test it and figure out if there are some

issues so I I am yet to do this but uh yeah you will have it by tomorrow at the latest well okay unless there's a bug you will have it by tomorrow uh at the Got it. Sound good. >> Uh, next item I'll drop in the chat. Tom, you wanted to sort of provide an update on the lean SSC. Your audio might not be working if you're speaking.

>> Oh, there we go. >> Is this good? >> Yep. So, um I with Felipe we started to work a bit on some lins things. Why? Because um for the SS we had like conflicts of types and we had like like only kind of whole implementation not maintained anymore. one in Python by by the uh by one of whole team of the Tvium Foundation and one another by an external contributors remarkable uh also not not maintain anymore and we wanted as discussed during the last lean

consensus call to um to make things easier to do in Python using strong typing pyonic stuff pedantic and all all of the good principles of modern Python. So we started to work on that. This is almost finished and we are currently reviewing this. I will just share briefly my screen just to show you like a brief view of what it is. So basically in the me close all this in in the types uh in the type system that I have there we have defined all of the

all of the types required to do the SSD. So boolean types or u ins this is maybe the the simplest to to understand. Um and so we have defined that with everything clear trying to use pedentic as much as possible trying to use clear method modern uh python this is under review and we have open source it so we will try to improve it with time um and we have tried to implement also the SS in a very simple way basically uh the most important things are in this folder SSD and this is currently under review by Felipe who will provide some new

peers and some new insight into this. Uh but yeah, basically the goal was to renew a bit the ecosystem because uh the last things that we had was remarkized. Um so this one and it was only maintained last year. So we wanted something a bit new and uh more adapted to the link concepts. So we just started this small effort. Uh I worked on this a bit this weekend and a bit yesterday. Uh that is almost finished and yeah, Philipe is currently reviewing that. I will then post that into the global lin consensus

uh group that we have to see if we have external contributors who wants to contribute or to share some Python tricks or Yeah. This is my point. >> There was a a question in the chat from June. Do we need to use SHA 256 for hashing and SSZ Merkelization? >> Yeah, for now this is what we use. Yeah. Yeah.

>> Excellent. Thanks, Tom. Okay, any other questions on that? Camille, you wanted to provide an update. I'll drop in the chat. Uh, the Quadrivium client update. Gleam mini. >> Yeah. Hi, >> I like it. >> Yes. Yeah, I can really quick um just explain what it is. So yeah, we also just open sourced our um DevNet client.

It's uh still lacks some features, but yeah, working hard to introduce them. Uh yeah, overall it's uh yeah uh yeah, DevNet client written in C++. Yeah, we use C++ lip. I think uh yeah, Reman, they use Ras lip. So we'll kind of have a hopefully yeah, we have some diversity there. Yeah, once our client is fully implemented. But yeah overall we have block production ready. Um briefly show it. Yeah. So basically here we have like one node produces blocks and the next node is basically just synchronizes it. In theory yeah we should uh uh give it a try and maybe yeah conduct some interop because yeah

we have the gossip subtopics implemented for the block announcements. So um but yeah, working hard on introducing 3SF and STF there. Um yeah, also I think LM was asking like about the Docker uh last time. So yeah, it's not there yet, but yeah, there is also uh working in progress at the moment. So yeah, I just wanted to give some update on this client. Yeah, thanks. >> Awesome. Thanks, Camille.

>> It's great to see that coming together so quickly. Um, and it'll be nice to have that ready to go for the intera. >> Yeah, mo most of pieces actually they were not even implemented. Well, they were either ready or we just reused them. So for example, SSD we just took uh from offchain labs they had C++ implementation although they were not supporting this for more than a year. So yeah, we might actually face some um uh yeah, compatibility challenges there, but yeah, that's what we need to figure out with interrop. Um but yeah, >> all right. Um

>> has better name as John said, you also Yeah, accept it. consider it. >> Uh I think well first of all congrats everyone on a really successful lean consensus call last Friday. Um going into the call we were having some conversations about the one pager that I just dropped into the chat where this is of where we're trying to summarize everything that's in the uh pqnet spec zero or zero spec. Um and this is sort of follows a design pattern that is used in the you know primary ACD

panda ops uh PM repo world and I think that it would be great if we could sort of start to uh consolidate all of the you know update that with all of the functionality inspect PRs and inspect test versions that we're planning to include into DevNet zero. Um, I think getting the first one, uh, you know, sort of solidified. I'm happy to take the lead on it if people want to just direct me to, uh, you know, all of the the PRs, inspect sections that are going to be included in the DevNet. Um, updating it moving forward should be, you know, relatively simple, just sort

of tracking the incremental improvements. Um, but I do think that if we go too far without capturing everything here, we'll end up regretting it and it's going to be more work in in the future. So, our our future selves will thank us if we um take some time to either like talk through that right now. Um, we can, you know, I don't know the best way that we want to go about doing this. People can just submit PRs to update that um that markdown that's already been created. Uh, I don't know if anyone from the client teams or active spec writers have any thoughts on how to

advance this. Cinder, you're awfully quiet. I'm going to call on you. Yeah. Uh so what what is what is needed from us? >> Uh really I think it's just a matter of getting links to all of the pertinent information. Uh normally these DevNet one you know single sheets cover all of the um it will be a link to the current release of the spec like say the

consensus spec release. Um I don't think that we have releases bundled up yet quite yet. So it'll just be links to the individual subspec sections. Um and then this is where we can start to track any active PRs. you know, normally it's it's EIPs and PRs. Um, and you know, trying to get everything onto a single sheet so that you know what's included in that uh DevNet. And then that's also where you'll track the, you know, sort of have the the test scenarios that you want to include in the DevNet.

um and ultimately you know document the uh you know the interoperability of all the clients and if they're passing those tests successfully. >> Right. Right. Uh so yes I think uh this document make quite a lot of sense with that goal in mind because this is like you know anyone can come over here and it will be a starting point to dig into what uh is happening on test or spec or any of the clients uh clients that are participating in it.

So yes, we'll be able to sort of link out branches and PRs to it as well as uh the spec uh spec as well and maybe also detail I'll write basically a bit of detail of uh what is uh what is the functionality functionality that we are covering uh so that we already added in the uh added in the lean spec repo but I guess we can extract out of from there and put it over here or both the places can have it.

[Music] >> Uh, perfect. Um, yeah, it's not the not the top priority. Something I'm more than happy to track. Uh, I think it's just wanted people to like have context on it before I start uh reaching out and um trying to collect all the pertur information. But I can take this to the next level >> with that. It will increasing it will definitely increasingly become quite important because as we sort of >> get more and more towards interrupt then all these things will sort of be very pertinent to figure out what is going on.

>> Yeah. Yeah. And I'm happy to like uh update it week in and week out. So it once it gets going it'll be a nice kind of uh central hub for these calls and and other things. Uh okay. any I guess last week you know we sort of felt like was a completion of DevNet zero spec um can someone provide an update on the status of uh I don't know I feel like maybe we're working towards a DevNet one spec and launching DevNet zero >> yeah so I can sort of give the status with regard to

what's happening in Zim as well as what is happening in the Genesis generation but uh I think Phil uh I think PK uh so sort of basically put together a genesis generator that would turn out the files that we need uh he would although we don't need Genesis uh uh SS but he would still generate it so that uh clients can verify or clients can directly read that genesis SS and sort of uh have less of a crossclient issue uh and if there is an issue that will pop up quite easily. So uh so that part is ready. Um Z as such is quite near to DevNet uh uh

zero spec implementation. We are done with fork choice and some of the changes that was in that were that were introduced in the container and state transition function that I just need to port back and uh uh so hopefully by end of this week we will be ready and we'll be ready to sort of uh consume uh PK's Genesis file and uh sort of start a local and imp uh uh in process or local net with our own client and then if uh then when bream is ready with it then we can uh uh interrupt try interrupt on the local machine itself.

uh but I think before we try interrup we would basically need some of uh uh some of the test cases we need to pass some of the test cases because uh a lot of interop issues would be you know pre-andled that way and uh we could probably have a smooth inter uh I think in this week's call uh week's call in Zim uh PK and we have to basically take a call whether we want ktosis uh ktosis as a tool because ktosis right now has lot of other things. It spins up execution clients and uh so so there is whole lot of stuff and there is whole lot of tooling that

or whole lot of functionality code that we don't need and uh we basically it will be better to start as a independent package but uh I I don't even think that we sort of need that we have a quite simplistic way of uh starting uh starting up the clients and with genesis generation is also not really a big deal So uh so I think maybe we can have a small shell tool that can spin up clients at at least to begin with in the meantime getting ktosis ready. So getting ktosis ready will take two to three weeks in the least uh and we don't want it to sort of uh uh delay us and

delay our interop. So we'll figure out a way to interrupt without ktosis. But in the meantime, we'll get ktosis ready so that uh we can finally hop on to ktosis for that matter. >> Yeah, Jim. Uh yeah, so maybe can also uh provide some updates on it. So uh O and Cinder and me uh take some several calls uh about the lin chain spec. So uh I think uh we three are all quite aligned uh on the same page. So uh in in the rim side uh we already implemented most of

the updated the specs. So the what I show what I have showed shown on the the the very first part of this call is running the network with the latest spec. So I guess uh in in the rim side the spec spec implementing spec is almost done but one of the concern is is the optimization. So it's like memory optimization or any other DB integration. So we are uh working on this uh so I guess uh we can finish this in uh in only next week I don't know but uh that can be feasible and also um I

agree with the last sentences that uh as curttosis uh needs some time to be prepared we need some uh method to run this network in local motion. So I guess docker compost can be a great uh tool for running uh uh separate uh node in one machine. So uh yeah so I think >> uh yep >> just just to add over here so the kind of tool that I was talking was definitely we'll use docker images uh but I had something like a loadar quick start when I was working for loadar where you can basically you know use the tool to spin up a dev network and uh

through through basically you know it will generate the genesis and then start the network. So we have uh that kind of a shell tool and I think uh we can adopt that over here to spin up the nodes but yes definitely spin up all the nodes in docker so that uh uh it is an easy way to get the network going for anyone who wants to start it. >> Yeah. So I I would like to suggest to uh make a schedule of that kind of local interrupt things using using the image from each team uh as uh if we are ready.

So uh I think uh uh could you have any idea of this timeline before this uh the full interrupt? I think uh that is this is something that we we should start trying next week. So I mean I'm hoping that uh we'll be able to start uh at least figuring out the interrupt between uh Ree and Zim next week. That is that is my hope and aim.

>> Yeah. So and I also noticed that uh we both have some CLI tools to generate ENR uh to be more specific the set CCP key for the network that that means that we can just feed the boot uh the ENR addresses as a boot nodes for each each node that can also be handled in some some script in a docker couples. So that that tool is that uh data will be available through uh PKS generator. So we don't have to worry about it.

>> So PK so I'll share uh I think is PK on the call? I'm not sure. >> I don't believe so. >> Yeah. Yeah. So basically he did he did some work and uh he >> he provided some output where you know we had a discussion on this on Zen call last Friday and uh we basically uh figured this out that okay you know this is the minimum files or the structure that we need and which also included uh uh secret keys uh for the nodes uh lo for the node uh lip P2P as well is uh the ENR uh generation and uh

assignment. So, so all that thing should be worked out. What we just need to do is basically have a shell tool that generates it and then is able to start Z or ream node to read uh those config files and uh then basically the interop happens. >> Uh all right. So uh after we can also we can also add add lean view to it. >> We can also add lean view to it. Yeah, that would be pretty interesting.

>> Yeah, for sure. So uh if you have some Oh yeah, you can go ahead. >> No, I just wanted to add that uh yeah, how we plan to approach spinning up a network is basically from day one, we want to be kind of shadow compatible. If you know this is kind of the framework that allows to replace some system codes and basically have uh discrete event simulation for the networking. Uh the disadvantage of that is that it's not very convenient to to use it together with graphana as simulation kind of happens faster than in real time.

Basically we can simulate basically hours of simulation in several minutes or depends on the complexity and number of uh yeah peers in the network. Um but yeah that's just could be one approach to to do this. Uh there are some restrictions like for example to be compatible with shadow uh it doesn't support IPv6 addresses and some other restrictions I believe but yeah uh yeah would be interesting once we have all clients ready just to spin up the network using shadow because we can also kind of restrict for example the uh bandwidth between nodes set latency between them uh all of that stuff. So

yeah, uh if needed, yeah, we have some experience working with that. So yeah, we can help with this. Um that's probably kind of alternative to curtosis rather. Well, not no not no the other way around. It's not like the direct alternative to curtosis, but yeah, it could be convenient to to just spin up a network. Yeah. Yeah, I think that would be awesome to have where basically you can control the bandwidth or the resource allocation to the nodes and uh but I that is also possible in in uh Kubernetes but uh yeah I think that is all another tool to handle and we I have good experience with that but yes things

can be a little bit painful in So yeah, I think for the next week we can just uh try to do these things, try to drive for an interrop using very basic or rudimentary things and then as we gradually mature we'll figure out uh what other tooling we can use to basically simulate the scenarios that we want including what come suggested.

>> Good. >> Yeah, seems like we're kind of getting through some of these early growing pains and uh hitting our stride. Are there any other topics that people would like to cover? anywhere you're blocked, need a review, something that benefits from us all being together. >> Just one question to the ender about our spec. So, uh, currently one PR is open right now and, uh, can we just assume that this PR will be merged and also, uh, apply to our codebase right now?

uh the fork choice one. >> Yes. Yes. Uh so I just basically you know I just want to reconfirm everything and uh try to see that uh that everything is in order in the PR as such as such conceptually the PR is good. I just want to recheck all the small details and uh get the syntax properly done and as well as basically getting it implemented and uh so in z we have already implemented it. So basically a confirmation I was also waiting for a confirmation uh in implementation that uh whatever is proposed is all good. So there are a few changes that I mentioned

in the in our channel that we are coordinating for the specs uh that uh there are few uh minor changes that I would like to introduce and basically we'll discuss it over next two three days but as such it is sort of an abstraction and does not really change the technical content of uh the PR. >> Okay. So I think uh that PR can be merged uh I don't know the at Friday or something so so that we can um see in the master branch about the the latest spec of the eodna chain.

>> Yes. Uh let's try to emit March by Friday again. Right. Cool. Fantastic. Um, anyone else see some new faces? Welcome. Excited to see the call uh sort of growing in attention. Um, yeah, I think we're going to start uh turning some heads here soon.

All right. Uh, I will see you guys online. Have a good day. >> Have a good one, guys. Bye. Thanks. Have a good day.