All Core Devs - Consensus #75

Transcript

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

all right stream should be transferred over if you are on youtube let us know in the chat that you can hear us thank you yeah okay so um just quick order business beginning

Danny Ryan: uh we made a commitment to deprecating the 200 pm repo by mid november uh so the issues are now going to be tracked there i still need to do some cleanup on where notes and things live but you know the merge stuff has moved over there and consensus layer stuff is now moving over there so we can kind of track all of our breakout calls and things in one place nothing crazy there and if you're not muted

and not speaking please okay so uh kintsugi um this was an effort that kind of spun out from the amphora interop uh with the plan to finish there were many minor spec changes that came out of discussions at the m4 in person interop and um we did a sprint to finish those spec changes and now the plan after that was to hit it hard in november with the target of a persistent test net definitely approaching more production grade quality engineering at the end of

this month the end of this month means probably something more like december 1st or 2nd for the launch of that testnet and perry is going to be helping us with that and helping us weekly when we do get some people hitting some of those first milestones doing a weekly devnet build so we have released the stock kimitsugi thank you tem for the excellent name here um here is the dock i'm sure it looks like a lot of people have already seen this um and at the bottom we note that both the consensus layer call and the awkward ev's call which i might call the execution layer call um

will the first 30 to 45 minutes of each call will be dedicated to more of a cross layer office hours stand up discussion uh just to make sure we're we're touching base and and identifying any issues and and sharing information along the way so that's what we're going to do this morning i invite both folks from the execution layer to this call and i invite folks from the consensus layer to the uh all quadrants call on the opposite week we will let's see i think we'll do like a little bit of a quick stand up kind of like we did in amphora um doesn't have to be too deep but and i know not everyone has begun

but uh just a quick round if you are on the call and you're on a client team and uh there's any update with respect to kinsuki we'll we'll kind of run through that and then we'll open it up for questions and discussion i know there has been a lot of discussion on discord already and i will note that we do expect especially in this especially in this first week for some minor changes to land in the specs it will make it abundantly clear that that is happening and through the month we expect less and less of that although there's always a chance that there is a minor change between a devnet build weekly any questions about

anything at a high level uh what we're kind of planning to do this next month or how things may proceed okay cool so let's do uh let's do a quick round on uh where people are out on kinsugi i know it's just been out for a couple days uh but if you have opened it up and begun uh give us a quick update

i can stop excellent um so yeah

Marius van der Wijden: for guests uh

we started or i started implementing the spec um it was it was finished and then uh the the api changed a bit again um so i haven't um haven't done that yet um but i'm going to change the pr to reflect the correct spec today and i also updated the test vectors again they are not up to the newest spec but like only the fortress updated method changed a bit in the newest version

um so it's a good starting point for anyone looking into implementing this um just to make sure that like you have the basic format right i'm not sure if the format is correct uh anyway so it would be cool to double check with with other with other club teams that's it

Danny Ryan: great and i will note that the engine api spec changed out from under your feet because of the changes you requested

um next

Marek Moraczyński: so in nethermine we have just started implementation of the spec so i hope we will deliver it very very soon yeah that is short update from

nethermite

Adrian Sutton: for teku we uh a little caught on the back foot we were merging all the m4a stuff over to master and getting that production ready and then somebody dropped a new release and said we're doing test nets um uh so we're we're gonna try and do both and get it all into master and be ready for the first ever net the updated spec on master excellent toggled off obviously so it's good good code uh not as happy as empora was uh but obviously you know uh exactly production ready

Danny Ryan: yeah i apologize for any any failures in communication here i think those at the event were very aware and maybe we had mentioned on some calls that this was the plan but it

did not make it very clear so i i apologize if we caught anyone off guard on there

Adrian Sutton: uh no it's it's not a problem i think um i think it's the right way to go for us anyway to be honest even if we even if i was more aware of it um so it's all good

Terence Tsao: um yeah i can go next so for prism we are yeah short and sweet we're aligning the consensus spec we are aligning to the new api post so hopefully you worry those times soon

Mehdi Zerouali: yeah same for lighthouse uh we just started the work on kitsugi we have a pr open that documents our progress so it's uh pr 2768 uh still early days for us we're not at

m1 yet but uh yeah not much to report apart from uh the fact that paul's been working on a production-ready optimistic sync implementation for lighthouse he's going to document his findings as usual and he'll be sharing that with you all shortly uh he's also looking at how to structure the beacon node and valley decline api for giving i guess early notice of block proposals same here he'll update everyone on his progress

