All Core Devs - Consensus #24

Transcript

[Music] [Music]

[Music] [Music]

[Music] [Music] [Music]

[Music] okay the livestream is switching over

YouTube chat give us a heads up one you can hear us hey guys everyone thank you for coming today is the 24th call right for the inner upper tree here is the agenda share in the chat and we'll start with testing and release updates last week he goes last week released these r83 this is has no substantive changes but adds some testing fix fixes a couple of testing bugs and other I think of like

an SSD clarification so if you're passing 0-8 to your essentially your you're running the same spec as 0-3 but there's some additional tests in there that you just pull down and good chef proto is there any other testing updates with relaying right now for this week just like the ask clients to reach out and if there are like tests that are particularly difficult to pass are can use some like discussion I just like to help clients this week gets smoothly into them drop and then you continue with new tests after interim yeah Justin

have you spoken with Guido is there will there be a renewed effort to differential buzzing against Cayenne soon okay we can figure that out I'd say the calling us and if that you know goes dark then they can pull up some other resources I know we have some in general thousand people across the team's cool thanks any other testing related updates

repellents will move on okay okay moving on to client updates let's start with nandus hi so we were in Berlin two weeks ago and now we have team updates about everything that we did in Berlin if you want to read up on that we know also updated or documentation to welcome to include all well the main libraries that we developed while doing this freedom to be folks and we're even to

world build system so now you can directly build a freedom to client from the name becomes an repo instead of going through Nimbus so that's for the support part now on if I am one we have the validators and deposits interrupt that is almost done on consensus we have a couple of classification and finalization issues so we solved most of those but we still have some on testing we melt a big PR that introduced a lot

of unit tests and working routines for the state tests because so far forces take testing where we relied on simulations and now the focus is just to make sure that we pass the test for interrupt but since the unit tests were based on PI spec uh we were confident that it should be okay one concern that we have is that CI text a long time so that would be one thing that we will have to optimize after winter up in terms of performance we have some benchmarks on cryptography in

progress and we measured also the scaling of attestation processing justification finalization on a single node and on a typical laptop we can have 2030 data and lastly on networking so we have on the pure namely p2p implementation we have the TCP transport down and make this stream for next and we also checked or interrupt with rusts p2p and we managed to do gossip serve with lighthouse and so on as focus is

minimally p2p implementation with SE cayó for the premium the p2p and well interrupt for Anna next week great and to clarify is the do you plan on using the next week or is it still on the go daemon from now we're using as a go demon but who knows go great thank you how about Pegasus ion here to give her team Artemis so Interop remains to be the remains and it's the primary focus everybody's focused on spec tests and

SSE spike test format has been updated to v08 to for the most part which means these are a three will work most likely we're just going we're just doing the final verification zombies raid 3 so as on the SSD Fran sterilization and destabilization is working as well as the computational part which is the hash computation and they those are getting merged into our tests as well so we should be able to pass these are a to soon we explained on the engine also on the inter oxide we're working on in networking so Johnny

recently developed mantra which is the intubation of Lighthouse there Russell admitted peak integration so that we can aim to have a common wire protocol to communicate as well we are working on on the interrupt side of the beacon change start so Adrienne's been looking into that and has been communicating and he's also been working on the production ization such as Prometheus metrics doctors stuff a gun and also our collaborations are continuing some of our folks just returned from eath berlin

who had conversations with team white block and also team handle and which is something we're looking into for the future to integrate the novel networking spec that they've developed so also related time Interop which is taking place next week if anybody has any questions about that feel free to reach out to Joseph DeLong and finally we have benchmarking in progress for BLS signatures and aggregation there are any questions I'm happy to take them great thanks Kevin thanks Danny cool moving on about Christmas Creek

Christmas prism prismatic thank you oh hey guys Terence here given the updates so we've gotten a new DB and the new fortress integrated runtime so we have been testing this locally with a multi node setup using I 64 128 value live discrimination and it's well it's working nicely so far so we're just waiting on implementing issues saying before we move the employees in a single higher test environment and from the audience best point of view we've implemented regular stick or PC and then process up and we also enabled no discovery be a Discoverer v5 and that's

