All Core Devs - Consensus #74

Transcript

[Music] [Applause] [Music] stream is transferred if you're on the

internet and listening to this and you can hear what i'm saying say so in the youtube chat

Danny Ryan: okay um i have created an issue in the p e 2 0 p.m repo which we did not rename in the great renaming because we plan on deprecating it but i haven't and i made an issue named deprecate this repo so i've publicly committed to doing so by the middle of next month um i just need to figure out where to put the old information and move into the other pm repo announcement but until then we're using an issue in the old repo issue two three nine call

seven four let's begin um altair is happening i know that everyone's call knows but if you're listening altair is happening if you run a node validator or not a beacon node you must upgrade unless you want to run the old chain but otherwise you must upgrade i did create i scraped some data from uh nodewatch.io which has when possible collecting the client version and i i summed the altair versions against the total and the dock

i just shared with you shows that by node count by node count that nodewatch.io can find which i believe between the couple of crawlers you know there are some disparities so this is not canon but at least from what we can see from this tool uh 62 percent of nodes have upgraded and then depending on the client type it's a bit skewed looks like prism's 58 percent lighthouse 73 teku86 lodestar a hundred percent and uh nimbus for some reason that crawler is not getting the no the client version maybe it's being obvious um but i have not dug into that so i think we're in like reasonably good shape that doesn't map to

the validator node weight but um that has increased a couple days ago it was less than 50 so i'll be keeping my eye on that through the weekend um if you have connections with node operators if you run a staking community called east taker if you have a twitter sound the alarm it's time to upgrade um any i guess we wanted to get on this call and make sure everything's fine with respect to altair are there any issues or anything people would like to discuss as we move into next week

all right just one comment danny

Danny Ryan: oh yes

uh sorry we

we launched an experiment with comparing them the results of both crawlers not watch and our crawler in the same node running from the same moment and we let it run both for 24 hours and see to see if we get the same results or or not and we observe quite a number of nodes um that differ so we look at the source code of them and see if they were doing another using another technique uh to to categorize nodes but actually it's exactly the same that we do uh so that uh our conclusion was that uh most likely there is a kind of networking differences on the way we

we appeared with nodes notes and so we started looking into it we look under into the ip addresses of those nodes that we recognize differently and we we noticed that there was a bunch of nodes that we we saw that they don't see and there's a bunch of notes that they see that we don't see and that's basically the the origin of the of the differences right and we look at it and we also notice that they for the nodes that do ac and we don't see that we notice that they have all also other uh four digests um so it kind of looks like they are not only appearing with magnet nodes um but maybe other uh okay networks um and so that may be that's show the

difference

Danny Ryan: so that would but that would show one direction of the difference right but there's the other direction of the difference where there's nodes you see and they don't correct

that's correct and and we noticed that there was a couple of uh small bugs in in our case where uh when we appear uh afterwards for a second time with um with the same node that we already recognized in the past but for some reason the connection drops then we switch it as unknown but in a wrong way because we already knew the information of that peer before so we corrected that but that those nodes were like very i mean the numbers were very small so and they don't account for a significant part

Danny Ryan: okay so that

that might be the culprit so let's uh we can take this offline but i i really appreciate you looking in uh hopefully we can get some lockdown on the numbers in the next couple weeks yep cool thank you leo um other altair related items as we move into next week i know that eth staker is doing a watch party sometimes a number of folks do so if you want to join the festivities you can take a look at that

okay

Danny Ryan: uh we can run through some client updates and start with lighthouse

Paul Hauner: hello thanks denny um so we've been working to get the merge face-to-face branch uh merged into our main branch kind of splitting off little pr's and bringing them in to just slowly get into into master or what we call stable um we've been engaging in some discussion around the roles of payload building for the beacon node and evaluator client so being doing that on issue two seven one five on the lighthouse reaper it seems that the current favored approach just for the bn to drive most of the process um after the vc issues are kind of subscription type pc uh as the vc issues subscription type message um yeah if

you're interested in implementing that then maybe checking out that issue is something worth doing um michael sproul's been doing continued work on client fingerprinting and diversity analysis um and we're also wiring up some significant bandwidth usage uh improvements for the next release just been working on some a couple of breakages in rusted p2p but i think that we're pretty close being done with that that's about it from us

Danny Ryan: excellent thank you and um nimbus

Mamy Ratsimbazafy: hi uh so we released uh the nimbus 1.5.2 uh that is ready for our tire uh

yesterday uh not urgent for 1.5.1 users but for the others we need to upgrade immediately uh otherwise we had um several improvement on the rest api we increased the default limits so that you can make bigger requests and also we improved throughput for um especially for people who makes a lot of historical data and also improvement on the networking side and peer selection side so that you can have less peers and with cycling faster

uh into peers to disconnect phones that are less useful to us

Danny Ryan: thank you and prism