Adrian Sutton: yeah that's probably one of the big things to address is updating the standard apis particularly the ones that validators need so i did see that ticket um in the lighthouse repo that's quite useful um i need to digest it a little better and

get to that point but um getting some of that stuff into the actual standard api repo with proposals of what things look like could be really good

at some point yeah i think that's his plan anyone else yeah

Saulius Grigaitis: so we started to work on tests and most of the tests for merges is passing but we for blending that we are missing um missing the integration with the execution layer code but i think yeah this will be done in a week or two

so which team are you on

thank you and

Danny Ryan: any other updates

well

Mamy Ratsimbazafy: for uh nimbus we are always keeping track of the spec and for kimsugi specifically we have a call in two hours for monthly planning so this will be

a high priority lordstar we created the issue today uh hopefully i'll put some resources and work on it next week excellent cool

um okay sorry if that's off

Marius van der Wijden: of the clients uh i would like to talk quickly about something that that's happening in geth um so we haven't yet merged the changes from uh from from emporer to master and so we also cannot like i would want to get those changes in first and then get the uh the kid to be changes in a second and then we also need to update um we also don't have the reverse header sync in in master so we have like three open pr's that need to be uh

merged and until then we cannot have a working test net from our site um so there's still even though like i've implemented the spec there's some dependencies because it's not uh it doesn't have any syncing in it yet so for the for the um for the interrupt we hacked something together but we don't want to do this and so yeah it might take another week for us to create a client that is can actually sync

Danny Ryan: makes sense and that's one of the things

i want to talk about was when we're when we have at least i think one client on each side of the aisle uh we do want to begin to do these weekly devnet builds but um my current intuition is that that is not one week from now but maybe two weeks from now on that thursday um does that seem reasonable is anybody eager and thinks that they we might might be doing a devnet build in one week okay cool so that's we will skip the 11th and target the 18th and plan on doing

the 18th and the 25th we'll do a devnet build and and bring in more clients as already and then that following week assuming things are going well target that that persistent testnet are there other i know it's early i know uh people have just begun to look at the spec changes there has been some chatter on discord are there things that people would like to discuss synchronously are there questions with respect to anything uh in specs just open time for discussion

yeah i guess i've had a question regarding um how is

Terence Tsao: everyone feeling about testing this thing because like testing in production doesn't sound all that nice right but this is not something you can also skype test so i think like using merge mods the the two that proto and like i am right would be nice so i just want to ask what's the progress on that

Danny Ryan: so another tool at our disposal is definitely hive um and there are some members of this call and others that are are looking into it but yeah like client do you want to give us an update on merge

mod

Lightclient: yeah i'm currently implementing the

latest engine api spec on merge mock that's should be done the next day or two and then like the longer term goal of the next week or two is to have um a way of accepting like test vectors that are statically generated into merge mock so that we can all kind of run the same sorts of tests rather than what it's doing now which is just sort of generating random valid message calls and then you should be able to just use that to test either your execution client or your consensus client

awesome

Danny Ryan: does anyone want to give an update on on a hive there were quite a bit there were some discussions at the in-person

event on strategy here i know that i don't think we've dug into those strategies but do you want to discuss what the high level plans are here

Diederik Loerakker: i can give a summary of where we're currently at five there's this one pr open that introduces evm2 clients into hive i think this is just a prerequisite before we can look at the merge at all we need some kind of base to introduce ephem2 or these beacon clients i should say the consensus layer then after that we ended and if that's stable then we can replicate that but then instead of

running the phase zero or alter fork we can run the merge fork and with the merge we change this connection to the exclusion layer so there's the slight change in configuration but otherwise it's the same setup and it does spin up the whole thing so boot nodes ethereum one and theorem two and then after that once we have this general testnet like simulator working we should look at the the next type of test where it tries to do something more interesting something less common

Danny Ryan: although

testing hive etc doesn't get it's not as exciting as some other stuff i i do think that testing is probably could be essentially the long tail here so um if someone on your team wants to dig in that be very very valuable

Marius van der Wijden: so i i also started um [Music] fuzzing um [Music] the so i created a fuzzer for the execution layer engines and i started fuzzing gas against bisou and found some differences already and so yeah i'm going to also continue