working so the last penny item like I said is just initial sync which is currently getting implemented and we're also working on aligning on our code base to 0.82 you before in a row also we're playing and they experimenting the like high-end protocol that is current is specifying the spec and also looking into slashing detection and then prevention algorithms so yeah that's it Terrence hurry is way here I don't think we have way okay there's a lighthouse hey pull there so he completed our

upgrade to the latest networking expect with sinking away debugging that on a fun test that now we as let me said the D bogs and patches ago and compatibility so he wrote some stream Ochoco implementation he's verified the lower level handshake sick i/o multi-stream and Amex and as many said he tested gossip sub we mercy of italics bold signature verification scheme we're pretty close to merging in our first on hot cold database where the hot part is the non final layer stuff and the cold part is finalized stuff and we're storing all those big lists of

hashes efficiently so pretty much only once in the cold section so it's nice an efficient and we'll work on that a bit more we're building out more HTTP endpoints we made a suggestion about the API is moving forward I'm standardizing and we're working to make sure that I'm using lighthouse is very ergonomic very interrupt so it's easy to spin up and join stamps and stuff like that that's it from us thanks Bob harmony we have moved to 0-8 respec we are passing all the tests the spec was very easy almost no changes but

there were a lot changes to his tests from us and I hope it was it was last mile change for test format also that is the plan yeah we ate a lot of unit tests we have for the tests now we don't want it to be twinkies coverage rather we want to win his quality also we are moving to the Interop we meta meta issue

and some are things are lipid to be integration and discovery bhava miss per finish and Java IP in little B and we are going to integrate to be in our client next week the same is discovery I hope it will be finished next week and as a test for Interop min or like metrics and whatever I also we have we have made new registration pool but it's only

you now visible doctors or choice and Susur on off at the station from a poser and the bad thing is we are not sure that anyone from our team will be able to go to interval we have visa problems but I hope they will be at least one for us and this all right I hope so too in terms of priority let p2p obviously if the priority because a lot of initial testing we expect to do with static hearing and only if things are going well do some discovery b5 tests but

great work thank you [Music] [Music] so this week we are keeping focusing on the requirement of interrupts so earlier ways we skipped the version 0.8.1 applying our test case passer to upgrade to the point 8.3 picture test right now and hopefully we'll be passing swim and

about our pilot p2p package we finished the SEC I Oh module and now we are testing it against the cold escape to pee and we also done some improvement of the PI s SZ about the hatchery root cache and also for the performance that might be our one of our bottleneck falling it up so yeah we are trying to make it fast as possible yep that's Trinity

thank you thank you and hey so as past few weeks we got some progress on our sha-256 assembly script implementation we were working with the assembly script maintainer x' to optimize this implementation that recorded over I believe from C and we've got it working pretty fast it seems to be the fastest Wazza or fastest JavaScript implementation for certain leaks of

input which is pretty cool other than that we've been working on Interop you've finished the QuickStart and starting from a known state and we will be now be working on getting our lip p2p protocol up to spec oh and we also have some basic prometheus monitoring using the metrics going or going off the metrics repo some of those things are stubbed but we had least have some some metrics and we also implemented one of the those BLS

optimizations where we're not advocating pub keys in signature verification which is much faster oh yeah great thank you okay I believe that's all it's not here and I think he's been focusing on building a validators thing okay let's move on research updates anything from your side from my side and Carl side of car last year he published a blog post

on the roll up semi layer two protocols yesterday and I have a blog post that I'm planning to publish today and that's something that looks like it provides some immediate basic immediate scalability basically using techniques kind of similar to plasma except putting more data unchanged so you don't have to deal with like operators and exit games and all of that and all of that complexity and would be irrelevant to execution environments as well cool so I guess on my side I've started recently a

very detailed review of the phase one and I guess is potentially a couple of the substantive changes to face zero that are coming out of this review one is a focus fix and the other one is the idea of having Universal kind of slashing condition for equivocations that would work for beacon blocks short blocks and jollity stations so that's nice complexity reduction I am expecting kind of the phase one spec to be feature complete polished and tested by

September 30th but I think it would be it would be premature to to declare it frozen by then the other thing I've been looking into recently is this new proof system snark proof system called drunk and the idea here is that you can have a trusted setup which is a universal and updatable so in practice what this means is that the the trusted setup issue with the specific instruction doesn't really exist because you have a single setup which is usable

