All Core Devs - Consensus #43

Transcript

[Music] [Music] [Music] okay cool thank you everyone for coming

I'm really sorry about the delay this morning I was on a panel and we had technical difficulties and I it was both push backed and I ended up streaming the video so I kind of got sucked into that you couldn't leave early so but we are here now I just shared the agenda issue 165 we have the normal stuff and we have a couple of things including talking about incidence response week subjectivity a quick sanity check on the update hash kerb 9 which I didn't know existed till now and other things cool so we will go ahead and get started

testing release updates we have new 0 12 2 is queued but we are still working on a few things it's backwards compatible some clarifications and fixes in the network spec and we are the blocker on getting this out is tuning the gossip sub parameters there were a couple that were obviously not prime for the kind of you to configure in the context of thinking about slots and how long it takes for messages to get propagated so we have a couple updates that coming and are in some conversations with our friends at protocol labs to Sandy check and go through all the other parameters before

this next release those all will be backwards compatible updating the parameters locally but obviously we get a more cohesive gossip strategy as everyone upgrades proto do you want to give any update on the rumor chain tests things like that sure those fake reduce new rumor updates but being making slight changes since so there's 15 working groups lots of new commands to debug stuff that not every Newton mantis forest health

and welcome on the chain related comments think is Martin kinda thing you do the Phil thing instead of directing what saying like or maintain the chain are procedures worked on this new stop functionality so you can base for responses requests and all that and smaller to thing comments sacrifice um this generation is getting started being enabled and for a Python a if to Fastback optimized version of the

question along with trying some use a standard star which is making great progress there and the Dove style class well and protocol if I'm wrong but you're currently thinking that handling for choices via rumor style testing is going to be more tractable approach and it's kind of what we're holding off right now the Alex generated test from TX arts exists and we encourage you to use them if you want some additional testing there but that we're gonna take there are changes oh so like pitched us I'm releasing tutorial for rumor and explanation in the front lightest person

like the too long didn't read yes that's integrating another ourselves of interfaces and every other clients to inject blocks and injected stations and have it be like Lisa not real it's quite difficult because my clients immunization and like Wesley ignores the protocol that are enough through the protocol of something that projects out the data and that's the clients and to do this eloquently I hope that we can have straights define like which looks to imports and then they talk to serve

and that's it's like keep it very minimal that's also very useful to share today right so a test might look like ice I gossip you directly three blocks five at the stations and then your status is gonna tell me that you have the head but I expect something like that pretty much cool thank you for all that if you haven't looked at Rimmer then there's getting pretty awesome and pretty powerful recently and might just be useful to you so I like getting in just a handle on what this tool can do I think would be valuable at least having someone from your team take a look at it be good

cool Betty's here I think to give us an update about fuzzing nope hey everyone just a quick update on be confess I've just finished writing our latest blog post should be live in a few hours where we announced the completion of the localization process of through fuzz so as a reminder the idea is to enable community fuzzing or fuzzing at home as Danny calls it we have super detailed set of instructions keep and set it all up to fuzz all clients on all targets he'll spend one hour per buzzing target and move on to the next one I guess like Justin who came up with the idea originally and helped us test this and

troubleshoot this we've created the discord channels people can report bugs if they find any we can help them troubleshoot their setup if they have any issues in other news we've identified two high severity vulnerabilities lately one on inves lodestar the name this one is an index error that can be triggered over the wire externally would be a tester slashing processing function so basically due to a lack of encode validation when the station validation function is called you can get the client to crash this was super quickly as always by the members team and the other one as I mentioned with um lodestar it's a memory exhaustion

Donnelly went passing in Guardian on so you can basically maliciously craft en up strengths and those can trigger a JavaScript heap memory error which can cause the entire JavaScript process to crash one of the panics we identified while fuzzing the White House on an upstream library snappy crate has finally been patched we submitted a PR about two months ago and the maintainer finally emerged that one in so it's a bit of a relief it's a bit worried that we'd have to maintain our own patch version so all good on that front and I guess now that the state-transition spec is pretty much finalized we're shifting our efforts back to the differential

part of because so III furs and each tool if are pretty much complete now I've just finished counting will identify the total of 26 unique bugs across all major it's two implementations so that's pretty much it from fuzzing I don't know that if you want to piggyback on this and you talk about instant response or that's our first sounds good cool thanks many other testing and release updates or any questions okay um quick discussion of test nets

