All Core Devs - Consensus #84

Transcript

[Music] [Music] [Music]

[Music] [Music] [Applause]

[Music] so

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

[Music] [Music] [Music]

Danny Ryan: transferred over

okay welcome to the call consensuslayer call 84. the first half or really however long we need will be dedicated to kiln merge etc etc then if any client updates people would like to share research spec etc i can give you all an update on the withdrawals stuff that we're working on maybe some other stuff and close from there so on kiln um i believe that many of you attended the call on monday which is kind of a a testing

and security related call as we lead up into the merge the the major sentiment from that is this is super critical um at this phase for the next three or four weeks i mean and beyond the next three forks really uh we need to prove to ourselves that we are ready and so that it involves productionizing obviously but also involves a lot of the shared testing efforts so if you don't have anyone on your team that is involved in that or taking a look at high or digging into kurtosis or following along um i would suggest that we do that uh perry and and following along and

looking into hive

yeah and yeah

Danny Ryan: yeah and and and um yes uh yeah it's just it's a shared effort there's some people that are carrying it on their shoulders um and the more hands we can get in that i think the better perry do we have a shadow fork

Parithosh Jayanthi: yes so the shadow for configs have been released and the nodes are up and running um i think we hit ttd in another hour or something like that we're like uh about 200 300 blocks away i guess

Danny Ryan: nice and are uh you're running all the notes this time

Parithosh Jayanthi: uh yeah at the moment i think it's just

me

Danny Ryan: nice and is there any way to follow along

Parithosh Jayanthi: yes i can link some explorer links um there's no landing page this time because it isn't really a public thing um but one thing to note is we're following mean net distribution now so there's i think 60 something percent prism 20 something 15 whatever i just looked at one of the recent reports and then split them up accordingly

Danny Ryan: cool um great which execution layer clients are you running

and how are they split

Parithosh Jayanthi: currently girly nether mind and bezu and i've also tried to follow me in that split so i just multiplied the two splits so if it's 80 gets and sixty percent prism then i just multiply the two and whatever number results in that is how many get clients that

exist

Danny Ryan: um great so this is shadow fork and corley ideally the transition goes out without a hitch we're following a number of metrics and

the transactions will be piped into it so we'll have some organic activity is the base fee on gourley above 255 does anybody know

Tim Beiko: i'm looking down but i doubt it obey she is nine away um so what we can do if somebody wants to when would we want to spam gordy so i can oh i guess perry has a ton of eats as well but like we we could spam gorly either during or before or after the transition i'm not sure

Danny Ryan: yeah i mean leading

leading into it and right after would be i think the most interesting spot yeah but any place in there i mean the the prison bug would be caught at any time the base fee exceeds right 255 that style of bug but you know there's any number of other bugs

that might show up

Tim Beiko: yeah so we say basically in the next hour is when we expect this to happen

Parithosh Jayanthi: uh yeah i can just redo the math but i think it should be in the next hour

Tim Beiko: is it easy to start a transaction buzzer spammer now or i can start one yes i might need some more funds but i'll ping you uh if i if i need more

okay don't lose them

you're never gonna slip that one down um sorry ben what was that

Ben Edgington: don't sell them

Danny Ryan: yeah uh there is a gorly youth proposal right now to fork like 10 trillion heath into it so that uh the signal about buying gourley goes away but that's another conversation um okay and then there was some discussion around doing um either another shadow fork or stepping up and shadow forking mainnet but to do a bit more of an all

hands um you know have more people involved actually watch it make sure it goes well triage if there are issues um perry or tim is there is this just an idea at this point or is there a plan here

Parithosh Jayanthi: um at least the current plan for this is that we do the midnight shadow for two weeks from now so we wanted to do um devnet six next week and then based on how the girly shadow fork goes plus devnet six then we would discuss the main shadow for the week after

Danny Ryan: okay and devnet six would be a bit more participatory

um rather than

Parithosh Jayanthi: yeah whoever would want

