All Core Devs - Execution #150

Transcript

[Music] foreign [Music] foreign

[Music] [Music] foreign thank you okay

Tim Beiko: uh welcome everyone to awkward devs 150

um a lot to cover today uh on the call um but a high level really only a couple main buckets so um we've been wanting to talk about testnets and their status for a while and it always keeps getting bumped out so I think it probably makes sense to just take like five minutes at the start uh to just discuss this real quick then um main thing to cover is uh Shanghai and and how we're organizing that um and I suspect that'll take us uh probably the entire call um if we if we do have some time at the end uh there's still some engine API stuff as well as some execution specs and testing uh discussion to cover um and worth noting um there's only two

awkward devs left this year so there's today and December 8th uh the other one is like two days before Christmas so uh we'll skip that one and resume in January um so this is the second to last awkwardevs uh we'll be doing this year and uh yeah Happy Thanksgiving to anyone in the US I guess okay to start uh with the test net that uh afried do you want to give some context here

and and you know yeah take it away

yes sure thank you very much um so uh a lot of people will be probably be aware that we have issues with severely testing it and we have been trying to address this through different

approaches but uh long story short it's actually the most stakeholders recovering early but um get over visit and get maybe just deprecated and get a new testament the problem is um that there's a lot of migration currently happening in the community towards girly and um putting out an announcement um saying oh and now by the way we get really could be blown yeah for a lot of um let's say bigger applications or if they have to suggest to move their plastic so um I kind of sat down and brought out a proposals so to address these problems I I think we need to do

things we need to be more transparent here with regard to Communications when are we going to launch New Testaments and when are we going to keep Cricket in old ones and um to even make it more predictable so on the other hand I brought out a schedule to predictably launch like a new testament every year and limit um public test net uh lifetime to like four years and of our if necessary and additional for one year long-term support um for uh so that teams have time to migrate between two public test pets I was told by the community so it's a Wish by application developers that we have infinite runtime on tested so they

never want to migrate because it's a lot of work for them and I explained in the incentives for like free public adjustments are just not people and five years are actually a lot of times so they told me migrating major Stacks between uh that takes around six months for them including planning and execution so yeah a long story short I proposed that we um also move early and deprecated duplicated status starting next year and it looks like another year to run and then launch New Testament towards Q3 next year and um looking at the latest numbers so because girl is already four years old it was

fit very well with just it's playing for one year's schedule so I would say um girly could [Music] um sorry could um yeah hit end of life end of next year and simple yeah would hit end of life around 2026. and my main I know that more client teams it's more like test Nets are free and they can be just discarded anytime I just want to create the awareness that for client sorry for application teams it's a different story

and I want to know if there's like a strong resistance to accept more predictable schedule here and I don't know if anyone's saw the links proposal but I wrote a lot of text around

it but the long story short is just scrolling over this table where I created this very basically just applied this four plus one schedule to like future adjustments

Tim Beiko: thank you um anyone have thoughts on this they want to share right now there's the eight magicians thread uh that are free linked uh as well in the agenda we can have a longer discussion there but

um anything people want to share about the test Nets oh

Mario

Mario Havel: hey uh I just wanted to mention uh project uh on ephemeral testnet which we are working on in the past two weeks uh and the goal there is to create a network which automatically resets back to Genesis every given period so it would serve as a short-term testing environment for uh validators or um or even application devs uh without like growing State without supply issues so um uh just just to let you know I I will I will sure he'll a link uh for a repo

with more resources and if anybody is interested uh to help or have any questions feel free to reach out

Tim Beiko: cool anyone else um yeah and Mario if you could post that link in the eve magician's Trend I think that'd be great so it doesn't get uh lost in the zoom call um one last thing uh so we have discussed previously shutting down robsten at the end of the year it seems like it's already in a pretty bad State uh Adrian mentioned there's about like 30 or so validators online so it's not really useful

um does anyone have like an objection to just turning everything off uh during the holidays so to say you know we shut it down um around Christmas and um so at least you know client teams can know that they can just shut everything down we put out a blog post just to tell people um you know again I don't think it's it's quite useful uh for for anyone in its current state but um yeah at least we can have like a clear uh here shut down so anyone opposed to that okay and uh after you in whatever announcement we make I'll make sure to

link your proposal and so people know that this is kind of the the place to go for uh longer form discussion about just the the general future of test Nets

thank you

Tim Beiko: okay uh nice uh so next big thing is um Shanghai planning and like in in the last call two weeks ago uh we sort of left off in the middle of trying to figure out what was going to be cfied or not um and and we we basically run out of time run out of time there and I think that's probably the first thing you make sense to just discuss um then I spent some time in the past two weeks talking with different client teams

um about like the relative priorities and and how they felt about different things I was thinking I would summarize it all before it's called but honestly the opinions were pretty uh varied so I think it's it's worth it for people to like take the time to kind of share their views and and so we can look at the proper Nuance there um and then we have all these VIPs that we've been discussing that uh there's there's been updates too um but I was looking uh right before this call basically at like you know what what do we actually mean by CFI and how we've used it in the past and generally the like the idea is that this is something that you know conceptually we want to do that we'd be comfortable pulling in devnets you know even if it doesn't mean deploying it to mainnet

specifically um and so I don't know based on the the conversations we've had and and kind of the work that's been happening um it feels like a lot of the eof stuff that was not already cfied effectively were acting as though it is I'd say it's probably similar for 4844 and then the self-destruct and BLS eips I'm less sure um and I think the reason why it'd be important to just like get you know this kind of clarified is um I think it's like an important signal to the community to say hey these are like the things that are like seriously being considered um and then it and then you know the expectation I

think of the community will be something like a subset of this would be what makes it into Shanghai um ideally in the next two weeks we can figure out what the right subset is and we can use a big part of this call to do that um but I think first you know just coming up with like a clean CFI list uh it means we can just share that announce it and also you know people who are not in this call can can kind of share their thoughts in the next couple weeks um so I guess maybe just to start like and take these one by one at a high level um does anyone feel like you know the the other eofvips that we've been working on um I forget the exact number but for 200 47.50 and I think 54.50 is the third one fifty four fifty

um they're already sort of effectively passed what we would um well our bar would be for CFI um so does anyone like oppose moving them to CFI and again this is not a commitment to move them in Shanghai but just to say you know we're working on this it's on devnets and and it might be part of Shanghai um Micah and then Andrew

Micah Zoltu: uh just for clarity um to see if I my correct understanding that you're saying CFI means the core devs all agree this would be a good upgrade for ethereum but it doesn't make any sort of commitments on when is that accurate

Tim Beiko: correct I think the commitment it makes is basically we're going to try to prototype this on

the devnet which is effectively what we've been doing but yes it doesn't

and and I think like yeah so

Micah Zoltu: so something that we everybody agrees is a good idea but it may be one or two forks out could be CFI that would be a reasonable state of things is that correct

