All Core Devs - Consensus #87

Transcript

[Music] [Music] [Music]

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

[Music] [Applause] [Music] so

[Music] [Music] [Music]

Danny Ryan: stream is presumably transferred over if

you are on youtube please let me know that you can hear us okay issue 527 on the pm repo consensus later call 87. uh we'll go over the merge stuff i've got a couple of agenda items generally if we have any other client updates then a couple of discussions um around some spec stuff and then open discussion any closing remarks so on the merge i believe we literally just had a shadow fork like

are we an epoch in or something does anybody want to tell us what's going on here

Parithosh Jayanthi: yeah go we just had the we just hit ttd for me shadow fork five um it's too early to say anything but in the last like epoch i think there was one or two missed slots so it looks quite good so far we are doing a few things differently this time around we have an equal client split so 25 percent each el and 20 each cl uh besides that we are running sync tests so i just paused either a cl or el and we have

one of each combination running for get nether mind bezu um not doing eric on this time because they have some other sync issues that they're figuring out uh besides all of that the ef security team is running some address sanitizer threat sanitizer memory sanitizer race condition stuff so we're going to collect hopefully a lot of data this time around and i can update as many call about finality ah that's it for me this shadow

folk

Danny Ryan: great

is there a link that anyone can kind of follow what's going on here like we usually have with these like block explorer

etcetera

Parithosh Jayanthi: also ignore the uh peripheral ones they have an issue with each stats so that's not really valid data but the other ones are valid so if some other client goes offline on each test please let us know

Danny Ryan: great thank you um i know there are independent testing calls i do you know it's enough of a important effort is there anything to surface

there to the wider group on testing in general okay all good okay next up is uh also on the awkwardness call which i believe everyone on this call is very likely to wear at this point um robson was decided to move forward on robston there were a few consensus layer teams on there giving the thumbs up as well there was even a ttd chosen i believe on the call but it seems that we maybe need to reconfigure the ttd tim you brought this

up can you give us the

tl dr

Tim Beiko: yes pldr is we messed up choosing the ttd um slightly longer version is that robsten is robson is the hardest network for which to predict the total difficulty value because the block times and the hash rates are quite unstable um so we we made some new estimates now and we think they're better but then the risk is you know the risk of choosing the ttd is like if we choose one that happens before bellatrix that's really bad um so we we we we were aiming if bellatrix is on like june 3rd we were aiming for june 8th to be the ttd we can do either we keep this

value and we like massively increase the hash rate on robson a week before uh so that we we kind of hit it quicker um it seems like that is doable but it's still like a lot of hash rate um and then we we kind of updated the the model which uh which uh which which predicts the ttd and so the other two things we can do is um either we we pick a new value that's much lower that we now think is actually gonna happen on june 8th and then the risk is like if we're wrong again maybe it happens sooner um or the other idea is maybe we pick a value that we think might happen more like june 15th and then um a week before hitting

it we start adding way more hash rates to the chain so that um we we hit this like june 15th one on june 8th but it's still lower than the the one we currently have so it just requires less hashrate to be added to

roxton

Danny Ryan: um what is our ability to add hash rate like do we control hashes on the order of like 50 of what's on there on that network or something

Tim Beiko: um i think uh some someone on our team check that yesterday marius do you remember

Marius van der Wijden: yeah so we can we can add enough hash rate i think

um in the order of like one

gigahertz

Micah Zoltu: guess is that all we need to fix this is like one gigahash or

Marius van der Wijden: at least according to the calculation that i did like some days ago but

Micah Zoltu: how long like a week or a month a day until ttd until

from now until tpd

Tim Beiko: so from that so right from now

adding one so having robson on one gigahertz would hit ttd at the required point

Danny Ryan: and that's so that's that's option one

we could also change right and then turn on the hash power a week before

Tim Beiko: and yeah marius you have a comment saying the new estimates are worse what do you mean by that

Marius van der Wijden: yes so i just ran the the estimates the new ttd estimates from mario and they should be hit either on the 24th so in five days on the 28th so in uh nine days so

they are you're saying they're too low yeah way too low

Tim Beiko: okay

Danny Ryan: the 43 numbers were too low or an updated number

the 42 the 421 is way too low

Tim Beiko: okay and so basically what we had was 43.5 or 435 uh originally so i mean yeah the option if we so i guess one thing that would be helpful to know is like beyond the ef are there other people who can contribute hash rate if we need um i mean we can probably scale a lot of

this

Tim Beiko: yeah yeah yeah

Micah Zoltu: printing is super easy like it's a couple clicks you just spend some eighth point zero one five eighth per day i'll

get you a gigahash if you only need a month it feels like the amount of money spent on this call is likely to strip that cost

Marius van der Wijden: yes uh i think i think that's the way to to to do it

okay

Tim Beiko: okay so we keep the value but how do we make sure we don't add too much hash rate too soon and what like how how do we tweak this basically

we start we start adding hash rate uh once all the clients have have updated their images and then we don't care okay when is the bellatrix work when is the

Marius van der Wijden: june 3rd

Danny Ryan: okay so waiting waiting a week from now or a week and a half from now and then maybe renting more power if we need to is a bit safer than like cranking on it right now

