All Core Devs - Consensus #71

Transcript

[Music] [Applause] foreign [Music] stream should be transitioned and we are starting the and I'm sorry Ben

Danny Ryan: the consensus layer call number 71.

um great so we will focus I think a lot on Altair today as usual then we'll do some client updates we can do quick merge discussion although we had quite a more discussion over the past hour on the engine API then research updates and any closing remarks back discussion Etc v110 beta 3 is now out and the test vectors are being uploaded currently I will try to keep I have to upload each file of those Target Yeezys independently or GitHub dies so I will do them one at a time during this call and hopefully they'll

be done at the end of the call thank you for your patience on that and huge shout out to Alex for greatly greatly increasing test coverage so hopefully some good stuff will come out of that cool well that's uh so that was the beginning of Altair we do have a new release uh there's some other goodies in there with uh the merge and sharding if you're following Along on those

and uh Piermont

Danny Ryan: upgraded one week ago and we do have some coordinated uh testing going on on that I believe today we should be turning finality back on it looks like some uh some of y'all have begun to do that

we're back at 60 we've been non-finalizing for 702 epochs very cool um and there are a number of other things that we like to get on there specifically get a bunch of deposits get a bunch of exits make sure we have all the different slashing types covered and um you know do weird things to your heart desire we have is there anything on Piermont testing that we'd like to discuss

there's an issue

Terence Tsao: right so for uh food transparency we derang into an issue where the prison could not sink under a finalized period but the issue was quickly fixed and patched and now we got a new release out so yeah personally I'm

really grateful for this habitat that that allow us to catch issues on this

Danny Ryan: was it a fresh sink that you had issues so like trying

Terence Tsao: no startup or it is it's water checkpoints thing and then if you checkpoints sink for such duration with the e-park that's not finalized for some reason we couldn't process the block but yeah but let me post the issues here and the details are in the issues but yeah

Danny Ryan: gotcha cool and um I mentioned this elsewhere but we are looking into doing a more concerted effort to do scenario type testing in uh real large but kind of controlled testnets uh

this is just a bit of a taste of that hopefully we can get some of that going over the next couple months uh to harden all tear stuff and get ready for Merch great any other on Piermont I think technically once we do finish running through at least what I shared in that issue issue 59 on E2 networks um we will consider deprecated obviously you can do whatever you want with it and continue to run nodes and see what happens or call today

and I think as we approach the merge we would spin up a pretty sizable test net against each of the eth1 testnets that we want to keep and do kind of emerge practice on each one of those um I guess even regardless of wanting to keep them but we can discuss that later okay uh pratter will launch in one week minus two hours I believe uh there is a config up it was merged um if you haven't taken a look please do a final sanity check on that um if you are listening to this call keep an eye peeled for uh prouder Altair releases on your client of choice and

upgrade if you are on that test net um as we approach that one week from today is any any comments or questions I'm prouder Perry you're gonna work uh on upping the validators on pratter can you give us a quick

on that I've

Parithosh Jayanthi: just reached out to all the clan teams to figure out who's going to be taking part in in that and I'm just creating a small doc to figure out um who would who would um have to turn on the validators on which date I guess

I do the deposits over the weekend or early next week and should hear more from me next week

Danny Ryan: got it um so obviously after pratter we do want to Target in main net launch so we I think we have a handful of things in the works this these continued Paramount testing seeing pratter go well and also probably not well I guess we could turn off finality if we want I think there's a marginal gain to doing that but uh hitting it with operations and different things um and the test vectors that just came out hoping that doesn't uncover anything crazy and then I think we need to be eyeballing a main net launch

um I don't think that we need to set a date today I think we should get through what happens in a week and then set a date but um any thoughts feelings desires with respect to mainnet timing the main thing is do we give people plenty of time to upgrade between when we announce it and get releases out

to

Parithosh Jayanthi: when it actually happens we will depend on the community for this one right right we've controlled them all

Danny Ryan: absolutely and we'll do we can just certainly do you have blog posts with all releases and things like we do on uh

have done on the uh proof of work chain um what do you think

yeah sorry I was like what was that