to join

um ken johanna okay

Danny Ryan: okay cool and we'd maybe not write a blog post but we would invite even others that want to jump in and run validator setups through that transition

Parithosh Jayanthi: yeah exactly okay

Danny Ryan: okay cool um and target is a week from today so configs on monday

yeah that sounds right okay great um and i

Danny Ryan: i guess what we would like if possible is um client teams to have their eye on it and if something goes wrong treat it like a fire drill

Tim Beiko: yeah and i guess even more than that

like what you did during 1559 which i think was useful is just having client teams also like straight up like monitor node like to make sure even if your note doesn't crash like is like memory usage block processing time you know like just like are like ever you know metrics kind of tracking what you'd expect them to be during the transition

the

Danny Ryan: the shadow forking main net uh it says do we need to deploy deposit contract so yeah we could reuse the existing deposit contract and change the genesis fork id but that's not going to allow us to actually add any deposits i would suggest that we use the erc20 variant

of the deposit contract where there's an owner that can issue esu 20 tokens and by default you just pre-populate the genesis of validators so you know you don't actually need to be sending maintenance transactions but we can send a few to get some deposits in after the effect who wouldn't reusing the the main deposit contract the existing one uh be really really dangerous because basically you would like have to sign with your live keys on the shadow fork yeah there'd be a lot of reasons and we also don't control like any of those validators

yes

Parithosh Jayanthi: no but if we reuse the mainnet deposit contract and change the deposit id then all the net validators but then exactly so it's just our genesis set but then you need 32

yeah you need 30 degrees

Danny Ryan: and you'd you'd be burning that ease no no one would no one would for you i if possible i'd recommend we just uh use the erc21 um yeah i think that's the most idea deposits in there

i'm doing that

Parithosh Jayanthi: yeah

Danny Ryan: i had a dream that the gas prices were three way i just realized is that true is that

where we're at sorry

talking about i'm gordy dr

Danny Ryan: okay uh 35 okay i had okay a man can dream um okay so let's do that for the main net shadow fork in a couple of weeks i think one of the very important things is to monitor all those metrics the network-wide metrics that we want to see you know no miss slots that kind of stuff make sure there's actually you know the main activity is being ported over because this is beginning to look like a very real load test but we also not just the the metrics but i think we the network wide metrics but i think it'd be

really important to monitor uh system usage of different client pairs you know i think we have we can estimate that it's going to look like the sum of mainnet today but it's good to see if anything unexpected shows up there weird cpu processing or memory block that we haven't seen on some of these smaller test sets okay other kiln merge testing related items

Parithosh Jayanthi: yeah we have a nightly ci with kurtosis

now where every single client pair is a majority client um there are naturally a lot of combinations and it's getting a bit hard to keep track of what's broken where so it would be great if client teams could also look in and just have a look at your client and see what's broken um if someone needs access to rerun a job or something i can add you to

the report

Terence Tsao: if the client release a new commit or a new dark image what's the best way to push that to the 90 build do we just

Parithosh Jayanthi: yeah that can be one way you can make a pr or um

if you're always going to push from the same branch i can just have a tag slash nightly build like colon nightly build or something and then it'll just pick up the latest version from that tag uh whichever way you guys prefer

yeah that sounds awesome i wore the emu off money

Parithosh Jayanthi: perfect and the same thing applies for every client team i think i sent a list of which strategy i'm using for which client team um just sanity check it and if you want to change it then like a couple of you have pinned versions a couple of you have latest couple master um just have a look and let me know what you guys think

Danny Ryan: cool and and that's been running for a

few at least a few days right

yeah and

Parithosh Jayanthi: i think it's happened around three times um like three nights so far um the first table is just completely broken but because we had to get controversies up to speed the second day i think we had all green on gas and nether mind was green with two out of the five um and i think the bezu kurtosis mix still has some issues so i don't think it's a client team issue and today's i haven't checked it

Danny Ryan: great great work thank you