Tim Beiko: yeah and one thing that would be neat that wasn't it with the june 8th is like it happens like a couple days before all corded so it would be nice to have the fork happen a few days and then we can kind of see how it went and discussed like what we want to do next on on the calls and and it's not the end of the world if we lose a week because it happens like say on the on the 10th but it it would be nice to not lose that week

but

Danny Ryan: we can also get four gigahashes instead of one

Tim Beiko: yes

so

Micah Zoltu: someone should double check my numbers on that make sure i'm correct i am not a miner i'm not a professional i i believe if those numbers are mentioned correct but i might be like off the orders magnitude so someone double check me

Tim Beiko: okay um i i will look into it though i i sort of assume you couldn't rent nice hash for test nuts but like um i'll look into it oh you're doing whatever you want yeah i know it makes sense

Marek Moraczyński: i yeah just my brain not think but yeah i'll look into it guys i think we should check block

production on msf uh on the shadow fork five because something seems to be wrong unfortunately

Parithosh Jayanthi: yeah i think we're hitting this issue we had in the past where we're hitting timeouts so blocks are being produced and we're gonna finalize but transactions aren't included

so we really only empty blocks and we for example another mind is producing only with uh client compass that uh load star and gimbals so the clients combat that are producing that that are not giving us enough time and all clients are producing empty

blocks

Enrico Del Fante: yeah so lotsa has an ongoing pr for this to address maybe next week we'll be able to address and issue fcus ahead of the time so that els can make blocks

Danny Ryan: we do know that geth switched to also have the async but i didn't i wouldn't suspect that um the clients that were producing blocks with nethermine previously would not be able to produce them with guth so we might just be seeing a higher percentage because

of the distribution now the even distribution but it might be just the same known issue i guess let's get the percentage but we can keep moving on this call by some people while some people investigate okay um so we are not at least currently the people on this call think that we should not adjust the ttd

Mehdi Zerouali: we're happy with all options uh from lighthouse perspective

Danny Ryan: okay so right now we won't adjust the dvd and

we'll probably readdress this in one week on awkward devs tim

Tim Beiko: yeah sounds good and i'll look into getting set up on nice hash and um yeah we we can also look uh at the ef about setting up some minors on on our own uh instances and yeah

Danny Ryan: cool thank you um any other merge related discussions for today

Parithosh Jayanthi: oh when do we expect um client releases with the

robson stuff picked in um prism

Terence Tsao: was planning a release on the

weekend before that so maybe next thursday friday we will have a release yeah

Mehdi Zerouali: for for lighthouse uh we'll have uh we'll have this by the end of this week early next week we're just working on getting the significant measure-related changes in before the the actual upgrade uh so to get as much testing as possible uh pretty confident we'll do this and uh we'll also add our boot notes to the mesh test that's repo

yeah

Ben Edgington: oh tecu will be uh early next week monday or tuesday

Parithosh Jayanthi: awesome thanks um and just to reiterate there was one change

since the pr was created so please do make sure that you're on the version that was merged in like the genesis ssc file and the genesis delay

Jacek Sieka: yeah nimbus same thing there we just did a release today but we're going to do a small point release just for robson next week sometime

good

Mikhail Kalinin: um on the same topic we are expecting spec releases as well right and like engine api and

uh it says suspect

Danny Ryan: yeah i believe like a release candidate

on the consensus specs um and then i don't know how i know the engine api the execution apis have been alpha releases so it might just be another alpha release yeah um i need to do a bit of cleanup i was doing a bit yesterday i think we're in a pretty good spot on the consensus specs and um try to get that release candidate out tomorrow it's not necessarily meaningful other than just kind of signifying this is what's going into robson that's i don't think there's really changes real okay other merge related items for today

any

updates i'm going please so

Terence Tsao: beyond robson we're also working on a few thought posts on how to start up some beacon mode how to use theory cpn and stuff i'm wondering if there's like an effort for more general blog posts on just how to launch uh robson beacon nodes so that so that we can point our uh blog post to that one

Danny Ryan: tim you've been working on a robson blog post that's going to have some of the details here right or at least like the high points

Tim Beiko: yes i was looking for something to link for people who wanted to launch a robson beacon nodes so terence if you have that blog post ready in the next like i don't know

like before midweek next week i would happily link that in the ef blog post like it says it basically says like generally what people needs to do but it doesn't run through actual uh like how do you do it step by step so if you have like a good a good thing there uh yeah that would be really really helpful

this is

Terence Tsao: awesome thank you

Danny Ryan: is robson blog post gonna it's gonna reference the fact that you should set your recipient so that people use that but not like point out how to use each one

Tim Beiko: right because if yeah exactly that's like a good example because each client like implements you know few recipients differently it says you know look for a fee recipient value in the

configs of your client to make sure you set that but it doesn't go through like here's how you do it on nimbus and prism and lighthouse and

deku

Danny Ryan: okay um other merge related items okay um i do recommend maybe jumping having someone on your team jump into all core devs next week it just seems like

over the next four to six weeks there'll be relevant conversations happening in both these calls um okay um are there any other client related updates that teams like teams would like to share today

