All Core Devs - Consensus #48

Transcript

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

[Music] so [Music] [Music] [Music]

the stream should be transferred here is the agenda in chat um okay cool on uh testing release updates we have a v0123 release which has a number of kind of the minor work that's been done on the p2p spec that we will release a couple hours after this call [Music] one of the main things i want people to take a look at is the modifications of message id and gossip sub but i'll discuss that in the release notes um proto do you want to give an update

on this proto here proto is not here um i will give a brief update on what part has been working on proto's working on um something in kind of the direction of hive uh for eth2 um that allows for easily spinning up test nets it's kind of like automated multi-nut kind of stuff um but controlled by a local containers and um can specify unit tests and things so that is in the works it's very close

to being usable so hopefully some good stuff comes out of that the next week or so um any other testing release updates do you have any plans on merging the four choice bad tests into the official ripple um the current plan is to leave those as is um and to use the testing framework that proto is working on to be able to run for choice tests through the network interface rather than inserting blocks through a non-standard

method um i think this is going to be easier to specify and it's going to be easier to test but we'll see what that looks like in about a week or so got it i'd say that sounds a little bit more complicated i mean before choices after all like you know function yeah fair um but ultimately the fork choice is something that there's a standard interface to kind of hook into clients through there

and how they are fed blocks but the the issue with a full test net is that some of the interesting age cases um only happen like when you have a chain re-arc and you invalidate uh almost the wall epoch um how would you induce that into uh pro tools framework for example um if you have one producer and one consumer um then you essentially get to decide exactly what the other node sees so for example if you spin up a nimbus

node and you have a rumor that's producing all of the blocks and attestations um then that nimbus node now sees exactly what you feed to the network all right i don't feel very strongly about this one um i would rather have proto here to defend it he's been thinking about a little more than i have um my main concern is that um as jessic said it's easier to test just a function because

uh with a network test you also bring like uh lost attestations or messages into the into the fold and with the changes with gossip discovery it's better i think if we test in isolation what we can hey there's proto um we were just discussing hey proto we were discussing the pros and cons of essentially kind of testing the fork choice through network tests versus the unit tests do you have opinions here that you'd like to share

so um well for choice is not just algorithm that matters but also lots of integration so just don't underestimate that part of your choice can you go deeper into what you mean by integration so fork choice you keep track of the spoof at the stations the latest at the station and so on you need to fetch them from the gossop there's more it's not just just a state machine

and i see i think most of these books happen when like either information about like which blocks are known or which illustrations got inserted at what time is what really matters and we already have unit tests per client for just the fork choice state we could enhance that and extend it with more test cases but i think the bigger thing that's in comfort or not covered well enough is the parts where it runs us the whole thing okay um we're gonna move on

spadina i've been saying that wrong josh stark um correct me uh after your year around would you like to talk about that a little bit um i can take it i know that sometimes you can't talk during these calls um okay cool so spadina um the intention here is to have a we've talked about this on other calls we're gonna launch test net it's gonna have three day end of life um we can obviously do whatever we want with it after that point uh we're just not committed to supporting it um the configuration is merged and on tuesday we plan on

launching the launchpad along with that configuration so that users can deposit the minimum deposit count is our minimum active validator count is 1024 so that we don't have any worry about you know when that number's gonna be hit we can artificially hit that ourselves that's about it um genesis plan to be on september 29th questions okay client updates

numbers hi so uh the past two weeks has been very busy uh we had uh several uh networking fixes uh in p2p uh regarding uh especially async and memory leaks uh we still have some to hunt down we had also a peer management improvement and we have gossip 1.1 already and being tested using the multinet script and spinning up some kubernetes clusters with a prism lighthouse

nimbus uh just to check if uh we have proper compatibility with 1.0 and 1.1 and how everything goes uh on the core side of the beacon node we have merged slashing protection uh we have in progress attestation aggregation uh with the validator client in validator and the bitcoin node split case we have uh db planning uh it's uh for now offline but we plan to make it online um as we go and we have released a new sync algorithm that is uh significantly faster than the previous one

