All Core Devs - Consensus #59

Transcript

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

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

[Music] [Music] [Music]

[Music] do [Music] [Music] [Music]

Danny Ryan: okay great the stream should be transferred over and here is the agenda uh we'll go over to some client updates and we're talking about altair which we have the final little bits to decide on and then we can do a pre-release uh from there we'll talk about prater i know the status seems to be a little bit in limbo research updates general discussion okay so today we can go ahead and get started with nimbus

is it working yes yeah it's fixed

Mamy Ratsimbazafy: okay so we've had our 1.0.10 release uh this morning uh we skipped 1.0.9 there is almost no difference between them uh except the default so the main things in the release uh we updated our blst and brssl library and brssl includes uh an up to date list of trusted root certificates so we recommend you upgrade to 1.0.10 and also we are compliant with the 1.0.1 spec which only includes a very small update to the f1 withdrawal credential

we fixed a number of bugs in particular one that affected people where we had a crash on some hardware configurations if you built a nimbus from source we also fixed some long processing delays that were triggered when we receive attestations that were actually uh to prune the states from before finalization we have a better p2p peer management because we had a lot of inactive collection connections that could be accumulated and we have fixed a false positive in doppelganger detection when an old attestations were also received after

a significant delay and in terms of new features as a highlight of the release is an improved format of the slashing protection database we will roll out the update in 1.0.10 and the next version so in this version we will have numbers supporting both old and the new format to have easier rollbacks if needed but we hope we you don't need it and uh certainly from next version it will significantly improve uh reduce disk load uh when you have a large number of validators so thousands or more uh mainly uh for us on pyramids but if

we have a large stickers that would be helpful for him as well and we have also improved uh the automatic configuration and detection of external ip addresses

got it action-packed release thank you let's go with lighthouse

Mehdi Zerouali: hey everyone uh we've also had a release about 24 hours ago 1.2.0 uh includes several improvements to lighthouse stability and performance same as names i guess particularly for users running multiple validators um one of the cool optimizations that paul landed affects our block production times i believe

managed to reduce that by four times uh by introducing a block proposal cache and also running slot processing before the actual proposal window uh we're handling beta early blocks just gonna be good good for the overall network um we started pruning the slashing protection database periodically to essentially prevent from it being oversized and slowing down the signing we've removed the pubkey cache file which caused a few issues historically and we're storing that information down in the database we've added the ability for users to set the graffiti from files also updated on bls library apart from that some of us have been

going through the hard fork spec michael provided some extensive feedback um yeah that's pretty much it

great thank you how about taku hey everyone

um so we've been focusing on the upcoming hard fork we made some good progress on refactoring beacon state and beacon block body data structures to support versioning we merged in an implementation of the fork choice balance attack mitigation although we still need to do more testing and performance analysis on that we spent some time looking into the block slot for choice change we only measured some initial refactorings as it looks like

this isn't going to be included in altair and we have a pending config update for the new crater test net but we're waiting on the upstream pr to be finalized before we merge that and that's all i've got thanks

great uh prism hey everyone

Raul Jordan: um we have been also working a lot on the hard fork preparation um and you know similar to tech guru just making sure our data structures are um you know can last the test of time we don't want to make we don't want to have a lot of crazy conditionals or spaghetti code as a as there are more forks in the future so just a lot of thinking ahead a lot of uh

preparations a lot of just uh refactoring to ensure that it's maintainable uh more further work on the standard e2 api and we've been working on uh our optimized slasher implementation so hoping to release that by the end of this month and aside from that uh yeah just had a release fairly minor just uh you know some improvements uh runtime improvements and uh helping improve the experience for stakers that's pretty much it great

thank you and lodestar

Cayman Nava: hey everybody uh so we are also we're still working on uh getting ultir compatible so just a lot of refactoring we just finished refactoring the

