Devnet Specs (workshop)

Transcript

Um but yeah so in terms like coordination I guess like there are a few fixed topics that we're going to be going through today and there's some like flexible talk like flexible sessions that I think we can kind of basically decide on the spot what we want to discuss about to push forward the the the the effort. Um so namely this the f the next like one and a one and a half hour is that specs. So I think this is one of the flexible topics that we can discuss about there's some fixed topics after that which is P2P and then tomorrow morning we have bindings and metrics um that's that's fixed but in the afternoon we have the dev breakout sessions which basically we can we can basically decide on that um and

also on the third day we have key gen in the morning and then the breakouts in the afternoon. Um some of the objectives I want to kind of like um like get a consensus on today is that um for the entire three days I think there are basically three kind of like three objectives that we should try to complete. First is that zero is still going on. I think we we trying to aim to be able to demo something by the end of the third day. Um so that's one of the objective is to complete that net0ero. Um the second one is to get the lessons learned so far from developing net zero.

you know things that we want to improve going into death one and then the third topic the third objective of course is trying to push for death one as much as possible right so we know that we want to implement postquantum signatures but we haven't actually started uh talking intensely on what the spec should be like for uh postquantum signatures inside the client itself right for example like um you know are we going to go with just like one signatures or are we actually having different signature types for um like um proposing um attesting and also like for let's say like signachi um do we actually want to have that in the specs for de one or do you want to defer that till later and then we only have like one signature

types for for dep um so what I'm going to propose today is maybe like we uh we should start from maybe discussing about you know um what's the the lessons learned from the net zero um maybe spend you know maybe just half an hour to to discuss about the topics, list out all the problems, all the the things we want to discuss about to make sure that we can actually spend some time to allocate and cover all of them throughout the three days. Um, and then after that, maybe after half an hour, 45 minutes, then we can start discussing about uh definite one as well on like the the signatures and what what do we need to actually get one up and then for the rest of the day two and day three, we can try to tackle

clearing out how all the remaining works for the net zero. and then um sticking out definite one as much as possible. Um how does that sound to everyone or is there any specific things you want to discuss about? >> Sounds good. >> Okay, cool. Um so maybe for the next half an hour to 45 minutes we can kind of like try to reflect back. Um I would suggest that maybe we can spend maybe the next five minutes on our own. maybe jot down some of the questions uh the problems or some of the suggestions that you want to make going to definite one that you want want to be incorporated to definite one. Uh spend this first five minutes maybe jot down on your mobile phone and then we can um oh actually I also going to be needing a a note taker if anyone can volunteer. Yeah. Yeah.

I'll personally do if anyone can volunteer to to help take note of that. >> Can we just get to do it? Uh yeah, well sometimes it breaks down so we have to make sure that works. >> So it's it's I I guess it's more of like just um just tracking so that we can kind like have something visually that we can we can keep track of just take notes. >> Sorry, >> I I can take >> Oh, thanks. >> That's nice. Thank you. Just and then color it.

>> Okay. So uh let's do that for the next um five minutes and then we can start um like listing out all the all the suggestions from you guys. >> Maybe we can spend three minutes just to get around the table to >> introduce. Yeah. Yeah. Yeah. That's a good idea. Yeah. So um yeah introductions maybe I'll go first and then we all can follow. Um so my name is O Anut. Uh I am from the green team. So my background like I mentioned is is technical but right now it's more of like technical plus coordination. So maybe I'm not that too technical, but yeah. Um um yeah, happy to be here.

>> Hi everyone, my name is Mi and I'm from the P2 team. So we're basically developing um lantern which is the C implementation of link consensus. Um, and I'm just hoping that we can get some clarity on some of the blockers we're facing um, these workshops and hopefully make progress in future. Um, >> yeah, I'm Simon. I'm from Corpus Cop building the prey client which is a light type actually stateless client. So of of course I'm always looking from this perspective make sure that all we build also works with light clients later on even though it's it's going to be a little it's a little bit early for

light clients yet but so I'm trying to see how I can support me also working the this kind of options to make sure that definite zero is working as soon as possible. Hi, I'm Mammy. Uh, currently I'm working at LITA. So, more on the postquantum signatures and the LIN VM. But I used to work on the beacon chain from 2018 uh to 2023 when it was the merge. So, uh I was thinking that I could give some feedback about what worked uh and what didn't and how we did the DevNet uh five years ago, seven years ago now. Um yeah

>> sir what's your name? M okay m y >> okay uh yeah I'm Camille I'm from team uh yeah we developing we actually engaged in these efforts by doing some uh P2P research uh yeah part that I just presented and uh yeah we also started in August developing our own client in C++ called kin uh we also developing C++ lip library uh for this client so yeah that's Yes. >> Uh, I'm Guom. Uh, good luck writing this. And >> Okay. Excellent.