it's still not up to the level of lighthouse and prism yet but we are working on that and also on the other hand we have started the last phase of our audit so this one is focused on everything related to validators so secrets and key stores also everything that has to do with attestation and block proposal including slashing protection we have also a gossip sub in scope as our pc for bitcoin nodes and available client the command line interface and uh we have also asked

the auditors to review our users instructions just to make sure that we don't put something here that might be confusing and might uh have them lose either money or privacy and that's it for us great thank you taku yeah okay so uh on taco side we are improving sync algorithm to uh to balance load better across multiple piers and be more resilient to bad beers uh also we are working on validation points for

standard rest api also uh some work is ongoing related to handling with subjectivity also we added arm support for blast library so our raspberry users should now enjoy increasing sync speed uh also on disk wi-fi site we fixed some uh those vulnerabilities and also started implementing version 5.1 great thank you lodestar

hey so um we've been dormant on radasha for a while running into mostly memory issues and it seems like a lot of that's been fixed we a lot of that was because we were storing all states in in memory now we um we've broken up our block processing by checkpoint and uh and then now we store those checkpoint states in a separate cache and it helps that we can prune our states a lot more intelligently and also breaking up block processing by checkpoint lets us gives us a chance for other tasks like

network requests to also complete before we were when we had like long skip slot periods we would be hogging the cpu because our uh pro block processing is synchronous so just hog everything now we kind of oh wait after every epoch and with this pruning we also needed state regeneration and so we have that now it we can regenerate using the smallest number of steps based on whatever states we already have in memory so that's all good uh we also rewrote our fork choice and pulled it into a separate package

there were some bugs before we were not using the right balances for attestations now we seems we are and we're also we've refactored our eth1 data fetching for block production it was just wrong before um and um so we're and also in progress is our gossips have 1.1 integration still not there so we're gonna in the next week try to get like all this merged uh hopefully to be ready for spadina great prism

hey everyone uh yeah a few improvements uh recently so uh fixed up a few uh dos vector uh attack vectors that were brought up by proto and you know fixed a lot of our core logic to make it stronger against any sort of any sort of timeouts we integrated validator exits and our end-to-end tested into our master branch we integrated uh blst and merges it into the master branch so that's been really great um there's only a few issues with fuss testing but those are will be resolved shortly um and started uh you know going full speed on e2 api uh implementation and integration uh all of the program above definitions are done pretty much and now it's just a matter of uh implementing the endpoints and uh terence from our team started uh

the week subjectivity sync implementation uh after reviewing the spec um and also some initial work on pure scoring and fixing up the ipv6 integration so that's pretty much it from our end cool thank you and lighthouse hello there a few things to report uh two new team members joining us sean and myself herman progress on the standard http api all the endpoints speak on debug config and validator implemented and tested in fact we have with this new api 256 validators running doing well

so far there will be a code freeze for audits in the first week of october for this audits we will be implementing the shortcut method of weak such activity where we will start from genesis and wipe the database if the weak subjectivity point is violated we intend however to refactor and support the more user-friendly forwards backwards thinking in the meeting time we have implants as well a new 0.3.0 version which will include breaking changes to the database cli and api it will include of course the standard http api we're working on

the eta for this new version is two weeks meanwhile our current 0.2 x 0.29 version in this case will only be updated with critical fixes from this point also i want to speak about the remote signer implementation we're working on this will allow a central server to hold all your keys and perform the sign of objects remotely this functionality is useful for staking of service platforms as well as users wanting to add an extra layer of controls to their private keys we are upgrading our discovery protocol to this to be 5.1 not ready yet but soon

maybe less than a week and finally we are improving our sync protocol to be more resilient to periods of non-finality and improve the speed of thinking that's all thank you very much cool thanks herman and welcome okay and i don't believe anyone from another mind is here correct yep great um any research updates hey guys um as you might have seen there's an update on the week's

objectivity guide dropping a link to it right now um if you haven't checked it out please check it out uh in terms of uh the priority order in which you should implement it you should first start with um just implementing um a basic version of the week's objectivity sync which is taking a command line input of a checkpoint and making sure that the checkpoint is in the path of your sync and if you want to provide some advanced safety features for your users you may even input a state and make sure that

