All Core Devs - Consensus #94

Transcript

[Music] so [Music] [Music]

thank you [Music] [Music] [Music]

Danny Ryan: welcome to the

94th consensus layer call if you are on youtube please let us know if you can hear us um the agenda which i just shared is one merge research spec and discussion as point two um it looks like there's a couple of four eight four four topics that we did not get to last time um if we have the sufficient crew here to go over them we will um otherwise we can take it to asynchronous chat if um if not and then general open discussion um on the merge we don't have any particular agenda items um

michael we started like 10 seconds before we got here um we don't have particular agenda items but open discussion does anybody want to take the floor on the merge is there anything we need to discuss today

Parithosh Jayanthi: um just the updates from the live shadow fork we had a good one last time and on monday we updated the notes with the latest get version and with the update we did see some regression we did see a new issue in the gets released that's been um patched already so please have a look at the get release notes um and to continue

the shadow fork trend we will be having a nut shadow for 12 next week and currently i'm using the latest versions recommended on the blog

Danny Ryan: great

is

Marius van der Wijden: anyone from aragon here because we're still seeing a bunch of bad blocks on on miniature fog 11 so it would be really nice to know what the what the status of the

issue is

Danny Ryan: on a quick scan i don't think

aragon is here i can ping them in the execution layer chat after call and if they do join

Parithosh Jayanthi: well i do know that they were able to reproduce the invalid transact or the invalid proposals also on their own dobson nodes so i think they're also looking at some redeployments and some fixes so potentially the fix would make it eruption before the

shadows work

Danny Ryan: so they are aware of the issue

Parithosh Jayanthi: yeah they're aware of the issue uh they tried i think one or two fixes that potentially didn't work but it was a bit too much friction to keep trying it on

the shadowfox so they were able to reproduce it on their own drops in instances and i think they're just testing testing out um trying to figure out what's going on there instead

Danny Ryan: got it other merge discussion items yeah i will mention as mario said in the chat uh the the ef runs a bounty program um and normally critical vulnerabilities can get up to a quarter million us dollars between now and shortly before the target of the merge i

can't remember the exact date something like the 8th of september these critical vulnerabilities are 4x or sorry the entire bounty program is 4x so you can receive up to a million dollars for criticals um and then quite a range september 8th yes marius um in that depending you know low mid high so find some bugs

because the severity a function of like is very higher for finding a bug in a majority client such as guess impact to the

Danny Ryan: live network is considered so i would say to some extent yes

lucas

Łukasz Rozmej: so two things from another mindset one is the ongoing issues with empty blocks if we don't have enough time for fcu so i think we had issues with lord star and nimbus and i think lost already fixed it and it will be releasing before or it was released before the version that will come before the merge but i think nimbus already had a fix but didn't release it yet so as we will have one more release we are debating if we should just uh re revive the kind of workaround that i know also get

has uh just wait waiting for a block for some small amount of time on get payload if if we didn't have enough time in the first place so uh yeah that's kind of we are debating if we should do that because if not then if someone uses another mind with nimbus he will have a bad experience it's not something we want to do but it's like lesser evil to to move it back for some sort of time

Zahary Karadjov: this was one of the kind of fixes that were supposed to land in the 2008 release but we discovered kind of some issues in the

request in the last minute we decided to kind of hold this off so but it has been merged now indeed and it will be part of our hardening release just before the

match

Łukasz Rozmej: okay just before the merge so it's like should we should we release with this fix so maybe we should we will uh bring this hotfix just for one version before the merge just to uh if anyone has a problem he could he could just use this version for a short amount of time and then we will again remove it okay that's one thing um which we just want to have a good experience on the other hand this is out of spec and we also don't want to keep this hot fix

but okay so that's probably what we'll do and the second thing is um again i don't have the full picture here but we also experienced some edge cases in syncing with some clients and this is because we we are thinking a bit differently so basically it's about they're checking if we have a block or get logs for some older blogs and we we can get to head and start processing blocks new blocks on the head while we still haven't downloaded the entire ancient history so we for