>> Uh, yeah. So, I work uh I actually don't work, but uh I'm spending time on the Zim on the Zim client. Um, yeah, trying to to help with the designing the spec uh getting the real time proving stuff. do going and uh yeah uh I'm Tom from GM Foundation uh I'm working basically on postquantum things mostly about snarks and like signature education topic and also being >> hi my name is J I'm a computer engineer um before helping out in this project I

was doing stuff in like Z circuits and uh uh some organizations. Uh right now I'm helping the middle on the lead artistic project and I'm excited to be >> Hi everyone. Uh I'm currently at but I've been participating in joining in the Z calls uh regularly and hope to continue. >> Hi my name is J. I'm from Rim with O. I have a couple of years background software engineer and came to the ring uh developing the link consensus client right now and I'm very glad to see you here and ke to uh discuss about the

I'm from I joined a few months ago. I happen to live in Cambridge, so I decided to join. >> Hi, I'm Raul. I lead the peer-to-peer networking team at the Ethereum Foundation. I joined five months ago and my work has been mostly one focus so far. So, I'm just plugging into Bean uh sorry, lean um these days. So, that bear with me a little bit. I'm still catching up and I'm here to support uh all of the peer-to-peer networking efforts. Been uh chatting a lot with Camille and expect to like do a lot of knowledge transfer of from the L1 to influence the future of peer-to-peer

networking. >> What he didn't tell you is that it was one of the OG of the Bonchain P2P protocol. Cool. >> When because uh it was a collaboration between protocol lab and foundation back in 2018. >> Yeah. So I'll say anything about the B2B. >> Hi, I'm Lauren. I'm the technical lead at Lita and uh I'm working on the lead multi-IG um and supporting some of the uh work on three efforts.

Yeah. And I'm Lis. I'm with the DF as well. Help with technical coordination and leak consensus is one of the topics I I talk with. >> Okay. Uh thanks everyone. Um so uh next step yeah so like I mentioned let's spend the next like five minutes to think about like so far with like the text what went well are the things to improve and I guess like uh many of us are are new here. So I guess maybe for you guys maybe the questions or suggestions on what do you like to see uh in in devet one onwards in terms of like the actual features or maybe the objectives what should you actually try to achieve right so maybe start in the next five minutes and then we we'll share and then jump down and hopefully

we can complete this within you know like 45 minutes so we can get into the definite Um, sorry. So, we're talking we're thinking about >> um I think for this session is looking back for the next 45 minutes. look back into what what what goes well, what needs to be improved, and then we can spend the rest of the next few days to talk about the future stuff.

>> Okay, it's just that we haven't shipped it yet. So, it's hard to look back. >> Okay, >> that was I think we should why we didn't shoot. >> Yeah, sure. I think for I guess for for me at least something new. >> Yeah, that's I guess that that's fine. We or we could we could so maybe like three more minutes and then we can go through this quickly and talk to the future stuff.

>> Okay. He was okay. I suspect Okay.

Awesome. Oops.

One minute. 15 seconds.

Okay, cool. Uh, so let's get started. Yeah. >> Um, so how do you run and how easy or hard is it? >> Okay. Uh, cool. Maybe we can do like Q&A then. Okay. Uh, how easy is it to run a node? I guess maybe from from re we can answer that first, right? So, so basically we have two repos right now. One is our main codebase that's renab um so you can basically there's a a docker docker file there that you can you can run it as a as a docker there's command line right there. Um, we also have a separate repo. I don't remember the exact name.

>> No, no local. Yeah, local. >> So with that one there, that's a bash script. Bash script. >> Yeah. So if you want to run a single single client and see the logs and and see how it goes, you can use the real code base. If you run, you know, four four client environment inside your local machine, then you can use no heat to run. Um, the question was that uh how to run uh the the client Yeah. So >> for for for seam is >> um I mean right uh do you want the command line or do you want are you talking about what's called le quick start?

>> Uh what's the difference there? I guess I can continue maybe elaborate. >> Sure. Um yeah. Okay. Uh how do you run um the client? Yeah. So how do you run the Z client? Well, you build it first of all. So either you use the build the build command. So you know it's a bit like cargo. I don't know if you know cargo in Rust. Zig has its own build system. So you just say zig build run and then you pass the sub command that you want. Uh by default it starts proving stuff which is not what the default behavior should be but this is what it is right now. So you have to say node and then you will start a node and you can you know pass some arguments of where where it should connect and things