Mamy Ratsimbazafy: um so uh josek mentioned nimbus um uh release we have a couple of interesting updates for the release let me check the release notes um [Music] sorry yeah so we have like improv now the

proposal boosting we have faster uh snappy reduce cpu usage as well for uh when clients sync with nimbus and we had some focus on web free signer normally it's we have better compatibility with all and one thing that we released is bls threshold signatures so the idea is that now especially sticking pools can um have uh signing keys that needs to be like you need five out of eight or something to actually sign a block on at the station and this um so that they don't need to give

the the full keys to their sysadmins or a devops team which is one of their concern once they have a fleet with millions of dollars and a disgruntled employee could cause issues there so that's it for nimbus client itself and otherwise uh we have uh the light client protocol we made some progress and uh there is a ethan who's working on on the spec and implementing it at the same time you can look at it in the

uh related efficient repo and also well still uh trying to push and implement mev and mev boosting for [Music] the consensus layer

Danny Ryan: thank you any other updates

Mehdi Zerouali: yeah i can go next for lighthouse um we propose the pr to the beacon api uh spec to prevent production of uh attestations and sim contributions to optimistic blocks so it's pr2 on the beacon api's revo um we don't really expect this to be controversial but um kind of want people to be aware

of this uh since it's a pretty significant important change that would essentially allow us to prevent finalization of invalid execution payloads so please take a look um we've also made our discovery ipv6 compatible uh we essentially decided not to enable this until after the merge but it's ready uh we've started speccing and implementing um epi sub prototypes so epidemic meshes for for gossips are seen as a significant upgrade to gossip sub we started working and implementing the recipient method for the validate client from standard key manager api

and that's pretty much it on the client's side but i've probably seen michael has done a bunch of work on on block print for client diversity metrics um check out his tweet if you haven't

Danny Ryan: thank you other updates

Enrico Del Fante: i can go on next for tech so we uh work the we have some additions from the upcoming release for the next week um some of them are related to our rest api framework that becomes uh we are moving from from from

we are changing our internal framework to be our to be a little bit more optimized in terms of memory consumption because we are now able to streaming stream json it's directly to networking so we have less memory pressure when we are dealing more mostly with big apis that the streams for instance states that are usually very big objects so a big win for for inferior for instance and um we have some optimization on the bls battery batch validation for instance and we also have additional

optimization on the a on the events rest api events we still on memory pressure on that side uh big wins there and we also implemented the eth1 checksum this is a good has been good a good contribution from an external contributor so we are now applying checksum on the eth1 address this applies to few recipients for instance and we are still we are working on the builder api and today we had the very interesting results first successful testing around builder apis

so we are now be able to run the beacon blind address api flows plus builder get header and get payload apis they are working and we are also falling back with our local execution client when things that goes wrong on the builder side what is missing here is just validator registration signing and builder bid validation signature validation but yeah we are we are close to having everything implemented on that side that's it

Danny Ryan: thank you anyone else

Terence Tsao: i can go next so um prison released uh version 2.1.2 last uh this week which includes goal 1.18.1 also it has a few important bug fixes a few optimizations aside from that we're just catching up with the spat changes we are also um working on saving blind block instead of saving full block meaning that the execution payload will be header hopefully we'll see reductions on the db sites on that and then um also we're working on builder api implementation we are done with the implementation right now we're on testing with the merge mod trying to

write some sort of end-to-end test and um on the ux side we're working on config and client for users to specify guests they made and then the and then the desired builder fee the builder fee recipient and then also we're also on the background we're working on eip4844 with the with the with the with the optimism team and then we also have um two new hire they're just joining us so nick will be our um full-time uh typewriter and samantha is our new um pro developer so yeah well welcome to those guys

Danny Ryan: great thank you

Cayman Nava: i can i can speak quickly to lodestar last week we uh released version 0.36 had a few goodies we have validator metrics in the validator uh we i believe that also we also include proposer boosting in this release and we also fixed a security vulnerability where someone could create a malicious but valid slashing at a very very high slot number and cause loadstar to have a consensus split so that should be fixed upcoming where we're going to be implementing the light client spec along with itan

and getting ready for an audit of our code base and hopefully subsequent version 1.0 release next month

Danny Ryan: sweet thank you anything else any other updates

yeah so solas from grandina team so

Saulius Grigaitis: so we extended the website signer support with multiple signers and keys reloading and other things and also we started to work on the custom task channeler to replace the iran that use for parallelization is since we we optimized for the 8 to 16 cores cpus and the

four cpus with just a few ports or a lot of course like 32 or so the performance should be better than it is now so we are working on on this custom scheduler and they also improved the memory consumption which significantly decreased it wasn't high previously but now it's even smaller so that's all

Danny Ryan: what does your main memory consumption look like if you don't mind me asking

Saulius Grigaitis: um i don't know actually actually i talked with with leo from barcelona super computer computing last week or week before and i think they have these graphs

with memory consumption but but it's pretty low now i don't know it's like a couple of gigs or something like that not that high

Danny Ryan: okay uh any other updates great moving on research spec and otherwise um i actually don't know what your name is but r were 13 is here to talk about essentially exits a method to initiate exits from ox01 credentials from the execution layer