example cannot serve blocks or cannot answer on some old blocks queries i think this is fairly unique to nethermind like no one else does this this way and they firstly download the ancient history and then later they [Music] start processing blocks so it's an edge case and it's fine for example if you give it time i think there was problem with prism but i'm not sure if anything else so [Music] i don't think that's a big deal but generally i would advise consensus clients to to

have uh some testing around this scenario when net the mind sinks to the head but doesn't have old blocks yet and if they can handle this normally we return an error that we don't have this so we expect and i know that some clans will behave like that they will just retry until they get it right so because we will eventually get it but um yeah that's it and we are also um trying to df syncing here but this shouldn't be relied on probably but we're changing it here's thinking that right now we when we already start processing on head we would we return it is thinking false but now we will be returning uh etf thinking true until we

have all the historical uh blocks so that's potential fix for the future but it's not a big deal it's it's but it's a user experience like it can be potentially a problem that uh for users that okay they need sometimes they need to wait and restart something or something like that so uh it's sub-optimal and it's it's is because another mind has a bit different uh sync more sync order than other clients yeah that's it for me

Mikhail Kalinin: i have a question to you get paid out i think uh do you understand correctly

that the timeout will only be turned on when there is no uh when there is only an empty payload

Łukasz Rozmej: yes

Mikhail Kalinin: okay and is it in the merge release merge compliance release already

Łukasz Rozmej: no no so we are debating because we will have one more release before the merge because uh we have two around two two to three weeks schedule like we don't want to release in bigger time in bigger like spaces and we are still doing some bug fixing uh some related to the mesh some related to json rpc so we want to have a release

uh better release uh so yeah that's the idea it's it's not in the current version

Mikhail Kalinin: um yeah i was saying that in the discord so and that i'm in general like in general yeah against any like fixing or optimizing the thing on the other layer where the responsibility should be taken on like another one on the on the counterparty but yeah considering that we are close to the merge i think that in this very uh much of an edge case uh meaning that get payload will be

responded correctly if cl works correctly so it will be responded it will return the payload immediately if cl send fcu in advance i think yeah it's up to you but probably it's okay to go with this um or without it

Łukasz Rozmej: i hope it will be a temporary i hope it will be a temporary workaround that we can uh retire after

like another version yes and it's working minute we have no empty blocks oh cool so it helped great yeah yeah so from north star i want to

from lots of

Gajinder Singh: i want to confirm that we have included the fix for issuing advanced fcu in our version one release so that should not be an issue

anymore

Łukasz Rozmej: okay yeah yeah like i said i think you you fix it right so that's the only impossible the problem but again we we don't want to be discarded as a client because we have a compatibility issue so that's why it's temporary

workaround three

Danny Ryan: anything else on this one got it um any other merge related

discussions

Mikhail Kalinin: i saw a discussion in the interrupt channel about changing the status of the payload after restart which may help to recover in some scenarios when where when el responded invalid and then changed its mind or whatever i just wanted to i don't have a lot of details just wanted to ask people

if you want to share something about that on

the call this is essentially for getting the invalid cache on restart or persisting and that design issue okay

Mikhail Kalinin: yeah that's essentially uh all the uh some clients have as approach uh as follows so they just forget the the they consider all blocks optimistic after they justified uh one so and they just send them again to yell to get the status um but some clients probably light house and i remember they

persist the status and uh restart doesn't help to recover and there was like a discussion that an option uh that is not turned on by default to to do to persist the status should be added to to be able to recover um from this case uh by restart but not doing any manipulation with the database

Jacek Sieka: yeah i mean it's not switching back from invalid it's more like forgetting forgetting is the correct characterization because there's like an infinite number of invalid blocks out there potentially

that people could create but only a finite set of valid blocks so i think that's the background to our strategy at least