Parithosh Jayanthi: and also i just want to mention mario's

working on getting some more analytics in so that we can actually see some participation etc and i think over the next week we'd integrate that into kurtosis as well so we'd have a better idea of when a test net run is a pass and when to fail

Danny Ryan: yeah one thing mario was doing was trying to get the head correct and target correct percentages and that's why i was asking in another channel about the you know if there's an end point for this and i know lighthouse has one do other client teams have a script that they use based off of the the common endpoints or or how do they they get that data or is it only

coming off as prometheus metrics

Terence Tsao: we use matrix

Danny Ryan: got it okay other emerge related items

i

Mikhail Kalinin: just want to give a quick update on where we are at the block tax industry so we have on on the previous acd call we have discussed uh whether to add justify

block tag into the list that we already have and we decided not to do this because it would require a break and change into the engine api and also it has a dubious value of adding this tag as we already have finalized and safe so by the end of the day we are going to have earliest finalized safe which will be temporarily set to justified block as a stop gap and uns unsafe um latest which is gonna be an alias for unsafe and

um so if uh yeah there is a pr to the execution api's repository so if people want to discuss anything or propose their own tag or whatever we also discuss in the description of these tags there which i mean um comment and comment out also one contentious thing there uh this for me is there is a suggestion to remove latest uh from the list of tags but keep supporting it in clients uh what worries me a bit is that client employment may just decide to remove it from the code base and stop supporting it if it will not be um in the list

and in the description field there is the latest with which is marked as deprecated so yeah i'm not sure that this is how it should look like at the end but probably mike i want to champion on that uh small contentious change so that's that's it on this topic

Micah Zoltu: yeah i think uh that describes it well i'm with the opinion that i would rather people you end users who are looking at the docs i'd rather them not see latest and therefore not start using it rather than see latest and not read further and realize this deprecated and so by not putting in a list the only people that will use it with people that already know about it or you know read

the whole list and then see that or read the description and see if it's deprecated and then choose it anyway um i feel like it's much easier to just make it clear to the eight dev teams that they please don't remove latest yet rather than trying to communicate to the thousands of app developers

Danny Ryan: i'm going to jump in on that issue i kind of think it's early in terms of a deprecation warning but i we can have this conversation on a i mean not for the deprecation warning but for the the actual deprecation but um i'll jump in there

was i just muted did anyone hear what i just said

Tim Beiko: after i jump in there you

guys muted oh

Danny Ryan: okay whoops uh yeah it was an oversight the justified um when we thought we were gonna add justified it was an oversight that we didn't realize we were making a breaking api change so um anyway okay api change is coming testing in full force productionizing clients is there anything else people would like

to discuss with respect to the merge any unexpected hiccups any design questions people would like to share any optimistic sync design issues that people would like to bring up

Jacek Sieka: well there is one thing i can mention for nimbus which is that parallel to the optimistic thing we've been playing around a little bit with uh light client sync

and uh unless anybody feels it's very wrong to do so we thought that we'd actually launched the lip p2p protocol server and gossip like request response and gossip on kiln going forwards with our own nodes at least so what i'll mean is basically that uh the light client updates will be available on on on kiln for anybody that wants to experiment with light clients right and like

cleansing

Danny Ryan: are you gossiping those are those only request response

Jacek Sieka: there's gossip and request response

so there's um there's this back there's a pr up in the consensus spec repo that defines the protocol uh what we've done is that we've added a v0 to the topic name for gossip and likewise for the for the request response protocols so we've done this obviously because we don't want to pollute the official namespace with um pre-release code basically the spike is still up for right uh comments and changes and so on like it's

Danny Ryan: did we start with gossip topics

Jacek Sieka: uh we stick the fork id in there um and then we kind of hope that we won't change between forks but but in this particular case there's both fork and v0 because we felt that the protocol is not yet sufficiently nailed down

Danny Ryan: great that's that's exciting

Jacek Sieka: it's actually pretty cool like we've tried we have a client as well it crashes a little bit but it's kind of promising to be thinking this way

