All Core Devs - Consensus #77

Transcript

Alex Stokes: test test test

Tim Beiko: we are good the audio is working sorry about that guys that was my fault

Alex Stokes: um yeah if you want to just that's okay yeah yeah i'll take good from here great cool okay thanks tim everyone let's see i'll uh repost this oh wait sorry it's lagging uh there we go okay i had the youtube open and it was um wait like this is okay we're good okay so everyone there are some technical difficulties but we're not going to kick off the uh the consensus layer call 77.

and let's see what is going on today the first thing i wanted to say was just to call out the aero glacier hard fork so this should go live next wednesday and it's important for everyone listening and everyone here to upgrade your e1 notes especially if you're validating so i'm sure you've i mean at least hopefully by now you've heard this many many times but uh very important that we all upgrade the next big thing would be updates to the consistent layer specs i was going to call these out really briefly and then we'll move to concergi so in terms of the consistent layer specs uh we have this new update 116 einer kerry and again we'll get into the merge stuff in a second

but it brings fortress updates uh definitely including this proposal score boosting which helps mitigate every org attack so that was really cool to see and i just wanted to give a quick shout out to the stanford team at david za's lab because they've been helping with a lot of the fortress analysis there and then from here i think we'll officially transition into the consuming office hours there's i think probably a lot to talk about today uh let's see yeah i'll just briefly touch on the specs and then we'll talk about devnets and updates there and then uh kind of move into a more open discussion i think mikhail had some stuff he wanted to talk about that we can get to in a second

oh i see okay sorry um right so uh so important here we have the version three of the specs that were just released uh number of things actually let me post a link in the chat but essentially each of these effects are mirroring uh devnets that we've been doing so it's very exciting to see the progress there there's a link to the spec and yeah so v3 uh number of things uh sorry updated this notion of a validation error so that basically uh when the execution layer doesn't like a block for some reason because this layer now like has a much clearer idea of like

what's going on or at least that air is now like a lot more expressive uh some minor updates to the eips both for the transition process itself and for how we're handling the random soft code so that's 3675 and 43.99 that consist themselves or upgraded 216 that i just mentioned a minute ago and then last we have the engine api that was updated to uh version 1 alpha 5. so uh lots of fun stuff there and we should have a devnet three for next week that's going to target those specs uh and we can probably talk about a bit more in a second before we move into devnites i did want to say

one more shout out to merge testing uh marius has been uh rallying the troops so thanks for that i think there's been a lot of inbound interest for testing which is super important and it's again just really exciting to see uh see that spin up yeah zoom claps okay so from here we can move to devnets uh we've had two devnets so far with the third one planned for next week uh devnet one i believe was broken again by marius i think he ran two minors i don't know if you wanted to give an update as to what happened there or if

anyone here on the call does so we already have three definitions i think we started with uh definite zero which was broken pretty quickly um and then we had definite one uh which was broken by uh mining two terminal difficult uh two blocks uh two sister blocks with the terminal total difficulty and half of the half of the consensus layer clients chose one block and the other half chose the other block and so it was not possible for the execution layer clients too

to to move to the other block and so i think the way i see it this is something that the consensus layer client should should take care of um and they also should have should implement some method to uh manually at least manually specify which uh which uh terminal like which block hash they want to be the terminal uh terminal proof of work block uh so that we can mitigate these issues easy uh more more easily right i think we'll definitely want to see uh you know test

nights with multiple miners uh especially as we get closer and closer to the merge but i think for now we're just uh ensuring there's only one minor per per transition is that right

Marius van der Wijden: so that's that's what we did for the third test net uh we i i like we had two miners running and i stopped mine uh right before the transition so that the transition will not be affected by it um but yeah we should uh we should like definitely uh talk about this at some point and and test this in the future

iris could you please repeat the case that you think the terminal block hash will be useful for

Marius van der Wijden: um if we so if we uh if we reached a terminal total difficulty on our node we will the consensus layer node will see okay this is this is the the terminal proof of work block and it would say okay please build um on top of this terminal uh proof work problem and the the the issue is that it splits the the consensus layer into groups one one group that builds on this one block and the other group that builds on the other block