Jacek Sieka: I know I was going to pose a different question which is basically we've been considering whether to make two releases before a main little terror Just One release like a big one with a bunch of features and stuff and then just a small one with you know an epic update or two releases and I'm kind of curious what people think about that

Danny Ryan: I think Lighthouse has probably done a version of that and that they just put

0.5 out officially last week which I think was a big release and then Altair obviously would just be something more minor with an Epoch but as we approach my intuition would be doing a release within seven days of each other or something like that might cause more confusion than it's worth but I don't know

I'm

Adrian Sutton: pretty Keen to see each client have an actual release with the product config in it rather than an RC or so on how that ties into big features for you is you know kind of a side of that but I actually have alte emerge the main branch it's a full release that clients are upgrading to because then it's it's

ready the one change you have to put in for mainnet is is just a contract change which yeah hopefully you can't screw up um whereas there anything else is kind of merging and doing other other kind of more complex stuff it's much easier to introduce other bugs and and then effectively haven't tested it um so that's kind of my view on it I'd lean towards whatever gets you to there but uh beyond that uses a these are pretty slow to upgrade unless you tell them this is going to completely break if you don't upgrade so I think it's it's really just going to come down to when you put out the release that says you know this got the main Network in it um you have to upgrade that's when a lot of users are going to actually pull the

trigger and and apply it

Danny Ryan: uh back to the prior question Adrian um do you have in or you or any other others have an opinion on when those releases are the lead time between those releases being made and getting into a public blog post and that that fourth date is that a two-week minimum three week minimum more

Adrian Sutton: I I'd say two-week minimum but I'd be very tempted to to learn from what the eight one side is done and what kind of

timelines they normally set because I think that's the expectation most users will probably have right um it's a good Baseline anyway

Jacek Sieka: yeah I'm not looking at London looking at London guests had releases like what a few days before that is very true but that was also handling an exceptional scenario I wonder when the initial blog post went out on the lead time though which we can figure out probably quickly

Adrian Sutton: yeah I mean it emergencies happen and you can get it up very fast probably the best example of that was when the first constant mobile Fork got canceled and it was you know 24 48 hour time kind of

time turn around and getting new clients out to cancel it um and it went very smoothly so it is possible to do fast but

Danny Ryan: yeah and I think we might not cover all this in Altera but I think there's a desire to Define a bit more clearly what the finding bugs and disaster scenarios and things like that are especially leading to the to the merge um you know rather than very subjectively being ah we're fine um defining a bit more clearly what our like halts and arrows are although once you publish those midnight

releases

Adrian Sutton: for some reason I had just in my head is a month off so we folk um Prada so like a month from next Thursday um that probably could happen quicker I guess if we wanted to but I'm not sure that I think it seems like we're pretty much there in terms of engineering it's just kind of waiting for it now and perhaps giving like a little bit of extra time for people to move over and a little bit of extra time for us to run these test snaps is good um I'm not I'm not sure that I can't at least for us it seems I'm not sure we need a deadline to push us at the moment we're pretty much there we that that deadline was the test

net so

Danny Ryan: yeah I mean I think that puts us at the last day of

September which I think is a pretty good Target and then we need to subtract probably two and a half weeks on mainnet releases and two weeks on really getting that blog post out um which I think is looking at the calendar that all adds up um in a pretty reasonable way assuming that we don't run into any

unexpecteds well instead of subtraction on the blow post sorry I just met

Danny Ryan: um you know if we're going to release if we're going to do mainnet on September 30th which would be one exactly one month after the prouder upgrade um subtract two and a half weeks on the like deadline for mainnet releases and

the blog post going out a couple days from there so like you know the September 13th would be everyone needs to have their main net releases out and then the blog post is coming out the 14th or 15th which gives you know slightly more than two weeks of lead time otherwise you'd have to do mainnet releases the week prior and you know if you're trying to get the blog post out in like three weeks time

Adrian Sutton: all right because you want the blog post to have the client persons in it is that right

Danny Ryan: that is historically what has been done on the um maina upgrades on the perform chain yes yes

Adrian Sutton: I suspect that will not work well we