for all the circuits and it's updatable meaning that you have a continuous ceremony and you just need one single person in that very long-running everybody to be honest for the setup to be to be trustworthy so and it like there was a previous construction called sonic but that had a huge performance hit this new construction has a much more reasonable performance heads and so if if you don't trust it you can just add to it yes and like this this project called a stack they're starting a ceremony in September so I'm expecting that to kind

of be the the genesis of plunk you know blockchain kind of long-running ceremony and that I guess people can build upon and one of the cool things of removing the trusted setup issue is that it it might be a tipping point to be able to use snarks at the consensus layer and there's all sorts of places where they could be useful data availability for proofs a secret single leader election with this compression and I guess the nice thing is that if we already have BLS 12 3 2 1 then we already have the pairings at least from the point of view of verifying the snark

there's very little incremental complexity most of the complexity would be on the approver side which is I guess just you know algorithmic so I'm I think this is kind of an important moment in of snogs yeah quite excited about plonk great thanks I've also been digging into that phase their respect and finding nope thinks you're in there something else I don't think about is if you can have any sort of like herd immunity on PP networks we're not all messages need to be very verified by all validators when being gossiped I can't find any

existing literature on the problem but if anyone has thought about these things or knows of some good papers check out please share any other updates research updates and we just mentioned that I guess the problem with not validating at all this is obviously that this becomes a spam vector that you can amplify messages very easily an identification stream of news yes absolutely and the the ideas it can we can nodes

validate some fraction of messages and still prevent the specters while speeding up gossip and there's like a lot of different angles that's a sure soon Nicola do you have any updates for us we continue to walk a little and under so early we found actually the proof of a complexity that we are claiming we are clearing a log message complexity and we were relying on Hybris paper that finds a little bit approximate of cases so we do have a proof which makes the paper a little bit more solid so we'll update it so but

just paper we're not changing what protocol itself but would include that a lot of other and one arises because of this and we went in there in last week and we spoke a lot to actually Artemis and then whatever Shannon as went to Adrienne from lighthouse it seemed like a possible plan that we'll need to put in practice is to use under for small committees as a word we say okay it served its fast it's more built for big committees or Marv and 1,000 nodes but for small committees it's more or less proven for Byzantine cases and so on so it's interesting

children continue a little bit on this but we need that about planets on that so but actually because of this work we also spend more time on the privacy which is not handle specific which is the link but you can establish between the wallet that you use to stake and your IP address has a very data okay it's weave under it's a direct link but if you're not using and all you can just follow the committee's and look at what our buddy details public key that are supposed to be in this committee and what our IP on assist actually

participating and after why likely one hour view we've got a one-to-one mapping between the two between the two so basically you know this public key is actually this IP address which is not very good and there's a solution for that but we published yesterday evening of time and it will charge but is using a zkp a simple one so it should be called article part of it you watch and if you do buy to hide this link you add this mapping between this public key and the validator so you can more or less always guess but this IP address is

likely very less of a valid data but you don't know which one it is exactly so I think it's about party Constitution so I'm interested to get feedback and reviews on it and then can be for phase one or anything else depending on on what we want to go with ZK periodical and that's it homes great thank you so one more research thing I want to highlight is issue one 340 as simplifying empty pod transitions so this is a possible change to make a to make to the protocol and the idea

here basically is that if we want to make it faster to impute the transitions for blocks that have gone through a large number of empty epochs so like blocks where the parents of that block is very far in the past then currently this is very difficult because you have to go through a bunch of people transitions in every epoch transition has oh of n work that because there is you have to update balance this very validator calculate the new state hashes calculate committees and all of those things and what this proposal does is it basically goes through the parts that have that o event work and I know

restructure is the protocol using some techniques from the VIPRE version of cast for a couple of years ago but now but in a more limited way to try to remove that so that you would only have kind of either o of 1 or generally a very small amount of work to be done in a pocket on transitions and that come at the end of empty box and so this is protecting against the boss vector where a rogue proposer builds off of something in the past and disseminates is an hour thank you any other research updates