and it is not possible for them for the consensus layer clients to switch the chain that they're working on or at least i don't know if this is like i'm i'm so from from what i see there's no way to tell the consensus layer client hey you should be following this chain and i think that would be the use case for the terminal proof of work hash would be to say hey we we just merged and we we all agree that this is the hash of the terminal uh proof of work

block now i can go to my to my node that is on a different chain and say no please take this terminal block another another another idea would be to not to not immediately build on top of the terminal proof-of-work block but to wait uh like a couple of seconds until the the execution layer stabilizes on one proof of workbook but um i think uh um that's uh uh that's just a hacky solution and we should

definitely uh create a way for the consensus layer client to pin a certain

block hash

Mikhail Kalinin: yeah but this you guys see so there are two terminal work blocks right and the first proposer the proposer of the merge transition block is about to pick the one right and if it's not if it's accepted by the network then everything is okay and the next block should be built on top of this merge transition block but if it's not accepted then the next proposer will try to produce an appropriate other one

merge transition block and that may you use it it may use another terminal block as well so it's not it should not be like should not cause any split in the um consensus yeah network so i'm just trying to understand uh why has this happened

Marius van der Wijden: um i see yeah

Mikhail Kalinin: yeah when we go oh my god we may go offline and discuss this

Marius van der Wijden: yeah yeah i i agree that it should it should not happen but it did so

yes some things wrong yeah yeah yeah then i would like to hear from consensus

and pronouncers what has happened but yeah let's better do this online

Parithosh Jayanthi: so you just create information that happened on that nx0 and the devnet is still running so if someone wants to do a postmodern slash figure out what actually happened um i can give you all the details and access if

you need it are you sure it was

Marius van der Wijden: zero i think it was one but we rescued it one we had the issue that there was a get bug the wrong eip

i thought we had no yeah sure

yeah

Parithosh Jayanthi: one was to get back and two had no issues

Alex Stokes: okay so either way uh the intention i think we all agree is that reworks in this sense should be possible and then right you end up with a finite finalization through the merge and that gives you you know the one chain so definitely something we should track down something we should test something to keep uh people keep it you know aware of and then perry you said that that two is

going well

Parithosh Jayanthi: uh yeah just to pick up on that thread um devnet who's going well we hit ttd um already two days ago i think um it switched to pos as expected we have random users making deposits i've been able to make deposits and get um other data's active so everything looks good there we seem to have a lot of people from from the testing effort using the chain now and so far nothing's broken so that's a good sign and i think also joined uh in proposing and attesting yesterday so we should have a higher participation rate so yeah everything's looking quite

good for my

standard

Marius van der Wijden: quick question did you change the the amount of clients of from each team between

definite definite

Parithosh Jayanthi: um what i've done is lighthouse gets majority so that we at least would finalize and everyone else gets uh equal amounts so i think currently it's five percent each or something like that i can send you the transmitter but i'd like to slowly take that away right now we're getting that security that there's one stable base but in

maybe already in the next step i won't have a majority client and just do um two clients that are majority together or something like that

Marius van der Wijden: i also managed to get all five consensus layers and working together with uh uh gas on on on validating uh like on following the chain and um so so we're pretty good and on that side

Parithosh Jayanthi: yeah i don't see any big blocker and just having everyone only run an equal number of validators right now like

it should work

yeah it's nice to see tech and death has been working well since we've got that configuration sorted this morning um i haven't been able to revive techyou near the mine particularly sending an execution payload which is from the canonical train it should be valid and that of mine keeps saying it's invalid but i'm not quite sure why i need to up some hogs or something get their actual responses i guess i will

Marek Moraczyński: take a look we can uh talk about it after the call

uh i will probably be asleep i recall it's midnight here but um if you can take a look during your day i'll pick up on it

Alex Stokes: um cool so thanks everyone um yeah and then

