All Core Devs - Consensus #70

Transcript

[Music] so so

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

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

so [Music] [Music] [Music]

great we should be transitioned over people of youtube let us know if you can hear us and we can go ahead and get started

Danny Ryan: um okay i think the most topical thing and we can talk about immediately is this altar devnet iii this was led by perry and has a different client ratio than our even split on the past few to attempt to represent at least what we know of mainnet today something like 70 prism um and last i saw there were a few things being worked out still this morning um is there an update on that uh i guess mainly because we're going to

talk about pyrmont which is in a week and i just want to make sure that we are still good to go i imagine anything that we can anything that has opened up on that we should be able to settle in the next few days so my expectation is paramount so good but where are we at

Parithosh Jayanthi: sure so i can just start with a brief of where we are right now um had a bit of config error in the beginning but everything smoothened out later on but today morning we noticed that um the lighthouse client seems to have lost a lot of peers and in general performance doesn't seem to be

what what we'd expect it to be um i think lodestar is doing a lot better now they said they were overloaded and they increased their their machine size i guess and besides that there was an invalid signature that was noticed and here some peer scoring related things for

the lighthouse but i think i let the lighthouse team take it on from that we're still trying to figure out why um why we're down voting peers i think we're seeing some invalid signatures from our perspective so still um so they

get into that gotcha likely related to new gossip channels or old types or old old channels i'm not sure to be honest okay i haven't been um i haven't been working on this one we've got someone else i'll i'll get some updates and and provide something later if i can um okay well

Parithosh Jayanthi: another thing that i don't think i've um mentioned otherwise is there seems to be a load stop here that both lighthouse as well as prism have banned for um for invalid what does it say invalid sequence number i'm not particularly sure why that's

happening but i can share the logs

and we can take it from that

Paul Hauner: one of the things that we're down scoring people heavily for at the moment is for sending us late sync um messages um which we're probably going to lighten up on that because it seems a little um it seems like it's fairly likely that we're going to get those because the messages are so

short-lived

Danny Ryan: right so you're right that's going to be an ongoing very tight on like a single slot scope whereas we should maybe expect a few to be lagging

Nishant Das: yeah shouldn't you be ignoring them rather than uh rejecting and down scoring peers who send you late

messages

uh like i said not super deep on this one okay sure i'm gonna sandy check that

Danny Ryan: that is an ignore condition yeah it is an indoor condition um but yeah it might make sense to lighten that up at least once you figure it out um so i moved the client updates to after this so we can just talk about altair in unity with this so we do have a pyramid date set up uh adrian thank you very much for getting that config ready and porting it to the new format uh

i just want to sandy check that we expect to still fork pyramid in a week uh even if that means cutting some releases monday tuesday based off the issues we found today um i mean i think devnot 3 is serving its purpose is that a signal to not update pyramid or is that a signal to fix things and continue with paramount

by default i think we're going to continue to do pyramidal thursday unless people have strong objection okay

Parithosh Jayanthi: i think in general the technology

is also finalizing and everything does look clean so i'd say there's no reason to delay the amount okay so we will

obviously figure out what's going on attempt to get some patches out before then and if we find related or different issues hey doc red you are typing lab i'm muting you um if we find continued edition children pyramid it will continue service purpose which is to find issues um so let's keep chatting as uh as we work through the issues on the current devnet and take it from there pyramid is on

okay since we're talking about altair uh quick on release and testing uh we are it's very likely that we'll get a testing release out looking like maybe monday which covers a few edge cases that were not previously covered terence had found a bug in their state transition code that was iterating on like the full validator list rather than the active validator list and this only serviced a bug in the event of leak scores being non-zero there being validators that were not active so exited or not yet active and a leak going on

so we did get that case covered in the dev branch and are working on enhancing a bit more coverage and then we'll we'll get a release out there so keep your eyes peeled for that um and

Danny Ryan: that's primarily what i have for altair we could discuss theoretical dates for um pratter and or mainnet but my intuition is given some issues seen on the devnet and with uh the pyrmont launch in a week that we were better suited sorting through these issues before we try to put a date on anything else

any alternative feelings on that different strategy okay paramount it is uh are there any other altair release testing and planning items that we'd like to discuss before we move on

to the client updates great i meant to give a huge shout out to alex and proto uh for taking care of this

call a couple weeks ago very much appreciate it heard it went really well and that i can step down okay client updates let's get started with lodestar

dapplion: hey lion here so we did participate on alternate three and it went well um we overestimate our machine so had a bit of rough time but now now things are looking good we are actively working on lowering our