correct yeah and I think you know in this case you know the the more the more uh I don't know uh like we also don't want the subset to be like meaningless right like it's not like every single potential thing that could be considered but I think you know things that we're like seriously considering and and you know I think one signal of that is like we're writing tests and putting in on devnets

um yeah uh Andrew

Andrew Ashikhmin: um well uh I think because um we pretty much agreed that we are going for the big eof it's uh unrealistic and counterproductive to do it in Shanghai uh it's also like there is no immediate pressure to do it especially without solidity a sport then there is I mean there is no no urgency so my strong preference is to move it to Cancun all eof and move it like have started Cancun's back and move all the eif to CFI and also I I think I believe

that a good almost production or better production quality solidity support is a must for

eof okay all right okay I guess yeah I'm curious

Tim Beiko: I know there's other exciting teams who feel stronger about having this in in Shanghai so um does anyone just want to voice that opinion if yeah I mean I feel like if eof doesn't go in Shanghai it's increasingly unlikely it goes into a future Fork I think we have big upgrades that we want to do in like many of the next forks and it's always going to be this debate of you know this is the important thing we want to make the fork small we want you

know that thing to go in because it's important for the road map whatever and I think that with withdrawals and eof this is like a perfect time to have like a relatively small fork and do elf so if we move it to Cancun like I just really think it's going to get bumped out of Cancun

too

Tim Beiko: okay I think I know my view on like even if we were to move it to Cancun I think we should still CFI it and we can make the decision basically on the next Call of you know moving it to the next Fork but I think the signal like clearly if the if the argument is like you know we should maybe do this in Cancun and not and not uh and not Shanghai that would push me towards

having it see a fight so that it's you know clearly labeled that way

um Maris

Marius van der Wijden: just to kind of rebut uh Matt's argument I think if if something um is so low priority that it shouldn't go like that it won't go into the next Fork because we have something else then why should we do it now like if uh only because like now we have a bit more room in the fork which I I just think that people who are loudest on these types of calls don't prioritize

changes to the evm and I don't think that's like an accurate representation of everyone in the community and so I think that for that reason like things will get bumped and that's not necessarily a you know total representation of what people desire for the evm

uh thank God yeah I mean I think like I I I'm

Dankrad Feist: very worried about trying to prioritize it for uh for Shanghai if like if that's if that's by an argument oh like let's let's make it a small Fork like as I think I've said before I think it's crazy to like reserve a version for like a minimal version of EOS that isn't

actually very useful like I mean I think like reserving an extra version in the evm should be considered a huge step and should be only like should only be done when there's really like really important changes that that actually makes sense and that provide us like significantly better security guarantees better analysis uh better like scaling yeah right and that's why we've made the the this eof upgrade now like the bigger Suite of eof eaps because of that critique and now I think like this version of eof is you know hits those points

yeah and it's worth noting the two so the the

Tim Beiko: the two kind of counter

arguments against ncof still kind of make me lean towards CFI um because right now we do have two of the five eofvip CFI so I think and we can we can discuss like the status of things after but I think just did not um take up all of the time moving the three other ones given that this is you know if we do eof it's very much leading towards being those five VIPs uh that seems more coherent than having like two out of five of them CFI than the rest not um yeah Andrew

Andrew Ashikhmin: um well uh I I I I think uh they should be certified but it's like it's not a

good idea to CFI them for Shanghai because correct yeah and with Cancun like with a CFI for Cancun we have a clear commitment that we are working on it we do think it's a good idea it's just well at least my opinion it's it's a big change and I would hate to rush it and end up on some uh unused or like semi-broken version that will have to support forever there is enough time

yeah so I think I was feeling

Tim Beiko: we don't have like Cancun given we don't even have a scope for Shanghai I think I would lean to

make it CFI um all of the CFI thing will be like for Shanghai but there's this expectation that not everything makes it into Shanghai and then you know some of what doesn't make it would likely make it into Cancun so I think it's just probably easier for people to understand if it's all in one place

um but why why not uh move it to why why not create a Cancun and move all the era up there so I'm not clear that there's a clearer separation of like like all eif is in in one place a fight for Cancun we can mark it as like starting with a um enabled at the Cancun Block in evmc or Geth or whatnot so there is a kind of a more clarity

Tim Beiko: so I think that's maybe

like the second step of the process it's not clear to me that like that's the general consensus whereas like we probably want to do this at some point feels like obviously some people disagree with that but it feels like there's definitely more consensus there and then when we do it I think it's just like a separate conversation um but I'd want to just try to get the first part of it settled and then we can kind of uh yeah then we can then we can discuss when we do it and relative to everything else that's been considered um Alex

Alex Beregszaszi: yeah I would like to you to reflect to this um

no notion that it's not useful for solidity and or it may be broken um if it's rushed I just would like to ask you know what would be the the way for solidity to to signal that they would be interested in this change because um Daniel already did that on the Discord but seemingly that that wasn't like a strong enough signal um so what would be now what would be a convincing argument from solidity um for this group

Tim Beiko: uh Andrew

Andrew Ashikhmin: uh well my position that working a solidity compiler into eof without

Dynamic jumps is a convincing argument and that's pretty much in my view a prerequisite not not a commitment but a working compiler

I'd

Micah Zoltu: be quick to say that you would like to say slowly Implement first then the evm implement it rather than the other way around

Andrew Ashikhmin: well both can be done in parallel

Tim Beiko: solidity would implement it obviously you need support in the evm but before it's deployed the mainnet I think is it Andrew

yeah yeah I'm

Tim Beiko: Thomas

Tomasz Stańczak: that's my suggestion as well like uh all the changes of solidity side and the evm

side should be prepared and tested to get their own test Nets and people should say that yeah they're observable improvements and there is an indication from solidity users and so they compiler teams that the changes that are implemented in solidity and testable and test net are ready to go and then we all have everything to say yeah they delivered what was needed so they didn't didn't discover anything that uh that actually was against their assumptions

Tim Beiko: got it okay let's do Alex and then I think we can move on to another one and discuss eof specifically and which Fork it should be in uh later but yeah Alex

Alex Beregszaszi: yeah so solidity is a working on an implementation and it is related to to land uh this year so which means basically Before Christmas um but at the same time you know the the core developers have of solidity have said that this wouldn't break anything this should work um and now we are basically doubting um the the understanding of both the compiler and the evm um and also you know just generally when stuff isn't there's zero agreement about whether something is useful or not from this group that is that is a signal for you know people like solidity not to do anything

with it because also their time is is very limited um and the UF has been pushed back for two years at this point um and that's why solidity hasn't implemented it because you know they also have a lack of people and they had to prioritize other things

Tomasz Stańczak: okay so

Rolex

Alex Beregszaszi: last time last time everything was implemented already in the clients and it's and uh like the changes for the for the evm and then it was not used so so the example is working the other direction the functions

um so I mean the previous example the subroutine solidity objected it from the beginning maybe they just weren't loud enough um you know I mean Justice now