Artyom Veremeenko: yeah

could we please move the discussion to the last 30 minutes of the time while my teammate wanted to join and then he would be able to participate as well

Danny Ryan: we can definitely talk about step deprecation and anything else but i don't know if we're gonna make it to 30 minutes from now um but let's yeah let's jump into step deprecation

Artyom Veremeenko: um okay

this has been let's see

Danny Ryan: this has been up since march 18th um pretty much looking for any final feedback on this i believe

everyone was generally fine i think maybe only one client team is utilizing step in one edge case but it's not really utilized and the goal here is to reduce the complexity and have a backwards compatible way to do so um i guess i'm putting this on a final call we don't have a process here but uh i haven't no one said anything bad about it i think that we're intending to just move forward this is the specification is there anything else people want to discuss in this issue before we merge it and get a new release

Jacek Sieka: since i wrote it i can

note that there is a very similar pr coming up for the beacon api as well which basically allows the consensus client to implement both by root and by range requests with mirrored api calls in the in in the json rpc call and that one doesn't include a step parameter let's say yet because i kind of assume that this pr will get merged since nobody complained so far but the two things are related so the point of simplifying this right now

is that there's an actual reason to do so it's not like um yeah it's not just a fun change

Danny Ryan: right and the i'm going to toss this other issue in the x in the engine api onto maybe onto all core devs next week just to make sure that uh execution layer clients have taken a look at it um i know that there's been a little bit of review in general positive um and it enhances you know feature that lighthouse has already built out using the standard youth api i think it's a likely no brainer as long as we get

thumbs up all around

Jacek Sieka: yeah i think i'll just briefly outline the the one thing that i see as an issue and or there's a discussion point in that pr and i can repeat it later in the or all cardiffs but um there is the question of whether els should support both by hash and by range requests and then by hash requests they're kind of mandatory in order to grab forks or non heads whereas range requests are excellent for for the canonical chain and finalized

data but strictly the range request is an optimization so in in the beacon api spec it's done in a way that els are free to not implement the range request and then cls should fall back on rule requests um of course if everybody just agrees that range requests are absolutely fantastic we can remove the optionality from there and simplify the cl as well to not have this uh fallback logic but that's and that's kind of like an open question

Mikhail Kalinin: got it but we need this by by root request as well right or by hash i would

call them by hash requests

if you are

Mikhail Kalinin: requesting non-canonical

Jacek Sieka: yes we do we do need both so it's a question of uh do we mandate both requests to be implemented by the el or do we say that only by hash which is the more powerful request is mandatory and then the range request is optional and not an optimization basically and this is really down to i think the implementation effort in els because obviously not having this fallback logic is is more simple on the cl side

right

Danny Ryan: i did just toss it on awkward agenda for next week to get some visibility you ask if you could join that would be helpful

Jacek Sieka: i will do my best

Danny Ryan: okay it's anyone against this step thing i'm going to drop it in the i'm going to drop it in the consensus dev chat and ask for any final review and then we're going to merge this thing and put it in the release

Jacek Sieka: yay

Danny Ryan: yay indeed um okay

it has we managed to kill five more minutes um are there other things that people want to discuss today how about uh just a quick update on um the shadow fork it looks like things are going well and we were just confused by how block explorer was importing things

Parithosh Jayanthi: um exactly so the explorer seems to be running into some issue where it's failing to import a slot i'm not sure why it's complaining it's an invalid chain id um so it's just listing every slot as zero transactions the slots actually had transactions and you can query the node and check the slots so in general we have a really really

good shadow fork with an equal client split of a possible 97 participation we're at 97 um so essentially no client combination went out of sync post much so we survived the transition um the missing three percent was related to an unhealthy shutdown on bazu and that happened far before ttd so it's completely unrelated we are only running eragon with prism right now but that combination is working yep that would be the update from the shadow folk congrats everyone

Danny Ryan: that is fantastic news so the race conditions with the async

calls were those

patched because

Parithosh Jayanthi: we still need to check now um there are transactions but we're not sure if there are transactions in every slot we still need to check that

Danny Ryan: we would expect based off of the bloodstore's update i think we would expect let's starters still be having the empty ones

Parithosh Jayanthi: exactly um i think some clients didn't patch them so if there was not before they'd likely be about after

Danny Ryan: okay fantastic news excellent okay we killed three more minutes um can we discuss this we can also discuss it on the next call if you do need

your co-worker to join in um it's up to you arton and before that any other discussion points that anyone has for this call

okay so i saw raising discussions of the deposit deposits functionality and simpson teams would like to uh to change it or kind of get rid of the or the current approach is it like

is it the idea to have something in the in the next [Music] somewhere in the very fire future

Danny Ryan: uh we could certainly entertain it for shanghai capela um it's probably like if we have a low complexity path um then i i don't see much issue you know we'd kind of be debating whether it's just kind of worth the time at that point i do personally believe and you know i haven't expected out or explored it fully but i believe you can just likely reduce the follow distance to one and make eth1 data a validity condition