like this. But this is a pretty horrible way to do things. Um, and I mean this is something we have inherited. You know, it's already it's already true of the beacon chain time or even before there was a beacon chain. Uh, so Ginder wrote a script that he already it's an adaptation to be of some tool he already created for the for the beacon chain which is called uh link quick start. And here you can specify I want to run like you know uh n ring clients uh n z clients n uh team sorry clients and uh it will either go fetch the docker images uh for

you if they exist it's coming it's coming Um and uh and yeah if you want if you want to do some debug on any of the clients you can also specify in the config I want this as a binary and then you pass the path to the binary and it knows all the options for you and if it doesn't it's a bug and you have to addition anyone else wants to >> I can say very briefly but It's basically the same. Yeah, we in C++ it's

a bit more horrible because we don't have very good package systems. Um yeah, but we we already worked in C++ for multiple years. So we use VC package. So hopefully it makes life a bit easier. Um yeah, once it build what is a bit different for us is that we use some dynamic libraries. So we have to pass uh the uh well as CLI parameter like the path to these libraries that we just built. Uh yeah it's could be a bit inconvenient if you just use binaries but in docker it's very simple we actually hide this even you even hide the cla part of the run docker command.

Um yeah so and then we pass things like uh private key um our uh list and others that we use u yeah we don't currently have a database really because yeah we were focused on just implementing everything to make 3SF working um that should be taken into account but yeah otherwise yeah like that >> so just to clarify uh the net zero is already a multilan test net and there are three clients uh or more.

>> There are three clients right now. >> And we could add more just need to add more configurations to the script that can be done. Uh if you have if you have an extra client we can >> I don't have a client in near >> talking about you specifically but yes >> if you have new clients we can also >> I think the in terms of like new clients the minimum interface that you need to implement and there's no spec in terms of the gossip sub I think we just doing gossip is the request response required I don't think so right it's only the >> yeah there's probably only one one topic there >> mhm two top two.

>> All right. Yeah. >> And then in terms of running the command line, then you have to uh consume the validator registry which is basically the the private keys. Um you need the validator ID because it's a fixed register or fixed validator set. Um what else? And the the PR um ENRS. That's that's probably all that you need to to do. Yeah. Okay. So So that's the first question. How to to run a node? Um other suggestions, other questions? >> Um yeah, a question I have is uh if if we were to use a structured topology, how would that arise in a decentralized system?

>> Um yeah, great question. >> Who ask? I think we can. So there's a second to this one. Fantastic. We can touch on that. I think it's going to be quite a central topic. >> How does that sound? >> Yeah. Yeah. >> Seems like very specific. >> Yeah. Um but currently on the beacon chain you have uh those uh validators that are incentivized to be there uh for like client sync uh and there are 512 of them uh every time and we can just make those the aggregate or and uh because they are incentivized they they

actually uh they will have bigger machines >> then we can resolve the to touch a little bit on this like usually structured topology um what I what I usually understand from that is you have a deterministic way of routing messages between between nodes which usually requires you to know which nodes >> are part of the network and to know their end points and that is generally something that we refrain from disclosing >> or at least kind of like embedded in the one which is something that we can do >> in in lean today as a shortcut but in the future the proposal that I wanted to bring to the table is we have a

primitive from the primitive team at EPF that they're kind of like started working on but we don't really know how to leverage it but we know it's going to be a useful building block in the future some kind of >> secret leader election >> no so there's a specific so they they created a scheme and there's actually it's um the performance characteristics don't actually allow it to be used in a very like repetitive way, but it can be used for peer-to-peer. Um so basically the notion here is that you're able to prove to the without disclosing your identity or without disclosing any details that can further dean anonymize who you are uh you can prove to the network that you're actually a validator because right now one of the problems of peer-to-peer network is that it's

entirely permissionless >> which means that surprise surprise if I spy a node right now vegan node any vegan node I'm going to join the peer-to-peer network and guess what validators are going to rely on me to forward messages as well, right? Become a fully fully fledged member of the mesh and that is a massive problem because you have anybody can start a node. Uh and very frequently there's churn because you know we people like us and like hackers, developers and like anybody in the world that wants to try out the tech starts out starts up a node just for some test, right? And boom, you join the network and you're just there for five minutes.

>> Yeah. And during that time the network gets started depending on your routing. So this is something that we want to avoid that in order to build a hydroponics um broadcast layer like we want to put here. We had to find a solution for it without and then like kind of like the top of the decision tree becomes do you want to disclose are you okay disclosing uh endpoints right and membership and who's running behind each endpoint which is uh what permission networks like for example do right because they also have um optimized infrastructure to deter or to defend against DOSs right so they can afford to do this but if you