can probably pick a candidate upgrade epoch around the time private forks and then agree on it not long after once we see it's working basically that starts to release processes and kind of gives yeah should pan out

yeah I I

Jacek Sieka: feel the same that let's wait for the product release before we make that decision also because you know the latest test factors were released today

Danny Ryan: yeah cool I'm comfortable with our abstract sensitive plans and we can pick this up in one week time okay anything else we want to discuss

with respect to Altair planning anything that is glaringly missing from all of this or we generally have the pieces in place that we're happy with cool the minimal tar.gz is on the spec test release now and now the general is but now I'm gonna have to add uh the mainnet which should take a few minutes if anybody bonus points anybody that

runs minimal on their local build before the end of the call okay back to the schedule um let's do a quick round of client updates I suspect it has a lot to do with Altair no need to hit us too hard

but

Danny Ryan: we can start with nimbus

Mamy Ratsimbazafy: hi um as you said a lot of I'll tell you upgrades especially uh performance improvements make the blocks between slots and also ebooks way faster and also uh rest API updates as well

Danny Ryan: great uh granddeen

yes this service we still work on mainly on there on this separate Forks running on separator runtimes thing and even though we have it depends on this LTR test however there are still a lot of work that that needs to be done in order to to connect everything into one piece as a as running in the separate runtimes it's uh it comes with a with a different with a new challenges really for example just just an example to understand the complexity

uh when the all their runtime starts to work it needs to to get the history before the marriage sorry before the fork point in order to to have four Choice working so basically the initial idea that we thought that after the merge we will not after the fork that will not any will not have any history of the previous uh Fork it's it's not actually valid as we need to have at least some some history to make for choice on the Altier runtime work so so we are solving a lot of these uh interesting issues great

thank you

and loadstar

dapplion: hey everyone lion here so finally we have released our browser like line prototype super excited had very good reception and looking forward to a lot more transport next we have also hacked an alternative representation of bytes in JavaScript which has allowed us to reduce the size of the hashing cache by half and it's been great to reduce coverage collection performance Pearman went well and we are looking next week allocating uh portion of our team to implement the merge

and hopefully having it ready soon thank you

Danny Ryan: thank you and on that I I think maybe because without saying but uh on the execution engine side I think people are expecting to be heavily in kind of prototyping over the next month and so beginning to shift a bit of allocation on your side to implement the latest on uh consensus layer merge specs will help unblock the other side of the the aisle um cool great

and prism yep

Terence Tsao: hello everyone so um last two weeks we've been mostly

reviewing a hotel changes and merging those changes into the developed range and then as you know last Friday there was a minor incident with the with the with the Lido validators so that I think um I think they were proposing plots fairly late and due to that we found a few um we found a few deficiency with how we handle a decision main pool so first um we were not reinserting open attestation back to the main pool and that is fixed and then we found another deficiency where we did the attestations uh when a block gets verified instead of block becomes uh instead of blog becomes

um canonical so also if it's there as well and on top of that we're just working on E2 API and then uh gearing for the V2 release yeah that's it

Danny Ryan: great

teku

Adrian Sutton: yeah hi this is Adrian so we've got a release should be coming out tomorrow um it's just doing the final kind of staging process uh at the moment uh that will be 21.8.2 and it will have the auto upgrade epoch baked in for prata

um it'll also have some really nice optimizations particularly around reducing garbage collection time so lower CPU and memory usage uh and we've done a bunch of research with techu working against particularly infuro but anyway you have load balanced Beacon nodes and so there's a new option to disable producing early Ada stations because it's quite common to get from one node a head event saying they have the block and then you produce the attestation against a different node in it doesn't have it yet so you wind up with a bad headphone um so we've seen uh performance dramatically improved against our load balanced Beaker nodes and inferior with that option so that's in there and it will also include a change for

the remote signer API so that we can send um Altair blocks through to things like web3 sign up which is a block V2 type so we'll get the the rest API specs for web3 sign are updated with that but um yeah that should be should be good to get should be good to go with the Prada then hopefully and that's it from us

Danny Ryan: great