the current slot tick is going to be within the safe week's objectivity period of your input week's objectivity checkpoint i believe most teams have already started working on this but if you haven't please check it out awesome thank you thank you um an update on the phase one stuff uh was how can i have been spending a lot of time on reward accounting so the mechanisms inside of the state to kind of track what is going on in apoc to do the reward accounting and also um design and phase one of just the the micro incentives for the

additional um duties around cross-linking and others um and i think cover cover did pretty well like basically just a yes a simplification of how rewards they're calculated and this is also kind of coming on the heels of the other change to fit uh that we did in phase one where we basically just uh do as a a simplification of the accounting process and so we don't have to keep track of pending at the station objects and so forth yep other research updates

from the bsc side we are moving forward with the testing of the gossip sub 1 versus one so i'm going to post a link to a report in the chat thank you anything else okay uh if you keep an eye on the itfbl specs you've noticed that bls has been bumped to a version 4 which is incompatible with the current version that we're on this is a banning of the

zero private key um which doesn't really change much for us other than the allowing or the disallowment of the zero public key um after some discussions internally and some discussions with vlst library maintainers and the itf spec maintainers i believe that for the version 1 release for the main net release we will bump to this bls version 4 and so that will be one minor additional incompatibility um if you are using the blst the blast library uh they're working on an update now which should be done

very soon um so integrations to that bls version for from them should be relatively easy using other libraries this should be a very simple modification um does anyone else have anything to add on this carl justin or anyone that's been looking into it or anybody have any questions or concerns about this change maybe how are the talk with you over blockchain because maybe if everyone agrees to adopt v4 uh we won't need that much uh changes our wrapping so the um sorry there is a draft pr up

right now that has all these wrappers to uh modify it to modify the v4 to allow for the zero uh public key we are after some discussions decided that we should just go with draft 4 and not have to do these wrappers um sorry if that was not clear that pr is still up although is expected to be closed for a simplified just bls version 4. and a second question but maybe that will be for discussion in in the spec repo but it seems like there

is a need for zero public keys and signatures for phase one but not for phase two so um i just wanted to have some clarification on which scenario hello or requires that so there's a difference here between the zero public private key being valid and empty aggregates being valid there is a use case in phase one in which we do uh the empty aggregates essentially are banned in phase zero because of the way we handle uh the attestation processing but there currently is a use case for having an empty aggregate um with the way light client signatures are handled in phase

one this is a much more simple wrapper uh than actually allowing for the zero public key and at least right now is still in there but we could also investigate ways to avoid it does that answer the question yes perfect uh danny just to confirm there'll be a spec update and then we'll agree to what do a hard fork to um implement this on medasha or we implement for mainnet uh what's your what's the plan i mean technically it's breaking right so we should have a v0.13

yeah it is breaking um it right now i'm going to leave it as a pr um and the intention is to get into a v01 which would be the main net release we can discuss how we want to treat this on the dasha we can not upgrade or um the zero public key is not currently exist on the dasha so we could just quickly upgrade clients but that could change at any moment um my after i've been thinking about it this is a little bit of another conversation um i think that we should probably moonlight modasha

around uh the start of mainnet for a couple of reasons one because we'll have a v1 if you want to spec at that point that will have minor inconsistencies such as this um and we will also the vast majority of madasha is run by users in the community and i don't expect i expect the vast majority of them to turn their nodes off as they turn on their mainnet nodes and to not really worry about test nodes anymore if that is the case it probably makes sense to have a clean slate test net of v1 where we run a lot more of the validators so in that case for modasha we can support bls version 3 for the

time being and knowing that we're going to moonlight it and not need to support it in a few months or we can choose to upgrade it right now it's really easy to upgrade that might change at any moment any thoughts on that um yeah why not both why not try to upgrade me dasher but also have uh in mind that we might want to launch a new testament towards mainaction yeah fair um so i mean in that sense i can write some quick notes on what

upgrading modasha would look like it should be relatively simple and if we have buy-in and people want to do it then we will do so one other thing on all of this is in eip2333 i've been using the function called hkdf mod r which is basically the please else uh keygen from the specs and now with the new spec change that's not backwards compatible so that's changed so for what is very hopefully the last time there is