working on that next to hive and i also have a tool for sending uh fast transactions um to uh to the to the actual test nets so once the test nets go up we can create fast transactions

Danny Ryan: got it and there are consensus layer vectors um as usual but there's probably uh some some spots will shore up in the next couple of weeks and and maybe get an iterative testing release out um and the plan i'm sure is to integrate

merge builds into the the beacon buzz infrastructure when the time comes and then on the execution layer side um there are certainly a series of vectors we do need to create around this random op code and some of the other things so that and then integrating into the normal fuzzing infrastructure what's the normal path on getting the execution layer evm style vectors written

Marius van der Wijden: so we have a test team for the ethereum test team that is working on the on the evm

test vectors so we can just ask them to create some for these new codes the problem is that um the the infrastructure is very much based on on uh and the current the current way it works and so i think they need to put a lot of time into making sure that testing works post

much okay

Lightclient: how are you expecting that clients should import these vectors because like today you're kind of using this import sub command that's just taking in rlp blocks but after the merge if you want to test

things from the consensus layer as well and you need to have some sort of directives for the engine api is that something that would also be supported by the import

subcommand

Marius van der Wijden: i'm not sure

Danny Ryan: um does the import subcommand actually need anything from the consensus layer or essentially just these inner blocks these payloads

Lightclient: i guess i'm not sure how it would deal with a fork because like if i give it two chains that are the same length it doesn't really know anything about okay what's the canonical head

Danny Ryan: i didn't know if those test vectors

dealt with you know a block tree rather than just a chain but they do

Lightclient: yeah i think that the blockchain test just supports sending like whatever rlp blocks and you can submit a treat if you want

okay but i don't

Marius van der Wijden: i don't think that those are the important ones the i think the important ones like for testing the um the the avm random op code is is just the the general state tests and those are just basically just a transaction and

this can be applied pretty easily

Danny Ryan: and similarly there's going to be some like some that we probably want to see rejection due to non-zero values and headers and things uh but those should be the pretty standard uh as well right marius

Marius van der Wijden: yes so as long as you have like i don't know i get you give it a block that is invalid then it should be rejected this is pretty easy but yeah i'm not i'm not sure if we can

Lightclient: if you give a valid block will the rpc update without the engine command because i like wondering if like if hive if i'm asking is this block in the

canonical chain meaning it was like accepted and valid it may not return because it may just be waiting around for like for

choice updated um so you can uh you can set up

Marius van der Wijden: uh if you if you set up hive with a chain that is that is available or like it doesn't even need to be valid then you can query for the chain um but right now you cannot really add a block to the chain well you could maybe but like this this is something that needs like there needs to be some some more stuff implemented there to enable it in the tests

Danny Ryan: i think at a bare minimum maybe in the

next few days we can create a spreadsheet with the vectors that we do want to get in like the the standard kind of pass fail vectors um and then figure out how to integrate those

soon i

Marius van der Wijden: i also started when i when i worked on getting everything merged to master i already started a document with like things that i think are dangerous and that we should test for and i'm i'm going to share this document uh in [Music] in the intro in the interrupt channel and so if anything like it's just a general uh collection of everything that

i think is is is going to be it's difficult or something that we should test for and if you have anything to add to that then just please edit and in the end we can go through all of them and like make test cases out of this or check that this is something that cannot happen in the code

and um i will discuss a non-list that the long el client testing or everything

Mikhail Kalinin: like including hive and complex scenarios within communication between the layers as well i mean those uh various those like test cases that you have just mentioned are

there for standalone testing or should the cl also be involved

um right now like

Marius van der Wijden: right now it was just a brain dump during uh during implementation um so that i like i like those are the things that i thought about during implementation that could maybe go wrong and and so uh i'm not sh like it probably needs some stuff on the consensus layer as well i'm not sure

i mean my

Danny Ryan: my gut is to test things separately on layers where where possible and where it makes sense so for example like

to reject reject a block with uncles you know that's an execution layer test um whereas certainly integration style testing and more complex scenarios we want to hoist and to hive in other places

Mikhail Kalinin: right but rejecting this kind of block um should be done through execute payload right it should not be in general um like i mean the execute payload triggers a different code branch than the usual processing in in the fork network

Danny Ryan: right but i mean whether it's

via execute payload or essentially if you're importing a block in your post merge functionality so you know if some conditionals is hit then that should be validated as such