such that you toss out blocks with bad et1 data this you could use existing endpoints on the eth endpoint or you could potentially escalate or elevate this to the engine api to reduce the dependency on the ethernet points obviously then you still have kind of the machinery of having to get the deposits out of the el and stuff you could also elevate that into an engine api endpoint so there's a there's a number of like little design considerations my per if we do want to prioritize getting shortening that distance i think the the most straightforward way is to um

just reduce the follow distance to one and kind of deal with the implications of that but you could certainly also probably do a bit deeper redesigning and get maybe a more elegant mechanism but then it's debatable as to whether it's worth the complexity

Ben Edgington: just clarify by more elegant do you mean removing the voting process and all of that

Danny Ryan: well by by eliminate by reducing the follow distance to one the voting process just becomes one of one uh and it's safe as long as there's a validity condition on the block for ethan data to be correct so i think that that's

you could potentially like more tightly couple you could probably get rid of eth1 data you could make the engine api return deposits and maybe get rid of some of the merkle root processing i i don't know i just there's i imagine if you are more willing to redesign you could probably get rid of some of the other stuff but i think the most straightforward way is to reduce follow distance to one have it quote a voting of essentially just one slot and make it a validity condition on so that it's not actually voting

there was a good point battery and chad that the syrian the optimistic scene we probably

won't be able to just query uh yelp or verify this data like it's in toronto's instant chronos fashion

Danny Ryan: so i think you'd have all this optimistic as well if you couldn't get anything you really can't fully verify that you're depending on the execution therefore would throw it into optimistic

Mikhail Kalinin: um i think that you mean that skipping verification of deposits like in the optimistic sync

mode i see how that's dangerous

Mikhail Kalinin: yeah that's dangerous

that's it

Danny Ryan: is that not what's happening already yeah i guess it's not happening because they just they assume that the voting threshold is

safe enough so it's not throwing you an optimistic

Mikhail Kalinin: right right so yeah well i i it's gonna be easily imagined that an adversary will just induce a lot of big deposits and increases like uh portion of stake and for someone like i don't know sync with between in an optimistic mode yeah so it's definitely like a kind of a new attack vector that we all have to deal with that we ideally don't want to deal with and the uh yeah and what's possible to do is like uh if we have a a logical verify and a miracle proof uh that links the deposit route to the state route of the previous walk for

example but that would require like constructing this kind of proof and also verifying it on cl side not sure if it's something that cl5 players want to dig into but yeah that's like that sounds like a decent option from from uh a lot of standpoints

but it adds uh implementation yeah

Danny Ryan: okay so yeah i agree that it does open up an additional potential path attack or like heightened attack path if you're an optimist again it's an easier way to get keys in there to try to finalize something malicious

Mikhail Kalinin: um yeah i also think that we can easily the set and this is like uh yeah needs more rigorous analysis but i think that we can easily set this e1 follow distance parameter to one and preserve this you know vote in periods and sizes and have it now but i'm not sure if it's like a huge ux improvement that we want to make so the one is that even worth making

Danny Ryan: i do challenge the uh this actually making it much worse because you still have because everyone's using this as a validity condition you know in optimistic mode you're essentially like you're kind of in like honest majority

mode on execution layer validation because you're following the fork choice and finality of the people that are voting and so if this is a um that doesn't really change much if like if you make this a validity condition you're still relying on everyone's attestations and finality votes so you're still in kind of this honest majority situation um it's just what that honest majority can do to you is slightly heightened i suppose yes or dishonest majority sorry

Mikhail Kalinin: yeah but yeah but i think that reducing the distance is that we have this large it

distance now to to protect ourselves from rework some with one chain right and we will not have this uh problem

uh post merge

Danny Ryan: yeah

Mikhail Kalinin: because the chain that you're so definitely options here but i'm not sure that we want to dive deeper i like to to like tightly couple ourselves to the miracle proofs uh considering that there is an upcoming whirlpool tree upgrade so think about it

Danny Ryan: um i will say that if anyone's inspired and wants to kind of

try to specify a minimal complexity here option here that would help with considering it right like right now it's just a few potential ideas um and we if we're going to consider it for shanghai capela we need to get a concrete proposal you know in the next some chunk of time i don't know what chunk of time that is but uh sooner better

is the goal

Saulius Grigaitis: is the goal to speed up the addition to of all the data's to the state or or this

is not a goal

of

Danny Ryan: um that would be the goal of the feature is that this follow distance does not actually potentially really bias anything now that these systems are more tightly integrated um and so we can probably eliminate the follow distance if we specify

it properly there is their kind of need for for adding validators at a higher rate

Danny Ryan: no i think that i think the argument is there's probably no need to do it at the

slower rate technically so you can improve ux it's only a ux thing for onboarding new validators on the order of you know a day and so i would like if this was gonna get in the way if this was gonna decrease increase ship time or get in the way of something that's very critical then you know i could see it not really hitting the priority list okay

um art yum we have i believe killed the amount of time we can kill uh do you all want to talk about the xerox zero one initiated exits

Enrico Del Fante: yeah thanks uh messily is here now so it's just great um first of all we've got a question um uh what to think whether with the withdrawals enabled it's important to add capability to have withdrawal credentials initiated exits we've got some opinions on the forum