Danny Ryan: um excellent and this will prime us well for the

light client workshop happening in amsterdam uh yeah i at the the tip of my tongue is to jump in and review a lot of the depending light client stuff um we want to get that a bit cleaned up before the workshop next month and have a clear direction from there thanks for pushing on all that

Jacek Sieka: yeah there's a question about the pr i'll dump it in the maybe in the discord in a bit i i'm [Music] not in front of a keyboard right now

Danny Ryan: okay

merge related items merge related concerns and emerge related topics

Terence Tsao: i guess i had a question is anyone implementing um some way to retrospectively verify terminal block so i'm asking this because that you could sink through the terminal transition block using optimisation right but after using to the head you actually go back and verify the total terminal the difficulty is anyone working on that or planning to work on that

Sean Anderson: yeah i think in in lighthouse we have a

pr for that right now

Terence Tsao: okay awesome

Enrico Del Fante: yeah tech is already doing that so if we go through the terminal while optimistic sync once we we are fully in sync we go back and uh and check the terminal conditions

and

Terence Tsao: if that fail i suppose you just panic right

Enrico Del Fante: yeah i think so i didn't need to double check but yeah it's something that you cannot recover at that point

so yeah

Terence Tsao: thank you

Gajinder Singh: so in that case the folk choice should start giving invalids and with the error

reason that it is an invalid terminal block i think this is what the expected behavior should be

Danny Ryan: thank you anything else on the merge okay um any

client updates like in the past handful weeks we don't have to do a full round but if you have some interesting things you'd like to share by all means

Ben Edgington: i should mention that our um i don't call it a postmortem because nothing died but uh our post incident review for um the teku performance issues last week is up i've stuck it in the chat if you want to link through to that um so last tuesday nine days ago around 5 p.m uh gmt uh about 10 percent of the network vanished um and i think uh can take the blame for that puts a lower bound on our network participation um in

any case so um it was related to deposit processing uh there was also knock-on effects to garbage collection and another knock-on effect to caching of states and state regeneration so um yeah preston called it yeah very nice um so uh you can read all the gory detail if you wish in that uh review um we took it took time to to diagnose um the the tip-off notwithstanding um and we also we didn't want to just get out a hot fix for the immediate issue because it seemed to be under control we could see the kind of deposit um flows coming in and so forth so we we took time to kind of dig down deep into

the garbage collection issues and and fix everything all the way down so that is a great improvement 22.3.2 is out and fixes that issue now

thank you upgrade your notes

Mamy Ratsimbazafy: do you have any kind of specific test to make sure that your cash are working correctly and you didn't introduce any regression

Ben Edgington: i'll defer to enrico if you have anything to say on that

Enrico Del Fante: uh so say it again so you've seen

Mamy Ratsimbazafy: um

so yeah uh any kind of test to make sure uh you don't introduce any regression when you do caches because we we also have uh this the similar uh kind of caches and we had in the past as uh jasek uh mentioned in the in the chat uh something similar is a gc and we just want to share like the good practices for regression and spotting those kind of issues

Enrico Del Fante: yeah thanks i [Music] don't have in mind at the moment all the tests we implemented around that

thanks for the heads up we will have a double check on that and maybe reach you out if something needs to be shared

thanks

Danny Ryan: right and the fundamental question being caches are critical but your cache not working correctly still looks correct from so from like a ci standpoint it's hard to actually know if your cache is running properly

Ben Edgington: right because we it doesn't give wrong results it just forces extra work because we regenerate the states so it'd be a performance issue rather than a kind of catchy you know

wrong results from the cash issue

Danny Ryan: thank you ben um any other client updates people would like to share today

Jacek Sieka: uh i can just briefly share two little things that are up in the prq on the consensus spec one is that um we waffled a bit back and forth about how to reduce aggregate bandwidth once we reverted back to the old aggregate behavior of ignoring certain aggregates