right

Mikhail Kalinin: yeah okay so it it needs to be discussed how to design this kind of tests i mean like real clients support really all clients support this kind of flag that they are operating in the proof of proof stake environment and then every input block will mean that it happens um but here in the rules in the eip 3675 were or not

probably it's easier for doing it that way then we can keep the like implementation of the is the tests testing that test the implementation of the ap separately from the engine api which would be good i guess

i agree i mean

Jacek Sieka: one way that this kind of performance testing is done is through a marking setup because we'll end up with very very many combinations of different clients right i guess um

one potential test setup is that we have like a dedicated tester because everything is through apis and you should be able to validate that a client gives correct responses and does the right thing in response to certain being prodded the right way through an api

Danny Ryan: yeah i agree which maybe mergemock is angling in that direction to be such a tool

Jacek Sieka: yeah right and that would sit like in the right in the middle of the star of testing instead of making a mess of

testing we make a star of testing with this thing in the middle

Danny Ryan: right there's probably still value in on some sort of nightly or weekly build actually test literal client combinations you know with our nice n squared star mesh not star

Jacek Sieka: yeah but this middle tool is very helpful during development

i

Danny Ryan: agreed i agreed very much other testing

stuff people want to discuss we are at the half hour i'm happy to i mean we can take this as long as we want other kintsugi related items we'd like to discuss today okay uh the merge interrupt channel on discord is i believe where a lot of the pretty active discussion around the finer details here will happen so make

sure you keep an eye on that one a week from tomorrow the awkwardness call will also have the opening be related dedicated to kinsugi if it ends up being valuable and we want to schedule you know call in between those calls um maybe something like super informal just hop in the chat uh on discord um we can do so i guess just holler if you're hitting a wall or have some things we want to discuss and we can uh maybe hop in on tuesday or something but for now we'll plan on at least doing the weekly anything else related to kinsuke before we move on

Saulius Grigaitis: yes quick notes there was this pr merged

this morning with updated fork just updated will this be canonical for kinsuki right now or how do we approach those

Danny Ryan: yes i mentioned at the beginning of the call i think especially in this first week we might see some minor updates based on discussions make it in and we'll make that very clear especially because we don't have the um the first devnet is until two weeks from now we do expect maybe between now and tuesday wednesday to see a couple of minor iterations we'll make that very clear uh and as we're approaching devnets uh make sure testing is in line with the releases and that the releases are very very well known

can

Marius van der Wijden: can we have some at least some internal version number or something so that we know that if someone like just updated their code and then something new comes up then that they need to update again

so essentially version the kinzuki mega meta spec

Marius van der Wijden: yes because it was like i i implemented everything uh two days ago and then the uh payload id changed from 8-bit to 32-bit i had to apply and i didn't actually see that and um and now the project's updated so i need to update my code twice

Danny Ryan: to be fair you up you implemented before this was even

released so the eight the 32 byte was always in the in the original release but yes we're going to try to do this not a lot uh i i mean we're generally in like a reasonable place i think a lot of the decisions were made at the m4 interop and i don't expect big things to be changed uh but yes we'll try to not pull the rug out from under your feet and to make it very very clear uh what's going on here and and we can call what is the update that will likely come out tomorrow you know kinsu give you two um to make it better for internal versioning

Lightclient: so are you saying that we're going to

want to have another release of the engine api with this pr or are you wanting to wait a week

no no um i would i

Danny Ryan: i don't expect a lot of changes to come and so i do want to just kind of get them out pretty quickly um okay so clients right now should be like getting ready to do it with the new pr and not with the hashing of the payload correct correct okay again i'd like to anything that we do want to get changed do it very quickly so that we can quickly conform on something and not worry about version changes anymore

well

Jacek Sieka: for a sync in particular we discussed

an addition of block export so that the beacon blocks by range request can be implemented in the consensus layer right and that's something that would be nice to get in that case

Danny Ryan: i agree um i see that as at least um barring the beacon blocks by range not having execution payloads um if if that change ended up the deduplication across layers is a bit more additive so um i would like to open up that conversation but i think we can get the core done without that

right

Mikhail Kalinin: there is definitely just things to

discuss um because it could be a couple of approaches that could work

yeah we can prioritize trying to because