on the topic related to the withdrawal credential exits based on a generalized message bus for us it seems more or less important from the perspective of any delegated stake and solutions when where if the stakers and the pool are not capable to withdraw the funds thus the validators which are ideally are trustless are capable of holding the funds hostage [Music]

so the first question is whether somebody's considered this important to try to add alongside with the withdrawals

Danny Ryan: so i i personally do think that it is weird and potentially bad in the construction right now that the ultimate owner of the funds the person who has the withdrawal credentials which often could be the same person or not the same person cannot and initiate an exit so then you do certainly have in any sort of not even on chain delegated mechanism but

any sort of split there you have hostage scenarios that could happen and so i do think that having withdrawal credential enabled exits is likely a good feature to enable um i do think that in shanghai capela that we're going to be doing this kind of like cross el stuff to get the withdrawals enabled um and probably learn a lot as we do it and i don't know if we'll have the kind of complexity ability to do this other feature um

but i'm happy to kind of defer to others on the engineering complexity i do think that i question whether we need a generalized bus um i i don't think oxo1 credential rotation um actually should be handled by the the consensus layer i think that this we have smart contract wallets like you can certainly rotate control over these things um in a mechanism rather than having to have this as a programmable mechanism and then all of a sudden we only have one message that we need to send unless you predict other messages that we need to send out i i don't have a list of them

are there other messages that you think the execution layer will need to send to the consensus there over time

i honestly think that uh right now and like for the foreseeable future under the um for withdrawal credential english sectors are the ones because like you don't need with current proposals you don't need messages for um for the party withdrawals and withdrawal credential rotation is not super important like uh even if we wanted it uh you you it's it's not a priority yet like at all for for now and it's not

clear that it's needed so i think there is only one message that needs to be passed but it still needs to be passed in some way from the execution layer to the beacon chain layer

Danny Ryan: i kind of think we should maybe do the deposit follow distance reduction exploration and kind of keep in mind that we have another potential message to pass in and see if these mechanisms can be very similar

i mean we already have one message

python mechanism it's the deposits uh so uh yeah so like uh jmb is designed like almost exactly like deposits but generalized

so

Danny Ryan: i also think that we do need anti-dos mechanism beyond just people having to pay fees in the execution layer because being able to grief these mechanisms opens up i think we can easily avoid people being able to grief these mechanisms and so we should um deposits are naturally rate limited to a certain extent because

it costs a minimum of one eighth 8. i think it would be best if these were rate limited as well but likely the only way to rate limit them would be for the execution layer to have some view into the consensus layer like if you had the deposit route exposed you could ensure that just one only one validator could submit one of these ever um but we don't have that ability yet so without that i don't know if we have an anti-dust mechanism

yeah it it can be implemented with a like basically origin the merkle uh uh

uh the the the three uh the state tree for from beacon chain route for the valley data so like you you thought i can implement it right now uh but it's going to be brittle because like then not very uh not very beautiful honestly because you need to assume a lot of things about internal structure of the big chain layer on the kitchen layer and that just has complexity i think that like if we can manage the stuff with just fees we should manage that with justice because it makes much much much less complexity here and the

systems are much less tied up like executioner knows nothing about beacon chain layer and that's simpler to understand and the reason about don't have to track the changes on uh on the beacon chain layer to understand if you if you need to or make something execution there and stuff like that

Danny Ryan: it was just fees though i can arbitrarily block ox01 initiated exits

yeah for like for a very high price basically

Danny Ryan: well sure high in relation to wherever the market

is at the time yes

Artyom Veremeenko: for me it seems it depends a lot on the ability to to do a number of checks for the validity on consensus layer clients and for me this is the most mysterious part like for uh voluntary exits there is limit 16 and it's 16 because it because it because it's

it it's the limit not for the amount of checks but it's the limit for the amount of exits and this is okay but the check itself seemed to be much much cheaper and thus [Music] we could make i don't know 100 of them maybe more this is maybe a question to the client teams and the price of the attack depends a lot on the amount of of the checks we can afford like maybe if there is enough room for the checks

uh in a block then uh it's enough to make the attack price large enough even without checks on execution layers specific checks

Danny Ryan: yeah so the number is going to cost two things to the the beacon chain one is size of blocks and two is computational overhead um so but yeah i do see that if you could afford to put a ton in there then i'll you make the the cost of the attack to be sustained even higher

Artyom Veremeenko: um why why does it influence block size

Danny Ryan: these messages are included in the block

Artyom Veremeenko: only the valid ones the point is to make the checks before they are included [Music] everyone in the blog as far as i got it looking at the deposits implementation [Music] there is a part of execution where the deposits are cashed and the deposit requests events the positive events are cashed and preliminary checked and only then they get into the

block structure so the idea is to make the checks along the way

Danny Ryan: i might be wrong but i believe all deposits including invalid ones are included so that anyone can fully verify and to ensure that they're also processed sequentially

yes you're not world yeah

Danny Ryan: between the execution layer and the beacon chain you might be able to bypass that that might be an artifact of assuming beacon chain belt people

operating the beacon chain maybe weren't didn't have access to an execution there or the proof of work chain but um my intuition is you would likely want to include the ball and chain um especially if somebody if you don't include them all in chain then you have these modes where i can't be a i can't run a full beacon chain and a light execution client all of a sudden or something like that