during if Berlin I put some time in to looking into parcels and not accrues lot of coats and if anyone was interested in helping here at be like happy to discuss new IDs and how we serialize parcels and how we're in these boutique roasts more efficiently also in the context of a bustle I'll share a link after the call thanks is there anyone here from quilts or he was on this app do you wanna give an update on your end sure so yeah as a as

a as a nice to client I think we have we have been refining the specification now and also the testing infrastructure so so we're working on that what's probably more interesting is at least from a research point of view is that how this kahit model is going to help us later on show safety aliveness properties of the protocol so this is something that I think we are excited about but of course it's we're still trying to organize our ideas on that and

yeah so so this is this is essentially the main thing that we are we're internally discussing this stage thank you and on the deposit contracts I've I purchased merged in the compiler fix that was found by rent and verification they planned on releasing yesterday and check today if it had been released that and 1p are on our side is kind of the last thing before we do the final verification so that's moving along well okay I think we're done with research right great nothing more for me for now all right let's move on to

networking we have some of the protocol lab you guys here well anything on your end yeah hey folks it was great catching up with many of you last week and Neath Berlin a lot of amazing contributions there and conversations as well I just wanted to to emphasize some of those contributions especially the ones that are indigent for this group I'm just posting a link a feelings on the chat we received several contributions that are gonna be pretty interesting for free - there's a set of lab test vectors especially and these are important because like in contrast with with previous efforts but we try to

assemble much hotter sectors these ones are actually capable of decrypting Sicario traffic the contributor that also picked up this this issue this bounty also is working on finishing this task by creating a text inspector and these are incidentally the two protocols that we've chosen for Tesla so I'm hopeful that we should be having a sort of like semi mature set of detectors for the team that's going to be interrupt thing in two weeks so that they can potentially debug you know potential interoperability issues another one that was interesting is of course the noise

handshakes the change 15 plus add this one up and the spec is is evolving we now have a implementation you go this is going to serve as the reference implementation and has the spec evolves and we continue including maturing this back we expect you to modify the reference implementation in lockstep another interesting contribution we received was from from puja lambda as well he did he created a set of test harnesses and conducted some initial profiling on the reference implementation of gossip gossip southern go this invalidation is not optimized today's reference implementation to serve for for future implementers and other languages but we

do want to really want to optimize it especially ahead of the tests that the white car are gonna continue conducting over the next few weeks to that point we are trying to get a engineer or no routine to actually use this test harness exercise and stress the implementation and find bottlenecks and so on and conduct an initial knowledge of optimization before white block commences with their second round of testing of concept oh and also to be able to serve kind of like as the fern line or need to face with with white block and finally another interesting contribution which was the machine for

it for analyzing concepts message propagation which is basically my same as a tool developed by matrix code org - that allows you to create networks of matrix servers by a very nice UI with dragongirl and then set network characteristics quality of service and traffic shaping tools and so on just simply matter name dropping on on a canvas we for that and we adapted it to create gossip sub containers and to wire them and to establish quality of service rules and so on and simulate message propagation there is still some work to do to make it fully usable but the contributors are still working this week to finalize that with regards to what

the Liberty to be teeming PL is focusing on these weeks we are from the signal scalability testing on decentralized not for punching on jsk physical improvements to adopt a single weight and a center directors which was sort of like a main or a pain point for the guys that for the team that picked up the noise handshakes because we wanted to defend a je s a je s version as well but we face some roadblocks there those are going to be working on visualizations and of course supporting this group especially in the event of off the interpretability testing that is gonna is going to happen in two weeks from now not so for me thanks roll and thanks everyone for the people here and people

out there who could tip these bounties any other networking things great ok there is there a couple there's an issue I think open in this new Ito API repo and there's a PR which I need review which has some initial proposals for an API the general idea is this API repo is going to have these api's that are generally agreed upon and conformed upon

by a number of clients these things are not consensus critical they're not Network critical these are things for users and the more that we can kind of agree on some of these things the better user experience and better dev tools we can probably build but they're also I fully expect the cycle around this kind of stuff is often probably going to be some innovation some local testing and some talking to different users customers etc and then kind of like coming and trying to conform upon them III don't expect to expect these to evolve over time because we don't always