Danny Ryan: we did take notes about this conversation and [Music] my cat is scratching me sorry get a dog apologize they unplugged my headphones as well um we did take notes on on some design options uh with respect to deduplication of execution payloads across the layers and calls to get them back so let's surface those this coming week and try to get a plan of action done

Diederik Loerakker: is their intention to run like all the combinations of of execution and client and consensus they are clients on a test net or this is like just one combo from from each team

Danny Ryan: the goal would be to run all combinations all stable combinations i believe are run on the amphora and pithos test notes um and with the automation tooling that perry proto and others have been working on um it is not too insane to to do those to make sure all the combinations are represented

Saulius Grigaitis: okay and this this automation tooling

was mainly done not by client teams

Danny Ryan: correct i believe you can you can fill in the gaps here i believe uh build instructions and um docker images were shared and and inserted perry is there anything else that was critical in getting that done

Parithosh Jayanthi: uh no i don't think so but if you're having any issues feel free to text me on telegram or discord and i can help out

okay cool okay

Danny Ryan: anything else related to kintsugi great

let me find my issue okay um we can generally move on uh if you're part of the execution layer by all means stay and join us but if you want to go go next up we have other client updates if there's anything uh research spec etc and actually we'll do a point in between those two which would be a discussion of pyrmont and then open discussion closing remarks first of all other client updates anything that people would like to share in addition to the kintsugi

oh

Adrian Sutton: we're doing a fair bit of work on the

key management api we're hoping to to try and get the current version of that built as a more than a proof of concept but uh can't really call it production until the api is fully settled um so i think that's happening in a few clients which is promising and hopefully we can start getting some some stuff up around that

Danny Ryan: great and um there was a a request to make a separate repo and i guess the the counter the potential counter would be to put it in the beacon apis even though that's not super semantically sound are there strong feelings on separate repo versus beacon apis james i see you unmuted but i can't hear

you if you're talking

i'm

James He: sorry but can you hear me now yes um i don't i don't think there's any like strong feelings to move it uh outside or or keep it inside that that's uh why i ended up reaching out to you um i didn't know if um anyone from like the foundation side could give any direction on that

Danny Ryan: yeah i mean ultimately i think it's a matter of where people want things to live uh beacon apis kind of implies that it's the things you're getting from the beacon although we could have a totally

separate directory make it very clear in the readme that there's also these things that you can get from the validator client and but i'm also especially now that you know i'm a bit more caught up in and see that this is very much a multi-client effort i'm totally fine with making a repo as well

James He: i think the only argument for keeping it there was that not all the uh clients have separate entities called like the the validator piece of it

right so um even then i mean

Danny Ryan: it's definitely a different kind of you can logically think about it as a different

module regardless of ultimately if it's a different piece of software or not

James He: yep i'm okay either way

Danny Ryan: i think that there was the slightly leaning and direction of new repo new api does anybody feel strongly opposed to that or voice an argument in the other direction

Marek Moraczyński: i mean this is the same discussion that many teams have with going monorepo or not i think at the end it's more of an organization thing so if

you want to group issues and you want to have support in the same place also with ci if it's similar so the discussion will lay down more on that and how you guys want to organize and how many records do you want to maintain and if that's an issue

Danny Ryan: i'm also kind of going off the fact that execution apis are a different repo obviously they're even more carved out in a different place but um i i'm personally not gonna spend a lot of time maintaining this you know i i so i would love for somebody else to have a strong opinion on it

okay

James He: i think we can we can break it out

though

Danny Ryan: let's give that a shot okay i can um put in a request to make a new repo and get some permission shared and try to get this moving

James He: um all right thank you

Danny Ryan: yeah cool cool other client updates

i guess that's the first thing there you go okay i was just gonna say this is the first outer fork uh i'm sorry the first call after the e i'll say fork and uh yeah i think it

went well for everyone um we

Mehdi Zerouali: were quite happy with our release and how things were running and we're not back into our normal uh release cycle uh expect another release in the next few weeks i guess we've been also chatting with flashbots about how their system might work post-merge making some good progress actually um on that front uh paul's put together a really really thoughtful document that i'm sure he'll be sharing with you all shortly um i know michael's been working on a bunch of slasher database optimizations uh including uh some the duplication of attestations uh resulting in some great uh data disk usage saving um i'm sure he'll share that with you

all as well and uh the only thing i guess we should probably just discuss is uh allowing client teams to exit from pyrmont to uh save server fees and maintenance labor so i think we're on board i'm not sure if that's been already uh acted but um or something to discuss