Tim Beiko: okay um just to make sure we can move forward I don't think I've heard anyone say this should not be cfied and we can um uh yeah yeah and we can discuss like the specifics of eof later but I does anyone disagree with moving to three other eips which we've already started prototyping in our in devnets to CFI um

along with the other ones it's not a commitment for Shanghai specifically last chance okay so let's do that let's move at those

three to cf5

Tim Beiko: um the next one uh that's in a similar spot where we've started prototyping it on devnet already and there's a bunch of client teams that uh are working on it is 4844 um and I think this is also very much one where you know some people really want to see it in Shanghai some people I don't um but leaving like which Fork aside and whether it makes sense to couple it with withdrawals um does anyone disagree that like this

should be cfied okay this one was much easier um so let's uh move forward to CFI and we can discuss it in more detail uh after um and I think okay I'll push back on your commentators I think this is like a perception that if you attend all of these calls and have like a very good context of like all the stuff that's being considered then maybe it's obvious with like CFI or not but in the past couple weeks like a bunch of people outside of these calls have mentioned to me it's it's not so like

having this signal they're like people who don't attend these calls that these are the main things being considered and debated um it's almost more useful for them than for us and this is why I think it's worth insisting on having like the clear um distinction um like how do they act upon it I'm just curious like now the 484 is CFI like how does that change the operation of people outside of this like group so I think it makes it's not in Shanghai yet right it's like we consider as the core Dev call that we think this is an important upgrade for ethereum yeah but and I think this the CFI just reflects that basically and it's like a way for people to know that this is the case

and have like somewhere that it's written down but that's the yeah I don't know that it affects their actions but it affects their perception of the process yeah um um well I would say one thing which is basically that moving to CFI does put a strain on on client developers and the resources that we have to allocate to things so um right yeah to Shanghai or any other Fork like this is going to like saying that something goes into CFI will divert resources in that direction and it will delay

anything else that is CFI really that's maybe the best way to put it I think that's true but I think and then it's all it's already the case for 444 and eof right like there's already resources from teams um yeah that are that are that are allocated to both those things um yeah but but I didn't think yeah I think that's fair yeah definitely like client teams feel like more pressure to like work on it once it's CFI but um yeah okay and I think there's two so there's two more we discussed last call um that I think are like maybe slightly less obvious about what we should do

oh yeah okay I

Jesse Pollak: I just want to jump in and

share my perspective on the CFI um from the coinbase lens which is that uh I'll just share the kind of anecdote that even though coinbase has been working for the last six months on 4844 um I'd say in inside of what is now like a 5 000 person company or four thousand person company there's very very little understanding of what ethereum's overall kind of like road map priorities are and where coinbase has opportunities to contribute and um like make a difference in both the kind of ability for for us to execute quickly and safely um and to to kind of like figure out what should happen when and so I think the thing about CFI and like the way

that that Tim's presenting it that I like is it it is just like a checkpoint basically where it's like hey these are the things that ethereum is saying are like ready to be executed against and like over the next year or next one to two years will happen and like coinbase come and figure out how you can contribute to that I think without some formal recognition and process um that just becomes really hard and instead becomes about like people like me who sit on this call taking it back to like people like Brian who have you know 15 Brian Armstrong our CEO who have like 15 minutes to understand this kind of thing and that kind of like uh uh you know word of mouth is less effective

than being able to say hey here's the list of things that like everyone is aligned on being important over the next year like how do you want to help make these things happen um I just want to also add on top to that from our end prison we're being actually working on it for the last six months and thank you like optimism and then like coinbase for the support as well but I do want to Echo like yesterday come in I think we should be a little bit more cautious just to decide from our point of view I don't think we should delay would draw I think we draw should be the number one priority as a core Dev we should deal withdraw out as soon as possible and also as safe as possible so I wouldn't like basically

say today if you have 100 resources working on withdraw I wouldn't ship those resources like working on 444 and having to delay withdraw from 4844

Tim Beiko: okay uh yeah and thank you thanks for sharing and I think you know one part of this is like um we a lot of this stuff probably should have been cfied and like before as we were starting to work on it and it's like now just making sure that the status tracks what we're actually doing um and that provides like legibility to people outside this call um we can discuss the specific

definition of it offline uh we'll probably take the whole recipe call if we were to do that here um I think at a high level the things that like um we're already working on have resources already allocated um are being built on devnet it seems reasonable to move them to the safeties should have been in and then we can debate how they should all come together in a fork um I think the two so the two more um that we did discuss and and you know might make sense to CFI where um the self-destruct removal EIP I think this one's a bit different but I'm not aware that anyone's been working on it directly but I think a lot of people want to see it happen and um and and and and you know think it's

important so um yeah that's one I'd be curious to hear uh from clients if if we think it should be CFI oh and Geth has it uh sorry um I don't know Jesse if your hand is still up for that no okay Rob

Rob Montgomery: yeah hello so I my name's Rob I am a ethereum Dev and I have built something called re-vest protocol which uses the self-destruct pattern in its uh inner contracts what we do is we do a very unusual system and I came here today to tell you all about it because

the proposed change would unfortunately brick our contracts and result in hundreds of thousands to millions of dollars being permanently locked what we do is and we did this actually to ironically enough we did this to help with State growth and increase security the idea being that we deploy a contract well actually to begin with when a user makes a deposit we use an individual ID to create to uh predict where the create two contract will live with that salt what the idea is that salt and we send their funds to that non-existent contract that we will deploy in the future

when they're ready to withdraw we use that same idea and this is an nft ID actually so kind of fun but we use that same ID to say okay this uh we're going to deploy the contract now we're going to withdraw however much funds the user wants to withdraw um there is a situation where the user does not withdraw all the funds so this is that's that's the edge case that causes the problem so the user withdraws the funds and then at the end of that transaction to prevent State growth and you know keep the transaction from cheap we call self-destruct that results in the uh the contract and they're being destroyed and there never having been a record of it at the end of

the transaction so never exists between blocks or between transactions the problem with 4758 and its impact on us is that create two is designed to revert if a contract exists at a given address and in the course of this if the user were to you know withdraw partially in one transaction they would no longer be able to access any of the funds that are sitting in the contract now because the system still thinks the contract doesn't exist it will try to deploy a contract at that address again but because 4758 has deactivated self-destruct now we can no longer actually have ability to retrieve those funds

so I guess I just wanted to come here and suggest that the implementation of 4758 take that into account perhaps have some sort of an edge case check to make sure that if the contract is deployed in the same transaction that it can in fact be removed in that same transaction allowing that edge case would solve all of my problems and would mean that this wasn't a problem for me and for several other people I know who are using the same pattern

Tim Beiko: thank you for sharing yeah and that's definitely something uh that we need to consider um I think vitalik you had your hand up first

and then handscar

Vitalik Buterin: yeah so one thing I wanted to mention on