just looking forward the intention and i think perry is the main driver here so harry would happen if uh if something's changed but i believe the intentions have done that three uh for next week which will target version three the specs i mentioned uh incorporating the learnings from all the previous test nets and um yeah maybe we'll change the value distribution and uh move closer and closer to consugee which speaking of uh that would be the next test that planned would be the week after on the 14th and uh yeah that one would be this longer standing public test that's uh hopefully more stable than the deadnet so far and um yeah a great opportunity for us

to demonstrate merge readiness so everyone uh i'm sure is looking forward to that uh from here we could do uh client updates if anyone from the client's team sorry business team our execution team wants to uh give a short update we could do kind of a round robin thing there might not be anything beyond what we've discussed previously so no pressure

Marek Moraczyński: okay so nevermind our devops team is working on the document which describe

how to run different combination of clients with nadermite we are cleaning up our cloud and doing some fixes uh we need to investigate uh issue with tecu and i think the same is with nimbus and we are gonna adjust another mine to the new version of insurgency spec in meantime we are also testing our mev plugin uh with the merge it will require some fixes from us and yeah that is everything from us

Alex Stokes: thanks uh and that actually does bring out an important point everyone here like please please please

document how to run your respective clients on these test nets because uh yeah the intention with kinsuki is i think to get more community involvement and so uh you know if you need to go to like a particular branch and like have a you know different sort of command line interface and all of this that's fine uh but docs will help that pass us along

Adrian Manning: yes i guess that's a point for lighthouse today we had all of our code in a separate kenzugi branch today we merged it down into our unstable branch um in probably like a week or two we're planning on doing a a proper release so consumers should be into our into our stable crash so at the moment um all of the merge code is in unstable which is a

small change

Alex Stokes: great any other client updates uh just give everyone a few seconds but otherwise we could hop into uh more open discussion uh mikhail you had uh some questions here would it be a good time to discuss those

i'm

Mikhail Kalinin: sure if there are no more client updates we can go through these items quickly

Alex Stokes: sounds like we're good

Mikhail Kalinin: okay yeah so the first thing to this proposal um to add get block bodies or let's say get payload bodies to engine api um it allows for pruning or offloading and transactions from from execution payloads on the cl side and request them at hog um on demand from the execution left side it's pretty cheap to do it yeah so the basic idea is to just uh send

a list of ha a list of block hashes and due to execution via client and it will respond with a list of transactions in the format which is used by consensus layer to store those transactions so this is basically the idea and uh to utilize this method to consistently clients will have to um like when for for instance serving blocks over the network they will have to get a bunch of pixels then iterate through all these beacon blocks and grab block

hashes from the execution payload structure send it to the executioner client get back with transactions then like add these transactions uh to replace the transaction route with the actual transactions in the execution payload uh structure and uh yeah sir send this back to the peer determinate that has requested this this big blocks so that's the idea and my question my main question is um like does this beneficial this particular implementation of pruning um

does this beneficial for consistently clients if it does then i will open the pr um next week so if it's not um so it doesn't make sense to do anything and yes and also uh for instance yatzek had a concern uh that if like we use block hashes then the execution layer um will not be able to use uh some optimizations like if blocks are stored linearly so it will be much less intensive in terms of disk accesses to

request to to query blocks from execution layer by block numbers um so this was one of the concerns which is in the thread so you can see it and yeah why it's why it's proposed to be done this way is because these um methods in engine api the logic is basically very well mapped maps on the existing get blocked bodies uh methods uh in the eth sub protocol so if you have any concerns and you don't think that it's beneficial just to chime in and

drop yeah and like say this uh in the discussion thread otherwise i will just open if you are yeah anything to discuss here right now

probably has

sorry i haven't seen the issue but has there been thought put into what the consensus like client do if it's el is offline and blocks are requested over the network so an rpc request comes in because that's kind of a new way that you don't have block bodies available anymore

and can't service those rpc requests which would normally get you disconnected and then

Mikhail Kalinin: right so it will mean that you don't have blocks that you have been announced right like you

have announced that you're you you're at slot yes see yeah i mean

you are at fault so it's not the end of the world but right i don't know

just