need it know the needs of our users and so we actually have users that said getting some of the core stuff core data API is like how to get information out of a node about the state and things like that I know a lot of even talked to potential users and have some some good idea and some initial stuff so I think there's probably a little bit of a debate on how to format these things there was a general agreement with respect to the validator API and the extension with respect to API is in general to frame these things that HP REST API I have not taken the time to dig into what is currently there Paul or someone

who can cuz Matic I know y'all been talking doing give us more details yeah sure I made a PR that proposes it seems what kind of still in the meta stage since buying these API is I can how exactly are we gonna define them so I made a new prismatic have been working defining there's in protobufs and I propose that we make a more kind of abstract markdown definition of an API that provides a basic kind of rough HTTP guide enough to get people started and then we can use that kind of core

abstract API definitions and then make specializations from it so you can like to find a prototype file that implements all the methods in it or you can you can write you can write out some method that map's that abstract definition to concrete definition and then when we want to make like a super you know strict API that the consumers going to love we can we can make like a swag s specialization if that abstract one so that was my proposal always keen to hear what people think so you know jump on the on the PR and have a look yeah bring it up here right so there's probably two portions

of this one is actually the API the others diplomat yes I tried to put in the API that I made is pretty loose and I'm not even sure about like I pulled it the basic API I'm not even sure about the grouping of things so what I was trying to get out mostly was the format in that PR not not necessarily the detail at the endpoints but we might as well do both the people who came I think the problem was that the open API specification with swagger hub is kind of it's a bit opaque and it's hard people to pick up I and so is the Pearl of offers as well it's not something

that people can just sort of read and understand you know exact ways are supposed to do yeah so we're using swagger originally and then once I had to go in and do a bunch of modification in swagger I found it was actually I'm pretty painful unless you really get your head around the gamble specification so I thought that if we have this kind of more human language specification that's in line with the rest of the specs we have that it might be a bit easier for us to iterate on I think another reason to do it this way and I agree that this is a good way is basically that if you specify it in one of these more concrete formats you've

already done second piece of work which is mapping our sort of world that the rest of this e to spec rests upon to this specific instance we've already done the work of mapping I don't know BLS keys who wrote about strings and I feel that that is really a separate piece of work that might be different depending on where you're aiming with your with your public API say that you want to implement them a similarly shaped API over find they're here or whatever that might be so I think it's much more useful to have a more at definition which is more aligned with

what we have in terms of data types and so on in the spec rather than some specific encoding protocol whatever you want to call it hey you guys hear me it's personal prismatic yeah hey so just a little background on what we've been doing so a couple of months ago we we saw this isn't you know an upcoming problem where we really need to start thinking about data API is people have been asking already for artists net where's the black Explorer they want they really want to understand like what's going on with their validator and within the network so we put out this products requirement document that we sort of collected all the the main use

cases that we thought that users would really enjoy in terms of getting data out of phase the phase zero implementation so what we did is we we took that we just the feedback we you know we passed it around kicked around for a week or so and then we added it to this theorems during API as repo which we were aiming to have us in some centralized repository that that you can access the schema for any any new or existing aetherium back-end so right now it just has the the eath two phase zero that we're proposing and we're happy to move this but you know again under the

same name because we we don't it doesn't make sense for us to necessarily own it but that's kind of where we started and we chose protocol buffers because it's a really rigid definition so it has the types it has the ability for inline documentation and you can really see what the schema looks like in terms of what the request the response and also the HTTP protocols can be defined there too so you see the route and how the server is supposed to outline these services so when you're going to implement it you can really see all that one spot now that might be premature in terms of you know oh we haven't decided the final thing so maybe doing it

markdown is fine but we chose this because of the generative properties so you can take this definition and generate your swagger or even generated markdown documentation from it we put out some we put this out for feedback you know a couple of months ago we mentioned on the call and we've got some some feedback from Paul and we what we'd like to do here is to agree on not really so much the format of how we're defining these things but the actual service routes message message objects and response objects so that's a bit of background from a mess thank you yep yeah I I also I generally agree that the

hard problem it's probably actually figuring out the useful and safe API rather than exactly how they're displayed okay let's take the rest of the session back to that repo I need to do some due diligence and look at these proposed api's as well any further comments today yeah hey guys they're all for prismatic there were some comments also about just like having it like being unreadable if we do it we don't think that's the case I think everything is extremely well documented and like Bryson said it's totally possible to