uh self-destructive particular is that I think uh one good argument for pushing it into CFI early is because uh historically we have been bad at uh convincing the community that some change that that might break uh compatibility in making is actually going to happen in people and actually need to take it seriously right so thinking back to some of our previous examples particularly was that increasing some gas costs and so like it this Pro this is to some extent to the uh like one of the best signals that we have that like hey this uh is a thing that's uh actual isolated to happen and that is uh not just I mean a

couple of people in in a court of uh randomly thinking about it and so that would reduce the chance of uh more applications that depend on the self-destruct feature being created in the future and then as was said before like CFI does not mean one fork it it could be a two forks for it from now or Three Forks from now and these kinds of things should uh absolutely have about long periods between the decision and implementation and just because there's so many applications and but of course that's but but then you know obviously there's like issues on the uh on the other side right which is which are the minimum it's uh if we like if we want to

consider a change that will uh reduce that'll reduce that impacts to a couple of uh important applications and if the same transaction Edge case does it then like that's uh like to me that's not that's uh absolutely worth worth thinking about and I don't know whether or not that's uh incompatible like I don't know what like that obviously does kind of affects the whole um CFI what what is the meaning of cfi's discussion but just that wanted to keep in mind the the broader picture of uh to the extents that we are going to do stuff that uh breaks uh backwards compatibility in the future

um so just examples of things that will break backwards compatibility in the future vertical trees are a big one that'll break on every application that require that relies on manual introspection and like in EDM verification or in Stark verification of um statement State Merkel branches uh so not like for those kinds of things in the future like it's we should somehow because like we should have some ability to agree signal that like yes this is actually happening in a way that's like much ahead of actual execution because that's going to be needed for developers and just generally better think about the issue of like how

to these kinds of things so that we're both actually able to make changes that have uh that that have long-term benefits that are worth it but uh also do them in a way in a way that does minimize their costs and that leaves a room open to make to make changes that minimize costs further if options figuring that appear

foreign

Tim Beiko: right yeah I just wanted to briefly say I think I generally agree with um metallic in that I think it would be really useful to have some like Advanced

signal of commitment to making changes um just for the outside but I do think that the like CFI as we currently have it it's just not quite the right format because like to me at least the meaning of CFI it really is that in the Erp in its current form is at least already considered for a minute and I just don't think like the like for example right now I would be very strongly opposed to bringing the the aps estimated without at least having fully evaluated the same transaction um kind of edge case so the app is just not ready yet and I I really I'd be very hesitant to physically break with the meaning of CFI purely for the signaling purpose of it

um especially because I mean we see kind of Rob coming on on this call here already like people do start to to be aware of of uh kind of self-destruct and perception of removal in general so I I think yeah I really think we should stick with kind of let's see if I supposed to mean and only move a piece to CFI that are basically final right and I think basically the for you the bits that would you know make it worthwhile to move this is if we've have this like Edge case uh you know at least proposes an option in the EIP and we've had eaps in the past that

propose you know different edge cases or different ways of solving stuff so at least having some spec for how we deal with like the this create two um yeah uh Andrew

Andrew Ashikhmin: uh yeah I basically agree with Ansgar I think if we update this Eep to uh include the uh like it still allows self-destruct within the same transaction uh then afterwards we can move it to CFI but not beforehand

okay uh Democrat

Dankrad Feist: yeah I mean I wanted to respond to anska

because clearly like now we have the situation that uh since we have already very strongly considered um deactivating self-destruct someone has deployed new contracts that make use of it so clearly they haven't noticed that like this really should not be used anymore so like I'm yeah I I don't quite understand like what what you are suggesting how to solve this

here

Tim Beiko: well there were some proposals uh about you know if the if the self-destruct happens within the scope of a transaction or something like that you can you can still keep self-destruct um and we discussed a lot of these

like

Dankrad Feist: yeah yeah sure but I mean this contract

specifically was deployed at a time when it was already very clear that we're gonna deactivate it

like there was like well

Tim Beiko: this was like it just wasn't set to CFI but I think like

Dankrad Feist: there was like a clear moment towards that already and uh and now react like I mean yeah like now we're adding like a special case I mean like let's just consider this is this is like a huge thing this is like technical depth that we're adding to the VM to support this one very special like this one case there's one contract forever

Tim Beiko: well there's more than one to be clear like I and I think we are still looking into like how many there are but it's not a case where there's a single

contract affected there's like a pattern and there's at least a handful of like contracts with non you know with significant views that that are affected um yeah uh Andrew

Andrew Ashikhmin: uh well my position on technical debt is that like there are different kinds of technical debt so backwards compatibility is very important so okay but if by technical that we mean that there are some extra 10 lines of code and like some extra 10 10 lines in the spec then to my mind it's not a big deal so you write it you test it you pretty

much never change it it doesn't affect like your performance strategically

yeah I highly doubt that this is going to be 10 lines of code like sorry well yeah we can we

Andrew Ashikhmin: um we need to investigate but if it's a reasonably small piece of code that mitigates a number of uh real contracts so then to my mind it's worth introducing this small

Tech well this is going to change

Dankrad Feist: this is going to have to change the way your your right stays because it means that you can you because like we don't support like we don't the whole point of self-destruct deactivates after trackers that we don't

want to support um deleted contracts from States uh now this means that in order for these temporary contracts you will have to add a way of writing that not writing that state during the transaction and like keeping in some cash somewhere so I'm one against I think like this will be much more complicated than people imagine

Andrew Ashikhmin: we already have such data structure in any gun and guess and probably in the other year as well we already do it it's like no no technical debt on that side

Tim Beiko: okay uh and Garcia hand this up again and then you can yeah

Ansgar Dietrichs: right I just wanted to briefly clarify that from my point of view I didn't want to say that I would want this change in the EAP before making marking it as if I I just think that basically exploring this question and I mean I think that specifically illustrates why this is a complicated question it's not just like okay yeah sure we could do it it's like a if this seems like maybe desirable but it could also introduce meaningful extra complexity so this is just like a small basically side research question within the Epi that's just not explored yet and I think that means it's premature for CFI that's all

Tim Beiko: um yeah I'd be curious to hear from other trying teams as well I think um yeah basically is this the general feeling that to make this CFI people

would want to see at least some like explored or fleshed out proposal for how to deal with these edge cases or is this something because it's going to impact people and we want to figure out how it's going to impact them and and have people show up uh we should kind of make CFI now so that people have like a strong signal that it's happening and and we can even if that leads to like massive changes to the the spec because we need to accommodate some edge cases

unfortunately

Micah Zoltu: I think the answer to your

question requires us to all agree on the definition of CSI which it sounds like unfortunately

Tim Beiko: so I guess you know using the ones you posted in the chat the second one was like you know Klein devs would like to see this in the next handful of of hard Forks um yeah does it that seems reasonable um yeah Liam

Liam Horne: uh come back to me after you refinish this

hello

Tim Beiko: okay I guess does anyone oppose like

moving it to see if I I mean I guess ends guard does

um yeah I opposed as well okay