yeah

Mikhail Kalinin: i think it makes sense in general

and i

Danny Ryan: i can't speak for everyone but i know there was some discussion around it and those that were not forgetting did acknowledge that it's probably a reasonable strategy for recovery so i i believe that uh there was momentum to move in that direction for clients that were not there

it's uh considering everything

optimistic and actually save us uh with um with some bezel interaction where it changes its mind and we we we were able to recover within the after the very next head so prism does

Potuz: something uh in the middle so we we inadvertently we're not recalling persisting because we remove invalid blocks from our database so if you restart we don't even have those invalid blocks to start with but on top of that we don't think we don't sync like other clients from a port choice we don't dump

four choice to disk so when we restart we just restart from the finalized checkpoint and everything below it is optimistic so we are always forgetting everything

anyways

Jacek Sieka: yeah nimbus has a similar thing we don't persist for choice we just reloaded on startup from blocks basically

all right mikhail anything

Danny Ryan: else on this one no that's from my end got it

um any discussion points around uh mev boost

hey everyone so there's been a there's been a post on these research about uh removing trusted relays using threshold encryption um not sure if folks have had a chance to check it out but uh wondering what people think about this proposal if anything might be getting out of topic but just thought not to bring it up now that danny mentioned it so the basic idea is that basically relays will be receiving encrypted bodies and there will be a threshold encryption scheme where uh you know committee of keepers will

then be able to disclose the master key that is able to allow decryption for proposers so it's an interesting approach to preserving privacy here um and i thought it's worthwhile to have a discussion about it at some point i believe jani is working on it so yeah very interesting research coming up and

Danny Ryan: such a design does not preclude a centralized relay as well right like you could you could communicate with some sort of committee relay you could also the protocol doesn't have to be fundamentally it doesn't have to remove centralized relays

in in lieu of

committee relays yeah i think that is correct

Mamy Ratsimbazafy: um one of my concern is like it's good but if we do this does it delay uh propose proposal builder separation or not

Jacek Sieka: together with merger releases but what we'll also be doing is document like in the documentation for the feature we'll be highlighting that uh some of the release like some of the relays may potentially be

having uh differences in transaction selection strategies that not that don't necessarily reflect the transaction fee

Raul Jordan: yeah also the issue with this design is that basically there's no way to really validate kind of the body uh you know before before uh the full reveal is done so basically they propose a kind of like an optimistic um like an optimistic approach where there could be some kind of slashing mechanism after the fact if uh if there's if there's if there are being invalid uh bodies being proposed

um so that's also adds more complexity to the project but it seems to be one of the one of the few proposals that is actually tackling uh you know the privacy you know the privacy aspect that at the core level

just out of curiosity is

Micah Zoltu: threshold encryption still not fast enough to actually execute a block in a recent amount of time

fast enough in what angle i was thinking like a an mvc committee that would validate the block without anyone actually knowing what's in the

block i don't know the answer to that question from

Alex Stokes: what i understand for this design uh basically you just hide the transaction contents until some other time and i do think there are some performance considerations with threshold encryption like namely it not being like that fast and so the way you get around that is you can just batch things and say yeah like rather than have you know this set of transactions in the next block uh it might take a bit longer to like gather like a block that would land on

chain and you just have to like adjust the parameters of the system to to account for that

i have a question about the circuit breaker work uh and namely like how clients are in terms of uh implementing it i know lighthouse had something uh teku i saw how to merge pr and yeah i guess i would wonder then if nimbus lodestar or prism have had a chance to look at that yet yeah so um our circuit breaker was merged in v3 which was a couple days ago so we're

using three a parameter so three meaning that three slots miss consecutively and the eight means that eight slots missed within the epoch and then sorry eight stars missed within last 32 slots we think like a rolling window style and we don't we actually count the block as miss miss so for the orphan blocks we don't count them as missed so that's kind of our strategy here yeah that could