Raul Jordan: hey guys raul here uh yeah definitely missed all you guys at the face-to-face and that liscon nobody was able to attend from our team but you know we're really looking forward to going to more events uh you know starting starting early next year uh so yeah prism can now sync with the with the test net with the merge test net um that's been it's been a huge milestone for us uh and we're pretty much all ready for altair we should work into other things um you know we're hunting for bugs in the merch test net support trying to improve the experience of running prism with geth

and trying out other other execution clients as well aside from that we have been completing uh checkpoint sync uh and and starting to integrate support for web3 signer um which is going to be important for multi-client uh for client diversity uh code health is also top of mind so we've been working a lot on just improving the code health of a repository reducing uh you know technical debt um you know kind of when we have this downtime between out there and starting work on the merge aside from that we've been also thinking a lot about validator key management api standardization and you know thanks to that deptlion for the design here uh we're looking forward to supporting the standard in prism which will make it a lot easier to build kind of like multi-client web web interfaces installation interfaces a lot of people

rely on the prism web ui in like critical capacity and especially for like you know onboarding and and getting you know importing their key stores and getting started so uh we foresee this as being uh you know a huge huge boost um and usability uh for everyone uh that's it for us thank you

Danny Ryan: thank you welcome to the test net and

takuru

Enrico Del Fante: so yeah we did a couple of release last week

introducing options to specify different ports for udp and tcp for p2p and we added the jdk 17 docker support and duplicated the jdk 514 and 15 because we are not getting new security updates anymore we also upgraded to blast 0.3.6 we actually then broke windows user release windows windows release and we forced us to actually roll back in the quick release after that so what we've done also not read not yet

released is um implementing the api release 2.1 which includes the new header for specifying the consensus version and what is not yet merged is um support of the liveness and point for double ganger protection and since we had some problem for this release in terms of windows support we are working on better release management for detecting potential problems for windows release especially at in general for

native leap dependencies and we are about to we are ready for uh supporting publishing publishing system metrics to remote service and mostly working on moving merge data from merge merge code from merge interrupt branch to to master which is a long process and we for the ptos test net we fixed the one bug related to related to this in committee participation rate and we roll over roll it over a new taco version on the

on the test net and works good so far that's it

got it thank you and let's start hey everyone dublin here first

dapplion: first of all the emerging drop was a great success great vibes we interrupt with everyone including javascript only execution and consensus which was very exciting just a reminder version 30 0 31 and any subsequent are ready for attire so update we also fixed some issues and now we are compatible with portman looks we can

interrupt everyone find there too we are still working on improving memory efficiency and cpu performance improvements both in entire and in phase 0. then also improve some tcp 5 integration now we can discover the weight vps faster and yesterday we presented that disc on the lifeline rest based demo that we have been working on so super exciting going forward thank you so much

yeah thank you and granted hi solos

Saulius Grigaitis: from the team so so finally we completed this experiment with with multiple runtimes and

we have a alter working it looks like generally it works okay but there are a lot of interesting findings and some are not so great and some are better and i think i still need to write a bit bigger description about our experience with that and the next will be focus on the match so that's all

Danny Ryan: great thank you yeah i'm curious to hear the one of the things and maybe you see over time is just like that i'd be concerned about is say an optimization that is worthwhile

to back port and then you have to decide if you want to backboard to all run times

anyway

Saulius Grigaitis: oh yeah this is uh i would say the one of the reason why we tried this we thought that well if if all the hot fork is faster then we should not touch it anymore but it turns out that's not always the case you know right and yeah it felt like initially like it's it's a great idea but later we thought that well some optimizations and so on and and some similar things are a good back part there's one thing the another thing

actually what we found really really surprisingly hard is the transition uh process uh when you spin a new runtime and it needs a lot of context from the old uh runtime for your previous forum and this is something that we underestimated really so i think i'll just try to to write a bit more about that

Danny Ryan: that'd be great thank you okay um moving on to merge discussion obviously we did not have this call two weeks ago because of the amphora interop and there's been plenty of write-ups about that um

moving forward there were a number of um based off of discussions there a number of alterations the specs primarily in the simplification and a lot to do with the x uh engine api uh i've been chipping away at that and mikhail just got back from vacation today so we will both be chipping away at that uh with a target to complete all of those changes by the end of october so that we can release a new stable target of specs then so you can follow the changes in kind of the active development branch on any of those three components consensus

layer execution layer and engine api but that is not what pithos is targeting and so um and it is also will change a lot will continue to change over the next week um but moving out from there uh we do plan on then having kind of a new test net target at the end of november based off of this stuff uh shouldn't nothing's radically changing um and most of the core functionality is is stable if not uh some communication a bit simplified other merge related items today um something that paul brought up

is naming right now we kind of call the whole thing the merge but then we call the time at which the beacon chain upgrades its logic but the merge hasn't happened the merge fork and then we kind of call the point at which the transition occurs the transition process but it's also a bit confusing because the whole thing is called the merge you know the merge fork the merge transition process um and there was a suggestion to maybe name the upgrade it would also avoid the name collision with merging prs which is kind of funny i