memory usage and we have found three strong strategies um with the help of blotto2 so hopefully we can get that merged soon and we should release by monday a lifeline article with a working demo that would be connected to

alternate three and that's it thank you it's very exciting thank you um prism

Nishant Das: hey guys uh sean here so um for the last two weeks we've been mostly focusing on bringing down our changes from our hot fog branch to our developed branch

in the process we've been carefully reviewing the code we have implemented for altair and in the process we found a bug in our state transition function as mentioned earlier so it's not covered by inspectors so this has been valuable in uh finding different edge cases um also along with that we've been running uh short-term test nets with other clients for all the year so this has actually helped us quite a bit in finding subtle networking bugs that are much harder to find in you know the bigger death nets so especially to do gossip scoring and in the fall keep up transition so uh we are happy to have that sorted

out uh along with that we have actually finally uh implemented all the official api endpoints in our developer branch so uh this has been in the world for a long time so we're happy to have that done and now we're in the process of

implementing our v2 endpoints for altair cool thank you michonne and lighthouse

Paul Hauner: hey there paul here not a whole lot to report this time um we did publish a pre-release which is 1.5.0 rc 0. um

so this is the release that we're going to ask users to use for the pmo fork we might or may not make another release in the meantime we just want to try and get everyone ready for it early um we pro we probably won't publish a full 1.5.0 before pm on um we're just trying to prioritize those stable releases for mainnet we don't really want to let pimon dictate the pace in which we do things for mainnet um where now that we've got kind of staying to get that release out the door which includes doppelganger and a bunch of other cool features um it also means all of our um lts stuff is now merged out of it's it's not no longer living in separate branches and

it lives in in um at least unstable for now which is pretty cool um

so now we're progressing with our weak subjectivities think i'm also doing some devops stuff in the background um finding that aws is just too expensive in terms of data transfer costs for our types of networks they want to do big fancy pipelined things not decentralized things so yeah looking at some other providers um that's about it from us great perry's had a lot of success doing some like dedicated hardware um if you are interested in hearing about his strategy there hit him up yeah thanks we've had a chat we're trying to one of the ways you can go is like by you know buying a giant box and splitting it up but we're trying to keep

it um in separate nodes all around different ips and stuff like that yeah we see in test nets um people lots of people running behind the same ip and it makes things a little bit weird for us not represented in normal conditions

Danny Ryan: gotcha and grandine

yes hi this solus from grenina team so we work on some some fixes and optimizations and the full focus is now on uh on this multiple on time support and this is also part of of the ltr support so

hopefully we'll have it working in a couple of weeks or it could take a bit more so we will see that's all got it thank you and i'll i'll put in a request again if y'all do have success with multiple runtimes i think it's a really valuable experiment so please please write a blog post or two yeah yeah i'm going to do that after we have a bit more solid results as this is still in process got it thank you thanks and taku hey this is adrian uh we've got our 21.8.0 release that came out today and that has

uh altea air support finalized and ready to go it is scheduled uh to activate on piermont at the right point um so really important that everyone on piermont upgrades to that um a bunch of stuff happening in the background in terms of research and other fixes there's been some docker upgrades and various little details to make things easier to manage in bigger environments that kind of thing but nothing that particularly needs to be called out here check the changelog basically yeah that's us great thank you adrian and nimbus hi i'm here

um sold updates for the past two weeks we now have multi architecture docker images also we released um v 1.4.2 which is um an update just before london because we had a lot of people running client older than march 2021 and uh they had issue when jump once jumping from uh 1.0.13 i think to uh our latest uh client version so that was an update just for votes it was a db immigration issue and otherwise we've been keeping up with altair we have a dedicated attire

branch and just like lighthouse so far we didn't want to mix alternate updates with magnets got it and sorry if i missed this do you have a pyrmont release out yet or is that primarily going to be in a development branch for pyramid um yeah so for now everything is in the alter branch but we'll put out some like instructions for false who wants to ask running permanent got it thank you

okay i had one more altair thing that terrance had brought up um [Music] pretty much we want to see more manual testing performed uh on these test nets devnets make sure that we're hitting a lot of these corner cases i shared an old list of some stuff that uh i'd written down for prior to phase zero launch i suggest that we use that i mean we don't need those numbers we don't need a thousand validated deposits but use that as a starting point on some of the conditions we want to see um and make sure on that first week of pyrmont to kind of