Enrico Del Fante: just merge the logic for for the moving window is enabled by default with 32 as a lot

um window and a maximum eight missing slot and the approach is only looking at the state so we we look at the current state we have during the product proposing so we only look at the block history in the state to find out if there are some missing

spots for lord sir it's work in progress and we aim to merge it maybe next week

Zahary Karadjov: you also will be focusing on this in the coming weeks still no implementation for

limbus

Danny Ryan: great thanks everyone great any other merge related items

cool um moving on there's a couple four eight four four discussion points um let's see

does anyone have the context on this first item whether the blob gas price update rule in the eip should be optimized for stable throughput or bursts of blobs maybe barnum bay so this has to do with oh sorry go ahead barnaby i thought maybe

Barnabe Monnot: um sorry i don't have an update on this i didn't really look at that question so

it should should it be a burst or a average yeah so the the gist of it is

Micah Zoltu: uh in order to decide what how we want to adjust the gas price you know between blocks um

we need to know do we prefer to have things bursty or do we prefer them to be spread out between blocks like is it from a client implementation perspective

is it less work if we do a bunch of them at once or is it less work if we do like one per block as an example and that will inform whether we want a gas pricing strategy that results in burstiness or we want one that results in a very smooth distribution

Barnabe Monnot: so do we know what's better on the client side if it's regular processing versus processing all at once

yeah that's the question i think for seal devs

Danny Ryan: any thoughts on this one or do we need to have this asynchronous or in a call where people have read it okay um we should probably open up an issue to talk about it then number two here was whether blob syncing should be tightly coupled to block syncing quote long term the desires decouple this but this adds implementation complexity and given the low number of blobs

it might be best to

sink blobs along the associated blocks um [Music] right so there is a design goal in 4844

Micah Zoltu: to essentially have it such that really one of the only things that's changing when moving to a larger sharded data construction is that your data ability check is changed if you are if you tightly couple these things you then add more work potentially in the future when you have to decouple them um but presumably if you have just a block sync method mechanism that pulls them down simultaneously then you simplify things out the gate um does anybody want to take the

argument for one

or the other so i wrote this design doc we don't have to go through it so i kind of explore explore the different trade-off and honestly like you said like i feel like the difference is pretty small because like even though it's the couple right it's still like a testation and become blood today where like you don't really process this attestation in the fourth choice until the block is seen so you have to implement some type of pending cure and then most clients do implement the painting here already so it's so i think like it's fine but i do want to hear like other clients feedback

regarding like regarding like regarding preferably having them coupled and i think another point it's like how does checkpoint sync work because i today do checkpoint thinking you starting from the starting from tripling state and then you have to backtrack to get the blobs from the last month and um so that part is slightly trickier because now you have to also bad try to get the blog as well so if they're being together i think that us may be slightly better because now you can just batch try to get the blocks you you don't backtrack to get the blocks you don't have the battery to get the blobs so that's another like design decision factor as well but yeah

i mean as someone not in the weeds of implanting it my intuition here is keep them separate uh because such a waiting queue would exist when you had david date availability sampling um essentially you know you're blocked on importing a block or considering it part of your uh your block tree until you handle that data availability sampling function similarly as you'd be blocked on retrieving the blob um i think the the symmetry there is really nice and kind of sets sets the code base up for what you know we need there and as you said

there's the attestation analog um but the historic retrieval i don't have a good intuition here um as to the complexity yeah i tend to agree with you like the code is already there and then it's also future extensible it's it's totally reusable so so that's quite nice

Enrico Del Fante: yeah i tend to agree to do to be more forward compatible and do the shortcut only if we are tight in time in general so if you're going to design something that will support

better the next version and even if it's get a little bit more complex now

i'm definitely for that okay so happy to hear other input here but i think this specs we should still kind of bias in this modular standpoint where blobs the retrieval blobs the availability of blobs are kind of isolated uh from from the core of blocks