gossip validation and handling to support different forks we've also been doing a lot more profiling and adding up metrics um just to kind of help with some of the performance issues we've seen in the past we just fixed a memory leak that's haunted us for months and reduced a lot of memory while we're syncing so things are looking good on that front and finally we're working on just proof of concept like client things right now like right now it's uh looking like exposing uh the like client sync updates and multi proofs on some endpoints and um working with like requests and response

of those things and then the last thing is we are working on like weak subjectivity state infrastructure and i'm kind of curious how other teams handle this like how do they distribute these states or with what frequency they're updating them and maybe we can ask that question later

Danny Ryan: yep oh we can bring that up thank you okay um let's move on to discuss altair um there is kind of a large pr that i've asked in a review to review

um that had this 65 64 epoch boundary processing update where essentially uh when there is emptiness like empty blocks you forego processing a lot of pretty much everything most of the validator set until these boundaries to reduce the load based upon feedback from a number of the engineering teams it's unclear whether this is the proper optimization um it kind of targets first and foremost computational load uh whereas it is unclear exactly how disk io comes in and whether that can be optimized in a similar manner um and so to that it's also a relatively deep feature so to that end i would

recommend not putting this in altair um it seems like that's the recommendation of engineering teams and that any such optimization to the spec should probably be accompanied with some like r d on at least one client and some data driving it is anyone there's also another feature that was in this that is validator independent leak in activity leak and so there's a leak score array leak score list that was pulled out into a separate pr so it can be considered independent so we can talk about both these things but first and foremost um is there anyone opposed to leaving this um 64 epoch period boundary out

i know we've discussed this offline i just kind of want to let anyone error any grievances okay um so there's an independent pr on the league scores uh this is a very nice feature and when it's independent it's it's actually relatively thin um and i think a very manageable and a good thing to put into altair um so there's that pr with some testing and it's ready to go in um i i guess i'll i'm gonna merge that this afternoon um unless anyone has some issues here or has a chance to take a look at today and um wants to speak out against it i think it's a much clearer cleaner uh feature than the

other and is not allowed overhead to implement and specifically this attempts to resolve some of the issues that we saw on the test nets where you have um say oh a week of leaking and then you get to finality and then the leak restarts and then you drop you know one percent and all of a sudden you're not finalizing again um whereas this uh off-blindedness is kind of tracked independently of each validator um and so if that leaks started up again and they hadn't come back online uh they kind of start where they were and then that quadratic leak um this helps kind of the network resolve partitions

in a much cleaner way any comment on that if not um please if you want take a look at it otherwise we're going to merge this this afternoon in preparation for i think tomorrow's pre-release okay now we've seen some conversation around uh block slot uh edition do you want to give us kind of the the status update and what we're thinking on this

Aditya Asgaonkar: yep so there are two pending for choice uh pull requests that are open uh one of them is 2197 which is block

slot the other is 2101 which was randomized timing for attestations and block production uh it looks like we we are definitely not going to include them in hartford 1 and we are most likely going to abandon these because of some issues with how these fixes work and whether they actually solve the underlying problem so we are definitely going to not include them in hardwood one and how we can include them later whether that becomes a hard fork or just a point of coordination that is up for discussion and we can take it on when we have a concrete fix in mind

Danny Ryan: yeah so especially with block slot the

um solution might be worse than than the the problem if not if we don't add any additional mitigations in that it puts a pretty significant um four second assumption on latency and the blockchain just kind of becomes live not live and when there is longer than that on block propagation times um which is not great so we're investigating a bunch of other stuff we hope to bring some other people into think about this problem and there's some leads but it's just not ready to put into this fork and point of coordination in terms of the uh additions right in that most fork choice changes as long as they're not a company with a

consensus like a state uh transition change um can be done outside of a hard fork uh but there's also not a potential that it could be coupled with a consensus change so we shall see um some of these attacks are somewhat exotic and probably probably pretty unlikely to be seen in the next six months but we'll keep our ear to the ground in case they emerge okay um networking let's see what i have there okay there's a open issue on that age opened up