altona and again we'll save the incident response to later but ultimate is running we didn't have a little bit of non finality due to a whale showing up and not writing there nerd but generally things are looking pretty good and I think I've reached out directly to client teams to talk about when and what's still on the plates before we're comfortable moving on to a larger scale multi plant test that it's very public facing and it seems like there's some little things in the works a couple

clients working on stability issues and playing down why applications are not always getting in and people are hardening out UX just making sure that key management is going to look as close to that as possible so that the experience would get people on a Cessna carries forward I'm also working on I've been playing with some of proto scripts to spin up nodes easily to get attack us to be spun up really easily and that's something that we're looking at during the next week week and a half is to have an attack that running the parallel that we're requesting people to please break my current plan I think image mysteries

go is to again we'll talk about the incident and a moment other things people are wrong tenants cool okay so we're gonna move on to client updates and we will start with lodestar your mics pretty low if you can talk me close to a mic yeah so last few weeks we merged in our 0.12 branch to

master it started we started kind of lurking on in Altona kind of sink or 0.12 compatible with the exception being gossip sub 1.1 which you have not merged in yet still a few blockers on the limb p2p side to just be the the large philippi TP side we started connecting the chrome debugger towards running load started since it's really handy for profiling and in an afternoon Pro helped us and we've kind of optimized some pieces of art state transition and to great success so I think we're gonna be

in good shape using that tooling we're still there's still a few blockers on the stability side so it's not really working fully yet but making good progress in the past few weeks so we're feel like we're closing in on some something that's kind of like a Minimum Viable client we've gotten a few new CEO eyes working we've got a validator sea lion an Accounts you lie so that makes things a lot easier for testing too so yeah we can good progress great and were you able to get two outs

on his head no so as of last night I got two the epoch roughly a hundred and ten okay so before I called it quits gotcha did consensus in an era where you offer you just so there was uh we had a bug in our SSC which we worked through and then at that point it was just waiting on sinking kind of having a few bottlenecks in our sinking like archiving blocks and rock climbing state little slow right now

thanks gaming Trinity everyone similar story working on getting Trinity to sink altona so this week we've been working on refactoring our FERC choice so we can implement further array which should give us a much more efficient work choice grant has been working on sinking so he was able to connect to lighthouse nodes on Altona and could put on blocks from the network but again our sink speed is like way too low so our next task will be working on performance optimizations another mind

hey so in the last two weeks we had to refocus on material on clients and we didn't make much progress progress on these two so we started soon I hope cool curious did neither mines see any usage numbers jump after the awkward death call us.we yeah sorry again after D after the awkward death call or that is it I focus on client diversity did never mind get a bunch of new users nothing very visible promo line and 20% increased I started running thanks to us ok can I just ask my divine

what's your take on running of the mind as an East one client for the deposits so we we published an article how to do that so we are running girly notes that would support prismatic labs in lighthouse make clients see the prison and lighthouse and they both worked with net amount as a if one deposit provider the information provider and at the same time we are working on binding our own implementations for baths there you can do that therefore and we also improved a lot recently because like after after we started to have heavy usage of etherium one for interim to the deposits used a

lot of the pre-compose related to the cryptography and we had them slightly slow and lost last month as part of the preparation for a burning heart for a claim a huge improvements of those precompose which means the gallery in any amount of syncing is much faster now so it supports it here into a very very nicely in the Des Moines alright great thank you Nimbus hi so in the past two weeks we had a lot of work done on fixing bugs raised by

Altona networking concepts and also work really working on the mist artists stations we have audits that will start in on Monday and we are working on auditors Handbook which is especially valuable because a name is completely unknown language to auditors link below and similarly for altona lots of work done to help or to involve people as validators and the link is also in in the chat and we have an ongoing effort

to documents and also to debug Oh Kobe's great thank you I know there's been a little bit of a gestation stability issues maybe the longer you're running into miss flying is there any headway on that we we know what it is we're working on the proper fix it's an issue in the b2p were gossip table isn't maintaining the mesh correctly okay so we expect this to be fixed like in the next few days like it