Mikhail Kalinin: yeah so if if your el is offline you probably will have more silver issues then this one

yeah that's that's true um it just means that you'll be likely to lose beers and possibly get banned for a period it makes it hard to recover when it comes back

i don't think it shows over there

Mikhail Kalinin: okay so yeah any any opinions yeah just welcome to this issue let's continue there okay the next the next item is the uh is about optimistic sync the question is what should validator what should not or should validator do um when the optimistic sync is in progress so the particular thing is a test and

should validator a test uh while the sync the optimistic sync is in progress and it's not yet finished uh like imagine the case when yeah the optimistic had yeah there is the optimistic ad and everybody is voting for it and you can receive receive and process those attestations and hope change works well uh but uh he have also be like fully verified head uh which is um um the block uh from the canonical chain um the the latest the most recent block from the canonical chain that you have

verified the execution for um and like say optimistic has ten blocks after this one so what to do here uh can the equality should be validator attached to a fully verified block or should or should not attach to it there are a couple of like related issues to this problem because there is also an edge case during the transition but in general i think that a testing in this case shouldn't be done because this fully verified head is by ace is dictated by the optimistic head the validity of which is not yet proved

so um yeah i just wanted to highlight the thing and um let me drop the issue here everyone is welcome to comment as well on it so this one like one of the tricky questions um if people have any wrong opinion let's discuss it now here

Alex Stokes: it feels like to me validators should wait until they're fully synced otherwise it kind of opens the door to this almost like laser valida lazy validator setting where

you're just kind of almost blindly signing and you don't quite know uh what what actually is going on and it also um yeah it would let you have a node that isn't fully synced with respect to execution layer and that's definitely not what we want so my gut says to forbid this

Mikhail Kalinin: yeah yeah i i think that first wallets um if if the block is fully verified it might make sense to test it it contributes to the casper ffg rules probably but in my opinion it can open some it can

increase in attacking surface not sure that any disaster can happen before there's the test to uh while the optimistic sink is still in progress but this is definitely a change of the status quo and yeah if we if we do this change we will need to reason about it how does it affect the security and blindness safety and blindness so this is my gut okay if no no nobody wants to share um that let's move to the last one to the

last one the last item um this is the yeah i'll drop an issue here this is the edge case scenario um around the transition and let me just try to give a context on it so suppose the um there is the first the merge transition block uh appeared in the network and it signifies some terminal block so some some specific terminal block and yeah it's been this transition block has been created and sent to the network but eventually it's been it has been not accepted by the

network participant for some reason so it it hasn't become the head of the chain and another proposer um like say that it it proposes on top of the uh parent of this transition block and like it may propose like a block with an empty payload which will be like a legal case so um and then uh yeah the issue here is that part of the um of the nodes can receive this transition block and switch their functions rule

to to the proof of stakeholders so the functions rule of execution that client the proof of stakeholders rule and the question actually um whether do we want to like revert the switch if the next block after the emerge transition block is coming with the empty payload so this is very much of an edge case and i think that we should not do anything so uh once the proof of once the foxtrot's rule has switched it should stay there the implication of doing it of doing nothing in this case is that some proposer picks the terminal proof of work block and it like kind of

dictates this terminal before block by sending this immersion position block and other nodes that have processed this first transition block will just um uh say that uh well we'll just set their terminal block to a specific walk that has been picked by this proposer i'm not sure that if this like really clear explanation so yeah yeah just go to this issue and probably read the thread for a better understanding of the context and about to close this issue like uh early

next week um if nothing will happen so it will just stay the logic will stay as this now currently in this

pack

Alex Stokes: yeah that's all i have thanks for listening today yeah thanks i'll have to look at this specific issue and get caught up to speed uh it seems like we don't want to kind of roll back uh going from proof of stake to her pork choice uh with i guess the only caveat being if there is a reorg around the transition point but um yeah i'll take a look and anyone else who's interested on a call should do the

same okay i think that might be everything i had on the list for kinsuki is there anything else uh anyone else would like to discuss bring up talk about while we're here anything with devnets or the

longer-standing test net