but yeah working

Danny Ryan: yeah we'll pick that up right after the client updates

Terence Tsao: yep uh i can go next so from our end um lots of optimizations on our between day tree structure so nishan has been doing great work on that

and we have been participating in lots of uh standardizations on the beacon validator key api so really happy to see effort on that front and um i have started looking more into the four choice fixes in particular the proposal boost and so i've been started refactoring our pluto array for choice implementation to make it more modulized and testable and i guess i i do want to ask later um what timeline that we're looking at in terms of i understand that this could happen a synchronously we can roll this up to minute but i do want to know like what

monks are people looking at so that i can prepare or budget more work to it but we can talk more on that later

Danny Ryan: yeah let's pick that up right after this too all right anything else any other updates people want to share

apart from the major uh progress we we are working on detail with the outer rewards and so that that maybe would be interesting to uh to see for others so that's all

thank you love star

Marek Moraczyński: we are connecting with the bolton network folks uh to figure out how to decentralize the networking on the right client and yes looking good yeah that's it

Danny Ryan: great okay let's talk about pyramid um we decided to kill pyramid we decided that a long time ago um and pratter is now near about the size of a main net and a a plan to continue to to grow it

um given that we've already made a decision on this i think that we can if we are all still happy with that kill it i mean obviously you can't kill a test net fully uh but you can just turn things off and see what happens um there are two potential things we could do with it one would be to kill it in a bit more interesting way you know maybe turn off half of all the nodes and validators and observe just to see another thing that we can do is save it for the merge for a merge test but we do have the capabilities to spin up very large test nets without

too much problem and so we can happily kill pyrmont and then in january um spin up a test net very easily to do a merge test um i given that we do have a number of these proof of work and clique test nets um i think for any of those that we want to continue forward what we would do is create a beacon shade and test net analog against that one and then do a merge and for those they don't need to be nearly as many nodes or many validators as as pratter so for example we could just do like a hundred validators and one node per

team uh and and it that end up ends up looking more like a uh proof of authority net uh and then do a merge and say like merge robson or something although i think they're trying to kill robson so even with the the merge testing and merge test nets coming we don't need pyrmont and in fact we already have a beacon chain in relation to gourley which is prouder and so we definitely don't need pyramid shall we kill pyrmont

Saulius Grigaitis: is it known how much of nodes are outside of the client teams

i mean maybe there is value in the network as there are a lot of you know some random nodes there

Danny Ryan: i don't know the node count but we i believe client teams control something like 70 percent of validators on pyramid does anybody have a better estimate on that yeah but the client teams mostly run a lot of our data spin order and i don't know maybe community is engaged enough to participate in these um you know these tests and maybe we have like thousands and thousands of random guys yeah exactly we have made it clear that piermont is to be killed and prouder was

to succeed it um and i believe that one of the biggest operators that was still using paramount was rocket pool doing a beta until about a month or two ago and that was one of the things we were still waiting on um i considering that there is pratter and considering that we did do the diligence to to make sure that the people that really needed it uh got what they needed out of it um i think that we can move on and kill it we'll give them another head so yeah um and i can in a blog post monday or tuesday uh just

a roundup of the various things going on i will mention that uh it is no longer supported and that prada exists i think it's been mentioned before but i will reiterate again okay is there any i suppose uh even if we don't want if we want to do you know turn off half nodes or something we can actually just do that on the ef side so if anyone is interested in doing that we can but maybe follow up with me and perry otherwise let it burn

anything else up here i mean turning off is fun perry you want to turn off half our nodes and see what happens how many what percentage of nodes uh validators is the ef operate

i think we're running 30 i'm not wrong

Danny Ryan: so maybe we'll just leave we'll just leave uh the ef running longer than others by a couple weeks we can but just to add on we did the finality tests on payment already we turned off i think three-fourth the network or something and then brought it back up and vermont recovered so at this point it's already done those

tests i forgot

Mehdi Zerouali: okay we'll just exit our validators if that's okay

Danny Ryan: get ready for a long exit cue um okay then i don't given that i i don't see much value in even doing a non-finality test but if anyone is inspired and has ten percent of the network and wants to just run it into oblivion and become the new king of puremont then by all means i feel like michael want to do that okay we're moving on uh the next item that was brought up was the uh fork choice attacks