Tim Beiko: okay so I think and I think you know there um the next step for this would be to actually flesh out what those edge cases and and solutions are and we can have that conversation um at a later time um Lucas

Łukasz Rozmej: so I'm not opposing moment of CFI if we can have a CFI with a big Asterix that the spinal it's not spec is not paid finalized because of its cases

Tim Beiko: okay

Łukasz Rozmej: and in terms of the like Edge case itself I think we should wear it's possible and the cost isn't and

isn't enormous and it seems in this case it isn't enormous to keep as much backwards compatible as we can yes it is something that complicates things a bit but unfortunately that's life of supporting uh low-level system that a lot of higher level systems are built upon and I don't think we we should break it we are supporting as much as we can of existing stuff makes us seem more reliable in the long term

Tim Beiko: um Liam you had your hand up and Andrew

Liam Horne: yeah I mostly wanted to um I wanted to understand just kind of where we landed with 4844. um which I can go into more detail about what I'm thinking of there but it's just the right time to jump in

do you think Tony got there

Tim Beiko: okay yeah so I think um foreign clearly people want it at some point in the next couple Forks if it's Shanghai or not is still to be decided um and I think you know it probably makes sense to to move to like what are client teams perspective on what Shanghai should be the only specific EIP we haven't touched on is uh the BLS one

um so I don't know I guess yeah maybe this should do BLS quickly then we can discuss Shanghai so we're kind of done with the CFI stuff but does anyone have a strong opinion in your direction about Twitter we should CFI BLS and and you know consider it for either Shanghai or the fork after

um and we don't have I think we should

Tim Beiko: okay does anyone disagree with that yeah we uh DLS was cfied for burden um so I yeah does anyone disagree it should also be CFI okay

I will take this as a no um so just to recap you know these are all the things that are considered in the next Forex um we've added the rest of the uh the eof VIPs and we've um uh also added uh 4844 uh and uh BLS uh self-destruct uh I think we want to see just some better thinking around the edge cases um yes recipe left that includes 55 5450 um okay so now uh obviously you know we have all these things we could be doing uh which ones of them we should do when is the biggest uh this uh the biggest discussion um I asked all the El teams what they

thought about this in the past two weeks and the answers were like pretty different so I think it maybe makes sense for just the different El teams that take a couple minutes and then do some CL folks here as well um just take a couple minutes kind of talk through what what would be your preferred kind of outcome for Shanghai specifically and how that you know relates to everything else um yeah we can we can go from there um and Matt I know you've been sort of in the chat dying to have this conversation so do you want to start and um yeah we can go from there um yeah I mean I for a while have felt that it's best to try and keep Shanghai

small you know historically client teams have preferred smaller Forks to like very large Forks and I think that if we go into this saying like we'll do withdrawals in 4844 and eof that something will end up breaking later on and something will get lost and we'll spend a lot of like development cycles and energy trying to do all the things and then we come out with less of the things and more energy expended so I I'm like a proponent for focusing being very focused on a small fork and then trying to like somewhat quickly after have you know another small Fork rather than putting all of the eggs into a single basket

so my preference is withdrawal as an eof for Shanghai try and do that sometime in March and you know and then the other CFI apes or sorry not the cfips but the things that were CFI prior to this call um and then doing like a Cancun fork with 4844 sometime you know

Q3 got it thanks um anyone from another crime team

Andrew Ashikhmin: um yeah um I think uh public reference is also to do a small Shanghai release with just withdrawals and these three

small Eeps but uh if we want to make it bigger I would I guess go for either four eight four four or two five three seven so pick one of those not make it too big

Tim Beiko: okay uh anyone from Basu or nethermine

Marek Moraczyński: yeah I think I uh we we are agree with Andrew so with route should be a top priority and we should decide what we want to Target what we want to try to deliver if we uh notice huge delay because of this thing we can do it later but uh generally withdrawals plus trying

to deliver eof or EIP or

eight four four right

Tim Beiko: and do you have a preference between those two another mine or

whichever one yeah

Marek Moraczyński: I think uh Team agree that we are slightly prefer uh for

a44 uh Basu

Justin Florentine: yeah um so we're pretty much on the same pages I think what like client outlined definitely withdrawals um I think we're more comfortable with all of eof going in and then deferring 4844 to Cancun

Tim Beiko: got it

um so just to recap on the the outside uh obviously everyone wants withdrawals to come as soon as possible and then the handful of small eips that we'd um we did uh we considered before um and then you know there's probably room for something else whether that something is 444 eof uh is clear um and um yeah I there was a bunch of comments from like uh CL devs in the chat as well um does anyone want to share their view there yeah I guess I can go first I think live we draw Remains the highest power risk

Remains the highest priority I think as a core there we have a responsibility to get withdraw out as fast as possible and then also as secure as possible and um I personally would not want to see withdrawal being delayed by like anything else and that's just my perspective and then after we draw definitely 444 just because I don't think CL have to worry about eof like luckily yeah oh yeah I think 444 is a good Target after

we drop

Tim Beiko: and when you say after that would be a separate upgrade right or yes assuming there's delay yeah okay right okay so if

444 was the delay uh withdrawals then we would just remove it okay um anyone else on the CL side

Ben Edgington: yeah

Paul Hauner: I don't have a um a consensus from the entire team but my personal consensus is um aligned with Terence

got it thanks yeah I'll take you here

Ben Edgington: I agree with um Terence and Paul um the I think there are there are many unknowns about 4844 we haven't tested it in a network environment um and there is extra load on the consensus clients that we have not Quantified yet so there are there are uncertainties around that committing in

cavity in Shanghai introduces uncertainty about timing uh on that and we'll we'll inevitably delay things we love to be optimistic but uh I think it will will potentially delay by several months withdrawals favor a small withdrawals Fork on the consensus side and then uh separate that decouple it from 4844 that that's personal view not speaking for Tech 18 specifically

Tim Beiko: thanks yeah I can agree with what was Ben and everybody else has been saying which is that uh we want to ship withdrawals uh our test nets for withdrawals are coming now

and there's holidays coming up um 4844 inevitably will delay um Shanghai if we put it in there so I would prefer to see a smaller Shanghai and then um faster Cancun let's put it this way so that we can ship 4844 in a timely way as well thanks um anyone else on this CL side okay uh we can do Andrew and then I know uh Liam you had your hand up earlier and Proto you had a bunch of comments in the chat so I think it probably makes sense for

the two of you to go after that but um yeah Andrew

Andrew Ashikhmin: uh well it's just an open question so uh what do people mostly yell the client other El clients think about than if uh 4844 is going to delay uh Shanghai then should we include either 1153 or BLS pre-compiles uh 2537 like what is the sentiment like you pick one of those other useful do we

one dimension High now

Marius van der Wijden: I think they're useful but I think

they would also delay um so from my perspective

Marek Moraczyński: yeah I agree with Marius just what like just what Matt said eof withdrawals in Shanghai and 1153 and 4844 in the one after that and I hope that by then we can stop calling it Cancun and

have like only used the CL top names gar