it's fairly talking at this point what it is that's cool thank you very much prism hey guys Terrence from Chris Matthew last so we have been spending a lot of effort on revamping our accounts key management so that's underway we have added new features such as creating new accounts this thing you account for using direct key store we're also working on remote key store as well that is in parallel and we have started reference remote sign there repo as a proof of concept so people hints so basically people can study that we're also working on integrating

Supernationals POS library into runtime and the initial result was promising we're working on cross compiling with the field so that we have readout for it for our day-to-day user and there has been significant improvements to the initial speed we've added batch signature back signature replication for block signature rendao and attestation signatures we're seeing about two to three times in crewmen on that so that's really exciting we're still working on addressing all the audio feedbacks there is a lot of them and then other than Badgers

constantly but faces and u.s. support so yeah thanks great parents lake house hey everyone yes Oh Paul resumed the work on our rest API and he's getting very close to having that completed which is going to help the dev work on our UI which is about to accelerate in the next couple of days we've also been working on integrating blast the beers library from supranational and started noticing a pretty good 75 percent increase in our sinks feeds on altona there's a few things that need to be tied it up on the rust binding side but Paul's currently

working on this we are finalizing our peer scoring system that will be introduced in different stages and will allow us to ultimately kick and ban malicious feeds connecting to lighthouse there's been reports of a deadlock that age and paul are currently tracking down along with some excessive queue usage that was reported by external users on Altona we've also observed an issue with our attestation efficiency or some validators were missing about the stations so the guys are investigating this as a high priority as you can imagine Michael has started the work on our /aa he's currently focusing on the design phase to make sure we get it

right and optimize resource consumption Adams been refining our database access to my city and we've completed our response to the trail of bits audit the report will be public after they perform their retesting of our fixes which should hopefully have been pretty soon and we've received two proposals for from shortlisted vendors for second security review and are in the process of organizing and conducting selection introduced it's pretty much it everyone so we finished implementing some improvements to memory management during

periods of non finalization as well as some other memory optimizations which means that our memory usage overall much more stable also in order to speed up the noon startup time we're now persisting in crota arrays date to disk so that allows us to avoid reprocessing blocks at startup additionally we've made made some pure management improvements related to establishing connections and we're now prioritizing connections to try and get even exposure across attestation subnets we need to release some small fixes to JVM would p2p and fix an issue with attestation gossip publishing we also fixed an

interesting bug that was causing us to produce invalid attestations Adrienne has a good write-up on this so I can post that in chat in a bit but basically the issue is we were failing to detect chain rewards that due to apparently skipped slots that were later killed by valid blocks that caused us to fail to recalculate validator duties when epoch boundary blocks changed and that led us to produce invalid attestations for the wrong slot so some interesting work tracking that down and I'll post that right up and that's it for us okay I believe that was everyone I would like

the next thing on the agenda is incident response obviously we've had I think with slicey we had an incident that we internally kind of there was a bug in the spec actually that we rolled out and had clients respond to and yesterday we had an incident which was Maddock generally handled many wanted to talk about our general approach and strategy moving forward to just responding to incidents on chestnuts and yeah thanks Danny yeah so nothing really concrete here but we just had a quick chat with onion I guess I wanted to announce that I'll be helping formalize the incident

response management for you two so the idea is to have a solid framework that we can all refer to and things go wrong once we're alive so we'll start by defining incident severity levels working on proper response procedures who to call when get a set of easy you know first troubling troubleshooting steps that people can follow put an emergency contact list together and see if we want to potentially share that with other stakeholders thinking of staking calls for example so I guess the first step is to create a small working group with ideally a rep from each client and try to learn from the each one experience

and yeah make sure people know what to do if when things get hairy so I guess I'll be reaching out to the client teams individually over the next couple of days and we can start discussing how did this together next week if that works with everyone yeah sounds good other than the formation it's working group does anybody have any comments or thoughts or questions before regarding that one of main issue is time zones we will need to have some kind of follow the Sun where we have multiple peoples depending like at least two people drink

that's what I meant by you know who to call when is being able to find the right person depending on the time of the incident and the severity as well okay the next item we have did you put together a great document on week's activity both explaining how it works explain how it works in the context of the spec and how it scales according to validator set size and also I think