want allow for permissionless participation in the network while at the same time uh concealing who you are and what your end points are so that the network can build a topology that takes you into account with like that that's basically where and by the way I said we we should probably touch on this in the next session but we don't use >> I have a question that might be completely irrelevant to this session but why why don't you already do this to improve you are validated because you should be able to use your keys to say look I I own those >> it's essentially it's essentially what the protocol does today like you can deanmize 90% of the network today >> simply by listening for some period of

time >> which nodes like where which who's which nodes are the first ones to attest um at a specific point in time where you know that specific validators are supposed to be tested And you know the roles of every validator in the network, right? The duty of every validator at every slot. >> So then you can if you if you have penetration in the gossip network um enough that you can pro like that you can um have good reachability to understand who's the first node that sees a message that broadcasts a message or like handles a message. Then you can deonymize and like 90% of the network can be demized in this way. But the

important part is that this is not baked or enshrined into the protocol because nowhere do you specify in a consensus object what your IP address and points are. Right? So that's um that's kind of the and we don't want to do that either. Right? We don't want to do that. It's not. So then uh one idea here is if you have a proof of valid agency where you can disclose that you're you can prove that you're validated without disclosing who you are or anything about you. Then you can join a like a um let's say an overlay mesh right that is used for by validators but backed by validators and

then everybody else can still read but cannot write or cannot influence the outcome the propagation there. >> Is it like something something like ring signature scheme? So you basically sign that you part of some uh set of validators for example but it's not really you based on your signature it's not clear who exactly sign >> I I don't I can't remember right now the details of the of the scheme we can look in we could look into it it's um and there's actually an implementation as well so you know it's we can consider integrating it already in leading specs um if we want to >> the the it's a zk it's the CD based

thing. >> Yes, we just uh what we don't want to lose is accountability of validators. So if they sign the message, we should be able to actually understand who exactly did this so that we can punish them, >> right? So this this would be for like think of this as being a primitive to use the transport name to create like a high performance like somewhat authenticated link without au like without disclosing who the other party is, right? Um, so if you present a book to me and I present a book to you, for example, it can be like pairs as well, right? So we each know that we're validated, which is and therefore I'm going to prioritize what I send to you and you're going to prioritize what you

send to me over everybody else. >> So that's one way of using this. Um, regarding performance, how many peers do you want each node to connect to to have like uh the best distribution of messages? So one of the things that I would like to see maybe this group or like you know a broader group define is and maybe it's too early even perhaps we can like signpost some numbers is if we have a road map for the dev nets and this can unfold right so it can be like dot dot dot but for each I want to I would like to see what the intended network size is

>> because that will then drive different network topology experimentation to cater to those network sizes and at the same time maybe there's like some expected improvement in like um signature schemes that will like further reduce the the footprint of signatures and like we can I think what I would love to see is a matrix of how the numbers and the magnitudes are going to evolve over deadlines because That's I think what Continental if you take a very simplistic view here of what the peer-to-peer network is going to be doing is it's going to be

moving by around the most efficient way in the most mechanically sympathetic way with the protocol. So we need to create dedicated networking layers like a dedicated networking stack of for Ethereum where I think what we do indeed is going to influence as well what we bring into the L1. Um I think this is a very good start. I think we should keep this like kind of like whatever with this. Um actually we we just like discussed earlier with I think coming in formally that I think one of the biggest like moving parts in the office like specs is is networking right. I think there's a lot of proposals going on and there's also you know like moving parts in terms of like the lead sync and lead VM as well. Um,

so I guess like our our goal here in the next three days is not defining the the the definite come up with like all the all the the candidates that we want to consider um mix matching into the next future test. So I I think this is a good >> right u maybe just before we uh we turn this into the peer-to-peer session which is going to happen. Yeah. Yeah, we will. >> Um I mean I would mind saving some time but I still have a question this session.

>> Uh but then that's zero. >> Yeah. >> So we haven't launched it. We have the tools. >> Um we have I don't know how much longer but uh 1 hour something like this. >> Yeah. Um until uh you know three >> 1 hour >> 1 hour >> 1 hour and half an hour >> until three or >> three is the next >> uh yeah three is the next okay 1 hour about okay doesn't matter it's it stops when it stops um what I would like to do honestly is see if we could at least because I I think there hasn't really been interrupt uh we have at least I'm not aware okay I was making the joke I'm not aware of any docker image for for culine. I'm not aware of any attempt at