we found um a way to make that a little bit more efficient so there is the pr2847 up which expands on the aggregates that we are allowed to ignore by looking at pure subsets basically so if a client has seen an aggregate that is better than the current aggregate that is being gossiped we can just drop the the worst one because the client will already have sent the better aggregate to all its neighbors uh i recently extended that to

uh contributions as well uh on a suggestion from from adrian sutton um so that's that would be nice to get in it it gives quite a nice improvement we've tested it a little bit here and there and the other one is our become blocks by range request it has a step parameter um the step parameter was thought to be used as kind of like when downloading from multiple clients you'd sort of interleave the blocks and then

apply them to your state in this interleaved fashion but nobody's really taking advantage of it what does happen is that in code and pretty much everywhere we have to bounce check this and um yeah there's like multiplication going on and and it's just annoying if nobody's using that stuff we might as well get rid of it um and there's two reasons for getting rid of it one is to simplify the code base obviously the other reason is that we're discussing for the merge a request between execution and consensus layer where

the consensus layer can fetch execution data from from the execution client in order to save space significant amounts of space gigabytes of space on the drive and in an ideal world we would actually mirror both the range and the root request on the json rpc level so i thought about writing a pr for for for the for the api and in writing that pr i would really want to not include the step um all right so take a look at that i don't know if there's anything more to

say about those

Danny Ryan: was there so on on 2847 i have reviewed this and i think it makes sense i was kind of waiting on um a bit more engineering to chime in on in case that was inducing weird tough engineering requirements on the caches which i don't think it is on the 2856 was anyone using does anyone use step right now um let's see

Jacek Sieka: so looking through the comments it was only taco that responded that they use

it in some kind of um [Music] exceptional case i think this was discussed out of band not in the pr but my understanding was that they were willing to to remove that functionality because it wasn't critical and what's nice is that um it's actually possible to deprecate the step in a backwards compatible fashion so the protocol allows clients to respond

with an incomplete response basically somebody requests 10 blocks the client is allowed to respond with just one right so any step larger than one the way to deal with that would be to just return one block and that's it right right that's a correct response so it's still it doesn't break those existing lines it's just that they'll be uh less efficient in those exceptional cases but i'd really encourage everybody to take a look at this pr and and think about how your client like how existing versions of your clients

would react to such a backwards compatibility hack so that we don't break any user stories here

Nishant Das: yeah on our prisms and um we do use the step parameter in the case of extended period without finality and you know there are a lot of skip slots but i've looked at the code and i think um we can fix it to handle the case where the step value is only one this makes it slightly more inefficient

Danny Ryan: thank you um i suggest y'all take a look

at these uh they're pretty simple i think we just need to kind of have some quick consensus on whether we want to get them in um so please do and i'll make the rounds ask for input again probably in about a week and no input at that point i'll assume is generally being okay with it okay

any other client updates great i want to give you a quick update on withdrawals from the consensus perspective i believe this may have been shared this is alex stokes uh metaspec that kind of stitches together what's going on with the engine api the execution layer and the consensus layer on the consensus layer there are three kind of of the core features one is uh under 2836 which is withdrawals manages the withdrawals queue and does

full withdrawals essentially once you're exited and withdrawable um the other is 2855 which is a new operation which changes 0x00 to 0x01 credentials and this is a prerequisite for doing a withdrawal because you need to have a place in the execution layer for your value to land on the other side and then i do have i meant to push it up before i have a branch locally that is the third feature which is a partial withdrawals mechanism we've gone back and forth on how we might design this one was to do an election optional election when

you make a block um but after discussing some of the advantages and disadvantages here um what i have in a pr coming up today for review is a essentially just rotating through any anyone that has an effective balance of 32 and has balances in excess of 32 and also has a 0x01 credential on some interval just gets swept and for these balances to go into the into a push style withdrawal i think this is cleaner this allows you to do it on an interval faster than block proposal which is is nice and