Dustin Brody: yeah i'm uh interested in sort of aspects of actually optimistic sync and so i've been looking at

the the current i don't know specifications such as they are kind of mix a specific implementation of a goal with uh various ways of achieving that or with a specific or with the goal itself with a broader goal so the the broader goal of separating the el from the cl head you know granted um the specific optimistic sync homepage and the network of hack empty pages around it discuss a really specific implementation and the kazuki specs um are written to mandate that specific implementation um and and to give a specific example of what i mean

the yeah okay link here we want this is just one of the and the implement that it gives eight implementation requirements of which the first four um are pretty i would say broadly apply to anything that can call itself um optimistic sync the last four are really specific to uh um one approach to implementing optimistic sync this wouldn't be a problem except that the optimistic sync documents all combine this several aspects how to implement that specific um version uh approach um the what is the sort of an explanatory aspect of what

the purpose of logic's optimistic sync is what is the design space of optimistic sync some discussion that was just had about can you attest based on an optimistic cat what are the useful points in the design space what are and what is useful or or reasonable to require in the spec and so those are and those are all kind of semi randomly intermixed and so what i would be what i would like to see i guess as an outcome is force up as can moves to being a little bit more finalized uh you know to contribute this back to the merge spec to the um uh for this to be separated out a little

bit more queenly um so that there's a specification so that there's extended stand it won't explanatory part um there's a what does a spec require uh in a way that is a little bit more separate or independent of implementation and sure if one wants to implement a specific type of optimistic sync well what what are some hazards one might look for so that that's what i'd like to see

Alex Stokes: okay yeah i hear that that makes sense um i think paul wrote this document and i don't think he's here today but yeah especially if we uh upstream this

to the 2d specs or any uh you know further merge stacks we can definitely keep that in mind and yeah if you see something in the future i'm sure car would be greatly appreciated if you see a

weight champion all right

Dustin Brody: um and so i have one final point uh related to this and and to motivate this a little bit and like why should one care potentially about like um this aside from sort of in principle the aesthetics of specifications um is that there's 1.5 in this uh list that i linked um add the ability to loudly explode if a finalized block has an invalid execution payload and elsewhere talks

about this kind of situation requiring a social consensus and the like well that's a specific artifact of that particular sort of uh optimistic sync where the chain itself where you fully import a block one can talk about an optimistic sync where the fork choice is allowed to run ahead but the justification and finalization and spec terms is not in the same way um and so just as as one example and that would sidestep the particular hazard there by it would simply never finalize on those blocks so

it couldn't happen um so yeah that that's

Alex Stokes: okay yeah i guess i'm a little confused because i feel like as you like the fork choice is rooted in finality and then by justification and so i feel like as you're processing the chain that you receive you would always see that um but yeah maybe i just didn't follow what you're saying

Dustin Brody: okay yeah sorry it was not super clear then okay so the notion of having the notion of of

one can okay how maybe put it this way one can imagine an optimistic sync implementation which does not ever fully trust um in its most that only in some sense fully finalize this um uh in in the sense that it's going to that ever would have to be roll back rolled back or could ever interfere um a verified block um if i'm not saying as well i'll and you know reconsider and how to articulate this but um for at another point but essentially this assumes that you kind

of mix kind of fully trusted and not fully trusted walks um and that the client really commits at any in any real way to not fully what's it called verified blocks and there's no strong reason for that to happen but i can tell

Alex Stokes: right okay yeah i mean i'm happy to keep chatting uh but perhaps we should take it offline just uh to respect everyone's time here yeah and um yeah but definitely i think uh you know i think we all strive for aesthetics and specs i do think aesthetics are important um and yeah if we can refine this and separate the lawyers very cleanly i think that's a great idea

Mikhail Kalinin: yeah i would like also to add that we

work on the optimistic things back is in progress so it should be like the minimal set of requirements um for uh for cl to here to be to to do it in a safe way so it's basically yeah gonna be based on the ideas of from this document that you have that dustin has just here is written by paul

Alex Stokes: great uh charlotte i saw you have a link here to talk about issue