a minor change to the eip to update to this new this new hashing mechanism and here's a link to what the changes look like with the new test vectors uh while we talk about uh cryptographic eip uh or auditors uh ncc um had some concern about input validation in eip2387 the one for key stores they will put something in the fellowship of ephraim magician forum but they already did in the eip pull requests

also carl the practical implications of modifying that eip at this point would be that if tools bumped to this new version they would not be able to do key recovery so for example if a tool did not support this old version the modosha keys would not be able to be easily recovered with that tool the simplest way there probably is to use an old version of that tool rather than supporting both but yeah there's not a huge loss on the dasher side dude thoughts on that uh yeah indeed that's that's basically

the risk there so uh it makes it hard to recover keys based on your seed because you need to find a compatible um eip version um and if you wish to add more keys that would also be something that's difficult to do um but as then he said hunting down an old version is probably worthwhile and uh i think it's a worthwhile thing to have to draw this squash just now and then have everything just lined up ahead of mainnet thanks anything else on uh bls version 4

bls itf specs anything here great um i wrote down apa api status client teams have generally gave us an update about implementing that during their updates so that was good um is there anything worth discussing about the api at this point i know the the repo is generally pretty active i just wanted to make sure that things were moving forward but it seems that they are click upside and now that we're talking

about the apis um um beacon chain explorer is moving from the previous piston api towards the student api um and so although like currently there's a lot of focus on validator api um in the future we maybe want to extend this for other users as block explorers and energy users looking at their own nodes for performance reporting so yeah just account for that in the future got it

okay um networking we had a call last week it's productive so many items would like to discuss here um so one thing about networking i've been working on this dust runner that spins up that's not a little bit like the multi-client repository but then shorter lift test nets more contained hooked to a test suit defined 3d in yemo so to make it easy to define network tests

and then start and run different programs it's a little bit like hive but more focused on just getting the e2 details right maybe eventually we'll try and merge it or run it in in if one hive at some point um but yes the core of this i'll try and open source it soon and then we can start running some node clients and network tests great okay uh general spec discussion

anything here okay um did we want to uh talk about uh talk about the parameter changes for mainnet or is that like basically done and decided at this point um we can if you saw a couple days ago vitalik and i release a phase or eip notably there's a section that discusses uh the punitiveness of the initial launch and a suggestion

to have a reduced punitiveness on these tail risk scenarios because if something does happen there it's likely not an attack in the first handful of months this specifically is the reduction of a 3x multiplier on proportional slashings to 1 a increase of the leak penalty quotient by a factor of four meaning it takes four times longer to have to leak to what previously what was this in such a scenario like the madasha incident

would have made although it would have made it not quite as painful for users and the minimum slashing penalty quotient is increased by a factor of four which makes the minimum slashing more of more around 0.258 instead of one and the amount that you're slash um with the stated intention of upgrading to the full punitive parameters on the approximate five-month time horizon after launch uh this would give us a chance to practice a hard fork before phase one um and at the same time make it a little bit less uh make reduce

the stakes a little bit for early stickers questions thoughts uh we should probably run this in some sort of network before going live with it just to make sure that all of our implementations are consistent i mean it's not complicated right but it's uh we should check so on that note within the next couple weeks we'll release a v01 a v10 which will have these parameters and we'll have test vectors built off of

these parameters in addition to that i would expect we should do a number of like multi multi-net like dry runs um and maybe proto stuff will be in the works as well um so that we can test do dry runs maybe not with uh the community but we should probably do some one-o dry runs with ourselves um because it's going to include these minor parameter changes along with the bls version for so i think there's enough to test

anything else on that other spec related items other spec related items okay general open discussion closing remarks anything here okay i'll get that release out as soon as possible

i recommend prepping um the spadina configuration has been merged i recommend prepping releases or whatever you need to do uh with the spadina configuration um so that users can start messing up the next week great thanks everyone talk to you all soon thanks bye all right thank you [Music] [Music]

[Music] thank you [Music] [Music] [Music] so [Music]

[Applause] [Music] [Music]

[Music] [Music] [Music]

[Music] you