in january uh 2183 and there's a pending there's a fix out for that right now um essentially it's a removal of a aggregate attestation propagation condition that was kind of short-circuiting it wasn't doing what it's supposed to do because of uh the way the interplay with message id and and some of the way gossip sub works was actually probably inducing more load on nodes uh than it than if it were the potential optimization the attempted optimization was not included um there's a pr for that uh this we too will likely merge today um you could potentially do an

alternative um that does like a type specific message id um my gut is that this is probably not worth it but we can chat about if anybody has any thing to talk any recommendation on it right now let me know otherwise um check out this pr that's two two two five um and the accompanying issue um we can chat there but this will likely go in very soon okay pretty non-controversial stuff um

where is my agenda i lost my agenda one second too many tabs okay and then we have some exciting test format updates coming out um is showing on the call no proto oh yes she is would proto or xiaowei would you like to um talk about the changes in test updates actually proto you you probably have a better handle on that um with the snappy compression can you give us a tldr

sure um you can hear me russ

yes cool all right so um there was this pr opened

Protolambda: in october last year that introduced compression to the test format so that it's going to take as much as like 10 or more gigabytes of this data but rather like half a gigabyte so your test setup would have to go through this in compression step but aside from that it's an improvement in the like a large improvement in the dust size and then later on we had this issue opened about further improving that does format um everyone kind of agrees on

compression so we're leaving it at that right now maybe in the future we'll have more sophisticated test hormones with deduplication but right now this seems like the better and more direct option to reduce the uh dust size for the next hard

fork

Danny Ryan: great and the numbers ran in october i think we're reducing the outputs from 11 gigabytes like half a gigabyte that's probably changed now with an additional fork but still very significant um and this just adds an ssc snappy extension rather than just sse and we also remove the dot yaml versions of um

states and operations which from our understanding and investigation in october uh there weren't really used by anybody okay um and shall we what's the status on for choice tests is that we're gonna have maybe a sample of that coming out in the pre-release

Hsiao-Wei Wang: uh yes so currently the pr 2202 has shown it's a preview of the incoming test moment and it's a follow-up of alex vladov's previous work i think it

was discussed on the eastern spec test uh repo so the there are some differences uh between the previous proposal and this proposal uh mainly it's for making it more easy uh for high stake to generate the test so uh you can if you want to see the test vectors are there uh example of the the get head test and you can check the state states uh file which is a

it's kind of like our meta configuration but it's uh it shows what are the states that the client has to checks and let me see so checks is basically like the assertions uh like you have to check the value if it's equal to the test vectors and we have the block and attestations of files um in the test vector output so currently i use just a test station and the authentication

has uh roots to present the file name but i'm thinking i would can maybe just use the first eight uh bytes or like four bytes to make the filename shorter yeah so if you if uh kinda things have time you can check the 10 vectors up to 202 and see if it would be like some drawbacks in this pr right now and if there's no further issues then i will first compute to get head tests for clients to

try out

yeah thanks

Danny Ryan: great um yeah so check that out any questions for show a or proto on some of these test format updates great and as it is a pre-release um if you get into it and there's something that totally didn't make sense in these new formats just let us know we can iterate okay um next i want to talk about prater aphry's on the call who has put together that pr and there's been some coordination although um i'm not quite certain the status of launch

and things like that so um afri or somebody else want to give us an update on where we're where we stand

Afri Schoedon: um yeah sure so uh uh i missed last call so kind of the back story was from how i understand is that we want to front run main net with a test net it has significantly more validators and we want to propose this test net prata with a bit more than two hundred thousand genesis valley datas and instead of um spamming the girly test net with a lot of deposits um we decided to uh pre-populate the guinnesses with a certain amount of validators

and uh proto was so kind to write a small go tool to [Music] generate a test net genesis from a handful of seeds and uh this pr on the east 2 test nets repository is ready to go so we took the guinness time from the uh deposit contract on gurley which was i don't know 11 days ago and had have a custom um guinness delay that puts it to i think next week on wednesday which should be 11 uh 16th of march and