have kind of a mirrored markdown kind of object definition of that I think as discussed in the past that most teams are resistant to having protobufs as a requirement here correct me if I'm wrong protobufs does not have cannot handle some of the types that we even have does it support a UN 64 yes well am i incorrect am I thinking of a type I camera the exact type six legs legs were one and yeah and you

know they like there are ways to differentiate like specify canonical types and thought about three at least which your protobuf decoder will map into these types but still on the wire and that's where like one of the major missing ones yeah every single every single part of the eighth you spec is supported by you know we do everything input above and we haven't had any problems I hear you on that my intuition is that we shouldn't specify this in

protobuf primarily because we've gone down the path many times on why we don't want to integrate protobuf as a tendency in any of these repos that's my intuition engage after talking to a lot of people about this but let's take it to the issue okay we have the center drop retreat coming up and white block-long proto

have put out a lot of these they put out that survey thank you everyone you're responding to it it's gonna help us be really productive at this thing so Zack or proto would you like to discuss at a high level some of the things that are worth mentioning and then we can talk a little bit about some of the stuff that you know yeah sure my internet connection is a bit spotty so I I may drop drop off and yeah proto and I have been collaborating working on all these Interop survey thanks everybody for responding so it seems like most clients are on the current are up to date on the spec and or have agreed that

8.2 is going to be the version that will standardize on so most clients didn't have an issue with updating but there were issues in testing the remaining issues had to do with like merc polarization and SSC but they're pretty minimal there was a most a lot of people had bottlenecks with networking but it seems like everybody is kind of has has already or is very close to implementing a functional Lib PDP stack so good work on everybody for that and sac IO has been implemented as well so that she didn't present any bottleneck the only immediate bottlenecks that we can

foresee just based on the results of this survey is sinking and I think that's probably going to be something that we want to iron out and define in a better way to make sure that we're we know what we're doing once we once we get to get to Canada the wire protocol as well so we should probably iron out and review the existing wire protocol make sure it's up to date I personally haven't looked at it for a couple months so and also anybody who isn't aware just know is like the networking spec is the pretty good progress so everybody should be up to speed on what that presents cuz

it breaks down everything pretty nice like what we're gonna do for Interop and what we're gonna do for main net what we're gonna do in these coming weeks aren't necessarily going to be reflective of what we're going to be doing for main matter what the main that plan is but it shouldn't require any additional development time from anybody another thing we want to try to work out is like how do we effectively communicate between client teams like what are we gonna do what we're talking about is setting up like like within the Interop event we'll set up like these specialized kind of client agnostic teams just based on certain topics so everybody can help them help each other out like passing existing tests what our sync strategy is going to be wire protocol and like exchanging initial

network messages so we're trying to write some cooling that kind of helps everybody along with this process and automate as much as possible we're going to be sharing these results on Monday so I don't wanna get too long when it's so proto if you have anything that freedom I will say that it seems like maybe half the teams don't have the facility to even be gossiping individual authorizations not aggregate and that for some very limited types of tests with very limited number of nodes and validators this will likely work to some extent but that if we're doing I have

any sort of interesting tests and networks beyond that we do need to be a gossipping attestation so if that's not currently part of your network wire protocol and you can you can gossip box you should take them on that and add that if possible I have a question for clarification is this in reference to the survey that was sent out recently yes and just to confirm you said you're gonna talk about results on Monday we were discussing sharing that aggregate results on Monday yeah so the high level right now

some of the more like subjective answers we'll probably pull out but having a table of just where clients and with respect to features so that we can make informed decisions on how to group clients and doing a full testing this is something that I even though we might publish on Monday we'd like people to be actively updating as features and things that are completed or close to the next week sounds good thanks guys yeah and the purpose is primarily so we understand where everyone's at so we know how to allocate resources and support for each team as needed but in general things are things are looking

good and I'm pretty confident that we're gonna have some interesting stuff and some at least two maybe three client test nets that we can spin up and get some good stuff out so anything else on this before I move on there's plenty of planning and coordination and things that we want to do over the coming seven days and and it's going to be an active conversation and we'll get some different Docs and things together on that I have a point I just not sure if it was mention on this call the beacon