Ansgar Dietrichs: right um yeah I just wanted people to say that I think I think it would be

important to talk um generally talk about timelines here kind of just to concept contextualize this discussion about because I think um a absolutely minimal uh fog uh could make sense I personally I would I would like to just hear some clarification around um it seems like people some some people will visit like for example it made it sound like like UF would not be an extra constraint um at all whereas some other clients made it sound like basically withdrawals plus one big big change so that sounded like you have would um it would delay like I I personally like I think if we if we do a kind of minimal withdrawals Fork it should really be a fault that we

can deliver on whatever that absolutely passes time and as we can like I don't know February

folk or something um and and then yeah yeah yeah and I think I yeah I think you know

Tim Beiko: given everybody wants withdrawals to happen ASAP um you know there's some conversation in the chat about like what's the quickest we can Fork I think realistically for mainnet it's probably March you know like it's basically end of November now um you know assume you get all of the implementations done before Christmas that means you're testing stuff in January you're forking test Nets in February and you're like 14 main met in March

um you know it's hard to imagine things going quicker than that unless there was some sort of emergency um so maybe using that as like a you know an anchor uh of like you know what we can do um yeah assuming we wanted the fork and have withdrawals go live in in March um you know what's what's possible to to include alongside that and that doesn't delay withdrawal significantly um yeah I I don't know if anyone has like a strong opinion there of I guess you know get the shared like for

them it would be withdrawals this eof and um it's unclear if other people feel that way about the eof um and I know earlier in the chat Proto was saying that you know if we if if that's the line for 444 we might be able to do it so um yeah anyone have thoughts on this product so um based on the CFI description I like the meaning of CFI I think like US quarters this car we're not 3D doing our job very well we should be signaling and discussing these erps in detail on these calls based on the merits of the erps

and to like explain the impact of what it has on ethereum as a protocol and we should be listening more to seniors outside of this call to set the roadmap rather than prioritizing eip's purely on what we think is the right thing to do um and so with ep44 specifically we are making this this big impactful change to if you're a master's data availability layer and I think this is super intervalued um

delaying this would basically mean Roll-Ups today keep hijacking call data for something that was never used never designed for and at the current rates this means that ethereum just grows linearly and will keep growing linearly these resources are misallocated and users are overpaying a lot for layer 2. and by changing this long-term layer Bond can have less stress with less stress on the disk space and the consumption of layer one exclusion layer clients and by basically creating the zero Zoom game between 4844 and the eof erps we basically

we ruined the roadmap of ethereum by not listening enough to Outsiders out of this call and by setting priorities based on development rather than based on the pressures on the ethereum network um Ansgar

Ansgar Dietrichs: right I just wanted to say that I agree with Proto that it seems to me that kind of from a how important and Urgent is this point of view for it for four is the only urgent upgrade like withdrawals we want to prioritize because we've been

promising it for a long time that makes sense but it's not in itself urgent aeof again we have been wanting to do exam upgrades for a long time and I think it's a very sensible upgrade but in itself it's not urgent quite before is urgent so I don't think that necessarily in itself means we should we should not do a um withdrawals only um Shanghai Park but I do think they would depend on how much we believe this would delay uh for it before if basically we say having a separate Fork means inflate for full come arrives three months later then I would very strongly be in favor of having one combined bigger fog if people are confident that just separating it out into two separate Forks has no or

minimal overhead um I'd be fine with separating it out but again it would be very strongly dependent on the impact on wait for not just the Readiness of the

other earpiece right

Tim Beiko: I think it's worth noting in the chat there were a couple comments about uh withdrawals actually being like quite urgent and critical and you know beyond getting people their stake um back there's a lot of concerns about uh you know centralization and people not being able to move their stake around um and and you know uh so giving people the opportunity to withdraw it's not only about the like ether liquidity it's about like allowing people to then stake with

providers you know either stake themselves or stake with providers that they think are better um because there's been a lot of changes that is taking landscape since the beacon chain went live um uh Jesse oh just see if you're talking we can't hear you I still can't hear you

Jesse Pollak: um hello

oh yes hello yes

Jesse Pollak: um uh just having you with the coinbase perspective um the the first thing is that withdrawals are the P0 number one priority for us uh just like you know other client teams here uh it seems like you know everyone is aligned from my perspective that pushing for withdrawals to to get out as uh safely and quickly as possible is the most important thing we can be doing um second uh I think from uh other CFI uh EIP is uh 4844 is the highest priority for us um uh we uh as I mentioned at Devcon uh are uh actively working to bring our customers on chain currently we can't bring them on to ethereum L1 because it's too expensive currently we can't

even bring them onto srml2 because it's too expensive and we see 4844 as a key unlock for actually enabling um us to be able to bring our customers on chain and kind of continue investing in the ethereum ecosystem and so that's a really important priority for us um and I guess the third the third thing that I would say and this is uh not a priority input but more just a process input which is I I feel like there are kind of two cogent paths that we can take at this point one is um we say like withdrawals are the most important thing and we should do nothing that blocks that um and that means we're not going to take on additional scope uh and we're going to just push as quickly as

possible to get out withdrawals uh and then ship everything you know else that we want to do in the next hardcore um I think the second cogent path is we say withdrawals are the most important thing and we believe that we have capacity to do X number of other things and then we have a priority conversation about what those X number of other things are um I think if we get into the situation where we say like a third path which I think is being proposed which is like withdrawals are the most important thing and we think we can just slot something else in um and we need to decide based on like the people who are kind of driving which respective things which of those is like the right thing from a size perspective to not impact withdrawals it's going to

just get subjective messy um and I don't think lead to a good outcome both from a process perspective and from a kind of timing perspective and so I'd encourage us to try and like decide which of those two paths we're going to take first and then have the downstream conversation uh which which feels like it will lead to the best outcome

Tim Beiko: um Liam and then Guillaume

Liam Horne: I yeah I fully agree with what Justin said I just

wanted to say something like you're breaking up VM um clearly reported oh gosh

um here let me check

Liam Horne: is it okay now

Tim Beiko: a bit better yeah try

Liam Horne: okay if it's breaking up it's breaking up okay I'll try really fast from the optimism perspective um 4844 is like clearly um our priority because we see it as an unlocked for basically ethereum specifically being like establishing it as like the the sole place you'd want to be going if you're going to be building any new sort of software blockchain environment we come just purely having operating optimism mean that constantly see projects that come to us saying they they would be on optimism or or more generally an ethereum roll up if it were uh the case that 4844 or more generally ethereum was was just affordable to them

for their use case uh and instead they don't and they moved other ecosystems or other worlds that don't offer the ethereum security or any of the ethereum ecosystem benefits so it's I'm saying the obvious here but 4844 is not just like a win for Roll-Ups it's a win for ethereum because all these projects and these users that are going to other ecosystems we'll have a we'll have no reason to because ethereum's ecosystem will offer the exact same price at the ethereum security that we're already familiar with and so you know I'm saying the obvious but this it you know I think it matters quite a lot