running and zinc together. >> I'd like to make this happen. >> So, uh I would like to finish answering everybody's question >> and then take whoever is from those teams and I have a machine running where we could run and we could try to get in uh >> sorry, was it called lean quick start to run and if we have this >> um we find a problem. If we don't find any problem, well, good job. Uh, we're done. We go home. But >> but uh otherwise, yeah, we just >> The thing is with this schedule here, I don't see any Okay, I guess there's

tomorrow, >> but um yeah, there's not much time to to start debugging. If you find some problems, we have back and forth and things. So, Yeah. >> Do you have uh tools like if panda ops kurtosis or something to try to monitor >> it like that? No. >> So, so what happened is that uh I'm trying to be here. You can cut it out.

>> So, you know, I'm pretty famous for finding bugs in every single >> Anyway, um the problem with crytosis is that it's exclusively Docker based. if you want to if you want to connect to debugger if you want to do all these things uh so okay there are many problems with certrosis uh and in fact the recommendation that we've write our own tool is coming from PK 910 from Philip I can't remember his last name just now but Philip from from east ops uh that we do this because cryptosis

will will require them to uh to write their own genesis generator like there's a lot of tool of go code that needs to be written before um and uh yeah they don't want to really spend the time in building this until they know we have something >> okay >> workable. So this is why we have this script that we can use. When this is ready, we can go back to them and say, look, we have this config. Um, you know, please create this genesis generator. Please create all those things. I mean, Philip has already done some of that work, but um but yeah, I forgot the reason. Last time we talked about this in during a meeting, he said, uh, yeah,

let's try first without the whole shebang and then we can streamline this into a curtosis conflict. What is your onetop shop for your uh network deployment tool? >> Yeah. So, uh when you want to build net, it's a great tool because you just write your config with your docker images and everything and it will um deploy the network for you. So, it will create as many rim uh clients as you want, as many uh as many keys. it will generate the the genesis like config for you everything. Um but uh yeah it's uh it's a specific tool that uh they they like

Emans and it's only them who really know how to use it. Uh so that's why if they don't want to help us uh because they have to do uh if they don't want to help us we're kind of >> cool. So I I guess like we already got two topics that we can uh focus on for for the next two days. Um one is the P2P designs. The second thing is the the three client interop. Um any other suggestions, other proposals? >> Testing, >> testing, >> spec testing, >> spec testing, >> right?

>> Testing and working. >> Oh, would this be part of the inter thing because you mentioned that we could also like do like spec testing or something. >> Uh I can touch on like this. In fact, right now we have the spec. Yeah. So inside that we we have the primitives and the first element of the spec. Let's say for example we are like proced kar and some state take function so that we can play with most of the primitives to test that we have like basic p test just to test that the python works but for now we don't have like tests that can be consumed by clients like it is done for example in the

execution spec or consensus spec where where you have this kind of test vector that you can serialize ize and import into your client in order to test that and so that we have a common test vector. >> Why we don't have that for not because I didn't have time to do that and also um because I think that we have to have some discussion with the steel team. I had some with Leo and with Fipe they proposed different ideas and they have much much more context than me to do this kind of of stuff. So I will let them cook.

>> Yeah. >> And then of course I think that right now they they both open some branch and work uh for specific file. Then of course once the setup is done and once we know how to think that I can duplicate for other files test but I will let them cook for for this part and maybe I discuss also with also a lot of experience with the client. >> Yeah. Yeah. One thing we could do uh so is review their branch what they've done. Uh but unfortunately it's a team that's not unlike espan they're extremely overwhelmed with a ton of requests from many topics. So uh on top of that it's a weekend they're in a time

zone that's compatible with this one. um it's going to be a bit hard to get anything to achieve any unfortunately a milestone on this but I think at least discussing it and providing them with some feedback would be quite useful. >> Yeah. Yeah. >> Um just also raising a quite kind of suggestion from from Kinder as well. Kinder mentioned that um for I think Leo's approach right now is to compare based on the the final state route and I think he he disagreed with that. Um I'm not so sure if Gon have more context on that >> just just for flagging. I mean check. We need to double check. I think the PR because in fact he submitted an issue on

the repo that is a suggestion already suggested for like the beacon chain, >> right? >> So there is already a lot of of context. Yeah. And there's there's PR I mean like the the actual implementation PR because I just an issue and Philipe open the PR that he send me internally right trying to bootstrap something check >> I mean just checking the state route is definitely not the whole picture but it's already a pretty good yeah >> I mean at least you know the transition function executed properly then of course you need yeah like if you want to verify everything that is not related to the transition function that's going to be missing. But