change start is that a part of the API that needs to be mentioned is and prep for inter ah so there's a few potential starts right there's are you suggesting the reference in the document and the Ethiopian repo right now yeah just to get people to know that there's such a spec being developed yes and I'll share that that being able to have a coordinated start is probably very important so targeting that is useful and I there looks like there's there's a few notes and there on how things can be

so and the way to start from a state was a little bit under defined which was pointed out and there's an issue on that but we can clear that up today tomorrow sounds good thank you mm-hmm Danny do you still do you think that we should be trying to start from any arbitrary mid chain State for this intro of N or you called her to say that we only need to start from some Genesis recent is Genesis state the thing is starting from a Genesis state is obviously the bare minimum and being able to I think coordinate on a couple of parameters to define a Genesis state which is I think like the Genesis time

and the number of validators with some underlying algorithm I'm generating that I think it's going to be very useful to spin out these systems quickly there are certainly debug opportunities that we might miss if we can't start from say an arbitrary recent finalized state that said the initial debug path if there's some sort of issue on the network is not to just restart the network at a recent state and see what happens again it's so like pull down data debug go against check with specs add different things like that so there might be some missed opportunity and

doing some interesting things if we can't start from the arbitrary final eye state but I'm not certain that we're gonna get to the point at which we'd want those during this we can erect proto so the results from the survey there were like seven different options listed in the survey and there's even more options - I always would start a chain as well and so for debugging like the real minimal thing he really needs is don't post a it's a low two states then if we produce books in from one client or from one test net in another run or that's another clients to see if they have the same problems this would be really

useful to reproduce these books without repeating the complete network setting in case if the client passes a zero point eight point three SSD tests and can load any of the three as state from SSE that should allow a lot of experimentation already I just wanted to ask like a quick strummin well do we use as a Z as the you know on disk format of of these states or do we want to go for something else like Jason Hammel I know exists

yeah we discussed llamo but also I think that if most people have implemented as a system there's no issue in on disk storage doesn't need to be standardized though right no we are not spin enticing storage you're standardizing how do we want to loads estates from Oscar for debugging yeah the the store state storage itself is kind of outside of the scope for this initial and drop for the initial launch right so if I want to provide a state to my client for as a Genesis state say or for this launch

that we're discussing is there any preference oh yeah they're both fine for me I'm just my plan was to just drop in an endpoint from us so we can curl down a Genesis state from us and then just like I know telegram it to someone else yeah I don't really mind whether that's llamo or s I said like the the readability of a giant Genesis state in the animal is not necessarily that great either so I wouldn't be too worried about missing that I think that's Danny and I had discussed yeah but I was several though several weeks ago oh so it should probably just be based on how

you guys are feeling and what the preferences are there because I already have that sorry I was just saying I already have yeah Emily that's I have a bias for that but it's very easy to make as I said other people one I was a prismatic was having issues I know right I know so if difference of one clients finish to make enough all clients unless you see or just prefer associate yes so the issues we had with what the yama format was that hex drink like extreme

can be represented as literal strings instead of using base64 so that led us to almost a week and a half of extreme pain but i just wanted to say that yeah sorry I kind of thought it was wringing over with us he may be in that case since the unit since the consensus tests are SSD formatted now right okay they both of them exists no there's you know so in general with this coordinated start where you can specify Genesis time the number validators we don't even

necessarily need to be passing around this state but to do more novel and interesting things beyond that type of start we do is anyone against being able to on the state input version of start be able to do a SSE start great we can update that doc to specify explicitly that you expected is SSE but that obviously clients can interpret the data either way and I I think we have

relation so loading a CSUN thing if you have a vaild to output as you see as you see we can debug it's in the spec we can debug it in other clients so you can find these books occur and that works really really fast instead of waiting to have it reappear on a network or elsewhere and dumping status also really useful but optional yeah similarily there we'd go for SSD in that case the movie question a in question B do we have any I know that we've discussed tooling in the past that would take SSD data and make it sort of human readable I don't know Jason or whatever yeah no I

just - okay data that's working of our ago before I like the latest a seat change in the simple serialize does come from chainsaws I think we can a bit let's relatively easily now that there debris is that that is and then they can fish lice or make it readable yeah we'll be sure to get gonna get that up to make sure it's the Pilatus mac yeah turning that into like a command-line tool that can take in like parsing that out is there a component in