Tim Beiko: yeah thanks sir thanks for sharing that uh Guillaume you had your hand up

yep

uh yeah so I was actually going to

give some pushback on what Jesse has said um yeah we we have those uh we have those projects uh different people are different are interested in everything and in different things and and they're pushing for their own uh uh for what they think is is correct I mean we've been hearing different views so some people believe withdrawals are more important uh some people believe 4844 is more important uh I have to stay both of them are important in my view the question is I don't get the impression that either of those efforts are ready and I don't get uh like a ready to ship and I also don't get the impression that uh the there's a lot of uh conflicts between the two so we could perfectly

have two uh Forks like very close to each other like clearly not the same week but one or two months apart and uh I mean I would say sorry for the strong wording but I don't care what uh What uh the internal conversation that coinbase is uh they are free to allocate the resources how they see fit but we're not going to uh I mean I I don't think we should uh make a decision uh before we have any clarity on what projects are going to be delivered at what time we just need to focus on delivering things there's a lot of important things to be delivered in ethereum we need to work on that and whenever it's ready it will ship I think

that's the that's the wisest approach

Tim Beiko: right I think on that though there is like a there's like a path dependency thing here so for example you know if we say we're good you know if we say that 444 is the next thing we're going to ship obviously client teams put more resources on it than it happens quicker if we say eof is the next thing we're going to ship the same thing happens there and and you know there's not an infinite amount of resources in in client teams um I think another thing like just from the chat uh you know there was a lot of conversations around you know if we forked in March with like withdrawals and maybe uh you know some minimal stuff could we then have another fork with say 4844

um um like around May or June and is that something that's like possible um so I don't know I'd be curious to hear like just from the client teams like you know again everyone seems to agree that like withdrawals is the main priority and you know we want to ship this as soon as possible which realistically is probably around March um you know if we if we go down that path um you know is it realistic to include 4844 in that timeline and if not what's like a realistic timeline for 444 to is it like we could ship it a month after um because the work's all happening in

parallel anyway or is it you know we're gonna need three months or six months um yeah uh Lucas I see you have your hands up

Łukasz Rozmej: so I want to remind something that Peter shilagi said I think like two or three author deaths uh in the past that uh realistically we are not able to deliver uh hard Forks very fast so having a timeline of one two or even three months between hard Forks is probably not realistic and this is because just coordinating all the devnet upgrades giving time for people to test etc etc is a huge effort and if we if we treat 4844 as same

similar high priority it has withdrawals I would say just bundle them in one big Park um this might delay it by a month or something uh or two but it's it will be generally a lot of faster to production than doing two forks and never mind is able to do that in terms of capacity

Tim Beiko: nice um any other teams have a perspective on that I feel like we showed after the Berlin hard fork with a very quick London hard

Fork that we are capable of shipping Forks quickly if the need arises it's not the most fun but it's very possible so I don't think that we should make the assumption that we can only do one fork

yep

Tim Beiko: and yeah Vernon and London I'm looking now were less than four months apart so burdens shipped April 15th and London shipped uh um August 5th which is like just under four months um yep

uh mirrors

Marius van der Wijden: yeah and I think the um we've improved quite a bit uh since then especially in the testing

Department and um so one one thing that I want to point out um is uh that um between Berlin and London we like we kind of had to create new features if the code is ready um by February then shipping the the new Fork is just testing it and uh well and testing is done by February then it's just uh enabling it on the on the on the test net and then publishing the the final thing and that's exactly two

months one month for for going through the different test Nets and one month uh in anticipation of the of the final artwork so we can if the code is ready we can push it in in two months if the code is not ready um then there's no discussion because then like then we then we then we will delay the withdrawals for for it for four so if if you can reasonably promise me that 4844 is completely ready and tested in um in basically January um then I think um we we can we we could schedule it uh

with uh together with withdrawals uh but I I don't think anyone is willing to uh to make that uh that commitment and uh so we will would delay with Scrolls over that and it's a at least for the guest team it's a different story with eof we have UF uh ready and it will be ready and tested by January and uh so it's it's uh it's kind of a different story for us it might be different for other client teams um but that's for for them too to to say

Tim Beiko: thanks

um Ansgar and then uh if any other one client teams wants to share I think it'd be good A lot of people are like typing this in the chat I think it would just be good if some other client teams after want to share their thoughts on the call because um most people will be listening you're not reading the chat that's very visible on on the YouTube stream um but yeah

asgar sure

Ansgar Dietrichs: I just wanted to say that um I would at least say that if we go with a minimum minimal Shanghai then I think the future set there should be just be withdrawals Plus Things We want to to include but that we should be very ready to say in a month or so if it becomes obvious that these features are not quite ready and they would start

delaying the fork to to kick them back out um I think basically like a withdrawals plus ideally this and this kind of folk makes sense but if we make it like it's if we basically bundle them too strictly now and then we have to delay the entire fork for it I think that would be a failure

uh thanks uh Daniel then Paul

oh so quiet so quick one from me instead of like having strong opinion on what should go first and how uh I will just give you a short um of information how what is the status in for example in Netherlands so we are

working in parallel on uh four eight or four and in with Rebels and so from my perspective it seems that we drive us uh our you know and and but I agree with Marius that we could you know work that would be the best uh approach to work on both of them ship according depending on on what is the status of both but I understand that it could be a problem for creating capacity in some of the teams but uh could maybe we could actually ask what is the status

between the teams of uh of these pcips we're just talking what should be shaped but we don't actually understand what it

Tim Beiko: yeah I think that's a good point uh let's do Paul Dano and then we can end with uh just client team sharing what the status is and also when they would need to make a call about coupling or not coupling um in order to uh not delay uh withdrawals um so okay sorry then soldiers just came on but like Paul danosolius and then if we can just get um yeah the teams to share uh the status of that uh Paul please

Paul Hauner: sure I just had a similar sentiment to

the previous speaker that we're working on um withdrawals and 4844 in parallel I think doing a rapid fire fork is something that we're definitely open to considering um might even in some ways help us because it kind of unblocks the two teams from each other because withdrawals is um clearly a few steps ahead of

four equal four Celtics uh Daniel

Danno Ferrin: um so as far as withdrawals and eof and 4844 the efforts for the engineers are fairly segregated between eof and the other uh consensus layer impacting things so from a basic perspective um where UF lens is completely disconnected from the consensus layer

work um as far as my understanding of uh CL priorities withdrawals are much further along than 4844 work um but I should let them speak to what they want to do for together

or separate uh thanks as solias um yeah so I was

Saulius Grigaitis: just thinking you know like before 844 is is clearly not too ready at the moment and why you can't just uh you know delay this decision uh a little bit and see what is the progress in the coming weeks or a month from this 4844 because there are already some some things like