hammer it with a bunch of different things to make sure that we see some of the interesting edge cases um i guess additionally we might because we control a significant number of the nodes on pyramid it would likely make sense to turn a bunch of them off to test a stretch of non-finality on a test net that is planned on being moonlit and probably is not the place where users are expecting a super high quality of service so i think that would be a good place to do some stuff so maybe over the next couple of days we can come up with a a plan on you know if and when pyrmont goes well at the start then we can kind of hammer

it in finality case and hammer it a bit in non-penalty case seem reasonable any other comments on that i suggest we just kind of chat chat about strategy in the early next week okay

Danny Ryan: great moving on uh research updates general research updates we'll talk about the merge

at the next section cool all right small updates

so we have this uh we had this pr

Protolambda: open for sharding for an update to separate builders and proposers this is based on like earlier posts from vitalik and others about separating mfv and trying to create this market for data and this should also help for example ease the burden on federators to not specialize in every single layer

too but rather move this burden to the builders and it simplifies different parts of the specification and we just merged it after a month of development

but it's not timeless at all yet so if you want to take a look please do and we'll uh keep polishing these yarnings back in the next few weeks right additionally and also one of the features that i'm really happy about is uh puts the incentives on the cr the making of that data available directly on the builder's standpoint who can specialize in particular subnets or shards or different distribution mechanisms that puts a lot less complexity on the core kind of validator network and spec and requirements cool check it out i shared that that's 24.86

Danny Ryan: other research updates or general r d updates that are not merged okay uh moving on to the merge

i believe the merge was rebased both to altair and london recently so it is getting primed for kind of the next wave of r d and there are a couple of issues that we wanted to discuss uh in the rebase to london the base fee there were some calculations put in there on the base g and the base view is represented as a un-64.

this is unsafe in some scenarios for overflows thank you proto for pointing that out so there's probably two alternatives uh the pr that mikkeil put up 2548. that moves to un256 and has some uni-256 calculations this is because some of the base fee validations were put into the beacon chain spec so doing the calculation to make sure the base view is correct the other alternative which i would lean slightly towards is to make this you know bytes 32 value that the beacon chain doesn't really care about and that the validations in the execution layer continue to happen as they're happening rather than hoisting them up into the

beacon chain i don't feel super strongly about this uh mikhail you put up the pr for the uh 256 version uh would you like to comment yeah sure um yes danny said that uh uh this field has been introduced by uh basin with london and uh yeah when i was doing this uh i was like thinking that you end uh would be pretty much enough in general case because it's hardly uh to imagine that um that we will see base fee for gas like let's say um 38th which is

really crazy number but then proto pointed out that during the transition process it might be valuable attack though the cost of attack is relatively high but it depends on the different conditions and so we need to reason about it and ideally we don't want to reason about it at all um so that's why this pr i agree with option to use bytes32 but since we would like to move more checks from the execution layer to the consensus layer or at least duplicate them here

for different reasons uh it might mean that which is differing we are creating the technical depth that will need to be resolved at some points in in future but yes for now that's using biased d2 is a viable option um also as i understand it matters for sharden as well so proto might comment on that so it might also be valuable to introduce you into the 564 sharding and uh one comment from potus which makes sense from some points from some standpoint is that we may use bias 32 for the transition process and then

when we need to introduce this check for the base fee computation on the consensus layer we might shrink it down to un-64 and use the n64 arithmetics because we'll be safe we'll be in a safe position after the image the downside is that we will shrink it down and there will be discrepancy in between the execution layer um the originality of this field in the execution layer and the consensus layer so that's actually pretty much it just wanted to hear from implementers and what do they think

about it whether it makes sense to introduce like this mathematics even 56 right now or like before defer it for some period of time so can you explain again why this attack matters prior to the merge but is does not exist after the merge the overflow with yeah 64.

the incentive will will uh yeah there is an incentive of miners to break the merge right so they can collude and and emerge this kind of attack oh that's that's it uh and yeah there is there is no incentive like to burn uh yeah the amount of heat burned uh to emerge this attack depends on the certain points where base vapor gas is like for example if it's 1024 away um so it will require 82 000 east to get burned and will require like 110 blocks

to emerge yeah that's crazy number but it depends on the price of e so is it correct to say that someone couldn't do this today though hypothetically and break beacon chain and isn't doing any sort of competition and but after the merge it will start doing such computations is that correct i see and michael i don't fully understand your argument as to why that computation should be hoisted to the consensus layer in general because in my