um this is ready to be merged and i think unless anyone has any comments on that we can move on with this and i'm looking forward to against this next week uh yeah regarding guinness body datas we have pre-populated togetherness with 210 000 valley datas i'm not sure where we stand regarding the um uh regarding the let me just pull this up here we have a spreadsheet yeah i opened all the links except this one so um it's for each client teams 40k validators um we'll probably uh

finish distributing the keys before the weekend hopefully and then we can make sure that everyone is running their validity as next week i don't know proto uh did you hand out any keys yet

Protolambda: no

otherwise i would have updated the spreadsheet okay yeah so i

Danny Ryan: i just want to make sure that client teams are ready in terms of infrastructure and have time before genesis uh to get things done

Ben Edgington: yeah um so i flagged earlier on the teku side so we were advised uh that the signal to find like that everything was final would be the

merging of the pr so it hasn't been merged yet so we haven't done anything and less than a week just isn't time either to bake the uh genesis state into a release or to get the infrastructure uh up and running reliably i mean it's it's a lot of infrastructure to run this this number of nodes so uh we i think we would propose we would request um putting back uh genesis by a week just to allow uh us to get a release out with the genesis data in and and just to make sure the infrastructure's in place without having to rush and work the weekend and all of that

uh that's

Afri Schoedon: perfectly fine for me it's

just uh so i can push this back one week regenerates against us and then we start distribute the keys and uh everyone should have enough time next week to prepare clients and set up validators

Danny Ryan: yeah it's totally fine for me this isn't this is something we need to do we've identified that we need to do but it's not uh critical that it happens next week so um all right and and after will the pr be merged or will it stand as is for the next week but we have all agreed that it's happening i don't just process your thoughts uh so i can merge it

Afri Schoedon: i mean i have write access but uh i was

hoping that someone else could just say okay this looks good or something or even someone else merges so we know this is fine to go i mean i can merge it if no one has

a bandwidth

Danny Ryan: um make the make the update to the genesis time um and maybe paying on discord and i will certainly do a review um with a explicit approve and and maybe others will but we can merge from there yeah i think we're all in agreement that genesis is in two weeks

great yes thank you much appreciate it yeah absolutely

Protolambda: and make sure to have the correct genesis state in your clients changing the genesis time also affects the

state file right

okay is there anything well how do i pronounce this pra pratter prater prater yeah sounds good which one okay great

Danny Ryan: um so is there anything else people want to discuss around practice before we move on excellent let's do some research updates maybe we'll start with mikhail i think you have some merged stuff to talk about

yeah sure thanks danny

Mikhail Kalinin: um there is like the open pr uh with the merged stuff

to the spec repository um it contains like the executable beacon chain proposal um so let's drop it to the chat now uh this is like a good time to start commenting on it looking at it and so forth um it should be like fairly easy to reason about because the amount of change that's not that huge um so uh it requires some like upcoming work like making this back executable um running tests and like creating new tests and supports but yep it's ready to ready for everyone to start looking at

it so that's pretty much it on the

merch cool thank you um excited to get in there other research updates

Vitalik Buterin: nothing on the easter side for me this time around

got it okay great

Danny Ryan: moving on um it was the uh state of kind of reciprocativity

exhibitivity state distribution and things like that um was brought up by cayman at the start of this call uh cayman do you want to pose a question or is anybody else want to kind of give the state of what people are considering

Cayman Nava: yeah i'm kind of curious just uh how you all are generate generating the state and then distributing the state if anyone has any thoughts

Danny Ryan: aditya what's the status of kind of the format to distribute states and uh some state providers and stuff in the in the network right now

Aditya Asgaonkar: um the last time we talked about this

the status was that we're just assuming that um we share the state uh in alternate channels maybe torrents or somewhere else uh we really haven't thought about how to share this state over the eth2 p2p network um we can try to think about how we can compress the state or break it down into simpler pieces and reduce the load on our p2p network the main problem seems to be that state sizes are run into a couple of mb's at least and that would um kind of weigh down the p2p network a lot so this would be a larger research problem to think about