there's some recommendations in there you X because we need to figure out to deploy these safe states and checkpoints to new users that are sinking by the network and so that probably falls partially onto clients hands a digit do you want to take it talk about you know about just quick background on what's going on here and then we can move on to like the UX discussion sure so basically weeks objectivity is required in proof of stake chains to avoid the double spend it's basically

one of the more viable attack vectors for proof of state consensus and yeah the document is supposed to be an introduction and not a specification for what to do but hopefully that gives you an idea of what might go wrong and how we can prevent this it has the two main tasks that appear are going to be the client side for choice handling of weak subjectivity and then the more important discussion point would be how we distribute these weak subjective States and that's something that is going to become regular maintenance tasks for clients where you know you update these

states that whenever new clients come online they download from somewhere and the point to discuss is how this download happens and where this download happens form and since this is going to be maintenance tasks for client teams we want to get your feedback and your thoughts on how to do this yeah so I have listed four methods to do this so you can either put the state in your code base in your releases and new clients just download it de-facto the other way is pass it as a parameter so that you expect the user to download the state from somewhere and pass it as a CLI parameter when they initialize their

client process the third third way is have special boot nodes which are responsible only for providing this state so whenever new nodes come online they'll look up this boot node and download the state from that and the fourth and the most decent last way to do this is serve beat subjectivity States over p2p and this is also the most intensive to implement but yeah so if so if anyone has thoughts reviews questions about this P to do what now and yeah so one thing that comes to mind when I think about the trusted that

might serve you this state is that these boots could be Byzantine it's very hard to tell where is like they could serve on user a some state and there should be some other state and actually publicly verifying that that that happened and you know maybe the social cred of a client team being diminish because of it is kind of difficult whereas these being released in signed releases provide a little bit more of this public verifiability another another thing is that I think regardless of the method having a - - start state and for a user

being able to override is also like a very important and powerful dependent oh so like although I can trust what is maybe cut into my release I can also override it because I can go and look and decide on what the state I believe it is I think one of the important things is the client teams releasing the state there's probably two primary methods one is cutting a state route into the release the other is actually cutting the entire state under the release obviously the state even in the event that there's formally validators is relatively bound in size I think it's less than hundred Meg's so it's not like a crazy statement

burden on the sides we released but it is something to consider but the other thing to consider is that is the implied in this is irregularity abilities so if you look at some of these numbers when invalidate or set sizes are very low police activity theory becomes very low and so if there's only $1000 if there's no change you might need to be cutting releases like every half day which is but when we start getting to the more realistic validation numbers say fifty thousand hundred thousand the the one week range becomes I think an obvious

target for releases and I think there's there's probably there's probably more to work through here that we're gonna do on this call but I think client teams getting in the habit of releasing every one week and including updates to either a hash or a state I think it's gonna be the same version of this process well mean if and when we have three hundred four thousand validators I think that that could potentially be pushed to two weeks and I'm not looking whatever is now so that might be at this speaking but the one week is certainly a good a good target knowing that there's other things to talk about here but just

targeting this this one component is weekly a weekly release something that clients use one if maybe already planned on doing or like a philosophical argument so we have here like if we as fine teams are expected to sign a release with the state state but it's a pretty big target on us to be coerced into signing something else or evasive failures there's an eye ability question right

solitary comfortable crowd together about that so even if you are coerced into signing something wrong it won't break the network it might you know tarnish your brand or something but it definitely won't break the network so if it happens you know because of some pub in your in the code that you use for this regular bees it's not going to you know do much damage and I do I do agree I hear you're saying acid and it is it is kind of this unsolved getting these

weeks of Nativity checkpoints before you've ever seemed to the network is kind of this unsolved view X and so what I'm heavily implying is that one way to solve it is for client teams to be a but there are probably other ways and worth discussing and debated one thing that is true is that if a user a user must get some sort of check point from the recent chain that they want to sync to and they're sinking so we I guess the meta question here is like what is that what

is the Bible u X here you know what one Bible you X there sarcasm coming is metallic and just tweet it like every five hours but that's also probably not like fully a very satisfying solution there might be other decentralized solutions like when when just like state network that people are working on in the 1x research is this potentially there's a way to like query nodes there's a lot there if each client includes a bunch of