i don't know the proper path here on picking a name it also collides with naming process on the execution layer um there's a bunch of conversation in the merge general channel any uh i don't think we're we're not going to come to a conclusion today but any any thoughts to share that were not shared in the merge general channel on naming

and

Mikhail Kalinin: we will have a new name for the merge work on the beacon chain right like it's like the next name of the the name of the next star or whatever language we use

Danny Ryan: yeah i think by so by default that's the that's the path i think um

so we could pick a b name uh but then we have to think about how what is the interaction between that and the upgrade on the execution layer um does this envelope the naming scheme over there or is additive this that name over there

Mikhail Kalinin: it's whereas it's like more difficult um thing like what's the what's the upgrades uh that involves consensus execution layers simultaneously will look like and how do how should they be set up yeah of course

Danny Ryan: because we also very well might have upgrades that are just on one layer um you know if just the evm changes in the

future uh so beetlejuice shanghai tim said no because shanghai's been reserved for a different fork but we could we could kind of keep the the naming independently and and have it additive as the sum total beetlejuice serenity thank you light clam that's also not my intentional spelling um the intention of the spelling is after the name of the star not the um mad character

Micah Zoltu: well that's boring

Danny Ryan: i guess but then beetlejuice is also a long name i i'm only saying that because it's the

only star name that has a b that i know of off the top of my head that's not the name um okay i maybe take this offline maybe we uh talk with the the people on the other side of the aisle and see if we can come at least like a compromise on how these names are related and then if we do pick a um star name we can pick some some nice ones and then uh either do a emoji vote or bring it to the call and see if anyone has some strong opinions um

any other merge related items tldr being pathos is up people are iterating and making things more stable specs to be done at the end of october and then um we'll have kind of a new meta spec that targets the stable versions of things moving into november within the intention of these being near mainnet ready specs and really only changing them if uh issues are uncovered between then and later

Protolambda: about the pitot the transaction count is currently very very low priority and me both have some beef to distribute

i do believe that maybe one or two clients are not quite ready for our transactions at the emergent drop event it does certainly it affects the state's roots in some ways red so it's just another way uh looks good surface so far it's been running well i think we can handle it so if anyone likes to have some testy for transactions then please just reach out and we'll start distributing some

Danny Ryan: cool thank you brother that's not so going once going twice anything else

merge related for today okay um any research updates that people like to share today

Protolambda: well this is one fork more ahead the withdrawals so i think that at least we should look at potential future api changes that the withdrawals may cost so that the engine api is port

compatible so you know how it might change

Danny Ryan: right and a lot of that centers around a push first pull on withdrawals into the execution layer which i think there's a rich conversation to be had around that

Protolambda: right for context for others the funny thing is that deposits on rollups are the same as withdrawals in ethereum ii where you move something from the consensus layer into the execution layer we could try and unify these types of things we don't have to and then

there are nuances as well where it's not exactly the same so maybe we shouldn't

Danny Ryan: the primary id being there if if we do make the functionality look pretty similar then the engine api can be reused in a different context to drive rollups which is nice

Protolambda: the push model is basically a new transaction type on the execution layer and an addition to the prepare payload methods to be able to introduce a transaction into a block that's suggested by the consensus layer instead of taken out of the memory pool then the alternative is the pull model

where the consensus layer keeps track of withdrawn federal data tasks and then the execution layer allows you to mint if based on the commitment and based on another transaction not a regular transaction to some special pre-compiled contracts that can process the withdrawal

Danny Ryan: right where the the formers probably if you can get it right maybe a more elegant design but uh at first look has a bunch of edge cases around especially when those withdrawals are headed towards

smart contracts which consume gas and there's a question of who pays for the gas

what happens that kind of stuff

Protolambda: in developed context you've been thinking about this in two ways you could have a deposit that doesn't trigger the evm it just increases the balance so that you don't have these edge classes but then you also probably still want the other side as well so you end up with two types of transaction or maybe some kind of flag within the transaction so if you have some kind of feed payment for the minimal thing where it doesn't trigger ethm it just increases the balance or maybe not at all which is some limiting to this in the contents there

you can at least have this type of deposit or withdrawal transaction but then you if you want the contract interaction you get into into a hurry situation with fee payments and with all your cases in the ethiop anyway keep an eye out for future updates after the merge while they're designing this api

Danny Ryan: yeah absolutely and i think uh once we get the merge spec stable at the end of the month that's one of my priorities is to begin to specify and engage on the

different designs on this all right any other research updates or points of discussion great any other items to discuss today open discussion closing remarks etc great well thank you for joining if

you're at liz con enjoy um and we will talk to you all soon upgrade in six days it's exciting thanks everyone

wait thank you so everyone thanks everybody [Music] so

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

[Applause] [Music] so

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

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

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

[Applause] [Music] so

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

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

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

[Applause] [Music] you

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