yeah

Danny Ryan: yeah i understand

is anyone planning on cutting these into their releases i know there's kind of back and forth on that many months ago

we had talked about it at one point but we never got around to it

okay

Danny Ryan: i think that we there's definitely a desire to kind of have this machinery in place around altair so um it's probably worth us running through some of the various scenarios and making sure the machinery is in place um do the command line options generally exist on clients today to be able to start from a state rather than from genesis

it's a yes gotcha

Mamy Ratsimbazafy: we have something in nimbus but it's not tested

right

Mehdi Zerouali: yeah michael's working on this um i think there's a branch that has that feature but certainly not

unstable um prism is working on this as well okay

Danny Ryan: good so i think and i think this has been recommended in another context with the um kind of targeting this to be in a version one um for altair although it doesn't affect kind of the core specs precisely um i think is a good a good target um so we can talk about it offline a bit and

um we'll bring it up on the next call as well kind of check check in on the status um is there anything else to talk about today i know there's kind of a lot of nebulous items related to that that aren't so clearly defined um if people want to chat about them more now by all means otherwise we can chat about it offline

Mikhail Kalinin: i have like uh one thing that i would like to share as well it's related to the merge and not the before request but yeah um so i'll drop it to the chat this is like the proposal by then create to which is about deferring the execution uh by a slot um so the idea behind this is to

give like more time for uh testers and for proposers xbot to execute uh transactions of the previous block it has its own trade-offs but would be great to chat about it discuss at them yep for those who are interested

take a look right

Danny Ryan: so doesn't it delays the commitment to the state route until the next slot so that you can continue computation uh throughout the entire slot right

Mikhail Kalinin: yeah right so like the proposer of uh of of the block is like the

is like the sequencer for the current application payload and the the executor of the previous one so that's the idea

Danny Ryan: okay take a look okay moving on to

general spec discussion um just general discussion anything else people want to talk about today

Vitalik Buterin: uh anything about merge plans to talk about or do we still want to have more time to formulate the options

Danny Ryan: options with respect to

Vitalik Buterin: speeding it up

Danny Ryan: um so i think next thing that we plan on doing is doing a public call maybe next week definitely by the following week um to kind of invite at least a member from each team to begin allocating resources to it um that's the main speed up other than getting specs written

which is now in the works um i mean and i think you and i have talked about this and a number of uh mikhail i've talked about this in that there are the way the specs are going to be written are going to be very the most minimal merge on the first pass and that's the first target people can begin working on and that can even be what we bring to bring to mainnet that might forego a handful of features um including say validator withdrawals you could go to mainnet without that and do a four three four months after so definitely in terms of speed up that's also a strategy is to really

scope the uh tightest version of it

and like the what also was discussed uh for a bit it's like the consensus upgrade um is what then it just referred to uh is separated from the merging the like application chain with the beacon chain which means that the application chain history will retain and the er and this like merging the chains is gonna be like a separate separate upgrade um through the governance and other processes

procedures

Danny Ryan: right and some of that might seem a bit abstract um nick is both working on um kind of technical road map documents that we plan on sharing soon that show kind of the dependencies and and the the minimal version of the merge and things like that so we can we'll make it more concrete soon anything else today

okay very chill call um i appreciate it uh we are on the final little bits of getting a altair pre-release out to you thank you for sprinting ahead taking a look at those features and getting code bases ready i imagine there's going to be kind of a round of feedback there that we're going to want to do and and some implementation work that we're going to want to do before we set a date um but definitely still targeting that approximate june date

at this point so great thank you take care uh we'll talk to you all very soon on the internet and we'll have another call in two weeks

bye guys thank you bye [Music] [Music] so

[Music] [Music] [Music] so

[Music] [Music]

so [Music] [Music] you

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.