public keys of known institutions in the a tearoom ecosystem and they you can see that a particular root hash is signed by your own foundation like House members and so on and this is flesh in the UI user grace and it's patch things on automatically and very tight against this road yeah yeah so we could instead of yeah I think that that that requires a little bit more work and a little bit more of a standard but I think that pushing on a standard like that it would be really valuable I think what is there we have to standardize maybe like a URI

a URL scheme for pulling these down and a formatting signature which we can probably pretty easily do and then defaults for signers are included in a release and those can be overridden that's definitely what it is when when a new client just you know spins up from scratch it's definitely going to be a web of trust thing Oh ever trust is more attractive than like explicitly relying

on you know what is it for save five times or whatever it might be or really the one client that you're you happen to be running right because if it's just one client then like just use your crush you Google Drive that's true but we I mean the way I see it we should definitely implement more than one of these options where you know maybe the client signs the route includes it in it Cellini's your favorite block explorer advertises the latest subjectivity checkpoint their website some people have posted it on Twitter's and like whatever else

medium out there so a multitude of these options should be the preferred approach okay so it does seem like we're gonna want a standard uri for seeing what people have signed and also a standard uri for pulling down these states once you've decided on say the route and also probably a standard as to the frequency with which some signer might publish these for someone doesn't someone that wants to serve these subjectivity

checkpoints out-of-band probably doesn't want to be able to serve every single one so maybe I think in your document I recommend every 256 or something like that I think the issue here is incentives right nobody's really paying the client Eames to take on this risk like that's created but yeah outside we probably should create a working group all of this yeah I did so you wanna lead a

working group and pull out a number from each team to continue this conversation sure the tongues good great again big we have to figure this out like a reasonable UX path somehow because it's not just so for now I guess the lowest hanging fruit before would be like move forward and plan this better is just past dates as CLI parameters and probably that's it seems like a pretty trivial thing to implement so if that's

something client teams are up for that could be done first and then we figure out how to distribute States you know in the general way yeah absolutely so it again highway being able to start from a state rather than from Genesis is crucial to this like flow and so if you cannot do that right now I would make an issue on github and figure out how to do it it's kind of similar to enter up how we were starting with we had a flag where we're starting from the states sorry I guess I was going to say that though will you always had that actually and I was wondering he's indeed the key thing the immediate

issue is that you don't know the block of that state in the genesis state there is like whatever in its Genesis block so I don't miss you need prevent the block well you don't need it strictly but like in the code that might be an issue because you might assume that you can generate it right you can look at latest block header from the state and then you can embed the savior though yeah yeah yeah compared to compared to whatever yeah but all the information is there that you need so again we're form working group to figure out the you know

good compromise in New York's around here otherwise any questions on this before we move on okay moving on to research updates anybody wanna get us started I'll talk about some developments at tx/rx okay so the worked for monopole is being you know this is our transpiler for the spec as being rolled into tech ooh we've talked about that before and mikail has taken that and taken the

implementation and made kind of a fully fledged simulator and he's doing two shards and sixteen validators and kind of the blocks and data stations are being produced on time cross link cross links are happening and he's running at 120 epoch minimal config very ran it for 128 box and the minimal config and he's only really added one workaround from what is just standard at the specs that's good news and yeah it's gonna keep working on that that's super

exciting Congrats McHale if you're listening other research items so one thing that I've been thinking about is the question of whether or not the spec can be changed in a way that allows basically easier verification of state transitions so and so basically the challenge here is kind of looking at some of the big items that take up a lot of computing resources and processing if you're in

blocks where the two biggest ones are signature verification and end of epoch processing and that basically the challenge behind the East End the V part processing is basically that you have to kind of walk through the entire validator set and you have to kind of rehash the entire validator balance the West I mean do any of this computation that involves like basically all of one work for every validator and the thing that I've been trying to figure out is basically can that work be either reduced or kind of snark so one person the block proposer does a bunch of work

and then everyone after them just verifies proofs so the challenge that I'm there so far is basically that right now we have these validator balances that are stored in a moral tree and the end of the port processing requires basically recomputing the entire myrtle tree which is I think 1 million hashes um and the first idea that I had is basically can you take use in stem instead of a Merkel tree something like a gate commitment to a store validator balances right and the reason that basically they're kind of reasoning behind that is that a big part of the reason why we have ends Vblock