opinion it doesn't necessarily need to be there uh i guess it allows for an earlier simple check for validation right right yeah yeah because it allows for this simple check so but yeah but the cost of this check is relatively high relatively to other checks that we have that yeah and in general we there is like as i understand that the general line would be to move more checks as much checks as we can from execution i think it makes sense does the so the fact you can do this check tells me then that you have the full transaction list in the beacon client or in the

consensus client is that correct for the previous block yes but that's transactions transaction set these transactions that required for this and the reason i'm asking you guys [Music] or checking the computation of the base for gas whether it's done correctly right which requires right and so in order to calculate the base for the correct basis for gas you need the full set of transactions for the parent block which is fine if you already have it but i definitely wouldn't want to make you guys have to make the says clients have to start tracking all that just so they can do

this validation the execution class is going to be you can just use i would assume they would just use the gas used in the block header and then assume that's yeah accepted yes okay um just just so if we go down this path of having this client do more checks um there's pros and cons there in general so the pro is that we have even more things that are validating consensus which is good so the more diversity and code we have the more likely it is that we're gonna catch bugs before mainnet the obvious downside of course is if we now have eight clients doing the exact same check there is a higher chance that one of them will get it wrong and we'll have a consensus

failure like there's some diminishing return on number of unique implementations of a thing before it's no longer beneficial and it's only harmful i don't know if that number is four or eight or something else even when i was looking at the london rebase i was certainly unsure of the base fee calculation being hoisted the correctness calculation being hoisted in the consensus layer i don't see much value in doing that as maybe ever especially if it requires the introduction of the un-256 computational type which we've attempted to avoid but we also made that decision literally years ago um so we could certainly revisit the decision um i agree that

if it is requisite for doing the base view calculations with respect to sharding that we might just have to bite the bullet and have uh 256 and then they have a different conversation here uh but i i think that investigation is still underway and you and 236 specifically being the basically meaning anything beyond 64-bit is that correct yes yes 128 isn't any better yeah okay better i don't know i just and and maybe maybe clients have rich support for big integers already it probably depends on the client but that was just a design decision made a while ago as to was to avoid the requirement of those players

i can very much appreciate that desire um the i'm just going to throw this out there um i don't necessarily think it's a good idea but just to brainstorm um we could check to see if it's reasonable to have the execution client just cap that into q64 like that's a big enough number that it's like a significant percentage per gas of the entire supply and so i feel like uh it's a number that if it ever reached that like like there's no possible future where that's reasonable like even if it's worth a dollar even if it's worth a million dollars whatever like even if there's the global universal currency that number still doesn't make sense i'm saying you could put a max in the

actual one five out of nine yeah we could yeah exactly we could just say talk to the execution layer and say hey can we just cap this at 64 bits it makes our life easier allows us to do some things that you know we'd like to do and that may go over well yeah but counted b then overflow um in the same scenario no i mean it would be it would have a max value so it would not be able to go higher oh yeah yeah any consensus player you still multiply this number right right so if you want to do the check it

wouldn't be the full 64 max end value it would be some value less those calculations oh actually that's a good point that's going to be a pretty significant some value less because it's a 64-bit by 64-bit i think yeah yeah definitely um okay yeah 64 bit times 64 bit so 63 bits i guess is that right is my math right there or is it 32 bits it depends on the max value of what you might be multiplying on the other side you know it might actually be you're only multiplying by eight bits or

something probably 64 bits minus one okay um so and uh do we want to try to intro to like introduce this change to the execution layer first um but yeah i i'm happy we need to do the napkin math to decide what restriction we'd actually be putting one more arguments for the uh 2 of 56 is that it's just one computation it's just o of one

whereas we didn't use these larger integers or validators or other fields because it would amplify revenue validation this is much more manageable in terms of performance right but that's there's two sides the argument one is is the unnecessary uh computational requirement and then the other is the introduction introduction of a different type of type and potentially library which if you're just doing one thing is an argument for avoiding the introduction of that additional complexity that's the most compelling argument to

me the let's avoid adding a new library dependency let's anybody have any other things to add here um i think we can probably take it to the issue um i guess we could also do do clients have un256 support already or is that still something that was avoided in clients we haven't talked about it in years i will take your silences there is no support for 256-bit arithmetic currently i mean

yes in the same languages that cover the same math for each one with 256 bits so it's definitely out there it's a matter of can we plug it into if2 or not i just wanted to point it out that cpus current cpus all of them would support or most of them would support natively natively 128 but not 256. right um in all languages uh i mean go rust javascript there are already