and lighthouse

Paul Hauner: hello everyone Paul here uh so this week we released version 1.5.0 it seems to be going well um it's a couple of reports of Miss that is like a lowered as a station

performance happening um but I'm not sure if that's just limited to Lighthouse or it's Network wide I'm still trying to figure out exactly what's going on there um we have a 1.5.1 release scheduled for Monday that's going to include our Prada um the Prada Fork um so 1.5.0 means that we have all of our LTS stuff in in master now um we're also started working on remote sinus support for web3 signer which is what um Adrian from techy mentioned just before so that means I believe that Lighthouse and taku will both be able to support the same remote signer from their VC which would be pretty cool um our week's objectivity progress is going well we've done some successful starts and backfills I know we're just

working on getting review ready I'm ready for production uh and that's it from me

Danny Ryan: great thanks Paul

um okay

Danny Ryan: and number three merge discussion um if there's anything people want to chat about by all means uh I think we hit the engine API pretty hard this morning so I would defer additional conversation on that to Discord and some follow-up conversations rather than doing it here uh but are there any other merge related items we'd like to discuss today

Mikhail Kalinin: I have some uh yeah we decided to like continue our engine API discussion

during the next stalker that's called great uh it was benefited a bit of time on it yeah uh with regards to other stuff on the merge uh there is the first by Dimitri and perhaps been evaluating the Precision of the total terminal total difficulty computation that we will use for uh the actual transition from proof of stake to proof of work um a bit of a context this terminal total difficulty is going to be computed during the merge Fork and it targets the seven days after uh the merge of work is happening for the actual transition to proof of stake and this research is

about evaluating the Precision of this prediction on the historic data on the historical data um yeah the key takeaway from it is that we might want to use a more precise value for a more precise value for the seconds per group of four block than the 14 seconds which are used currently it will increase like the Precision of this um like yeah it will make it it will make the prediction more accurate um you you may take a look at the comments below this post for the comparison table

um but yeah it will like make it more accurate but the Precision is like uh we should expect the merge like within the 20 hours interval um which is it which will be around this you know Target uh Target uh time uh which is seven days according to the current spec so uh this is because of the um um off of the difficulty fluctuations and because of the stochastic process that we have uh to drive the block building on the work chain I don't think we can do anything better here and as I understand uh we

have the like the London Hearts work slightly after the predicted time am I right

I'm not sure okay

Mikhail Kalinin: okay anyway so there is 24 20 hours interval uh but we might increase we might move this interval uh and to make it more accurate if we change this uh this second Spirit block parameter so I would suggest to add like a new parameter to this pack and get back to evaluating the average block time uh uh as as we are close on the historic data is very close to merge and settle

with some value that will be either great to the state of the network by that time so that's that's it that's just a suggestion

Danny Ryan: got it as real as one confounding Factor might be if we are approaching an Ice Age which um may be the case

Mikhail Kalinin: yes and we want and we do want to approach the ice age right right so where's the match so we should take care about it as well yeah we'll all right that's all for this post to take a look at it that's just nice like collection of 36 data

and thanks to another mine team Who provided us with data from the magnet or This research

Danny Ryan: cool uh thank you Miguel um any other merge related items we'd like to discuss okay um it looks like there will be some continued refinements that come out of uh enter into that engine API um over the next couple weeks so keep

your eyes peeled and like I said um as Altair wraps up getting merged prototypes that are um in the direction of the current merge specs and the EIP that is up will help no thanks for it um okay cool any research updates people would like to share today

okay and any spec discussion open discussion closing remarks

I've

Paul Hauner: been asked to mention something in the configs about the temporarily set Fork versions The how people would feel about knowing them I don't know the background for this so I can't make an argument to it but I'm doing what I'm asked for there is an issue for this I'll find it

Danny Ryan: yeah sorry what can you repeat that one more time

so

Paul Hauner: there's a so issue on the consensus specs two five six nine uh it's about knowing using null instead of U6 form max value uh sorry to the 64 minus one um yeah I'm not

yeah there's I'm just trying to see if people would be against that

um I'd