and if we if someone feels strongly otherwise obviously when we're modding messing with specs chime in there and um you know if complexity begins to bite us we can open up the conversation again okay and then there was another link to a comment from proto from two weeks ago and there's a number of 4844 items proto you're not here are you no i'm doing a quick scan here to see if

there's any pressing points here's the link you can do as well okay so it looks like okay so he's agreeing agreeing agreeing does anybody have an uh blst update or other crypto library update on um extending the functionality for optivize

kcg um the blst team contacted me last week about my like use cases on kcg but that's just uh gaffering requirements i guess

Danny Ryan: got it and i do know um produce watching nicole hey proto um i do know that a couple of people on uh the research team have been speaking with uh supernational the blc maintainers

about getting some uh some of the requisite crypto in there so i know there's stuff in progress but um this is relatively early early and then uh the final point is in eip 444 test net first experimental version is running but missing the new fees approach and likely needs to be restarted include more test youth and adam fawcett um does anybody have a status update on current test net or plans for future tests okay um i think we're all kind of in a

merge shell sack still but let's continue this conversation over the next handful of weeks as the merge approaches and maybe something pretty important to reboot at devcon kind of get a new target in terms of current specs current engineering um and play with some new testaments from there sorry for my relative unorganized 4844 discussion is there anything else that people want to talk about with 444 right now great

anything else related to the merge related research really

specifications so regarding the merge i just wanted to ask how other client teams have encountered you know the communities preparation for the merge and how people are you know are dealing with the latest updates i know a lot of clients release their you know they're obviously the merge ready uh releases out there in prism you know a lot of folks have no idea what an execution client is a lot of folks have had issues with jwt uh many don't know that you need to run you know an el client um just quite a bit of confusion but i do feel like it's getting better i just wanted to gauge how other clients are feeling about you know their users uh their stakers or or

anyone else that's running uh you know running their notes i didn't get that much feedback but uh the feedback that i've heard was rather negative about people really knowing how to configure uh but it was not firsthand feedback that i was discussing most recently so i think for the solos all about interest might be not not the best but so i would keep pushing as much educational material as possible i think we're doing

that already but the more the better so i noticed quite a lot of users that are asking questions that the mind is not thinking and i ask what is your consensus client and they for example forget and they were confused that they need to run consensus client right now so and yeah i i i noticed some users with this problem yeah similar experience in nimbus we have a lot of users asking about the jw

secret and the fact that they have to switch to different rpc connection that there are not two uh rpc interfaces one for for the cl and one for normal users this is causing confusion with the ports um the other thing is the suggested fear recipient there's not great clarity on what that is and why it's suggested and uh how it's different from the you know the cl balance so we're working on clarifying those things in in our documentation as well yeah i will say

eatstaker did have a validator workshop this is the fourth one yesterday um you know if video content is how you learn i highly recommend checking that out and then samara did update his guides or has a new set of merge guides and also has some guides that bridge his old guides his new guides that uh just dropped yesterday the day before um i highly recommend we'll take the check check those out how far away the smallish oh go ahead uh another small issue i also mentioned is that um in nimbus at least we don't start calling the execution

um api until electrics has happened uh on this here the actual the the question client might not be ready for it now execution plans on their side are that there is no consensus client if it's not calling the execution configuration call so we're kind of waiting until september 6 for this warning to go away but that's just a small thing that we've put in our docks as well too for users to expect yeah you can't win on that one uh we we do the opposite and uh we're getting

complaints um that's true why are people complaining about the opposite well because they haven't upgraded their execution clients yet and we're complaining that that we can't see it because uh teku is expecting to see it now even though we haven't reached bellatrix um how far away are we from how far away are we from having it where we can automatically just connect an el ncl for people who aren't trying to set up a really sophisticated um