there that can easily just take the sec input and dump it to json rather than just inside the website who's there standalone that we don't have one but we we can whip that up by the inter up that's easy yeah we can do that as well although it would be Nimbus Caroline to the piece of code in and out oh it well your question yes I wanted to ask people here they have been besides lighthouse conducting

one-on-one smoke tests with one another what sort of tests just a smoke test so basically a basic connectivity check making sure that we are able to connect to one another that were able to authenticate to one another establish streams initiate gossips and a few other things basically my rationale here is we definitely want to mitigate you know any potential risks up front such that you know we don't want a situation where you get to the internal pertree and people are blocked on networking because you know they haven't

been crying or tests confirming basic connectivity and how to make the the basic mechanics or the BGP I know that members at night house have been experimenting with this and they've got successful firing but it would be valuable for you know teams to do kind of like so if like one one on one tests with one another right I like team art that's that's what we're gonna work on regarding is a test between Nimbus and lighthouse we were using the goalie p2p demon and lighthouse was using the rust whippy to be so if you are using either

that means well I hope that means that it should work right these initial types of smoke tests if not completed prior would be the initial things that sorry would be the initial types of tests that will be run in Ralph's ideally the more that can be completed prior the better mm-hmm yeah I agree with Rose point when I extended slightly with the formats and the types that would be synced up through the network once it's established so whether that means SSE

tests are also passing for whichever attestations or whatever info is being communicated and I'm presuming some of that can be done in parallel like esse spec test plus the smoke tests I probably mentioned but yet to answer your question Raul that was that was our plan and Artemis - you know to do some initial tests with lighthouse and um you know ping Adrian involved decided oh so yeah yeah I'm just thinking if that's kinda like a

maybe like a procedure that we can use here because for example if we can create kind of like a hawk MD that we share across whole teams where teams basically add the instructions to run their client and just keep it kinda like as a running as a running doc well I'll give you saying yeah other than just copy and paste the instructions to run whichever other clients in the network can conduct a one-on-one test for that I think that would help sort of like polish but then preemptively polish some of the potential interoperability basic interpreter the tea box that could bog down a lot of like you know the true and nitty gritty like efforts that you

really want to punish out in internal I just want to you know do as much pre-emptive work as possible if that is if that is even possible because we are likely the nothing to be team at protocol apps it's like you're not going to be able to join the interrupts retreat in person so being able to like help you off bound during these weeks is definitely you know a better better approach to make sure that you know we oh yeah and then you can fire it up too and take a look at it versus don't like crunching all of these tests and just one very intense week we can spread them out at people so so we can discover a lighthouse client but that's as far as

I've gotten so far discover meaning say hello or discovery no generally yeah I'd like finally just go back to our PC yesterday I have it ok as part of what we'll do the next couple days I'm gonna talk with lighthouse and Nimbus about what procedure to do some of the initial testing was on the end and we can document that and put together notes about the state of each client and some of it'll split this we're gonna go

okay I know there's a lot of work to be done and the next week a lot of times cleaning up clean up the last things before interrupt but if you do have a chance to just initially do it some attempted peering and things like that the more of that we can do before we get together the better anything else you want to talk about prospectus in-app stuff before we move on okay general spec discussion anything any questions about say transition for

choice network spec that have come up you wanna address here a did a short write up of all the optimizations for the state position a sauce Billis sse and a few other things OC edit link' South Africa okay and general open discussion anything we want to talk about before we

close great okay and this week if you have this is not the week to spend banging your head against something to try to figure out yourself if you have questions around the spec questions regarding network anything that can aid you in getting where you need to be seven or eight days from now please don't hesitate to reach out to me reach out to proto reach out the white blog reach out to other teams you know we want to help everyone get to

where they need to be to make this next week productive cool yeah and also if there's questions on the networks back like we're always happy to go over the rationality some of the decisions there yeah absolutely thanks Jesse actually did a edit a full read of the now expect history just get it in my head okay thanks everyone talk to y'all soon see a buncha land about a week thank you all thanks Danny thank you yeah Thank You Danny good job

[Music] [Music]

[Music] [Music]

[Music]