>> yeah, >> what I can tell you also is that will probably be different than what we have currently on the Bitcoin chain because we have the Y and all of this. This will probably be replaced by a more andic friendly serialization >> something a bit thinner. So yeah, >> forization uh JSON is okay. So >> yes, it was a little bit too the first thing >> because uh when we did the first test of the beacon chain, I insisted to have YAML because um we had issue. We wanted to add comments into the tests to explain what was buggy or not. But in

the end, we never used it and YAML is just a pain to implement serialized. The serialized >> you were the one. Yes, I was the one that that pushed for uh atization with comments. >> Are you the one who pushed for digital? >> There is no reason to use big engine. No reason like x86, ARM, CUDA, AMD, everything is Italian.

Don't uh don't get triggered >> except for beginners if you want to start beginners. >> Anyway, >> anything else? Um I guess the purpose of this is just to make sure that everyone knows like what these are probably going to be like their own separate breakouts it seems like. So I just want to make sure that these are relevant to anyone to to everyone. So if there's something that is still missing you want to discuss about this but not part of the list here yet please feel free to to mention >> uh I'd like to revisit the two months ago docs uh I can post the link in our chat.

>> So there's a um GQ net zero lockdown file and link >> Oh right that's >> yes yeah that that's like right after beam day I think. Yeah. So two months ago it it uh suddenly uh uploaded and there's no update on this net the specification file. So uh I'd like to suggest that uh we are kind of lacking a single source uh the success criteria or the meta specification of current dev.

So uh as a single dev single dev I'm kind of lost in uh developing this uh clients uh so I'm just looking for the link back and but what's the goal of the current net is is kind of uh gray area for me uh in this September. Yeah, I'd like to Yeah. I'll just write directional plan or something. >> Yep. >> So, uh when we did the begin um we had a common repo called if uh-client and we put all the uh test net config uh inside so that it's shared. We didn't put goals

uh but that could be uh you I think you can use a linear frame organization to create a a test net uh repo and there you put the config and the goal uh so that everyone has one source of truth um >> and I guess like once we we if we are able to achieve like now then I guess we can start to fix the numbers on the actual targets >> and then introduces configuration >> configuration is that uh would that be part with um no because curtosis is not going to work this this weekend for sure. It's uh it really needs a lot of work because it's too different from beacons. They need to replace core components difficult.

>> Is that something that we need to kind of like decide as a whole or is it more like splitting the task and finish the task? >> No, it's just us getting enough attention from these kind of ops. >> Okay. So, >> yeah, >> it's unfortunate but yeah. >> Okay. Okay. >> Uh, anything else? >> Do you have a channel to synchronize and discuss between everyone? >> We have like the table.

>> Yeah. >> But maybe you should have also well a GitHub repo for more long form and >> we have like a PM repo inside. >> Okay. >> Yeah. So any kind of like spec work that goes into the inspec inside the yeah meeting nodes and decisions um those are in the Ethereum/PN >> okay >> then all the previous meeting not >> yeah we are like general like deb group with everyone we have like a lean spec deer group for the developers who are parting into the fake and we have the PM PM repo and we have a meeting every Wednesday Okay cool.

>> But but to Jun's point, um we don't have like a tracking of like a high level like goals and whether we are achieving them. For example, how many like validators are we expecting to run? What's the like the um signature generation verification time that we are trying to achieve like that's that's two months ago, but we haven't revisited. So that's that's something that we can also improve there. So what we did was um we had a recap either at the beginning or at the at the end of the call uh saying uh well always about the devet status uh so that they have very um uh because otherwise you spend a lot of time talking about spec

what works what don't and not about the real implemented stuff. Any other suggestions? >> Okay. Yeah, this if this is for Z we want something for dead one. >> All right. So, should should we maybe discuss about that as well? I mean I don't know because um you know we we need to discuss the peer-to-peer proposal uh have see what's what's going wrong uh in the dev net like when we launch the

the clients and things like this but when all of that is covered I guess we we will get a much better idea of what we want for that net one like we can decide oh this is what we want to work on and we do it um >> actually related to that Um, I wonder do we do we have to um specify more of the P2P stuff for net one or do we can we actually stick to like what what we have right now? >> Well, that's what I that's why I would like to have this session to to answer that question.

>> Do we can can we use this session to do that or do we think like we have to wait for like say P2P session first and then reconvene to discuss about it to >> Yeah, I think we should have the full peer-to-peer session. see if it's a good enough target like you know the the biggest question I want to know is how long is it going to take to implement >> because if it's you know if it's a 5day process then definitely that should be a target for net one if it's a five year process maybe dead two also maybe about signature aggregation but