Danny Ryan: like to see more just the the justification here I'm just I know I think that the investigation at least some magazine is better Clarity I think the the alternative argument is that you don't have to have any exceptional logic because you can just use your basic uh comparison operator and not really worry about what the value is I don't feel strongly here um but does anyone else want to jump in or shall we just move to the issue

Paul Hauner: perhaps we can just move to the issue

I'm going to ask people to put some more justification there I feel like it doesn't warrant it at the moment sorry for bringing it up

oh

Danny Ryan: no it's good um take a look issue two five six nine okay snowman is going off in the chat um YouTube chat having a conversation um okay cool I think that we are good anything else

um I have a question concerning the peer ID uh when when

the nodes update uh their client it seems that uh the period changes to a new one and uh I would like to know what what is this um is there is there a particular reason why this is like this or it's just arbitrary decision

Danny Ryan: update as in uh change their client version or just like cycle their node and this is all clients or just a couple you're seeing

um I'm

not sure about all clients I noticed that in in a couple of them and uh yeah update like a div they get a different uh a new a new ID and because of that is difficult to track

um um you know the evolution of um of new versions drawing out um so we have we have been using the crawler to uh see how um you know people adopt new versions uh and how this evolves and but the thing is that what we see in the figure is that um when a new version for example a new version comes up we just see kind of an increase so so we see the new version a lot of nodes getting up the new version but we do see a lot of new nodes and um it just we don't see a decrease on the other ones and this is because I think they changed the ID and then it's difficult to track you know we just see

them as new notes we don't see like oh this is not just changed from previous version to another version I don't know if that makes sense

Jacek Sieka: yeah so we explicitly change pair ID for every restart for privacy reasons like there's no reason to keep it the same and like by changing it at least we casually break the link between Beacon known and validator every now and then we've actually considered for every connection um and the other thing the last thing about crawlers that I say that I'll say is that we don't

when our peer table is full like when we have all the connections that the users has configured it to have we will no longer accept connections on the socket even so we won't allow the crawler to come in so those are like common sources of why uh Tom crawlers might be skewed in general in Lighthouse we persist our peer ID

Danny Ryan: yeah I mean I think it's a very reasonable to keep that as an optional design to be able to cycle or persist um and it's unfortunately probably in the impetus of the crawler to figure out

what is stale and what is not um because I think there are very valuable privacy considerations for wanting to be able to cycle and and move things around

um pay different guests

Paul Hauner: I think at devcom Prague did a really interesting talk about tracking himself around the world by his peer ID so it's definitely privacy

Lake all

Danny Ryan: right um I do you also got you all have no um you you don't have a Target and a Max so that you can accept inbound connections and then kind of like prune them back down uh there's just a strict Max

Jacek Sieka: well we have a strict Max for the simple reason that every time we accept in

connection we have to negotiate the key with those new connections so that is actually one way to Dos a client it's just like keep opening connections um and we kind of want to save those resources so when the connection table is full it's full I mean we're not going to be talking to these people anyway um we've considered um softening that um but again like the only one that benefits is crawlers um and and again you're like leaking leaking a little bit

Danny Ryan: yeah I mean you can imagine an extreme where you have like a

lot of network rigidity and it's difficult to join um if everyone was following their strategy as opposed to say Target 50 Max 55 allowing you to grow up to 55 and then like having some pruning strategy um which could still potentially handle the Dos as long as your pruning strategy wasn't really aggressive and you could always open new connections but anyway I don't think there's a strictly correct Behavior here

Jacek Sieka: well even that right you'd still get pruned right presumably

Danny Ryan: well sure um your pruning strategy would depend on some sort of heuristic algorithm which

then all of a sudden becomes potentially a eclipse attack Vector depending on if somebody can find an exploit in that algorithm

Micah Zoltu: I think it's the tension between you you want to rotate clients to prevent the like Danny said the front of the network remain too rigid and getting stuck with you know no one new can join because you have everybody's at Max um and on the other side you want to prevent Eclipse attacks which definitely get opened up a lot if you allow um if you have a well-known strategy for rotating clients people can exploit that to force their own nodes to get rotated in and other nodes rotated out um