you know long-running instance on their computer like if i want to connect to a test net right now it seems like i need to like create these jwts in places and it would be preferable if i were to just go into another mind another mind dash dash sepolia prism dash dash defolia and they just are able to connect to each other without any additional setup so i mean the jwt is specter's requisite so that's hard to get around that unless we subvert that what i meant i think if we have a standard place that we try and write jwts too that that sort of gives us a way towards connecting them but i don't know if

there's other ideas on that we were discussing this and one thing that changed in the last month i think is that previously there wasn't clarity on who should create the jwt secret so right now we're in the situation where all guides recommend that users create it manually but de facto the latest execution they created so there's two things needed a standard location an agreement in consensus clients that we kind of

keep looking for the jwt secretary start up because the consensus client might start before the execution plan so that jw secret file might not exist yet there are like these little race conditions there otherwise standardizing on the port 8551 i think is another such simplification are we not standardized on port right now um it is specified i don't know if anyone's diverging the jwt secret location the name is not so they're called different favorites

the port maybe but a lot of users are coming from the old rpc uh jungle where they have all kinds of ports and they're confused about the fact that they need to change it okay i mean is anybody opposed to adding some default locations for the jwt token that the el can generate and the cl can look for are seals and els currently storing them unencrypted on disk so my instinct here is just that we

shouldn't be storing those unencrypted on disk but maybe that's just being overly cautious if that instinct is correct though then i feel like a shared location would still have the problem of needing to share the decryption key or whatever that might mean um during the exchange would it be possible for one of the clients to say i've written uh jwt to this location do you have permissions to read it from the location you're saying to to put this information

in the exchange configuration api right this defaults kind of also assume that you're running on the same host but i guess that's what the default's good for yeah i mean i'm just trying to work backwards from a user who just wants to connect to girly and previously they were able to connect to girly by typing in guesthouse girly and now they are syncing and i would like it to be as easy except maybe now in another window they also type nimbus dash network early can i interfere a bit uh so nevermind devops developed

this solution called sedge it was actually the uh working working name was one click and the idea is to provide a user this kind of a way of very easily setting up their notes it uses this docker underneath but the downside right now it's not stable release yet um but i think it's stable enough we are using it for our smoke test for example uh but the other downside is it doesn't support all the clients on execution layer side it clearly supports only gef and nether mind and on consensus

lighthouse lord star prism and taku so i know they i know they will be working on on other support of our clients it might be also useful if if those clients would like to have support to make their own pr's maybe to this tool if they want but yeah it's generally simpler to set up for end user but it's again some third party thing so if you want something you know it has its upsides and down sizes everything but the idea was to make it simpler

Lightclient: yeah i mean that's cool and i think it plays a role in the overall story

but i i do think that we could pretty easily set some defaults for the people who want to run the clients on bare metal and not go through docker and that should also be part of the whole story

Łukasz Rozmej: well yes but it's harder to automate this way and so that's why i think this this was chosen

Lightclient: is there anything that needs to be automated besides a list of places to look for a jwt token

Łukasz Rozmej: not entirely sure but it also allows you to pick from different networks things

like that so yeah depends

Micah Zoltu: so each each major os has pretty standard places for storing things um i suspect the easiest thing to do would just be to have someone go and do the research to find what those standard places are and then carve out a spot for ethereum and propose it as a spec that's what i would do i was interested in this

right

Danny Ryan: do you shove that in the engine api as a suggestion

Lightclient: i think it goes in the off portion of the engine api

all right since this topic is kind of

over i would also mention one more thing um the light client protocol has been merged right and actually one way of driving an ethereum node an execution node is using the light train protocol these days so um we do have a beta of nimbus light line that basically does the same thing as a full beacon node but instead of being a full beacon node it just follows the lifeline protocol so that's an easy option if people want to just follow the chain

without validating the obvious upsides are network bandwidth and we lost blah blah jurassic we lost you but we can hear you now all right so i don't know where obvious obvious benefits are network bandwidth and obvious benefit network bandwidth cpu usage downside you follow the chain