and uh and for vulnerabilities thus potential attacks and uh related fixes i did blog about this the other day to just provide some high level context and i will share that context here these are sirius attacks and they the the proposer boosting fix in in particular has been um well formally analyzed by a team at stanford with rigorous liveness proofs and uh of given the proposer boost what an attacker and of what of various sizes can do

and that formal analysis will come out hopefully very soon but our understanding is that given the simplicity of the poser boosting fix and the formal analysis available with it that is the best thing to do especially prior to the merge so [Music] that pr has been spec since april um teku i think has even implemented it behind a feature flag and our understanding now is essentially that that is that is the best thing to to merge and get implemented prior to the merge merge and get implemented prior to the merge

that's funny so given that i believe that we'll do we'll do a final pass on that pr make sure that there are test vectors released and get it out by the end of this month for an inclusion in clients as soon as possible with the latest inclusion date being the merge fork any questions or thoughts on this one and as as terence noted um this handles this this provides better liveness and

and rear resilience in some of these edge and attack scenarios the core of the four choice is the same and when you don't have attacks you literally agree with the old fork choice and the new and when you do the more that are on this new fork choice the better resilience you have against this so uh with respect to a main net release plan once we do have implementations and once people have put this on on test nets then i would say starting february people should just begin to roll it out but we can touch base at the beginning of january

make sure there's no standing questions with respect to implementation and test factors and things okay moving on uh any discussions related to or research updates spec discussions or anything else

well

maybe briefly

Ansgar Dietrichs: so this is mostly actually relevant for the execution set but i was thinking maybe to briefly ask you as well um there's been some thoughts around how to handle like missed slots um on the execution side but from from from a base fee point of view so it's a very much execution logic um but why this could be relevant here is just that um there is a erp um that that's been proposed that could be included as part of the merge already to make some small changes there one of the motivations for it would be that it could actually reduce the impact of individual validators going going offline um and specifically there were some people

that were concerned that um basically with uh a denomination of validators they could become targets of of the targeted dos attacks just around the time they were kind of like it would be their turn to produce bugs and would we could be taking offline and so they're kind of like doing this chain including this change could kind of reduce the the incentive there and so my question would just be uh just in case any like e2 client team has any thoughts around like how big of a problem targeted like the enemization and dos attacks could be expected to be like that could be helpful to inform whether this is high priority enough to consider for the merge itself or not um

to me it always was a bit more like a theoretical concern but if anyone any team happens to have like some further thoughts on this that could be helpful otherwise i would just assume that client teams also consider this more for theoretical

concept

Danny Ryan: um i wouldn't call it a fully theoretical concern i think that targeted doss is is definitely a problem in that the there's probably a wide range of anti-dos capability depending on the operator depending on the hobbyist depending on the home or cloud infrastructure um and thus i think

dosing the entire network is probably not realistic but maybe dosing a somewhat significant percentages um and so still having uvm capacity full leaving capacity in that event i think is is really valuable i think that there's also just the the chance of a 10 node operator being offline for any number of reasons uh is is probably high over some period of time and so it's also nice to have in that evm capacity wouldn't go down in that event that's my opinion um i i i yeah

maybe maybe we'll discuss a bit more on friday but the uh i think it's a really nice to have i do think that it provides additional security resilience um i do think that if it doesn't go in that ethereum's probably fine

Ansgar Dietrichs: yeah i think i generally agree with that assessment i was just wondering it could have been there like was one client team or something had some had spent sometimes thinking about this specifically or something

but

Mehdi Zerouali: um okay do you mind linking the vip please

Ansgar Dietrichs: oh yeah sure um the ip of course is focused very much on the execution side but it does list the the concerns and the motivation so i linked it in the chat thanks

thank you

thank you aunt scott other discussion points for today yeah i just wanted to ask if anybody want to discuss the choice updated and prepare payload and the unification of the two because it's been like a question of a couple of last days okay

nobody wants to you'll probably get more engagement if you just assert what you're going to do if no one's pipes up there is it i think we'll do nothing right it's been already done but the question is why it was done horizon okay uh if if we do have further conversation we'll take that to the merge interop

channel on discord anything else for today okay down with pyrmont long live kintsugi talk to you all soon thank you thanks everyone thanks everyone thanks everybody everybody

everyone hi [Music] [Music] [Music]

[Music] [Music] [Applause]

[Music] so

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

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

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

[Applause] [Music] you

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