it's not easy

Adrian Sutton: the flip side there though is that it's much easier to Eclipse you if I can just fill your connections when you first appear and you can never just be the first one to connect to you and then you never connect to anyone else and I own you forever

Jacek Sieka: yeah so like we did two things to balance so one thing is that we have quite a high peer limit compared to the others um 160 ish and this works well because gossip sub itself which is like the bandwidth POG manages its own bandwidth usage through through the mesh right so so having lots of pairs connected doesn't really affect bandwidth that much um

and then yeah there is a peer scoring system in place where where we occasionally kick pairs that are not pulling their weight so at the end of the day we we still have a some uh Dynamic Behavior it's just that the moment that it's full we no longer spend resources on uh new pairs until we have determined that some beer is useless

uh but if we if we update the PID so frequently uh doesn't this damage a little bit the appear scoring algorithm

Jacek Sieka: well both ways right it forgets

penalties and it it depends like we can't assume that others will remember our peers course across connections uh so we start with a clean slate with the new peer ID and we work work on that reputation right uh and the reason is I think yes does also drop their reputation uh on this connective I remember right and they motivated this with uh the fact that um you know the moment that you restart something completely different might be happening even if it's the same peer ID connecting so there's like difficult to reason about security and peer score

Danny Ryan: you could have fixed a bug in your client that made your fear score bad or you could have made your client malicious trying to Leverage What was a previously good score but you could also like make that change to move towards maliciousness without cycling but anyway yeah I mean at Leo I think there's there's something at odds here fundamentally you know I there are uh it's not always in the best interest of a client to make things easy for a crawler uh because of privacy issues and other other types of issues um and so I think as a crawler you have to try to just navigate the emergent landscape

absolutely absolutely no I completely

understand and we will figure out a way to um just um you know discard the connections that we don't see for a certain time and and we will figure that out I just wanted to bring up the description a little bit to understand and another thing uh just to remind please all the clients about the standardization approach uh I mean effort that we are doing uh so that because we are trying to start uh building these dashboards with um with all the uh standard metrics that we um agreed on so um yeah just uh keep an eye on that so that the next releases have all those metrics using the standard metric sorry naming system that we that we are open

on thank you

got it

Danny Ryan: okay um anything else people like discuss before we close today regarding this this ID thing is if I understand correctly so the actually the benefit for the client is to keep this idea to keep the the score and the I'm not sure I mean if if this is the suggestion to make this optional or or mandatory to uh to to roll these

IDs

Jacek Sieka: I mean the suggestion is that you choose

for your users or you let them choose there are reasons for both we allow both because for example when you're running a boot node a stable node that some users presumably trust the same the pair ID is also used as a source for the public key that verifies that you're connecting to the node that you think you're connecting so when you have a trust relationship between two nodes for example you're you run yourself to nodes and want to make sure they're connected obviously you need to keep the pair ID but on the other hand um there's a privacy issue so I mean right now in the network design the most private thing we can do is actually use

a different pair ID for every connection that we open uh and that is that is an extreme option that I don't think any client does right now but it's secondly a possibility it would cost a little bit in terms of DHT lookups and like it would be a little bit more difficult but uh it's certainly possible but but this issue mainly raised because of the Crawlers or somebody asked for the increased privacy uh it was discussed that at early stages what to do about the Casual link between Beaker node and

validator uh the main issue is that if you know which validator is using which Beacon node you can trivially dos them in a targeted attack and then if they don't have a good uh backup strategy then potentially you can like a low-cost crafts grief individual validators basically yeah just disconnect them from the network okay okay thanks I just mentioned that changing pair ID is not

foolproof it's not secure in that sense it's just a tilt in that direction all right

Danny Ryan: okay other items people like to discuss great Prater in one week if you're listening keep your eyes peeled for releases that include these updates and you can join us on the test

Network talk to you all soon thank you

thank you cheers [Music] foreign [Music] [Music]

foreign [Music] [Music] [Music] foreign

[Music] [Applause] foreign [Music] foreign

[Music] foreign [Music] [Music]

thank you

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