uh a slot and a half behind everybody else for 15 seconds and you're relying on the light client the security of the white clients yeah that's cool yeah uh is there a link to that and share with our viewers is that uh or is that do you do you run it off an embassy too with some sort of configuration or is a separate piece of software it's a separate piece of software right now um i'll post a link in the consensus there because i'm talking through my phone right now and

but i'll post a link in the r d channel is there aspirations to having that as one binary with the nimbus eth1 client eventually or probably not probably yes okay i mean there's no reason not to we're also planning on publishing this as a c library for anybody that wants to integrate it but because we will be integrating it in into wallets nice so for example

with the correct bindings geth could have that in light client consensus mode oh yeah totally like gas the other the other thing the other thing that's bubbling under the surface is something we call a light proxy um basically if you take the json rpc interface of an existing execution client and you combine it with a call called ethget proof which is i don't remember the eip now we lost you again

i'll figure it out in 45 seconds or so yeah okay um like client options like clean options might actually help for our standard user ux um with more straightforward hey we lost you you're back i don't know ah my internet is dropping sorry guys yeah i don't know exactly where you were you were discussing an eip um all right so light proxy um there's an east get proof call in geth which allows you to get a merkle proof for for any state basically and that mirko proof you can verify it

now with the light client so basically what you can build is um a json rpc proxy that uses something like infuria or any other you know data provider and then it validates uh the data that is provided via these merkle proofs against the data that comes from a light line so you can build like a very very nice wallet verifier in lots we also do something similar in fact

we have a demo a website running in browser basically you can do all the stuff uh you can get finalized vendor latest uh from lordstar like client server and then again you use this as an anchor to find out what are what are the headers for uh for the execution blocks and then you can basically again use the verify and get proof api to get those headers and we have gone even a step further where you can also fetch the storage slots of the contracts to verify uh what the token balances can be and again you can use the verify api and

verify that okay this is the valid token balance and it all links to a straight root that is referred by the block header that comes from the latest and final from the latest and finalized from the lifeline so we already we also have this running in the browser currency to some ethereum js library server pleased um okay other discussion points a

Saulius Grigaitis: small note on this discussion uh

regarding the uh regarding this the way the client stores uh the state and somehow forgets uh uh forgets almost everything and stores from the starts for a checkpoint or so and is it a problem that after the

restart they have a bit of limited view like uh the at the state the gossip attestations are not uh remembered and so on is it an issue or not uh because at grenina we also do the same thing we forget everything and start from the checkpoint given that the fork choice is lmd latest message driven um

the reconstruction from blocks and then listening to new gossip i believe should be very sufficient um you know there might be some sort of degenerate case where your world view is like slightly off but um i i would say that it's fine for boot yes so generally this is considered as issue and that's okay to restore the limited view yes okay thanks

Danny Ryan: micah you had a discussion point you

brought up in

the chat uh sure is this last one i don't want to take time away from anything else it does seem to be the last one okay um i will try to keep it short since uh i think most of you are on the all core devs call or have listened to it so um it doesn't need to be long the general gist is that i think everybody here probably knows that one of the primary security benefits that proof of stake provides is the fact that we can punish bad actors after the fact unlike with proof of work with proof work if a someone mining um attacks a network with some reorg type attack so that means sensor ship reorgs or double spend type reorgs there's nothing you can do about it

afterwards like they keep their hardware you can't take the hardware away from them and so if you fork away either you fork away the entire mining algorithm or which hurts everybody or you fork away and they just come back and do it again so the um yes as danny said the the key here is these are failure modes that we know about and then we can enter attributable so we can assign blame to a person but we cannot automatically handle them and reorg attacks are this class of things with censorship and double spends that sort of stuff so the problem is is that it seems that a lot of people don't understand that this is part of the protocol it's the human