processing instead of just immediately processing at the stations is that every address station and it affects every validators balla in a fairly but it or it affects a whole bunch of random we selected validators balances and so it affects I kind of all parts of the miracle tree and so if you tried to modify those parts individually you'll end up doing something that's almost as hard as recomputing the entire tree but doing that every slot which was just horrible but if you use a kid commitment instead then basically every balance update becomes an elliptic curve addition which is ten and potentially like not even enough to curve

multiplication like really just an elliptic curve addition which is potentially really powerful and the question there basically because because I just think what do you what level of I'm going to be efficiency can we can we get out of that right so the benefits that we get out of Keith out of just using K commitments so one is that instead of I'm log n hashes it turns into an elliptic curve addition in other you nor potentially a few elliptic curve additions that depending on how you do it and another benefit is that it might be possible to remove most of the end of epochs per validator processing so the

thing you would still have to do is you would have to and to figure out at the end okay you know this is the number of per pair of a Manta stations that go for with a particular target and source epoch and then you have to calculate like which ones went above two-thirds in all of those calculations but anything that's kind of per validator you can do it more block-by-block so enough challenge of that of that approach as well so it does see a seem like you'd be able to do that in a lot of cases but at the same time it's only a kind of one

game to one part of the process like and if the limits of the game comes basically because ultimately you do have to do like in the worst case something like 30,000 signatures in each block and so you have to do things to 30,000 validators in each block and that's like the the arithmetic is a kind of fundamental and that's in that sense so but then arithmetic is much cheaper than doing hashing or doing any kind of other commitments so the question is basically could we potentially create a system where like everyone does the arithmetic but then you go even a step a step further and you say one person modifies the kate

commitment or model or the problem of the block proposed or modifies the key commitments or mantras whatever and then they create a basically kind of like a special-purpose snark or a special-purpose blanc' proof or something like that but that proves that the balances were modified correctly and then at the end you would well you would not you you would not really meet them need to need to do it to do that much at the end anymore but every other validator would be able to just verify those proofs so that's one route and then obviously the ideal route would be as like if we can also come up with ways to UM sonography part like signature

verification so even let's say like we know that we have something like two hundred and fifty like up to 2048 validators for every at the station and so can you just make a proof that says and if in one go here is the public scene that represents and of the total sum of this particular subset of validators and basically just kind of marks the whole that whole transition so the challenge is basically and if can we find subsets of that or kind of ways of doing that that are viable today you're close to today and and ideally reduce more complexity than they add on at the

same time makes the in transitions more cheaper thanks Joe any questions on that okay other research updates great next up isn't that working I was hoping that Felix to join the call but he could not stay I'll work on getting an update on what's going on discovery five to share that one there is this one issue at Point show yesterday that was

known from if I roll a couple weeks ago which is do we need non snappy request/response domain which I think there was a little bit we got a few different sauces on the discord seems like people are leaning towards no as long as the crest ratios are actually where we want Leo did a little testing all the Commission ratios on 8th one blocks we need some data on these two bucks so let's not touch savvy person on snappy until we get those numbers to Sandy check that were actually seeing reasonable compression and then my gut would be to just remove the non snappy just to remove

maintenance I don't think that it's very valuable and as somebody mentioned gossip only has snappy it so to become a client that's gonna be required it's a dependency regardless so it doesn't really give you much game to operate without snappy on the crest response in like early development any other thoughts on this before we move on okay as I mentioned we're also working on refining these gossips uh parameters there is an open PR in the spec repo with a little bit of conversation going

on there and hopefully in a few days we'll have a couple more parameter changes and I'll make sure knock on team's doors on the networking side to sanity check what we have in there on back that's palpable we upgrade in waves but ideally this would just be from these parameters would be updated from start then excess stuff you have people in spending a lot of time on networking recently with test nuts and bugs and things is there anything people want to discuss with respect to the networking spec or even just debugging networking anything any never right bra that adds a message to the goodbye and a goodbye

call goodbye message it renders it kind of incompatible but there's been a discussion that during the bugging people want to know why why they're getting disconnection would be similar to the error message kind of like a debugging health as much else I'm unsure whether to put this BR up that this up as a PR any initial reactions and the other alternative is to expand

upon those codes to try to make it more gainful yep I'm gonna this one out any reactions from Fighting's it's funny because it you could you could argue that adding response code is not a breaking change in almost any relevant context because if I send you a bad message on goodbye we were gonna disconnect anyway but

