# Eth2.0 Call #61 [2021/4/8]

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2021-10-09
- Duration: 31:41
- Topics: blockchain, smart contracts, distributed ledger, ethereum
- Watch: https://streameth.org/watch/yt-XLB5HEWdZUE
- YouTube: https://www.youtube.com/watch?v=XLB5HEWdZUE

## Description

https://github.com/ethereum/eth2.0-pm/issues/212

## Transcript

um yeah i was testing a different audio setup and then my zoom kept crashing so i have to just call it today but thank you um cool welcome call 61. we will discuss altair a bit peritosh and i think leo are going to talk about some metrics naming that might be useful talk about research updates uh if you you're probably aware there's a number of other things going on specifically the ryanism uh calls there's a golf call yesterday thank you proto and there was um there's also a fortnightly merge specific call so although we can certainly answer a couple questions here if you want to dig in any of that i think it'd be best to use the appropriate channels and the appropriate calls to dig deep into that um i think the focus here will likely be on on alt's hair for the time being um i on the client updates i'd love to hear just general progress on altair uh specifically uh just kind of the feel on where we're at on engineering um are there any huge blockers any any skeletons in the closet as we've been kind of modularizing components and stuff so help us understand that um so that said let's start with client updates and we can go with uh prism yeah hey guys um terence here from prismati labs so let's um so let's chat about a tear first so from a tear front um it's a little bit slower but we're making progress so the latest progress is that um we implemented a terror uh bitcoin state um with the with the replacement and the additional fields so um we're doing some testing around the estate to make sure that's implemented correctly and i've i'm almost done with the process seeing uh sync on committee and uh so the next in my to do this is to work on the um accounting reform so that's us for our tier um we're pretty confident that once we have the foundation for the hard working logic done then the rest can move pretty quickly and in terms of the merge we release a demo for prism and catalyst so i hope that people have tried that and on the current work front we did some optimization for the slasher db schema for a more efficient storage we started working on with subjectivity sync so people can pass the state or url slash block route to the coi and and the notice thing from there and we also fix a few parts on the pier store in front so yeah that's it thank you vice chance let's do decker hey everybody it is i this week um yeah so the last little while has been pretty much all about altair uh progress is good uh so we've updated the alpha.3 reference tests and almost everything is passing uh as i understand it there are a couple of sanity checks which are failing so there's some insanity going on somewhere and we are failing to decode the ssd in one of the fork choice tests which is weird because we pass all the other ssd tests so i just need to investigate what's going on there but otherwise i think we're in pretty good shape on altair other than that we've been making optimizations for the workload on prata mostly improvements to peer scoring uh updating the latest blast library and doing a bit more batch verification of signatures in attestations and that's pretty much it except to say like everybody else we're hiring thank you i have a question i request when y'all do figure out the ssd decoding issue um if that is in fact some sort of corner case that we're not covering in the sd test let us know so we can get a test specific for that in the in the right place rather than kind of implicit in the poor choices yeah for sure okay load start hey everybody uh so real quick let's we cut a new release 0.19 um on on tuesday it's pretty chunky uh and we're now supporting the latest lts of node version 14. uh we added queuing to our gossip validation engine and we also have threaded bls verification now so all these things kind of combined much more stable node running as far as altera goes uh we have done a lot a lot of the preliminary work for for altair just ensuring that we have support for different data structures uh updating the database we also have a naive implementation of the alpha 3 state transition and it's passing spec tests so i think the upcoming things are making something that's more that matches our fast state transition implementation uh and also implementing the various network updates which we have not yet tackled wait did y'all integrate the um fork choice test yet oh we have not uh we'll we add that to our list cool and the other clients as we go if we you can let me know if you'll integrated those cool great thank you let's move on to lighthouse we are also passing the alpha three consensus tests danny what was that i missed what you said just then you wanted um and so i'm just curious especially because techy ran into some decoding issues i'm curious if there's integrated those yet no so we haven't done the four choice ones just the consensus one so far it's all by that i'm passing those uh we're also working on alternate networking with twine and age we have our doppelganger implementation in for review that's the protection against running multiple dc's um we've been doing a lot with the memory allocated still we've got kind of three to six times memory savings um they're kind of in review and we're still squeezing a bit more out of it um we're working on a ui development um so it's in working on screenshots now and designs and it should be starting coding at the end of the month and we're also working on preparing for the merge test net and rayon rain is in hackathon that's it from us great and nimbus hi uh so regarding the altair uh hard fork uh for now we have the low impact and preparatory changes uh merged uh still evaluating the modularization of the code base for example the beacon state uh the main thing that we need to solve is that currently we assume that we have a kind of one fork at a time design but when we replay all states around the transition we need to be able to handle it properly otherwise we improved performance of nimbus so we had some bottleneck real related to planning and we also uh added uh attestations batching and uh this uh improved performance on raspberry pi to be able to handle uh the increased load on pyramid and hopefully a pratter as well uh regarding prata we also added a prater page to our nimbus book and we also merged a long-standing feature request fallback if one provider so that you can point to geth and also insurer in case your gif instance fails so you don't have any issue with producing blocks otherwise we also finished or http server work because uh in name we didn't have any uh http secure http server that was working with or stack and so this means that in the future you won't need to add the insecure option to have metrics and this also means that the rest api is almost finished it's just pending review and you won't need to use a json rpc which was used as a stop gap and lastly on the devops front we will be migrating or flipped away from aws to save on costs for now we are migrating only one node but it's possible that in the coming weeks we migrate uh some more and we have some done downtime in in between got it i have a question for those that have done the baffle ganger protection uh especially after the prodder launch with nimbus did you all decide is there a workaround for genesis that you have integrated or is that just still a case where people are offline for a couple of epochs given that it happens once every six months is we didn't work on the workaround yet gotcha paul did you all do anything with that um i think our plan is to just not enable it at genesis right like a flag yeah that's right cool okay thank you um on i know everyone's kind of working on different ways to modularize the codebase handle these these fork data structures and worklogic is there any particular blockers or issues people run into that want advice or information sharing here ask away yeah cool reach out to each other moving on to altair as you all saw alpha 3 was launched i actually was i realized i did something embarrassing but then prototype is not too too embarrassing but i i realized i started at alpha one instead of alpha zero um and actually confused myself when i was releasing alpha three and i was like wait we haven't done four of these um so anyway i had a little off by one error in my head but uh that is out that is really close to honing in on a final version i i think there's a couple of cleanups there's some additional testing being done uh but nothing substantive that is in dev currently and the plan would be to get people to um to kind of get thumbs up from engineering teams that implementations are done and also obviously any feedback that you might have so we can hone in on on finalizing that we are at kind of the beginning of april we had discussed doing uh this release two main net in june uh that's beginning to be maybe not aggressive but uh the optimistic timeline i think we should definitely shoot for june july um but i have a feeling based off where people are at that we're not quite ready to talk about timelines does anybody have strong feelings about earliest timelines currently that they want to share uh we need to like two months is lead time for audits so uh that's a hard constraint okay if you are looking to do audits i would schedule them right now uh because the way that um my understanding of the the current auditing industry is that people are incredibly busy and getting timelines even within the next three months might not be realistic yeah i can second that um any other comments on altair planning i i figure in the next couple weeks we'll have a much better visibility in this okay uh so let's keep digging in and communicating quite a bit as things are ironed out so that we can begin to set some uh target dates okay uh leo and perry are have been discussing some standardization of some core prometheus metrics that might help in various ways perry leo do i want to talk about that uh yes um so yes the idea is to try to standardize some of the metrics and uh the plan is to start just with a few of them uh say about a dozen of them uh we have prepared a document that i just uh i just shared the link on the chat uh in which we have two sets uh one of uh then we call the minimal set uh it's about a dozen metrics that we think are interesting to look um in particular in the context of the proctor test set and so um we provide the list of the metric the description the reasoning and we look at four of the five clients and i think at least for the first batch of metrics all of them already implemented them um the the problem is that they just have different names and we are not 100 sure that this is what it really is um so the idea is to really um uh start with just uh these uh few ones and standardize it into a way so that we can monitor it and make uh dashboards and and really see easily what is going on um so what it would be really great if is if um you know the different plant teams can either choose or select one person that can help us with this um process uh we promise to take as least as time as possible from you guys we know that you are very busy um but yeah if if we could try to uh set some call uh in which we can discuss for example which of these metrics are the most relevant and if the numbers that we sorry the metrics that we got here are correct or not uh and and discuss on that would be great um so um yeah we will try to set up a meeting uh within the next few weeks uh to disclose this metrics and it would be great if the client teams can select one person that can join this meeting and let us know which uh which person is that uh party do you want to add something else no that's a bad thing thank you all right right for one and you have to have questions one thing i want to reiterate is that um for client ease of client fluidity i think we did a good job with the validator interchange database but one thing that i think is locking people in and hear even more is their monitoring setups people do a lot of work to get things set up and monitored properly and then don't want to do that again and this could potentially enable some some better fluidity there leo and perry what were the particular use cases that are driving this effort on your end is it primarily monitoring i mean obviously it's monitoring but um yeah what are y'all attempting to do here yeah so um i think yeah that's that's what we discussed with barry um several use cases in in the context of the pratt or not i think uh in paris has very clear uh use cases uh do you wanna mention those party yeah sure so um it pretty much started with the prata setup um i wanted to create a bunch of dashboards to monitor how the testnet was going but quickly then into extensive amount of having to look at three or four different documentations to figure out the exact metric names so i looked at what pain points were there and what metrics were relevant for me to know that stuff is working perfectly fine and i just sort of spoke with leo discussed them if he was also on the same page and then we listed them down regarding monitoring um i've seen that the if 2.0 api repo has a v1 release so i assume that it can be targeted as a standard or some common monitoring across client uh which which link is that uh i mean i'm adding it on the chat the apis are different than these monitoring metrics right they're fairly independent there actually exists a metrics document which tried to standardize this like back maybe a year ago so that would also be maybe that yeah growing old um but some of these metrics um on the lighthouse side we've also been quite interested in um standardizing metrics to enable client fluidity um one of the approaches that we've looked at taking is there's a bunch of um community members i guess that have made some pretty cool dashboards i forget their names now but there's some some quite popular ones uh typically they work with prism um so the approach we've been taking is trying to get these dashboards and then and then use that set of metrics to indicate that people you know want to use it and then try and focus on those first um so that's that's kind of the route we've been taking we had someone on that full time but they got distracted but i think they'll get back onto that full time so lighthouse is keen to standardize that would it be possible for you for you to put us in touch with this person so we could at least get the information about the dashboard and then correlate that with what we already have in a matrix a minimum metric set yeah sure so something i found with metrics is that it varies a lot depending on what you want to do so if you're like sitting there and you've got like you know two main net validators there's a certain amount of things you want to do if you're trying to monitor the health and network there's the things you want to do and if you're someone like me there's a whole other set of things you want to do so um yeah it is that's just one thing that i've found but i think um there's the lighthouse um has a ux channel people share some of those in there i think cmonkey82 is someone that's made a good one i can also see joeldock has tried to convert it over to lighthouse um but perhaps the prism discord just reaching out there and seeing what people are using is a good idea right so we noticed that actually most of the clients they already have a number of metrics that are already common to all of them so i think uh the best way to start is to um you know to decide this common intersection between uh all the clients or at least most of the clients and start from that point um so i think in in the document we added a small table uh where you can have uh other contact person for each client um so if you can you can go ahead and phillip then we can contact this person and try to set a common call and so we can all discuss about what are the most common or like what are the metrics that make sense uh to most of the clients yeah we have probably a thousand or something so there's there's quite a few few but can't help out are you any other comments or questions on the sporting good one all right thank you perry and leo there's any research updates you'd like to share today yep i have um okay okay go ahead i don't know okay you're free okay i'll go um i'm happy to share that the new full choice spec is ready this has been in the works for a few months so pretty excited to share that it's pr2292 on the spec sleeper please do check it out and leave comments and feedbacks and if there's something specific you want to talk about you can ping me or danny uh the summary of changes for this pr is that the block restructure is changed and the way that latest messages are accounted for has changed during ghost execution and the happy um news here is that there's no change to uh the network structures so latest messages uh votes remain the same the way latest messages are structured remain the same and overall this has good security and good performance and um yeah we had a few setbacks in the research that was the cause for the delay but it seems like this is a really good fix that we have arrived at uh does that new fork choice imply that we need to have two for choice implementation or can we use it to replace the world chain from genesis um i think it should work so basically as long as that specific attack has not happened the both folk choices are going to give the same result and as far as we know nothing like that happens since genesis so that focus should be i mean also it doesn't matter once it's finalized right so only if we had a non-finalized chain that would matter in any way yeah both are rooted in finality and so it it could you could imagine it in causing a minor reorg in that stretch after finality if you switched it but that's fine right exactly but like once you have switched and you have finality you there's no need to remember the old focus rule yeah exactly it's written as such it is an uh a change to the the phase zero to kind of the base pork choice um like i guess we can we can make it so that it can only get activated on finality or something like that and then you at least should never have to use both sport choice rules at once yeah but even then in 99.99 of cases uh if you just switch the four choices it's going to give you the same exact answer as the old one right right yeah i guess true you can just say just make it a rule that everyone implements the new fork choice at a certain time of the day and then that should also work here right it would also probably be fine if some of the nodes uh have upgraded to the new one and some of them are operating on the old one but obviously that's um yeah might get tricky yes if if we said that we were all going to change at some point in the day then that would mean that we at some point the clients need to have both of them right right that's exactly what what i thought miami's question meant um i think yeah to make the transition there would have to be those two implementations living in the client at the same time um at least until we are done with the transition not even worth that complexity because if anything you like if there were this type of attack you might have a disagreement for some short amount of time but even justification and finalities still it's not like you're removing things from your choice so things can still move on right you're just adding so i guess like we can probably easily show that there's no safety issue with us with having both at the same time right and then i guess yeah mommy is right like we can just make it an upgrade yeah just get all the clients to release in the same week or something it sounds like it would be reasonable i that's what i would argue yes but we can we can just we can think about a little bit more but i that's my understanding is that we can it's safe to roll it out like that and something that we are looking for specifically as you look at it is just kind of like sanity check that engineering complexity and and that of this change is not massive uh that it you can generally kind of use some of your same structures and algorithms in slightly modified way which we believe in this case anything else on fork choice before we move on just to be clear it's not for real today right we are not currently planning on releasing it out again it is a it's a modification of the phaser rule and so once we do have it um inspect and we're considering it for merge we can have the conversation we can re-up this conversation maybe offline uh about how we want to coordinate this okay uh other research updates yeah i was just going to give some updates on the merge um uh first of all uh we are changing the terminology a bit so we now speak execution layer instead of application layer um execution engine execution payload execution block and so forth there is a corresponding pr in the stack repository and once this vr will be merged um i'm about to make a couple of a couple of cleanups more in a separate pr and then it will make sense to start working on making this back executable which has been already started by cellway thanks a lot for that um so yeah also um there is a spec for ryanism which is focused on the former proof-of-work clients and how to turn them into the execution engine and uh yep it's like i'm almost complete so need to do also some fixes in that um yeah so that's probably it for the merge uh also we have a merge implementations call next week if you want to discuss some particular technical detail regarding the merge just reach me out i'll add it to agenda that's all for me great and can somebody drop that uh ryanism [Music] spec into the chat i think it's a really good document especially to get people up to speed on execution inside yeah i'll just drop it thanks okay anything else on the research side great um spec discussion especially on altair anything that's come up that people want to discuss have questions about great and any items in general people like to bring up on this call so besides the merge call next week we'll also do more regular calls for realism so if you're interested to stay in the loop you can attend these kind of office hour calls these are optional and you can hop in and out on the discord in the r d discord and yeah you're welcome to to help with the early merge work great yeah less formal more just kind of catching up asking questions shooting the okay and anything else people have to share or discuss today awesome again sorry about all the technical difficulties earlier uh we'll get this up on youtube soon thanks for being with me have a good one talk to you all very soon bye everybody thank you bye thanks everyone thank you bye