also allows for those that have a split between the 0x00 or sorry the active credentials and withdraw credentials to ensure that they do get their partial withdrawal and that their partial draws are not held hostage by the active key which makes the proposal um anyway i we're definitely the the core of that the 2836 will probably be merged today um the credential change operation will be merged soon and i'll have this other pr up for review um by merging i just mean they're they've been reviewed they have tests they are feature complete from a certain perspective but i would like to get some

more eyes on this stuff soon any question or comment on how we're doing withdrawals on the consensus layer side in these specs currently

is there already apr somewhere our proposal on the access balance scheme and

Danny Ryan: i have a i have done a local branch i was developing yesterday i did not get the pr up yet but right after this call i'm going to push it up it still needs some more tests but it has the kind of the it shows the functionality okay and

on i think one of the things that's in active development although it's probably set aside a bit right now over productionizing the merge but uh is any updates on 4844 proof of concepts or specs or anything people would like to share

Sean Anderson: i haven't made any progress on our end but i'm hoping to soon in like next couple weeks just as far as like a proof of concept

thanks

Terence Tsao: from our end i have a branch i am pointed to um proto lambda's branch as well

which allows which has the right uh cryptographer uh which has a right hcg library so right now i'm just playing around with the library getting myself familiar with the kcg operation and in terms of implementation i am working on the networking side of things basically adding the new uh gossips of that and also doing some testing around it

Danny Ryan: thanks okay

any other spec related or research related updates for today for discussion points

Tim Beiko: so one quick thing if nobody has anything uh we we had this proposal on all core devs last week about uh trying to unify the eip process across both the execution layer and consensus layer we're working on an executable spec on the uh execution layer um and one thing that would be nice is eventually to have also eips to propose changes to the consensus layer

so that the community can kind of follow this a bit better and we're in this weird awkward spot now for like withdrawals and and uh 4844 where we're like we we have like these melee specs of melee ips which then point to both sides uh so we're trying to like harmonize all that uh i have a thread in each magicians and we're discussing this in the eip editing channel on discord if people have had thoughts

Danny Ryan: yeah it i mean i i think from our perspective from my perspective it enhances our process you know it allows us to have a

bit more exposition and stitch the things together and leverages the executable spec that we know and love and write a lot of tests with so um i think i'm i'm fine with it i think it's it's much of a more difficult change on the other side of the aisle

Tim Beiko: yeah for consensus layer people it basically just means writing up a bit more english bits and putting those in an eip

Danny Ryan: i will point out i think something that is emerging with 4844 and is is kind of

how withdrawals are working as well is this notion of using a feature directory rather than a fork directory while a proposal is independent within the consensus specs and only when proposals are decided on as these are going to go into a an upgrade or fork together would we then probably merge into a single fork directory um capella that's the directory with the withdrawals for for practical purposes is the withdrawals directory um and 4844 is its own directory you know and if those were to go into the

same fork at that point i think it makes sense to merge rather than the way we did with altair which is we had a grab bag of different features that were all intertwined during development and discussion it's kind of hard to parse and look at um i think merging down and when you get closer to a fork is probably also difficult but i think it's more sane from a future perspective and allows decisions to be made a bit more um independently from each other during the design and governance process

Lightclient: what are your thoughts on just maintaining a pr against the fork like for example for 4844

i feel like that is something that could just exist as a diff yeah and then rebasing against like new things that change and then when you have high confidence that it's going to the fork and it's at a place that's acceptable you merge

Danny Ryan: um one of the valuable things of so there's a couple things there one of the valuable things emerging is uh to actually be able to generate test vectors on normal releases although you could go into that pr branch and generate the test vectors if you wanted to release them early um you know i i merged that after discussions with

proto because there are things iterative things to do there but there's like at that point the conversation was huge there were lots of different uh changes and it just becomes hard to kind of track at that point and i guess to piggyback on that um withdrawals are these like three features together and so they really i'm developing them in three pr's that piggyback on top of each other um and i guess that works in terms of keeping them a separate pr's but then i'm having like three different places i'm re-basing and stuff and they kind of intertwine a bit so from a development perspective merging earlier