where to go uh 4 30 000 pm okay so right if we want a b star name should we uh open up this conversation right now

uh yes um so let me send you the link to follow up our previous discussions about

Marius van der Wijden: sorry um can we i have one quick topic before we go back chatting about about naming the merge if that's not sure yeah yeah is that okay shall we yes of course okay

sorry um uh one thing that i that i noticed uh is right now when i when i switch between clients with the same consensus layer with the same execution layer all the clients actually try to import all the blocks again and i think that that's something that will change with uh with optimistic sync i just want to make sure that that if you guys build optimistic sync you should also test just

uh not only optimistic syncing from from like the beginning but also from like an existing uh so you shut down your note and you you re-run the same execution the same consensus player client after one hour or something and also you you have a have a pair execution layer consensusly shut down the consensus layer client and you start up a different consensus layer clients client and i think that that should be something that uh that we should really look at to make sure that this use case is uh sufficiently supported

Mikhail Kalinin: yeah there is by the way i think it's

fine because he consists the client doesn't know uh the state of the exhibition their client like if it's uh closer to the head of the chain the executioner client because this is likely while because this recline is not so it will just keep seeing and then sending all the same blocks if the if this is the case you have described so i think it's okay

the

Marius van der Wijden: the problem is that like if you if you import i don't know like a a day worth of blocks that is like i don't know 50 minutes of of uh replaying blocks

um yeah but you because this this should a

client will just quickly respond with uh or well let's just quickly respond with valid if the clock has been verified before and as well or will it execute it once again

Marius van der Wijden: right now i think we executed again and um like i'm pretty sure there was something where we where we did this i can i can't quite uh quite get it i think it's because you have like

different blocks with the same state route um but we could just cache the the number to hash in the database and see if if we already have this block at this block height and then not execute it

Mikhail Kalinin: yeah see yeah it's really complicated anyway this is like why i'm doing this if it does not have uh the same head like if it's behind the l i think it's it's fine

Alex Stokes: and okay okay

yeah so very nice uh proto displaced in the chat that some cl clients don't persist the unfinalized part of the chain so you could be seeing that

Marius van der Wijden: yeah but what i saw was was more it was more than the last uh last six four four blocks it was it was more like i don't know since since i like shut down the note and then

Alex Stokes: right yeah okay uh and i assume that there's some way an engineering api to communicate with us or there will be eventually right

Marius van der Wijden: i'm i'm not sure what do you mean

Alex Stokes: oh just uh how to communicate uh to the cl like what the state of things

is

Marius van der Wijden: the steeler can always ask for for for a current block or something to see see uh see what our current head is but um like it it cannot do that for non for non uh non non-canonical blocks so for example if we like if we if we start syncing we we just shove the the blocks into the database and don't don't actually set the head and so they

are not non-canonical once we get uh um the the the thing from the the set from the uh from the consensus layer the focus is updated from the consensus layer we actually set the head and and have to stay for that well it it it doesn't matter i think it's it's all right

okay

Alex Stokes: yeah either way sounds like something to keep track of okay i guess i'll uh ask if then if we

want to move to uh any other client updates or final updates uh and then yeah we could jump back into uh the naming of the fork if no one has anything else

Hsiao-Wei Wang: um so it's not a client update it's a consensus spec updates so there's a fix to the uh proposal boost score and it was here that's so um there was a

plug that uh in the calculation of the proposal was score and thanks to it was shiny from lighthouse they found this blog and we will include this will address this issue in the next release next consensus fake release yeah

Alex Stokes: great so yeah that would be important for everyone to keep track of but it sounds like it won't be uh deployed for some time any of us have any other updates

um this is not an update i just mentioned that um we would like to continue uh increasing the number of metrics that are standard across our clients uh so we start with eight metrics and most of them are already implemented um you know clients so there are a couple of them missing but uh we're gonna move on with the next set um so we will be communicating with you uh guys to continue this standardization effort

okay

Alex Stokes: great thanks anyone else

[Music]