yeah it's a long and uncertain process that you say >> or do you have do you know any updates regarding aggregation like whether like that's potentially possible for the dev2 which probably starts from December or January to be too >> maybe I I think like the main thing there is the uh full recursive proving implementation that could turn out to be a bear or maybe achievable within that time frame. Yeah, it's very difficult to say because right now we don't have first we don't have like the full recussion that means that we are able to aggregate fresh signature together but we are not

able to aggregate the proof for aggregation first and second like we don't have like sufficient numbers for now this is RNG process so this could take a week but it takes winding up like Would it be worth like trying out aggregation but without recursive aggregation just a simple proof material? >> Yeah, I was thinking about this. Maybe this is enough because if we want to do a test def with a reasonable amount of of nodes maybe we can just aggregate and just don't do recursive aggregation to simplify a bit. Oh yeah, there's like

a trivial aggregation scheme which is just string concatenation. >> Yeah, but I I I mean that if you want to simplify, we can just um have a reasonable amount of node and just do like aggregate uh just 1,000 signature for example and don't do like the other part of the of the aggregation, >> right? Yeah. we could have a single layer of aggregation and uh if we can't do enough signatures in one shot potentially we can just >> you know do that several times and then concatenate those proof so that

>> might work aggregation um I want to ask like is it worth discussing about that there was a PR open about staking team um is it worth discussing about that within the next three days? you have that maybe let's have more context but actually I think that the concern guy will be there like for the C retreat just after so we will discuss this still is an open discussion we don't have the real final proposal and so there is no final decision >> yeah I agree I don't think any of us can give a

>> yeah like significant amount of input for us to iterate on and then like even after the workshop next week like >> I would suspect it to take like >> okay >> a bunch of more time to to even talk about a >> spec probably probably more on the lower priority for the next three >> yeah we can definitely think of roles but we we're not going to go all the way to to this place of proposals from lot of people Maybe quick question then um the the open PR on rainbow staking. I think it's only like renaming validators into

stakers. >> Yeah. >> What do we do with that? >> Two guys who reach out and who are interested into participating into the thinking about rainbow taking. >> Yeah. >> And so yeah they want to you to think about that will be there next week uh at the retreat but for now this is just a separate branch >> and just work in progress thinking on that side >> what is rainbow thinking >> rainbow basically so right now we only have validators which is basically

proposing proposing blocks and also attesting right it's the same ID does the same same role right we want to script that out so that uh you can be just a staker can choose a role. So you could only be just proposing a block or you could just be testing to two blocks but not proposing or proposing and not testing. Um yeah so so rainbow is basically dividing the rows into multiple >> I think that maybe you have more context >> it's pretty much it it's basically unbundling the validator code as it is maybe there's also this uh like in addition to what what said there's also this notion of delegation input code delegation which we may consider um so essentially like at the end of the day

we may we may have um like includers like for censorship resistance. You may have a test of the um the best lightweight duties and then proposers as as a different role as well and then also like this additional matrix of like an undelegated or delegated role. So but yeah like for now we are like we are not even sure as an Ethereum community if we are supposed to go there. So there's also which we have to take into account this at least like some more let's say conventional conditionalist notion of like uh not unbundling modes. Um, so let's say the phone node is still able

to do all as a as a validator. you run a formula and you're you're basically supposed to continue to do all of the task like this is obviously it's also a potential part like the question is then how does it like uh relate to do we want to scale the network to which degree do we want to scale the network so I guess it's yeah it's the rainbow savings more is just one proposal to picture a way and paint a way for for us to um uh to yeah to essentially scale the network at some much.

>> I think that the next lean goal will be dedicated to reinfor >> in November. >> Okay. >> I think the >> Yeah, maybe I actually the call not not the call to the public. Yeah. Right. Right. Yeah. I think Yeah. Any >> any final suggestions before I guess like we can then after this we can split into like smaller smaller breakouts depending on topics.

>> Actually I have a question about this because I was looking at the agenda and apparently the break starts at 2:30. So are we already at the end >> what we could do is like end the session like here I guess and do the break now and then start at 3 with a job. >> Yeah. I mean we we we started half an hour earlier because so I guess it's now is this a good point to to finish the discussion or do we is there any relevant segway you want to sorry relevant part we want to add here >> maybe one thing is who wants to like if if we're going to look at all those topics with develop one not being very uh like done immediately maybe we want to see who's going to work on what or

>> so that people feel ownership somehow. >> Yeah. >> Otherwise, nothing is done. >> Yeah. >> Yeah. >> Makes sense. Um other thoughts that we can just like test. >> Yeah. Okay. >> So, you just need to jump. >> No. Sure. So we we don't have to do it this year. >> Um you also have to work with the the >> Yeah. Yeah.