libraries developed for f1 with 256 so it's just a matter of taking rules integrating into clients right yes but that brings in a yet another dependency which um you know when you're worried about supply chain attacks and stuff one more dependency is just one more attack vector um it also you know there's some of those dependencies you know they function but are not great like i've used some of them and it's painful in some languages some languages are good like they integrate really well especially if you have opera operator overloading your language then adding new integer types is fine if you have no operator overloading then you know your

code is just uglier these aren't strong arguments these are just things to keep in mind when introducing the library right we're going to need to do this for sharding in any case this discussion is kind of moot right yeah so let's at least finish that investigation which proto just started a bit yesterday also i'm happy to take this option with the biosphere 2 until we decide to introduce the 56 charging or we decide to reduce this field on the execution layer and then we can use this unc64 okay

let's just we move on to the next item which is uh merge related client security settings i don't know if that's the appropriate way to call them essentially some specified cll cli arguments for handling exceptional scenarios in the event of merge so minor attacks or all sorts of other things uh these would be used to socially coordinate against exceptional scenarios uh to kind of force the merge through um in the event that our our code logic doesn't exist you can see an open issue where we're

discussing this there's two discussion points one is what are these parameters and the two is actually where do you specify these parameters i think you could do merge clientsettings.md another markdown file there's a bit of a precedent for this in eip1011 uh which was the hybrid proofwork proof of stake we had some client settings that were specified so that social coordination and the event of attacks was uh treated as kind of first-class citizen so uh mainly just wanted to bring this up so that you can take a look at it and also to hear any feedback about these settings actually being specified in the

in the spec like they are they're kind of like security related client settings that probably everyone should implement if they end up in the in the core specs is that a reasonable place to specify these things has anyone taken a look at this any comments i'm a little bit nervous about trying to use the exact same cli argument name across multiple clients because we've all got different styles for naming but the concept of you should have a flag for that you know that does this in in roughly this way uh makes a lot of sense um and i think we we should basically

just do that routinely like we've got an override for the ltf4 epoch um and that's that's helped in a number of cases with with um each one upgrades the constantinople that didn't happen for example some people just disabled it with an override and so on right and it probably even makes sense to [Music] actually revisit some of the client settings that are in 1011 which were used to like force following a chain with a certain hash like that allows you to essentially socially coordinate against an attack which is one of those things we always talk about but actually isn't probably very feasible without those client settings being specified okay i hear you on the naming we can

kind of abstract that out um to not put that weirdness in there yeah i mean like these details it might be okay it could be the same but it's just something to consider yeah yeah so i agree with adrian that keeping within client consistency in the naming is probably the most valuable thing but it definitely would be nice from a support standpoint if the clients all use like the same words and like if one does camel case other one the snake case is going to have hyphens then you know we can whoever is supporting your users can easily adapt when the names are just totally unrelated though it becomes much more difficult to keep track of okay what was it that this particular client used

it's like the more close we can keep the names the better so i think having an example name in the spec that generally fits most clients would be great we just maybe don't make it kind of a must requirement so it's a strong suggestion okay well we'll continue the discussion about uh the couple of settings that might be useful in the event of exceptional scenarios around the merge and work on a common way to be able to specify these within the two specs repo which i think will be you know fork slash client settings.md um

and we will also revisit a few of the settings that we decided many years ago that were valuable for 1011 that were not they're not really commonly supported and probably should be and uh maybe get those into this spec as well anything else on client settings i think we can leave the particular discussion around which ones are valuable for the merge to that issue please check it out if you're interested okay cool and then our uh closing few points anything related to spec that

we'd like to discuss or anything um otherwise that you'd like to bring up today yes there are new bls test actors big thanks to antonio we just published them today you can find them in the github ethereum org all being goods and chat and the idea is basically that we can test all these pos libraries outside of the eve to test suit so hopefully we can share this with other projects as well then keep expanding the test factors excellent so proto but there are there

are likely still some a few e2 specific bls targets that would be building and releasing with the spec tests is that correct so for now that's correct we might move them over but we'll see what works best for the clients okay and just some quick background uh the bls tests that are built against the spec kind of evolved out of necessity as we waited for official ietf vectors um it doesn't make sense for most of them to live so tightly coupled to our spec and are end up being less useful for others that just want to use these libraries so now they exist somewhere

else cool anything else people would like to discuss today okay thank you everyone um we will continue to work on the devnet three issues and have an exciting test network in one week's time talk to you all soon take care thanks everyone thank you goodbye [Music] [Music]

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

[Music] so so

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

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

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

[Applause] [Music] so

[Music] [Music] you

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