yeah so so we we are out of our depths on understanding the the costs uh of uh um

like uh implementing this on uh on consensus clients that's why we need like a lot of physical and we have no intuition about like how costly he is uh checking the for example reading the validated data structure and checking if the address uh in it is the same as address from the exit uh message for example

Danny Ryan: so i think your your primary costs are again going to come from the size of the blocks assuming even the valid ones need to go into the box [Music] um potentially and then computation at that

point the reads from the validated data structure probably going to be relatively low cost computing markle proofs if there are merkle proofs in these might be a higher cost there wouldn't need to be any signature because the signature it's just whether it came from the oxo one address or not

yeah there is no cryptography they're just originally checking and like and placement block so yeah the um the the the block size can be priced uh easy enough with a like extra fee on uh

on the execution layer

Danny Ryan: what do you mean

actually like we can we can do a smart contract that like charges uh a bit of extra uh extra other to to work like zero point zero uh one for example or something like that yes you have a minimum cost regardless of gas cost

yeah it can be tied to guys gas price the current gas price as well uh it's fairly easy to implement like the uh the cost on institutionally are if they are simple to calculate we we

can use arbitrarily mechanism here

Danny Ryan: um are there any engineers or other people that want to chime in on this

Ben Edgington: i'm a bit concerned about how it changes existing norms i mean the all current staking services have been built assuming that this functionality doesn't exist and whilst i agree it seems like a good idea um we don't want to break anyone's uh um model at least without giving them a

chance to to change things up

Danny Ryan: yeah i fluctuate between agreeing with you and then also considering the current functionality as a bug

um how

Dankrad Feist: what what could break i mean can you give an example i can't just can't see it

Ben Edgington: yeah i i don't know i just don't want to make assumptions so we should we we should do some due diligence at least and then satisfy ourselves that actually this this is fine

Dankrad Feist: i mean the the like the idea to do this has been out there for probably longer than we have even had the beacon chain and i don't think i

have seen anyone ever say that it breaks anything i i don't know i can't see it

Micah Zoltu: uh how many third-party staking services are there that potentially might break like is it three if so we can just reach out to them and say hey we're looking at this just fyi or is it hundreds

if

if we're talking about like uh on chain stuff like like the rocket pool what the stake fish does like there is about i think six and none of them are relying on that and i think lido and rocket pool i actually rely on this uh being uh included at some point like not reliant but uh would appreciate uh

and for for stuff that is not public and advertised i honestly don't know but there is i think that there is regular uh contract uh stuff that like a staker has a contract with not operator and this sorted out in the in the legal field

um [Music] uh currently all of them seem to be upgradable proxies so uh they all reserve the they all reserve the right way to upgrade their withdrawal contract so one sort

Danny Ryan: centralized staking providers that do offer this split to some of their customers

um but again i have a hard time the key like that the customer if they want to exit and the their operator isn't initiating exit and they initiate an exit on themselves by themselves like i don't and again that's not ox01 but i think if you do put this for x at one you consider putting it for oxo as well um and it's hard to imagine that the ultimate owner of the funds which is the withdrawal credentials owner not being able to exit is a good thing uh but i all right doing diligence is a good idea i agree

Yoav Weiss: no i think it's um uh i think i think we do need this capability it does sound like a bug if you can't uh initiate a withdrawal from

the phone with with the world address but then but then it exposes us to another risk which i wrote on the chat that uh since a central contract like the one from a lido could could get us to where i could get to a mass exit situation if there's a bug like you know where suddenly if a third of the validators exit at the same time that could become an issue so we would need to rate limited at least

and it is um exits are rate limited

Dankrad Feist: from current exits i mean that that's

the same problem already there right

Yoav Weiss: yeah it just it just makes this uh problem even uh even worse because a single operation in a single operation in the contract could could cause this same as exit but if it's rate limited then there's no problem and it's already limited now so we should just make sure it remains that way

Danny Ryan: yeah i think in general we just it does open up the attack surface for uh you know what people can do if they and which type of withdrawal potentials they can do things with but ultimately if the smart contract or the way you're customer keys is broken

through withdrawal credentials it's certainly uh bad in any case um [Music] i i guess i would encourage people to think about this i think that it's probably worth thinking about as we're examining how to clean up the deposit mechanism um i personally would rather see a more natural rate limit than than just gas fees but i do think i do agree that a fixed fee um or maybe a fixed fee in relation to

gas that isn't just you know the cost of running it could also be at least a worthwhile exploration

um are you speaking about right on execution there

Danny Ryan: yeah yeah

Enrico Del Fante: oh it doesn't help

Danny Ryan: no no sorry i don't i mean you're saying the fees on the execution layer are the rate limit so if you add if you add a fixed fee then and you quantify the cost of including such an operation on the vegan chain then that could potentially be a viable path okay yeah this may not it's certainly not as elegant as natural

right

Micah Zoltu: this may not make sense but um what happens if a withdrawal key and a um validator key both try to draw at the same time in the same block

Danny Ryan: uh that doesn't matter

possible