and social part of the protocol but it's like by design this is why we're switching the proof of stake it's so we have this capability and so a lot of people think that you know if someone gets 51 or whatever and executes a censorship attack or a reorg attack or a double spend or whatever like once finalizes finalize and that's it um or it doesn't finalize um it's still you know tough luck and so i think it's important for the core devs to signal i'm not asking for people to do this like as an official statement as a team just generally signal to the public and try to make it known that this is part of the protocol to uh do user activated softwork or hard fork in order to

punish attributable attackers after the fact and just let people know that you know as core does we've got uh reason to argue for both i think and i think that's out of scope for this conversation for this conversation i think it's just important that we let users know this is in fact part of the protocol this is not core devs going off and doing something new this is laser activated soft fork or user activate hard fork um so really this is just we don't have to discuss if no one has anything to talk about um it's just a plea to all the core devs to make it well known publicly you know when people ask on whatever social media you use if you happen to use any tell your friends let people know that you know this is an intended part of how proof of stake

works and this is not just some you know bunch of courthouses getting together and deciding they don't like somebody this is very intentional and built into the protocol cool if you didn't check out awkwardness from last week interesting conversation any discussion points based off of micah's comments we need some kind of constitution uh some um values uh in this case censorship resistance

that would be like um very clear for everyone and uncomfortable that it's okay to slash in that case otherwise who controls um the controllers let's say i mean users can decide not to use updated client for example but still yeah i

Micah Zoltu: tend to agree um the users being able to predict the behavior of the developers that are building the chain that they're using is very valuable so users knowing that we will eventually move to proof of stake was very valuable for use because they can plan for that they can you know they can decide is this the chain they want to

use long in advance they don't get bought in first and then later find out you get something that goes against them

so i tend to agree i think the anscar has argued that the the critical factor here is if we see someone intentionally reorganize blocks where intentional is you know with we can statistically say that they were intentionally doing this because you know we we've seen them repeatedly under these conditions not build on the previous parents um and or they're not attest to the the proper pork choice rule um this would be an intentional reorg and that covers pretty much all the cases i think that we need to worry about um right i don't know if you need to go into more soft constitution there you know there is a protocol there's a protocol for

finding the head and if you have a certain percentage of the network and do not follow that protocol you can induce reorgs which is against the protocol um i guess that's you're saying even broader than reorganized if if we can detect that you're running a client that is not to protocol with enough hash power to influence the network then that would be the critical event yeah without thinking too deeply about all of the types of things that can emerge there that's my intuition but yeah and the nice thing about something

like that is it's very cut and dry there's not a lot of wishy-washy like oh is this censorship or is this not censorship blah blah blah it's this is just either follow the protocol or you don't um and so i like it so yeah tell your friends please tell your when uh journalists reach out to you please let them know that this is intended behavior of the protocol we will do it etc okay

are there

Danny Ryan: any other topics for today before we close if you are listening and you are confused about how to configure your system each one of these clients does have a discord the east stacker photos are very helpful there are some guides by some air and others the launch pad does have a preparation checklist and there are some videos of people configuring this stuff from eighth staker there's also a merged community call on the ninth this is after bellatrix but upgrading bellatrix

you know i i recommend upgrading consensus layer and execution layer in tandem just to be prepped and ready to go but if you can only introdu uh upgrade your consensus layer you will make it through bellatrix and there will be a community call on the ninth um if there are lingering questions or concerns the ninth is potentially very close to the merge so uh you know that is a last ditch effort if you have final questions but try to follow these guides jump in these discords get your stuff upgraded yeah there's there's a good chance that if you start syncing your execution client and you're just doing a normal sync or a not snap sync you may not actually finish between bellatrix and the merge depending on how smoothly things go for

you okay we will close it here

thank you everyone congratulations on getting those releases out talk to you all very soon thanks bye thank you bye bye [Music] [Music]

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

[Music] [Music]

[Music] [Music] [Music]

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

[Music] [Music] [Music] so

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

[Music] so [Music] [Music]

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

you

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