six teams or so working on that and uh you know if in a few weeks it becomes clear that like most of all the problems are solved and maybe it makes sense to to strongly consider to include in the next hard for because at least from our experience it's it's much easier to to implement something that is already implemented by other teams and confinement on the test net comparing to you know building the new feature where which is not you know tested and completed so I think yeah at least from my point

of view it looks like the decision for it for sorry the 4804 problems to be delayed a bit on the until there are much more clear what is the actual status number and you know just to wait a bit until we have more results from the next

Testaments

Tim Beiko: yeah I think I think that's probably like the the best place to end um is just from the different kind teams that you know if like within say like one minute um can share you know roughly where they're at with the different implementations but also most importantly like when when do they need a decision about what

gets coupled together right like because it it seems like so far the discussion is is kind of saying that you know these things are pretty modular um specifically for it for for eof and and withdrawals and they can all kind of progress in parallel but obviously at some point we're gonna need to like bundle them together um assuming we didn't want to delay withdrawals and we wanted those to happen you know around around March of next year when when the client teams need to know which path we're taking right like and and and kind of commit to something rather than just pursue different things in parallel um yeah I don't know if any client teams want to share this

Marek Moraczyński: yeah I think it will be good to resolve discussion as soon as possible about eof uh versus EIP for 844 uh because if you if we really want to do something in March uh uh besides withdrawals we need to know it like right now I I mean very very soon right yeah yeah of course

Tim Beiko: um Liam and then if any other time teams want to

jump

Liam Horne: on one thing I'll just really quickly shout out is there are a regular 4844

um uh developer calls when I was curious or was be willing to kind of join those calls that's the right place to discuss the status of testing um these have been happening regularly for a while now and we go pretty in depth so if anyone is curious they don't feel like a sufficient amount of information whether their questions are being answered like that's the place to discuss them and there's like a regular Cadence of these things so I'd recommend anyone join

Tim Beiko: yeah thanks I posted the information on the chat there um I don't know if Mario is on to talk about testing um but if not yeah occurs from other client teams if uh if uh um

yeah when when a decision needs to be made about coupling if we want to ship something around March

uh produce

Potuz: so I can just report on prism and what's the status on withdrawals we are pretty much unscheduled and we can have full chat test Nets by January I'm pretty happy to work withdrawals in for girly uh if a decision is made to include 4844 uh it doesn't matter when you tell us in because it's clearly going to delay withdrawals anyways

got it at the other team have perspective there yeah from Nimbus similar as as prism

okay yeah turkey's saying

Ben Edgington: um I if we wanted to do a March upgrade I think we'd need to know the contents uh nailed down by the next chord uh in two weeks I'd suggest

Tim Beiko: uh Paul

Paul Hauner: yep I agree with the previous speakers

Tim Beiko: so there's kind of a trade-off there where um earlier Marius was saying like you know you want to have the code already and that minimizes the time to ship this thing uh once we decide to do it um obviously it's unrealistic to uh have all the client implementations for

either eof or 444 done in the next two weeks um but is it more valuable to like make that decision sooner and you know kind of decide which path we're going on the next call or is it more valuable um at least on the El side to wait a bit more and you know potentially to the first call of next year to make that call um because we see um yeah we sort of see more data about what these are okay one chat comment about deciding sooner rather than later

Marius van der Wijden: um so I think your guess it it doesn't

matter too much because we have um we have UF uh mostly done um 4844 is also being worked out on by by uh coinbase and optimism so guests will probably be um like the first one uh to have like the finished versions of every everything um so I think it makes more sense for so we don't we don't really need to know prioritization because it's all almost done I think it makes more sense for smaller client teams that have like uh resource constraints to speak up and say

um that like they they need to prioritize right they need to prioritize one over the other um and I think it's important for for them to say um how much time they would need to come like if we decide not to go with eof and to go with soil for only then they need to like probably like should prioritize quite a bit and so I think client teams and smaller client teams and testing should should comment on on when they need to have this the decision yeah um same with Christian we will continue supporting 444 we'll continue

working on it but you will just be a separate Branch so we will not be merging any employee for her stuff into our main developer Branch unless it's confirmed so for us confirming like sooner or later it doesn't really matter

Tim Beiko: got it thanks um I guess Liam and POTUS have your hands up we can wrap up with uh you guys because uh we're already at time and um yeah so please

Liam no reason

Potuz: I'm just quoting what I've what I wrote in the chat yeah I think there's been consensus and I unless I'm mistaken everyone here agreed that we do not want

to delay withdrawals and no one claims that we can actually ship 4844 as early as we're thinking we can claim uh we can ship withdrawals so I think on the CL side every decision is already made we are not shipping for April for uh in in February as we're thinking very much as we're thinking withdrawals and then the remaining eips do not affect us so I think this is a no no problem for CLS and the decisions are already been made yeah

Tim Beiko: okay I think that's like probably a good place to wrap up like I think then the question for the CL kind of moves to like you know how you can how you can um uh you know schedule and Pace these forks and obviously there's the CL call

next week where that can be discussed um so I think it makes sense for cl teams to have that conversation there I think would probably make sense on the El side in the next two weeks is to get like a strong view from client teams around like which eips uh well you know what if we want to do a fast withdrawals you know what's the best set of VIPs that works for them there um and and and I think you know trying to to narrow down that scope and and finalize it on the next call would would be really valuable so that's we kind of head off to the holidays and um we know um yeah we we know what's what's being uh included uh alongside withdrawals

um so yeah let's continue the 444 kind of scheduling and and and and you know uh sequencing conversation on a CL call next week and um if El teams want to uh look at the other eips that are being worked on uh and and consider what could be included without the lane withdrawals um we can consider that on the next call anything else people want to share before we wrap up um oh and we we didn't get to the engine API stuff uh apologies again uh we uh yeah we discussed this a bit on

the CL call last time but uh Mikhail maybe is there a one minute uh thing deck you wanted to

bring up

Marius van der Wijden: can we come I would like to give a like a 30 second update on the withdrawal test net yeah we started a we started a devnet with uh Geth nevermind uh prism Lighthouse lodest uh and one more uh taku teku yeah sorry taku and all of the clients are still following the chain I think maybe Lighthouse had some uh has

some issues but um yeah so we're on track and uh it's uh it's it's going pretty well so I'm uh I'm very bullish on on withdrawals

Tim Beiko: thank you okay so yeah and I think next call um because yeah we did get sort of sidetracked by basically everything else on this car I think next call we should start with um an update on where withdrawals are at that'll help kind of ground everything and then um we can also quickly discuss this engine API issue so that uh we don't skip it for a third a third time yeah um

okay Barnabas and then we have to close because we're already over

over time yeah sure uh I I would like to just mention that

Barnabas Busa: uh in willing to read then I I would like to be able to test for Every client's uh withdrawal and uh for that I would like the client is to reach out to me because I'm organizing now for individual tests and if you have any problems or any questions just let me know and find me on Discord

Urbana

Tim Beiko: cool um thank you anything else okay well thanks everyone

um and talk to you all uh next week

when I see a call and then awkward devs after that thanks [Music]

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