>> That requires June and comm. >> Are you okay with that? >> Yeah. But I mean I I assume the like the most of the work will be done tomorrow afternoon during the >> I mean I'm definitely going to try tonight after send you to branch. >> Right. Exactly. But um I I would say there's there's a whole time allocated for for work together tomorrow. So this is probably when when this happens. Yeah. >> Um but yeah, just maybe person. So >> right. So so clients interrupt. I'm also going to go to sleep.

um PGP stuff. Um I guess can I >> didn't quite catch your name, but I think you were also interested. >> Morgan. Yeah. >> Morgan. >> A little too. No, I'm just kidding. one I think we probably since like we have other cryptographers here we should discuss about it >> yeah I think for the last two bars this kind of optional

maybe we don't need to divide ownership because we >> um but I guess like the plan is we focus on the drop stuff getting it done tomorrow and maybe The third day would be >> yeah yeah >> but I think all session afterwards conflict with crypto >> I don't know >> how can you agree >> um because like at the moment the other session is proximity price this one is devet >> but I think the some of the session will be cryptography and then um >> client implementation and so he will have to present for example so you won't have cryptographer terms.

>> Yeah, I mean the other way we can do is we can in terms of the clients we can start thinking about the specs for that one and then whatever questions we have for the the cryptographers then we can >> but honestly the aggregation part uh just do your net one with BLS signatures uh do the naive aggregation and we can just make it so that the um aggregation uh the future aggregation on the crypto side uses almost the same API. So we limit the the uh friction. Yeah, there there will be also a discussion with Bit the other room for key generation and so we can group like XMSS aggregation recussion

and yeah in the same place >> BLS wise uh do we have to like is there something simpler that we potentially would have available in zig that we could use uh >> uh but you can just use um blast which is in C >> and Z calls C easily. >> Okay. Um yeah, the thing is with blast uh okay if it's written in C I assume it's written in uh what kind of C is that like is it crossplatform C?

>> Yes. >> Yeah. >> Like >> it even compiles to IBM S390. >> I'm more worried about the operating system. Uh it supports uh Windows, Mac, uh Linux and uh you can compile it with uh uh CNG, GCC, Mingu uh and supports ARM etc. >> Can I compile it with uh basically a freestanding target to use a zip term um meaning no no OS support >> there is no C calls at all. So it was written so that it can run into a arm um uh trusted enclave.

>> Okay. >> So um it has some uh not this calls but it can query the CPU for capabilities uh on x86 to choose whether to uh switch to ADX uh for uh some specialized instruction and for SHA 256 support on ARM. But that's all. That's the only CIS calls or CPU specific calls. But um it's even optional. >> Yeah, you can turn them off, >> right? Can turn them off.

>> Yeah, you you compile with uh underscore blast_able and then you have absolutely no dependencies. >> Okay. Then it also compiles for example. >> Right. Okay. Yeah. Okay. The smaller the set of instructions of the system calls that actually our nodes do the better because uh if we also plan to use for example our notes for simulation under the shadow which actually replaces all the system calls with the uh their own then sometimes shadow just simply doesn't work because well it says I don't support the system calls >> there is no s calls in blast there is not even uh maloc calls >> mhm

>> because you cannot do maloc inside trusted in case Okay, I'm just saying that yeah, we should keep it as simple as possible so that we can simulate easier. >> There's no mal that might work. Okay, so I have to compile yet another thing to do tonight. Uh compile last already has like bindings and we support >> yeah star. >> Yeah, but star is different. It's just that I assume if I start doing verification inside a ZKVM, I'm going to have to do that stuff and it means I need to be able to cross compile to the TVM target.

>> Um, >> that is support. >> But why would you do verification of blast inside >> if it's part of the state transition function? >> No, no, I don't do the verification of blast. I mean technically I would um I'm not I'm just like I would verify signatures which is part of the block transition function. Yes, but the um if you look into the consensus spec for the Bitcoin chain, the verification is called fast aggregate verify and it's just a a standalone function. And if we replace um by the CKVM from Thomas and ML, I assume it will be also a function.

>> Okay. So you mean like a function like a >> a freestanding function and uh >> just a regular function that I create as a C file. >> Yeah. >> Okay, perfect. Yeah, then no problem. >> Okay, cool. Um I guess we have to wrap up. That's a good point. Cool. So I guess uh just to kind of like summarize um I think we have like three important topics for tomorrow for after this tomorrow as well. So there's probably going to be discussion on PGP designs and proposals and then interopers.

>> So the P2P conversation going to happen like >> Yeah. Yeah. from from now on. >> Okay. Cool. 3 p.m. for the T2. >> And then day three we talk about dependent one and aggregation.