Danny Ryan: both of these are it's exits that we're talking about exits then eventually become withdrawals after they leave the queue um one of them so things are processed in a certain order so if you had a voluntary withdrawal and then you had a oxo1 initiated withdrawal one of them would need to be a no op or

one of them would not be able to be included on chain like if you had the voluntary exit if you had to just kind of depending on the order but you you're right you have to kind of you have to test for that case uh but i don't think it's

like something we need to test for but there shouldn't that be any problem with it yeah yeah we kind of already have fun if there's

Danny Ryan: some edge cases there like if a slashing is included then you can't include a voluntary exit on chain because that person's already exited initiated exited from from a slashing so they're this is not it's not unique that we have to kind of think about how these operations interact executable specs great

sorry gossip what's up

no i was just gonna mention the slashing race it's funny yeah

Danny Ryan: yeah and that was a it's an important case uh because i don't think we had a test for that one for a long time but uh now there's a consensus test for that one well part of it is unspecified right

Jacek Sieka: as long as the splash lives in the pool

oh

Danny Ryan: well that's an even that's a that's a slightly different case that's a that's a pool management problem a pool management block packing problem beyond the state transition problem

well

Jacek Sieka: there is an inherent imbalance in

that we can accept more exits than certain kinds of slashings in the block if i remember the block limits correctly

but anyway

Danny Ryan: um i believe you can put in believe you can put in 16 proposal slashings but like one or two attestation slashings but after station slash is going to include quite a bit of validators anyway we digress

um um i've

Artyom Veremeenko: i'm still got a question about uh uh doing preliminary checks

i found the place i was thinking about in prison client i've sent the link this is this is the function where deposit logs are parsed and here there is at least a check okay there are some checks for the events and some of the events are considered invalid and only then they go further where they get the part of the execution which is described in consensus layer specs and my idea was to

do the checks here uh am i getting something wrong or not

Danny Ryan: so if you do the check here then a someone who's only validating the beacon chain um would not be able to um it would be opaque to them why maybe if these were indexed and must be processed in order why they'd be missing ones if you assume every beacon chain does have an execution engine um then that is this is probably fine to do there um if

you do not you still have to specify it somewhere though so i i don't know my intuition is much cleaner do it the other way my intuition is that if you do put it in here then you do you do kind of limit certain types of uh lighter versions where maybe i'm only running the beacon chain and i'm not running the execution engine which although validators shouldn't do that it's certainly a thing that users might do for some reason or the other um so it does reduce the ability to process and fully validate the beacon chain state transition because you have to get this kind of missing component coming from the extrusion there but i i don't know i i would need to think a bit more about whether that can be done

in a safe way does anyone else have an intuition on that

Artyom Veremeenko: and the same problem doesn't happen for the deposits uh because the checks here are m may or may be only the checks for for the duplicate events duplicated events

Danny Ryan: i would presume these checks are primarily to ensure that they kind of make sure their cache and construction of the tree is valid but that everything that's emitted from the deposit contract is going to end up as a deposit on chain

here but i'm i'm not too familiar with this

code all

Danny Ryan: right any other questions for today okay we're still

by still what i mean to do uh figuring out how to make this process in the consensus layer a bit cleaner so that people can propose features beyond just an e3 search if you are interested in specking out this feature making a feature directory inside of the consensus layer specs would be the way to do so um there's like a if you look in there there's primarily things bundled into forks but there is a 4844 feature directory where that's specified so it can be kind of considered independently of a fork until it's time to integrate it into a fork so if you wanted to

take it to the next level and specifying that would probably be the place to do so and i think once you put if you deem it worth kind of doing then you'll probably get more eyes at that point but again i think there's probably some stuff to think about as we clean up the deposit or explore cleaning up the deposit structures

okay

Artyom Veremeenko: thanks

Danny Ryan: okay anything else for today

Parithosh Jayanthi: um just a tiny note would everyone be

okay with the next shadow for happening monday the 30th so there's more time for everyone to cut releases and we can hopefully test the robson releases either monday or tuesday so 30th or 31st

Tim Beiko: i like the idea of having you having one happen with like the robson releases um and hopefully we get them all by the end of next week so we can have the blog post out

there

Parithosh Jayanthi: exactly and if a couple of the clients still haven't made the releases that's perfectly fine but it would be nice to test what was

ready

Marius van der Wijden: yeah but you should you should really

make your releases by the 30th

Tim Beiko: oh no you should make your releases before that please you should really make your releases by the 25th ideally so that because like what would be really good is if the releases are out like next wednesday then that means like thursday we can publish the blog post and like people have the whole weekend to get set up before genesis of the beacon chain if they want um yeah so please before the 30th and i guess what we're just saying here is like we're not doing a shadow fork next week to give people the time to cut over these

Parithosh Jayanthi: exactly and just in general about stuff any quality of life stuff whatever you want to do yeah

Danny Ryan: great i assume the shadow fork still looks good

Parithosh Jayanthi: yeah nothing's changed since the past half an hour also yeah

Danny Ryan: excellent okay on that note let's close it out um awkward does next week um talk to y'all soon

thanks everyone so yeah see ya thank you [Music]

[Music] [Music] oh

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