Tim Beiko: um i have just a quick shout out but next week uh we're gonna have an mev call with regards to uh basically how to implement that on the consensus layer clients uh the flashbots team has been working with uh lighthouse to get it set up and so uh yeah basically we're just gonna have a breakout room call where uh we go over kind of the spec and and what's been implemented so far and and get feedback from the other consensus layer teams it's a week from now at 20 utc uh to accommodate australian time zones a bit better a bit late for europe uh apologies but yeah it would just be

great to have representatives from the different cl teams at that call and i posted the link in the in the chat

Alex Stokes: great thanks em yeah everyone uh please try to send the representatives from your clients if possible i think it's all uh oh yeah i would hope you all agree it's very important that uh we treat the zombie issue very carefully and a lot of the work that flash must have been doing um you know is coming down to this path for the merch so uh definitely important to attend if you can

and on a similar note uh i have a couple

of announcements with this merged um we are planning to organize a plea with the shen proto on december 15th at 1830 utc and which i am assuming that they will be explaining about merged has net setup so that's one for people who are interested to participate in this merch chestnut and the another one is with mikhail kalanine on december 21 at 1400 utc that is for eighty four three nine nine uh supplement difficulty of course that's random so if people are interested anyone uh ended up please

join us thank you

Alex Stokes: cool thanks vijay yeah this should both be very exciting and then just to call it out uh trent posted a link to merge community call tomorrow uh 1400 utc so a lot going on everyone has lots of calls uh you know you can see we're all getting very ready for the merch okay final call and then we'll jump into

uh engineering

shall we do you want to take over

Hsiao-Wei Wang: uh yes thanks alex and repost the issue again on the chat so just to follow up with our previous discussions about the naming for the merge hard work i opened these issues to propose what we can do for the next steps so the i think the rough consensus we have is that like we are going to then seal upgrades with the science things and

it's still a bit uh uncertain about if uh the the el client updates will go with uh the ctnes or statness or maybe others but uh so this proposal is that we if we can at least choose one starting we will starting with b since the last uh upgrades it was out there so this time we start with b so the action proposal is that um

maybe we can start to nominate some science candidates uh in this trade and then the deadline will be like december um 13th it's it's just for example and then we can choose the top four popular names and then if we want to um have small involvements around community we can have another vote election that we had one for the other naming us election

that last time or option two is that if we want to make decisions as soon as possible then maybe we can have another discussion in the call two weeks later it will be december 16th so this is my proposal any feedback suggestion absolute opinions and welcome to national thanks everyone um yep so i wish we can maybe

have um some decision about number one if we are going to vote uh we are going to propose with resigning for okay for the ceo clients and number two is that uh how will the election uh what will be the formula of the election like we just discuss in the connex in the next call or go community world there are two things i wish we can discuss today thanks

Alex Stokes: thank you um yeah i think what your outline makes a lot of sense uh personally i would say yeah we can collect ideas in this thread

in the issue that you posted and yeah either it'll be obvious which is the most popular or we can decide again well we'll decide for the first time but on the next uh let's see how it gets the next maybe the cl called two weeks from now

Tim Beiko: either that or we can maybe if if it does feel like we need a call to discuss maybe you have like a separate breakout room to not take up half these calls with it and also to just like be more inviting to folks who might not join like these calls i don't know i don't have a strong opinion but i think if if we do need an hour to discuss just like trying to isolate it

and having like a special purpose call might make sense

Alex Stokes: yeah that makes a lot of sense i would hope that we can do most of the back and forth asynchronous so perhaps to get started maybe we'll just uh start in the issue and uh we can just sort of coordinate asynchronously if it looks like there's a bunch of contention and we need a call for that then i'm happy to organize one and yeah i think the breakout format makes a lot of sense

Hsiao-Wei Wang: yeah i agree that um things think that the breakout room ideas make sense

Alex Stokes: okay

any final or closing thoughts anything anyone has been dying to bring up and hasn't yet otherwise we can go ahead and wrap up early

Tim Beiko: thanks alex for running this

Alex Stokes: you're welcome

bye [Music]

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

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

[Music] so [Music] [Music]

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

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

you

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