that's kind of a that's a would be a sketchy thing to to add and say us backwards about letting a code strictly at the breaking change adding a field to the Z is yes right but learning in like adding a code is useless if nobody uses it for actual logic and and so far no cases have been presented where where it would be used for logic right again I'm looking I'd rather see response from fine teams and if we can't get any right now I guess it I suggest you put up the PR and get a response there yeah sounds good

okay other networking things okay I do think that getting some more visibility into gossip is going to be important I know that we're at least we do see like random at the stations not get included and we don't really don't have much insight into what's going on there and so I don't know I don't know if anyone on this call that has the

bandwidth to do they're gonna stuff but if anybody listening this call wants to uh dig into gossip and make make it more tangible invisible if it could be valuable yeah I also remember there were a couple of like hackathon projects handful of months ago on gossip site visualizers and analyzers also maybe it's worth like Levi's always one of those okay other networking items about to move on great aspect discussion this is kind of in the spec range mommy you

noted that there is a version 9 of hash to curve has anyone had a chance to review this and Sandy check that it is either cut only cosmetic or effects components that we don't use a sweeter I've been through it and it doesn't touch anything that's us that's both for version 8 and version 9 so take the key for BLS if you support hash to code 7 then you wants to support hash to curve 9 thank you okay other spec related items

okay and anything anyone wants to talk about open discussion I'd like to talk a little bit about using be if to launchpad and integrating that into clients after we had that discussion and yeah everyone's been working on it I I think we're getting a lot closer on standards for T stores and how to integrate that but there's still quite a bit of friction in many other

clients for how to actually take a key store and include it so yeah as having going through that if anyone has any bright ideas please let me know otherwise I'll be getting a hold of client teams to to try work through that a bit with them sorry is is there a document somewhere we can refer to what the outcome of the discussion was just for reference that is a very relevant question I think someone took notes but I do not remember who it was off my top line off the top of the head would already have links to that I believe there were notes as well but what is

also relevant is maybe somebody from your team running through the launch pad and seeing the current outputs of the launch pad and go banging your head against how you might integrate that your client Karl is there an endpoint that people can refer to and actually use the launch pad today yes it is just hopping back onto that previous comment it looks like mommy took notes and listed them in the repo so you can have a look at them and thanks many for that yes so in terms of an endpoint currently this website sent in the chat is the

endpoint for it is the endpoint for the launch pad and you need a password that will be changed early and chatting with them up so they're not at the moment to get it posted on a like a more proper website but for now that's an end point and everything should just work and that is pointing at the master branch of the if to deposit repo right and when you finish this process what what do you have as a validator so at the end of this process you have a you have one key store per validator

in a file that is explained in the launch pad itself as well as in the CLI you're going to walk through it will tell you where these balls are as well as a deposit data JSON which obviously contains the deposit data there's only a single deposit a term with an array of deposits for each validator and it doesn't quite map to what is a deposit data on the EDX site because there's some extra parameters that we want to verify but it is very close there's nothing unexpected there and you presumably have a mnemonic that yes you have a mnemonic written down and the

user will have a password in their head with and the single password encrypts all of the validators otherwise that gets very user friendly if you're gonna have many many deposits okay so I mean the the same same thing bigger to do here is probably for client teams to run through this think about consider how these outputs would be integrated into your client if there are sticking points on why this is not a viable format to open up the conversation with Karl and s but otherwise to consider how to support that pretty easily from your client side you know like client launch pad integration point to file done something

like that but go through you have someone you can go through it so that we can sort some of these things out in the next up releases we plan on having this launch with the Knights assist oh yeah that all sounds like a very reasonable approach and also then if on the client side everyone can add how this kind of thing would be supported in their Docs and that would be really cool and then obviously on the launch pads side too we can have maybe an outline of what that is before pointing to client Docs I think is probably a good way of handling the handoff between the launch pad and clients themselves because presumably at

this point most people are not going to have clients install or will have but for the wrong version and that kind of thing okay anything else in this before anyone from my side okay anything else before we close great thank you everyone it's good meeting talk to you soon thanks right by Excel

thanks all bye [Music] [Music] [Music]

[Music] [Music] [Applause] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Applause]

[Music]