is nicer but i see from like a separation of concerns perspective that could also work well is that being considered on the execution side

sorry what no on the execution the executable execution specs

Tim Beiko: it's being debated

Danny Ryan: okay

Tim Beiko: um i think yeah i i think that there's one of the

trade-offs is like uh most eips on the execution side don't actually make it up the main net and i suspect over time as more people might propose stuff for the consensus layer that that'll be true as well so it's like there's a trade-off between like making sure we actually save the historical record of the eips but then not clutter the stack itself with like spam um yeah because if you if you do save stuff just in pr's it means it literally only lives on github and that's not great yeah and i mean we've seen literally for shanghai uh eip1153 has been like proposed again which is just based on the number several years old

um so you can imagine a world where like that spec would just be gone if maybe it wasn't part of like the eip repo itself or much harder to retrieve um so yeah i think right yeah we do want to keep a copy of like and and i think there's probably something similar to like when an eip before an eip gets merged as a draft it's also just a pr on github or like in somebody's fork and that's probably fine but then once the eip is actually merged and has a number then it becomes like a markdown file in the eip repo and like at least that's part of the git repository

so

Micah Zoltu: i believe the tentative plan from what i

understand from sam's plan at least is that once someone gets an eip to some threshold like draft or whatever it the intent is to keep it as a branch forever or indefinitely or until some extreme circumstances are reached um we would not delete them or remove them

Tim Beiko: right and then you could just say you could just pull the master branch or like your own branch if that's what you care about but at least it's part of the overall get repository

Danny Ryan: right but he's saying you would leave it as a separate branch

Tim Beiko: right yeah yeah exactly so it's like it doesn't clutter the spec on master but if somebody just wants to pull the whole repo and make like an archived copy of it like it's

with all the branches then it's it's manageable like it's still a branch part of the main repo rather than on

somebody's porch

Danny Ryan: i see i guess what we often see on the consensus layer side is the it gets written it gets merged and then you do over time see an iterative small proposal change or an iterative small bug fix change or adding a bunch of tests um

i guess you could always do that off of a pr of a pr rather than off of what we call dev

but

Micah Zoltu: um yeah i think i think my biggest confusion here the idea is is that the prs would still be short-lived the branches are what is are long-lived and so um okay you yeah there's like canonical naming system for branches and you know it's you know got a hierarchy to do it or whatever but the idea is is that the um again this is i'm representing sam's proposal here the idea is is that the all the text would exist you know in the this executable specs repo uh

but if it's not yet live in production then it's just going to be in a branch on that which is a branch off of master which is what's in production

right or scheduled forever

Micah Zoltu: i think for scheduled for production there is a special set of branches that are like london and berlin and whatnot okay and so once we have berlin nailed down and there will be a berlin branch that gets all the eips that are in berlin all merged into one and then eventually that will then turn into master once it launches

Tim Beiko: yeah basically yeah the the the for the time with well i guess the berlin branch would like grow right like because we might choose to include like two eips to start um and then you know we add the third one and so for that period of time where we're like

adding stuff it's changing and like master is still what's on main net and then once we i guess once we have the actual upgrade on mainnet then we merge berlin and to master and in the parallel there's probably london that's already been opened because we've already started adding stuff to it

Danny Ryan: i see i see yeah i mean we could be amenable to such a process

Tim Beiko: yeah to be cured none of this is like decided oh yeah absolutely up for discussion yeah so like yeah getting feedback from you all and you know how

this would help or hinder what your current process uh is really valuable

Danny Ryan: anyone else have any other comments on his proposal

great

Danny Ryan: any other discussion points for today okay great thank you um happy shadow fork later today uh please testing testing testing uh it is critical i know you all know that but it's worth saying out loud talk to you all soon take care

thank you thank you [Music] so [Music]

[Music] [Music] [Applause]

[Music] you

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