All Core Devs - Execution #151

Transcript

thank you [Music] [Music] [Music] foreign [Music] [Music]

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

[Music] [Music] thank you

[Music] thank you [Music] [Music] [Music]

Trent Van Epps: yes I will keep it brief uh thanks for the time so uh some people might be aware but for those that aren't ethereum is running a trusted setup uh also called the summoning ceremony or parameter generation event but we're running this to enable 4844 and dank sharding in the future uh if you're curious about what this is or want to learn more about how to participate there's a channel in the ethereum r d Discord called kcg ceremony so you can go there ask questions there's some probably some links in there as well that will fill you in more but if you're interested in participating uh go there or just reach out to myself or Carl and we can point in the right direction additionally if you're interested in

writing your own implementation we'd love to support you in that either technically or we'll be running a grants round a little bit later but yeah uh just so anybody who isn't aware we are going to be doing this in the next uh probably starting in the next month early next year likely so reach out if you're interested and we'll we'll give you the information to help you find your way alright that's it

Tim Beiko: thank you Trent um and is there a link yes there is a link uh on the call agenda for people to learn more um okay next up Mikhail you had an you had three engine API uh things but

there was one that we really wanted to get to from November so literally a month ago uh the engine API is spec Improvement uh issues 321 do you want to take a couple minutes to chat about that

yeah

Mikhail Kalinin: thanks Tim let me just give a quick overview over this proposal um and the status also um okay so there are two part uh first of all do people hear me well yes oh cool uh two parts in this proposal first one is to make this pack itself more neat for spec writers and for engineers The Proposal is to just break down the

specification MD into several files um and the debates are about how to do this what's the best way what's the best approach uh first uh first approach is to break down and buy features or if works uh so each file will contain all methods that are new newly introduced by some hard work or Modified by the hard work then after hard work and scope is finalized all those matters considered finalized and we move to the next document and starting to edit editing spec there as first so we'll have like every Fork will likely

introduce engine API changes we'll have a separate document the other way um is do this by by functional breakdown so meaning that all matters like interacting with payloads will be in one file uh folk Choice stuff will be in the other one both has yeah both has down processed cons um so yeah um if you're interested in it read more in the comments in in the um in the issue uh the other part of this proposal is about gate capabilities method whether we need it or not uh this method is basically for cl clients to know which methods are supported by El client

and allows for introducing new methods outside of artworks without any coordination of deployment and development and duplicate all methods and here we would like to to listen to hear from CEO client developers first whether they need those this methods and if they do need it and Define it useful then we'll back on the acidic call back elk El client devs to to implement it basically um about like breaking down this back I think we want to do this as soon as possible because uh High work is in progress and the faster we do this the

better so yeah probably it will happen next week so anyone who is interested go to this issue um leave your comments ask me in Discord so whatever thanks

Tim Beiko: thank you any quick questions or comments okay um and then okay and then the last thing I want to make sure we cover uh because last call we ran out of time uh before discussing it is uh the current status of the withdrawal work uh so I know there was a devnet stood up um so Marius do you want to give us a

quick update of just where devnets are at withdrawals and can go from there

Marius van der Wijden: um maybe Barnabas

oh sure yeah

Barnabas Busa: uh I yeah I I think I can give a very quick overview of how we are looking right now yep so currently we have two private that's not uh under private I mean we don't expect anyone from the public to participate in it we have a pretty merged which is a pretty much Genesis trial there we have a prism prism another My Lighthouse Lighthouse undermined and technograph and that could never mind uh no circuit don't join this that's not but uh I don't see the uh Point uh for

doing that and we have uh ethereum JS also in Works uh but we would like to focus on the post merge chain because uh we don't want to deal with the merge testing anymore on the long term we would like to run only one that's not for most of us and for that we would launch it with the postmortion Genesis currently we have load star with the government fermented mezu and Lighthouse with gas and take with gas testing there uh so what we have tested so far uh is basically full withdrawal it's working on both chains uh partial visual is working on both strings we have to

execution uh adjust change is uh distributed and currently we only have a single tool to do this BLS do execution conversion and it's F2 it would be nice to have another tool at least uh that could do this and where people could uh verify their signatures maybe you can have an update from someone that's working is taking deposit CLI whether this is a feature that they're planning to implement or not what we haven't tested so far is message roles where we just have a big queue and uh not a large number of exits or if we

submit some that data or just some Source information maybe these the items can come off it uh particular test and test them and just make some documentation so others can also does this so we would like to start a public access net hopefully on the 15th or 16th of December so that one week from now for that we would like to run all clients on that but I know that it's probably not going to be possible what's the need for getting working is uh person will need to work with a post-nergic Genesis because we're only going to have a single chain which is

starting with the post merge Genesis file uh bezels would have to work with the Shanghai time but uh we would need to have a update from them Nimbus would have to have something working and Aragon would have to have something working but I think bezel Nimbus and ergon are non-blockers and the only more blocker would be prism uh I would be happy to test without prison but I know that 50 of the public is still running prison note and for them it would be very useful if they could also participate in this Public Adjustment an alternative route is to just let Britain work on their chain and or their

implementation and let them join in the later stage so that's about it for me it would be great to hear from a field as how are they and what is their status right now sure

yes um we

Kasey Kirkham: can say that um we've been working on start ing from a Bellatrix block and uh we actually have um an end-to-end test uh passing with that um as of this morning um so we need to use a little bit more cleanup and um and look at the results a

little bit more but it's it's basically um you know next couple days we'll have that um available

who's we in terms of team I'm sorry prism

Danny Ryan: thanks

Sean Anderson: sweet so for Lighthouse we are able to start with the post marriage Genesis um we've actually just recently just started testing this with like 4844 um I haven't been working with withdrawals but it should work the same for withdrawals um and generally for withdrawals I know we're working on cleaning stuff up to get it merged unstable in the near term so that's our status

nice

Danny Ryan: any other kinds of question about the the CLI um my understanding is that that the CLI will be able to um do the BLS changes key changes um and I know xiaoway was working on that but it was a little sidetracked this week so I think that's a soon item

Marius van der Wijden: um Mario can you quickly tell us about

tithe

Mario Vega: yeah of course so basically on hype at the moment we only have one Suite or withdrawals which is the execution client part only um basically this is just um the field mocker are doing interaction with the

execution client and testing all the engine API endpoints on the execution client um I have a list of test cases that we have added there and also the entire um well the source of this of these tests and um we still have to start the interrupt uh suite for Hive which is the El plus CL clients testing sheet um that's still to start but if anyone has any comments or wants to see the the current status of the El desk pieces you you can just take a look at this uh uh page and just uh let me know in the comments

yeah

also

Marius van der Wijden: new El teams that want to be part of this just like message either Mario or me so we can add you to hive

Mario Vega: yeah at the moment I've been testing on get and never mind and I will be starting testing everyone which I think guys is uh completed the uh the docker image that I need and so yeah

Tim Beiko: sweet anything else uh I guess any other clients want to share updates on where they're at withdrawals or testing

Ben Edgington: yeah taku is co-complete we believe and feature complete so uh seems to be going well on the on the test net so all good

to go ahead

nice

um as I said the last week I did I'm from the ADC team we tried to Port everything on airgun client uh Aragon is at the same state I think as a go ethereum as we ported the same PR uh currently only a 54 sorry uh yeah 5450 is missing and uh it's able to to sing with sandok

so the state is pretty similar to go

ethereum I think

Tim Beiko: and this is for withdrawals as well or

yeah they have worked uh their gun team has worked on another Pier with withdraws and I think it's there already okay but I cannot tell that because I haven't checked at it

uh yeah we are

Andrew Ashikhmin: still working on withdrawals uh I I don't think it's complete yet okay sorry the other the other PR it's probably referring to eof

Tim Beiko: right okay yeah that's what I thought yeah

yes yes sorry for not telling that

by

Marius van der Wijden: the way Andrew I found a really really tiny issue in in gas um so if you if you're porting death uh withdrawal implementation to Eragon and make sure to also include this I'll I can send you a link

to it

Andrew Ashikhmin: oh yes please

Marek Moraczyński: okay so on our side we are working fine on devnet and uh we are reviewing kaifest because a few of them are failing uh however for us it will be helpful if we discuss get payload V2 with block value I know that Mikhail added it to agenda

yeah

Tim Beiko: okay so uh block okay yeah let's come back to that at the end uh yeah I'm making you notes so I don't forget

uh from best perspective I think the only thing I don't understand right now is what exactly we're doing with the timestamp and how we do the fork IDs but I think that's on the agenda later so

yeah

Tim Beiko: um yeah so there's not uh there's not an EIP for it yet um okay so yeah let's make sure to cover those two things um yeah so the the timestamp and the the block value

otherwise currently we are I think

failing around 11 of the hive tests locally so

that's our status

Tim Beiko: got it thank you any other client teams

Phil Ngo: lodestar is able to start from a post merge State um as well and um we are pretty much good for withdrawals at this point we've been on the shendong test net uh so everything's good from the low star end

Tim Beiko: anyone else I think that's pretty much all the teams okay so

I'll

Danny Ryan: call out yeah if you run

into a withdrawals issue and the test did not catch it reach out to Mario get it in the dock that's all

yeah

Tim Beiko: thanks and Mario shared the doc above um okay and yeah so the the two things I think it makes sense to come back to is like yeah this timestamp uh issue and then I get paid on V2 um I think that okay so the the most uh I think important thing to get right on this call um is how do we approach Shanghai kind of broadly um so that teams can have like a clear scope for what to work on

um like I said at the beginning this is going to be last call this year and so you know if we can agree on on what the scope of Shanghai should be um I think this gives us effectively an extra month where we can work with like a finalized set of VIPs and and move forward with that um and so there's desired value thinking in making that decision uh earlier rather than later um there were a couple comments on the agenda about this like high level which approach we should take how the different pieces fit together um I think the probably the the starting point that like everyone seems to agree on is we want withdrawals to happen relatively

quickly on mainnet um this is clearly the highest priority for for everybody uh teams are working on it and you know both on the last awkward ads and the CL call last week um that seems pretty clear you know people seem to generally want to Target around March ish for for this to happen on mainnet um and I think from there you know the question is assuming that's that's what we want to do uh and and Target kind of withdrawals around March or so what what should we be coupling around uh around that upgrade um are there things that we think are high value that uh make sense to send alongside withdrawals and and would not

kind of alter that timeline significantly um and I think after that you know we can have a conversation about what do we do with everything else that you know doesn't uh doesn't kind of make that cut um because clearly there's also a bunch of other important things that we've been discussing for like the past two three months now on these calls um that it probably makes sense to like align on priorities around um but yeah I I think that the most important bit is definitely figuring out you know given we want withdrawals to go quickly um there's a bunch of other proposals that can come alongside it what are the most important ones to include that that won't kind of incur delays um or lead us to incur delays uh when

shipping withdrawals um so yeah I guess I'd be curious to hear from just like the El teams first like how they generally feel about that um if their opinions kind of evolved in the past two weeks on this um but yeah assuming we want to Target the relatively quick withdrawal Fork and we already have a couple other tiny eips um you know like uh I won't go through all of them but the warm coinbase push zero and whatnot are there other things that that kind yeah client teams feel we should include it and yeah there's some comments in the chat you know around what does it mean to be relatively quick I think people uh people said around March or so um and with that he was saying in the

chat is that and there's now 100 comments the chat saying is that uh if we want to hit main net around March we'd have to be in the spot in like January we were doing mainnet Shadow forks for this so like where you know the code is probably not quite ready to push the test Nets but you know we're pretty pretty happy with it we think that it's feature complete we want to see it you know run against the magnet environment see what breaks fix some final bugs and and move the test that shortly after um okay so I'll pass here I'm yeah curious to hear just from the client teams on on the on the El side specifically like of the different eips that are being considered that have been cfied

are there things you think it makes sense to include alongside withdrawals um and that won't affect this this timeline too much

Péter Szilágyi: I would like to have 4844

Tim Beiko: alongside withdrawals and shipping in March

no only shipping a padmaker box wasn't that the idea always that we have for it for foreign

Tim Beiko: so my feeling from the last like awkward devs and and the CL call last week was Klein teams would rather have uh would rather have withdrawal ship really soon

around March or so um but yeah I don't know how do other client teams feel about this it's something yeah maybe Danny and then Peter again

like

Danny Ryan: the consensus layer call um and definitely from those teams there's a feeling that uh 404 is just not in the same state of Readiness as withdrawals and thus coupling would be a significant delay and at least on those sides of the teams currently there's uh no

desired a couple earliest autumn why

Danny Ryan: I think that can probably be debated

um but I you know I think that that's not unrealistic

I'm just looking at all the best artworks we did I don't see a way of shipping article faster our track record shows that we are uncapable of shipping artworks faster than eight to ten months Berlin in

Tim Beiko: London was four months um yeah yeah but I think yeah like it's

four months to March that's July I had a couple delays that's awesome

Tim Beiko: yeah like I think obviously if if you do decouple them um

yes it will ship later and then the question is you know how much delay would teams feel comfortable having I think yeah on the CL side last week it felt pretty clear that coupling them would have like significant delay for withdrawals and that wasn't something that teams wanted um but I don't know like around yeah I'm curious from other folks on the Yale side like

Péter Szilágyi: well am I I guess my challenge is that withdrawals brings absolutely nothing to make ethereum better yeah sure we

need to do it it's something that it's kind of like finishes the merge the breed but yeah it's just ethereum remains exactly the same thing whether whether withdrawals work or not whereas with 4844 you actually have the capacity to make it better and I don't know for me personally I kind of feel that scaling ethereum is significantly more important than withdrawals and if scaling the whole thing just delays

with those a bit I mean it seems exactly okay uh they cried uh

uh and then Proto

Dankrad Feist: yeah I mean first question is what does significant mean is it one or two months or more because that's like a pretty big question and the second of course there's like um our client teams the rights people to decide uh whether whether that

trade-off has worked I think

Tim Beiko: yeah I think significant I know the way I perceive it is like one month or two I think with regards to like the client teams it's like aligning what they can Implement relatively in a relatively aligned way um but yeah there's a bunch of other

hands up so uh Proto

so I'd like to ask Peter and others who

Danny Ryan: can you get closer to the mic

Protolambda: better

Péter Szilágyi: yes

yes

Protolambda: okay so we're forward for fun we have many layer twos that are very modifications to ship for it for fur at the same time I always believe which are also a priority and so I'm asking what does a timeline look like where the Uber drones first and then for it for for as soon as possible afterwards um if we aim for like a May June

kind of targets like how do we have to plan these public test Nets is it possible to try and paralyze work now to to make 4x4 happen after withdrawals without delaying withdrawals but still on the first timeline

Tim Beiko: I think that's like a really good question I'm I'd be curious to hear maybe from some of the client teams on that um where like yeah if we if if we if we separate them from like a code perspective um how quickly do we think we can we can get them out

um I don't know on the so there's a bunch there's a bunch of uh CL folks uh load star prism thank you in the chat saying that you know it can be parallelizable quite easily for teams so that you know we can ship withdrawals first and still keep the work on 444 so that happens quite uh quite quickly after um I don't know on the El side um how do folks feel about that

Péter Szilágyi: our experience is that people absolutely do not touch an EIP as long as there's a hard work schedule before it

so at least in ethereum one quarter world most people most that teams only touch any IP once there's actually somebody already implemented it and if there's a hardcore schedule which does not contain a pip then most people will just not care about it yet because it's just the future thing currently now that's an interesting question but historically it didn't happen

Tim Beiko: yeah I think I I think I agree with that and I think the question is then can we schedule two forks right like could we do something like you know we schedule this withdrawal Fork we finalize the scope and then you know we already have

4844 as kind of the main thing scheduled for the for the next Fork is that is that possible basically

and that line and then

dapplion: yeah I wanted to comment on consensus sites we are pretty close to Dawn on both Forks and there are no unknown unknowns for 4844 so I think testing would have would give us plenty of time to I don't have the box so I don't really from our side I don't see the need to give us a multi-month period to keep implementing

foreign

Tim Beiko: Andrew

Andrew Ashikhmin: uh well I think that withdrawals take priority and uh that that's that's uh like uh that's really important to deliver and I've changed my position on eof because I think uh there was some statement from solidity that they are very much in favor of eof so I would either pick 4844 or eof to deliver in Shanghai but not both like delivering withdrawals for 4844 and eof in Shanghai it's it's doomed to failure it's too much so basically yeah withdrawals Plus either uof or 4844

Tim Beiko: got it uh Danny

Danny Ryan: I wrote this in the chat but um my opinion would be in terms of withdrawal support for for is keep the specs separate especially on the consensus layer not encumbering these two things um you know it's a bit cleaner probably on the way eip's are specified um if at the end of January withdrawals and Report before actually look realistic like in a May time Horizon ship them in the same software the Stagger activation for by a week because they are separate specs and encumbering the specs at that point would be difficult especially like since the player side um and if not then say okay 444's next fork and withdrawals will come out I mean I think everyone that's working on 444 plans on having what looks like

future complete nearing production is testnets by the end of January if that's not if that's not met then uh then I do believe at that point it would significantly delay withdrawals and thus separate at that point but keep them kind of intellectually specified separate

Tim Beiko: got it and Sean

Sean Anderson: uh yeah so I I think we're pretty far along as far as the initially uh the this the spec that we currently have for 444 but I do actually think there are some significant unknowns which would change the timeline on the order of like a couple months maybe more I'm not

really sure um and that would be like specifically seeing what having big blobs in the gossip Network looks like because that could change like how we have to specify things um and and on top of that like the big question I think that we've had is about how bandwidth looks with um adding blobs and this could require something like episode as an upgraded to gossip sub which I mean I think Lighthouse is pretty far along with but I'm not sure if other teams have really worked on it um yeah so it's things like that and also I think Micah just pointed to it in the chat like um

the the question about like um whether the data availability window um should be like have a hard upper bound at 18 days I think that's like a pretty deep sort of philosophical question and that would have big implications if that's if we don't make that um a hard 18 days um yeah so to me there are some unknowns with the current spec though we are pretty far along

Tim Beiko: got it so clearly like it seems like you know

there's there's a desire to do 444 as quickly as possible not affect withdrawals too much um and and um yeah make sure those two things kind of come out quickly but but they're not holding each other back um on the CL side they luckily have uh these nice executable specs which make it easy to specify I think these this way and and kind of have this this logical dependency between them um we don't quite have this on the El yet um so I think if if we do something similar like we have this Shanghai spec which is the equivalent of of uh the capella spec on the on the on the CL where you know we

Implement withdrawals we we then um can basically have you know eips that are like scheduled on top of that um where you know it would basically be like planning the next fork and having 444 on top of it and then we can decide whether we want to um activate them in quick succession or not um the people feel like on the El side like this is something we we can do as well like where we just say you know we're gonna have withdrawals as the as the Shanghai Fork

um we then have a specification for what comes after it includes 4844 um and yeah this way you know if if we're we're really confident in the work on 4844 and it's it's going quite well um we can have the activation happen really quickly after but if for whatever reason you know it takes longer then we end up in a spot where um yeah we can delay 444 and there's no like technical coupling to the the withdrawals Fork which can go live so basically kind of have respect for a new Fork have 4844 included in that and um keep Shanghai as the spec for withdrawals and you know potentially

some other things does anyone disagree with that approach

Danny Ryan: yeah I mean I think whether that is so that independently whether that's realistic that they might have actually be coupled is uh dependent on 444 but also there's kind of the additional dependencies of what else goes in Shanghai not conditionally you know and that could also make or break whether the strategy is even realistic um but I you know it depends on those items

Tim Beiko: right right and I think yeah there's yeah and but the first point

there is like you know can we just align the specs in a kind of weird way so that we do have uh like we have 444 specified as happening after withdrawals have that not be really like Up For Debate in that like you know it is kind of considered the main thing that's coming into the next upgrade and and we make this decision now basically um Jesse

Jesse Pollak: yeah I I just want to say I also don't want to forget eof I feel like they've been doing a really good job executing on this and um uh it is the sort of developer productivity thing that can can get left behind and so I I want to plus one what Frodo said and what it

sounds like a lot of folks would be excited about which is um the idea of like pushing towards like as fast as possible withdrawals Fork but super narrow and then kind of all of us rallying together um to ship a fast follow fork with 4844 and eof basically as quickly as possible after that hopefully in the first half of next year that kind of gets everyone working together to both scale ethereum and provide a great experience for developers now I'd be really excited about that

Tim Beiko: thanks um yeah so I guess just to get yeah just this get the first withdrawals and for it for four settled and then we can discuss eof and all the

other things where they would fall in those buckets but does anyone oppose the idea of like yeah having withdrawals be the main thing for Shanghai trying to ship it as quickly as possible um basically including 4844 in a spec for the next work like it's done on the CL side and um you know trying to ship that as quickly as possible after uh withdrawals keeping the work parallelized like it effectively already is um and then we can discuss yeah for the other various eips you know where they should fall whether in either of those buckets or none of those buckets um or we're not like ready to make a decision about that today but just high level withdrawals in 0.44 does anyone

oppose that okay uh okay so let's let's go with that um we don't quite have a way to do this on the El spec side yet about like adding 4844 and like an upgrade after I'll try to come up um with something after the call and I'll post an awkward as but effectively yeah let's Center Shanghai around withdrawals have 444 uh be the the kind of center of the the next Fork um and then from there you know assuming I think again we want it to have quick uh withdrawals there's a bunch of

comments in the chat about uh you know eof and just his comment on the call um I guess I'd be curious to hear from maybe the El teams what do you feel should go alongside um what do you feel should go alongside either withdrawals or 4844 um yeah on the on the El side

Marek Moraczyński: so we will prefer uh smaller Forks so withdrawals and small VIPs however we are also okay with withdraws and eof if other clients feel uh it would be the best decision and we all can deliver it uh to sum up a smaller Fork but we are okay with eof and withdrawals

Tim Beiko: okay thanks any other client team

Andrew Ashikhmin: I think if it's the same for Aragon as Marek said we are fine with a a small Shanghai with just withdrawals but we are also fine with withdrawals Plus

qof okay

Justin Florentine: uh echoing the same status for Basil withdrawals plus eof is pretty ideal for us

okay and guess

Lightclient: I'm not sure if anybody else from the team wants to chime in obviously I've been working on elf a fair bit and I

think it makes sense to do eof and withdrawals but that's just my point of view

yeah I think that's fine um if Matt already has some those things covered

Tim Beiko: um and I guess yeah uh Daniel has two comments about the eof spec stylist updates uh in the chat so um yeah I don't know Matt or if uh aksik is on the call but do either of you want to give a quick update on where yeah where eof is at and and um yeah

what like the recent changes have been added

Lightclient: yeah I can share a couple things and then I'm sure axic can probably share some stuff uh the last couple weeks we've been working on just like resolving some of these like oh small open questions in this checklist and pretty much all of those things are have been resolved I think that there's basically just like one sort of like optimization question around the header about how to encode the code section sizes that we're like debating a little bit but I think you know other than that everything else is pretty much resolved we're finishing some of the PRS the eips Apollo was on vacation this week so a

couple of the things that he was like working on we haven't been able to merge those to the eaps but we've written this unified spec which is sort of a meta spec of all of the eof Eeps and it has the like updated versions of all these things so it's best to look at that unified spec to try to understand the overall change set of what eof is providing and I think that if you look at that unified spec you'll realize that the overall change set of these five Eeps is actually smaller than you know it feels with the five Eeps so that's kind of where the spec is uh Alex and some people have been talking a lot with the solidity team we've uh yeah just changed a little bit of the uh

exact op codes that are provided to support like exactly what the solid team feels is important for eof but you know adding eof is the main thing and so having like what additional op code is like extremely trivial to implement and to test it's mainly about providing that container format and providing the like semantic environment to execute in I don't know if Leo if you want to give us perspective from solidity too

hey um yeah so this is Leo from celebrity and Daniel couldn't join so I'm here on his behalf um so yeah so solidities for uh in full support of uh muf

um to suggested just like there's a lot of nice thing that we that we think would help the the language the compiler and um the the users as well and the developers in terms of gas security optimizations your acts debugging different things um so yeah so it's one of the priority items in the current solidity roadmap and we have a few PRS that were merged already and a few others that are in progress right now so um yeah I think it's going well um yes the other thing that I wanted to bring up was 663 so but I'm not sure if it's this is the right time so a little bit of that

Tim Beiko: yeah let's do 6x3 um after but thanks for for the context

uh Leo uh Danny

Danny Ryan: so I look at the I look at the checklist and it seems like a lot I'm not deep in this do we think that we will have we will be able to do mainnet Shadow Forks of a feature complete Frozen spec in January just given given where we're at on that

Lightclient: I feel pretty comfortable with that um I think the implementation is relatively straightforward it's like one to two week tops engineering time and we most clients are already 70 or farther on the spec

Tim Beiko: does any

yeah El team feel like really uneasy from that like the idea of an eof uh a mainnet shadow fork with eof and withdrawals in in uh January okay

uh Prolo

Protolambda: so I want to emphasize that not delaying withdrawals is a common goal between everyone here just for withdrawals itself but also not to delay public distance of all the features afterwards including fortnite

and so it's really like some strong commitments from El teams that they do not believe that anything

will delay the patrol search work yeah uh yeah El teams want to chime in yeah

Marek Moraczyński: we will work on the parallel on uh all uh features so eof for eight for four and withdraws uh Shadow fork in January might be a bit challenging but uh I think we are okay with that

uh Basu and Aragon

or Basu

Justin Florentine: is happy with that um eof is well in hand withdrawals as well in hand we should be happy with a midnight Shadow fork in January I guess let's talk about maybe more specific when January I mean early January feels like a non-starter due to vacations and whatnot

Tim Beiko: yeah I think yeah we usually mean like mid the late January obviously because basically coming back from vacation you know maybe we have like two weeks where people kind of finalize the implementations we run some devnets with all the clients and then you know we're in a spot where we're ready to Shadow Fork I think that would be

mine

Justin Florentine: okay sounds good

Andrew Ashikhmin: uh from America on this draws plus so if it's fine I think Shadow Fork late January early but probably more like early February is

more realistic okay uh bankrupt

Dankrad Feist: yeah I mean I have to say I'm honestly extremely surprised by these discussions because like it it feels like when you when people talk about still implementing new up codes that come out of a solidity team that this is more ongoing research like I I'll be really implementing the best version of eof if we literally make the time pressure to free specs like

basically right now uh so that's my first question this um because it seems like the specs as for very much reflects from everything against it and the second question is like uh so I mean from from what people say it does not feel like this does not delay with George so like why like it seems very likely that this will actually deny withdrawals and so I would be extremely against coupling this with uh withdrawals hardcore if we're saying oh we can't uh we can't uh sorry for fall with it uh since that is I think like infinitely more important for the future of

Return of all foreign

Tim Beiko: I guess there's anyone like on on the the part of like eof spec Readiness I know Dano I you had a comment in the chat do you want to maybe yeah share your thoughts on like how like where so UF is that and then yeah then we can do

that scar

Danno Ferrin: so some of these odd codes are being brought in have been discussed literally for years um they've been test implemented in things like evm1 um so these are not like new ideas that are being brought in all the new ideas that are coming in are already established there so it's being discussed is bringing in things that people have been you know back in 2020 this whole any significant evm changes put on pause until the merge is done so it's all been been being held in advance until then and we're really just waiting

is for a finished spec to say okay this is exactly what's in it so there's not too terribly much research going on into some some of these new OP codes are being asked to be put in and they're quite you know isolated and separate from one another the only real burden is getting the testing um the testing uh specs done in the ethereum test uh and there's there's people that written tests for those already those are also sitting in some cases in PR's waiting just to be checked in and turned on

Tim Beiko: uh thanks uh Ansgar

sure

Ansgar Dietrichs: yeah I just wanted to briefly say that I think it's probably not very productive because keep having having the kind of

discussion of whether or not we believe EF is right enough or not because it seems like most client teams are pretty confident so the only thing I would say is that kind of once we have our first ACD in January we should come into this with the mindset of if withdrawals is ready and anything else in the Shanghai heart folk is not quite ready even if it's just looking like it's a week or two or three or four delay we should be very registered to just say okay we slim down uh Shanghai for to test withdrawals and and move ahead and as long as I think we all kind of have that commitment in mind um I think it makes sense to just move ahead with UF in it um it sounds like everyone is optimistic on that front

Tim Beiko: yeah and I guess on that note um how because there is some engineering cost to remove eips once we've started coupling them too much and we've seen consensus issues in the past um because we like made a mistake when removing an EIP from a client um so I I'm I agree conceptually with what you're proposing yet scar but like from the perspective of like the implementations how doable is this so like if we come uh if if we come to January and you know we want to actually remove eof is you know is this going to take like

three weeks extra at the property do well um like well yeah and are we like kind of back in the same spot um yeah I know I'd be curious to hear from just the client teams like how easy it is to remove if if we choose to go that way

Marek Moraczyński: so for us it is no problem uh for removing uh eips

okay

Tim Beiko: uh and uh get this saying it's it's easy as well base to Aragon is it easy on your end as well

Andrew Ashikhmin: yeah it's relatively easy

okay

um Basu

Tim Beiko: just want to confirm as well

you know okay

Tim Beiko: so I don't know yeah um is like I think again like there's a ton of comments in the chat about uh delaying withdrawals like on the El side the client teams feel like having Shanghai being basically withdrawals eof and like 10 three tiny eips that were already there like that this will not basically delay the withdrawals that will be ready for like uh January uh main net Shadow Fork basically

um well pretty much everyone thinks that it won't be ready for them for Generation before

Andrew Ashikhmin: yeah maybe late January early February that should be fine

Marek Moraczyński: I think late January on our side

Marius van der Wijden: let's aim for early January um please and just put some more resources on it and we can do it

Tim Beiko: and when I guess yeah when would people want to make a call about removing eof

if we're not happy so we have the first awkward devs will be January 5 and then we'll have January 19th what would we want to have seen on both of those calls you know uh to keep her confidence that this is not going to delay withdrawals uh Andrew

Andrew Ashikhmin: uh well I I don't understand why like I mean it depends on how much by how much withdrawals are delayed into my mind a week is like why would a week or even

two weeks or even a month be that critical I'm not saying that we should relate with those by by month but to my mind a week is nothing

Tim Beiko: yeah I think a week It's probably hard to like even know like that a week yeah can't that's like we could plan a week delay that far in advance I do think if people feel like it's gonna be a month or more then and we we feel that way today then that's a sign that like it's probably going to be more than that yeah um yeah um let's see uh Holger you had your hand

up then Danny

yeah so I think um so I would uh um add to the discussion that two months or so actually makes a huge difference here so regarding delaying and so if we're talking about in March Shanghai Hartford for me adding your effing with with this kind of this kind of like current specs uh status and uh and uh planning on all the tests that everything sounds extremely ambitious so I would really um uh go along with with some certain reservations or from um if we're talking about may this might be rather doable um this is kind of like I think we are this is pretty narrow what we are

planning here um yes so I I actually posted on the on the um issue agenda this is other uh suggestion that we could actually do a relatively quick hard Fork after the Shanghai hard fork and then like two or three months after that and then bundle 4844 and bof and from my perspective since eof is not so pressing um nevertheless great to have but really not super pressing this would be the more attractive uh possibility uh still because then we have two or three months more time I can can calmly plan our test ads and this would not have do so much harm so I think this might be another attractive uh alternative here

and

Tim Beiko: there's yeah some plus ones in the

chat for this uh Danny you had your hand up as well

Danny Ryan: yeah I was just gonna comment you know the what is a week delay what is two week delay I I just I know that many if not all the teams on this call are planning on hitting um testing that kind of Milestone targets at the end of January and that's why I think it keeps coming up you know if if we get to the end of that and don't have strong signal on something like that's that is a that is reason for delay because that is going to be a big development Target so you know if then you can ship it the next week that's probably fine but I just think we're going to have a lot of information at the end of January

Tim Beiko: yeah I think the the so clearly you know on the El side teams feel like they can do something alongside withdrawals and and like generally feel like eof is possible um if so if we go that route and eof like is not ready I think the what this means then is we've basically remove eof from Shanghai and also that

none of the other potentially smaller eips that you know we've been discussing will make it in Shanghai and I think that's basically kind of the the the trade-offs there like where we need to be okay with saying in January like eof is not ready let's just do withdrawals um by that point it won't be possible I think to add something else to like replace eof because you'd have to incur like a bunch of testing uh overhead um and so so that means you know there's a possibility we ship uh we ship uh Shanghai on the El side with

specifically like literally just withdrawals and like these three tiny eips um and the time it's going to take to like remove uh eof safely from the code base and what that means um you know we probably won't be able to add something else in if we don't want to delay withdrawals um so I guess you know like our El teams like okay with that that trade-off basically um when I see Moody you have your hands up so it might be worth yeah take it in a minute or two to cover 11 53 and where it's at because I think if we go that route this is you know one of the things where like implicitly not including um in Shanghai

um yeah

Moody Salem: yeah I was just going to ask that we

don't couple eof with 1153 I think they're pretty unrelated and 1153 is ready to go into testnet as soon as it's ready as soon as the test net goes up um it's implemented in three of the five clients and uh one of the PRS is just waiting for clarity that it will be in Shanghai um and so I think it it can go in the Test match assume it's we just move it to the inclusion category

Tim Beiko: right but then the question is do teams feel like we can like have the bandwidth to test that and you know have it alongside and Andrew

Andrew Ashikhmin: uh well I think uh we get we can just uh schedule it for Cancun along with 48 44. so I would not include it into Shanghai because like withdrawals plus eof it's on the border borderline it's that's not delayed more like delayed by a week but putting anything else would definitely delay it more so yeah I would I would just schedule 1163 and 48 44 for Cancun

foreign

Moody Salem: to CFI um

I believe the um conclusion was just to get it into a test net and if there's any delay due to testing um we could drop it so this seems like a change which is because eof recently God made CFI just want to make sure I understand like the process here

Andrew Ashikhmin: well we have so many IPS in the CFI we cannot Implement them all in Shanghai

Tim Beiko: right we have to choose a subset of that um and I think obviously like any incremental thing we add [Music]

has like some costs and I think if if uh basically if we feel like eof is like the single thing and it's already quite big then yeah then it doesn't make sense to include something even like in addition to EOS and withdrawals um I do want that like yeah there's a bunch of comments uh in the chat about uh you know is um is like is Aragon like with the idea that like eof might be borderline possible for Aragon like what does that mean and you know does that end up

having a delay so I I don't know yeah Andrew like if it was just up to Aragon do you think eof is like significantly bigger to implement alongside withdrawals than um you know something like 1153 I guess yeah or maybe like I think what I'm trying to understand is you know when you say that it's unclear if you'd be ready for a January shadowfork is this because of like the size of eof is it because of like withdrawals at eof just like generally like or and and yeah how does eof basically change like Aragon's Readiness for Shanghai

Andrew Ashikhmin: uh well uh there is a NPR for eof uh for against Aragon and it might

they might be a PR for 1150 so I don't remember but uh with uh I'm just thinking that because uh so eof is uh kind of this pack is uh ready almost ready and the the implementation is almost ready and so on so we have um it won't be a big additional chunk of work uh and I would rather yeah so but what the so there's a delay compared with those with eof and compared to the withdrawals without uh the the delay that you have ads probably small like

one week or something so from my point of view I'm happy to to do eof

in general right yeah okay and

Tim Beiko: I think yeah I think the basically coming back to to the the earlier point and and you know not delaying withdrawals like the basically what is the cutoff that we want uh I think on both of the all core devs to decide eof is actually not ready and

you know we should remove it to not delay anything further because that seems to be generally the direction El teams want to go in is to try and get eof um but it's very easy if we go down that path they're like you know feel like we have some cost and oh it's only two more reaches it's only two more weeks the next thing you know we've delayed withdrawals six weeks because of this um so you know there's a bunch of uh yeah there's a bunch of I guess things that we need between um between like going live on mainnet and um and and having like the specs ready so like when we come back in January there's basically I think three kind of

check-ins so there's uh the first two awkward devs so January 5th January 19th then um there's gonna be a a client team interrupt week at the week after that so like what are the things that we want to be sure we have for like like what are the stages we want to be at basically on the 5th the 19th and like the end of the interrupt week such that like we're happy with eof and we feel like we're ready to move and if we don't if we are not at that spot then we should um we should just remove it um yeah curious to hear just from like find teams like on January 5th like on the

next awkward devs where should we be at and then two weeks after that right before an erupt where should we be at if no one has suggestions I have some thoughts but okay so I think yeah and then Barnabas has a comment about uh you know we're obviously going to the holidays so I think it is realistic to expect though that a month from now like one the eof spec should be like really final we should have

implementation in all of the client teams and ideally like complete test coverage and things like Hive and ethereum tests I think we have most of that all of this already I think on the 19th two weeks after that I would want us to have like a first basically yeah after the first operative so after the fifth I would want us to have a devnet which has eof with all of the El clients uh in in the week after that so you know the week of the ninth then by the like Nextel cord as we should be planning like a either a Gordy Shadow fork or a magnet Shadow Fork like

a first one I think with eof and the withdrawals and if we want to hit March that's roughly where we need to be so like yeah I think we need basically full implementation or and you know spec Readiness and testing like in the next month and like Shadow forks and devnets happening in the between January say like 5th and 19 um so that we go to interrupt we know that like it works across all the teams we finish um and like we we ironed down some cross-client issues during that and we hopefully have like a clean mainna Shadow Fork during the the interop week and then we know that like 4844 and withdrawals are solid and they're ready

to be moved to devnet I think if yeah if we get to like the second like the basically the first awkward abs and we don't have client implementations that are pretty much ready across all teams or the second awkward devs and like we're not able to have all of those running on a devnet or and soon on Amanda shadowfork to me that would be the signals that like we we cut eof out and and literally just ship um just ship withdrawals in the three small eips um does anyone disagree with that

Micah Zoltu: um week of January is there an ACD before that or is that the first ACD call

Tim Beiko: it's the first yeah so so uh the fifth of January is the next one

yeah

Micah Zoltu: sorry the fifth of January is the first week of January

Tim Beiko: correct

Micah Zoltu: so this will be one week after the first ACD call is that correct that we're targeting

Tim Beiko: correct so I think on the first January on the first week on the awkward devs we want to make sure like the clients have implementations that are basically done they work together like they're interoperated between the two awkward devs so that on the 19th we can basically be planning mainnet

shadowforce I see

Micah Zoltu: okay yeah

um so functionally the cutoff is the first January 5th like if if not everybody if everybody isn't done with the eof and withdrawals but January 5th we're dropping eof

Tim Beiko: yeah I think single client implementations that's what I would say and because there's like two steps to this one is like you know is it implemented in your client and like does it generally pass the test Suite I think we'd want that by the first awkward Dev so the first week of January and then it's always like trickier to then get them all on devnets because the different uh implementations need to like agree with each other and you might find bugs and I think this is what we want to iron out between the first and second all chords of next year basically um and if by the second awkward devs were not like pretty confident that we

can run this stuff on devnets you know with different kind teams and it generally works I think we should we should remove it from from Shanghai at that point

Micah Zoltu: so just just so everybody who's not looking at calendar is aware functionally if you take about a week or two off for Christmas that means everything to be done in two weeks right

Tim Beiko: correct

Micah Zoltu: like two weeks from now now for two weeks get everything done you take two weeks off for Christmas and then soon as you get back we're going to evaluate if everybody's finished

Tim Beiko: correct

Danny Ryan: is there a like how clear that people feel about the kind of requirements that are needed in the

first week of January like when we get on that call is it black and white exactly what it means to be either yes ready or not

I'm curious yeah

Marius van der Wijden: I would say have an implementation and um pass the the test vectors I think we have already tested this for year F so um if you're passing those and Martin worked on a tool where we can fast the uh like the verification mechanism of UF and so you

should also implement this thing so that we can first you implementation for the contract verification

algorithm and

Tim Beiko: I would maybe like add to that we should make sure that there are test vectors for like the entire spec right like um obviously um like the spec kind of changed relatively recently so like you know there should be like full test coverage as well if we don't have that by early January that seems like another problem

Marius van der Wijden: um Mario can you quickly comment on what we have for

UF test

Mario Vega: I'm currently working on a separate year

of this but the currently available set I'm not really sure if they are updated I wouldn't to get back to you

okay

Lightclient: there's also tests and retesties from the Epsilon team

Tim Beiko: yeah so we should make sure that you know all the functionality is tested either in we tested or meros test Suite um so that clients can can check against it and we'd expect that by the first week of January this first awkward devs clients are basically passing the tests for eof um does that and then

because this basically tells us that single client implementations are ready um I think then we get another two week to make sure that cross-client interop works well basically um and I think those are like the two cutoffs does anyone disagree with that um and then sorry I know POTUS and Moody your hand has been up for a while I will get to that right next I just want to make sure on these two um these two milestones any disagreements okay

um okay so let's move forward with that um so uh Gen 5 single client implementation full test coverage and then gen 19th um interrupt and uh yeah Shadow forking after that um code is and

movie

Potuz: so I have a question that is kind of related uh it's not hard for requirements but uh so we wanted to have a decision on engine API and Marek suggested today to have the block value uh by Shanghai so at the port and I was wondering if uh if we can get some clarification from El clients if this is

possible if it's this is going to be ready or not because depending on that is whether or not we're going to implement this now or not

Marius van der Wijden: uh we will be ready I have a draft PR I'm just waiting for the spec to finish I like to to be like finalized so I will I it's it's like five line change for gas and uh presumably for all the other clients as well um so yeah

are

Potuz: we good if we if we just move to add this to our capella branches and we start testing this on even on their

devnet yes from my site I think yes

Potuz: that's good

okay

Moody Salem: um Hey so uh I think in the chat like the the concern with 1153 is that we it might delay withdrawals especially in combination with eof but it I mean from my perspective and I it doesn't seem like it um it seems like one of the only eip's that won't delay withdrawals to quote Sarah um and so just to get some consistency it'd be great to understand like who who thinks it would delay withdrawals because it's already implemented everywhere it has uh a lot of test coverage with ethereum tests

um so I just wanted to pitch and understand like why we think it'll delay withdrawals if it's included

Tim Beiko: uh Marius

Marius van der Wijden: yeah um so I think it already deleted delayed withdrawals um and I think a lot of the other eaps already did loaded withdrawals by the way um I think one of the big issues I have with the 1153 is that um kind of from from a process perspective uh you've and like other people from uh uni Swap and and optimism have been pushing that very very hard and it's

I don't think it's a very important dap it's like a really really small Improvement to the ethereum protocol and so just having like just schedule like the like the technical part is only one part of the equation right and I think the bigger part is like the the Headroom and the the like thinking about it trying to schedule it uh trying to test it trying to test it in uh together with other eaps that's kind of uh that's kind of like been my concern and then of course the like the concern that uh solidity still hasn't declared that they

can use it or that they are going to use it um I'm not saying we should make a decision solely based on what solidity thinks but I think um in order for this EAP to be a positive for the network we need to have buy-in from the big language teams and I have not seen that and that's why I'm a bit hesitant to to to schedule this anytime soon

Micah Zoltu: other than other other thing you mentioned at the end are all of those or none of those or some subset of those things that other people could do or some of them things that only get team members can do

very good

Micah Zoltu: like you mentioned like testing and stuff like that are these things that some third party could pitch in and do or are they things that you really want the the guest team specifically to do like for example PR reviews a lot of teams prefer to have someone who's on their team do the pr review they don't want an outside contributor to do PR yeah definitely like we cannot ex we can work for testing and other things or um what can't be outsourced

Marius van der Wijden: no I think like some testing can be outsourced but um in the end uh those people like those outside people are not the people like paying the price if something goes wrong it's it's it's us and so it's very important for us to also have a look at it

um

Leo and then Sarah hey I

just wanted to quickly clarify uh from this from the saluted perspective there's like two sides of this thing there's a personal opinion of team members like me Chris or Daniel about the AP itself and whether it should be included in in the current shape or not those kind of things on the other side solidity as a tool would of course um include transient storage if it gets in um this is this is not a discussion right so if it goes in the compiler will at least right away support the basics which is just like add the up codes or support it via for bottom which is which you can already use at the weights too

and what would take a longer amount of time is just like using it like supporting it properly in the optimizers and this kind of thing so um yes as far as support goes there would be immediate support in like very very basic support and it would take longer to fully support it in the optimize those kind of things and there's a different thing which is a personal opinion of team members um on the EAP itself thanks for for sharing

um Sarah hi yeah

Sara Reynolds: um more of a response to back to Marius it it sounds like a lot of your critiques are mostly around sort of the

the rallying and and who's implemented the EIP which I don't see you know that doesn't have a lot of technical Merit in it and I actually think it's been an EIP um you know that that can set the precedent for having outside contributors um you know non-client devs work on things like this and so I yeah I think that um you know it's been awesome to see that from the community and um would like to see more of that from other APS I think at this point it's ready it's done it's been tested it would not delay withdrawals and I don't really see any technical Merit in pushing it past Shanghai

Tim Beiko: I guess there's any um client team feel like we should bring it in and that they have the bandwidth I think to me this is like the main thing is just you know eof already feels like it is somewhat of a stretch and that you know we're having pretty and specific kind of gates uh that we want to see and you know we have high confidence but not certainty that we can reach those Gates so like does any client team feel like adding 1153 alongside that would still mean you know we have really high confidence we're going to reach those Gates

Marek Moraczyński: so I I read some discussion uh that

Martin from geff team had some concerns about the CIP however I don't know details but if the concerts are valid I don't know

foreign

Andrew Ashikhmin: I agree with Mario's I I think it's about the Headroom so uh to my mind uh if 1153 might be a good one but it is not important enough to like to occupy our Headroom for with it in Shanghai we have in Shanghai is already for the draws and the of let's concentrate on that that's postponed 1153 and like stop

wasting our time like let's concentrate on Shanghai please

Tim Beiko: okay so I think you know just uh we only have five minutes left and there's two at least Shanghai related things that we we need to cover so like my understanding at this point is for Shanghai what we want are the currently included EIP so the ones that we're already in uh so this is the warm coinbase one the push zero limited meter init code which are I believe already implemented in pretty much all the clients uh obviously you want withdrawals which is the main thing and then we will add the five eof eips

um 3540 3670 4200 4750 55 54. 50 for the five EOS VIP is that uh people have been working on and then if we don't have those implemented in clients and kind of well tested by the first uh by the first awkward Dev so January 5th we remove it uh so we remove eof to be explicit um then assuming we are in that spot early January um right after this first awkward devs we started working on cross-client interop if we get to the second awkward Dev um if we get to the second all core devs then um we uh we and we don't have cross-client interrupt we remove eof

um to make sure that we don't uh we don't delay withdrawals um does anyone have a different view of what just happened that's my rough understanding at least for Shanghai

can you play that through for 4844 yeah alignment there yeah

Tim Beiko: so I think for 444 um so assuming this is all like we're on the same page about this for Shanghai we would say 444 is the main thing that goes into the next upgrade we'll figure out some way to specify that on the El side because it doesn't currently exist um but I think we have a commitment that that's what we want to do

um and then given we only have three minutes left I don't think it's worth discussing today if there's anything else you know we want a couple um in that upgrade but I think early January this is what we would probably discuss on Awkward devs you know like if stuff like 1153 for example should also be kind of uh included uh as part of this this next upgrade um but I think for now having your commitment on the specific complete scope of Shanghai and a commitment on 4844 being included in the next fork and kind of the main thing there are the two bits that are really important and thirdly having um clear dates that we want to achieve for eof being part of

um for eof being part of Shanghai and then removing eof if it does not meet that and the implication being I think like we just heard that client teams will not be able to consider other things for Shanghai so if eof doesn't make it then this implies that like Shanghai is just literally the four small eips um that are already included so worm coinbase push zero limit init code and withdrawals um 30 dollars along recap but does anyone sort of disagree with this View um Antonio you have your hand up

Antonio Sanso: yeah thanks a lot for the recap team

just like we want to add like if we can have a kind of mild Commitment if uh with the next like uh upgrade of EIP for 844 if we can have like as well eip2537b plugin in consideration

Tim Beiko: yeah let's talk about that early next year um I I think it makes sense you know if we are this like if we've agreed to make 4844 kind of the center of the next upgrade there's definitely a bunch of other stuff that's like you know really important like 1153 like 25 37 and whatnot I think it makes sense to have a conversation about whether we want to like proactively include some of those as well to give kind of clarity to those

themes I just don't think we have the time to do it in one minute today um okay but yeah let's let's do that already Jan right and uh I think the two things hopefully we can discuss today um even if it means staying on for an extra couple minutes are the timestamp forking spec and then get payload V2 um with the the build block value um I guess with regards to the timestamp forking Marius I believe you said in the chat earlier today you're gonna come up with a spec for it like an extension that's what exists you want to

give a quick update there

Marius van der Wijden: yeah I'm going to write an EIP I have an implementation guess and so I can also add the test vectors to the AAP for the fork ID uh based on with based on timestamp

Tim Beiko: okay any questions comments there okay and then last topic um for today uh get payload V2 with the locally built block value do we want to have this um as part of Shanghai basically the clients want to implement this now have they already implemented it

um I I think nethermine said they had um but curious to hear from from other teams

Marius van der Wijden: we have it implemented not as uh not as part of Shanghai yet but um it's like a separate thing but I'm going to move it to the Shanghai branch and we should we should finalize the spec

okay

Marek Moraczyński: so generally the next withdrawal devnets should contain this change right Marius

uh yes this and the I did change and uh get payload bodies

Marius van der Wijden: and get payload bodies yes

Marek Moraczyński: yeah okay I'm okay

Tim Beiko: anyone oh sorry please

Mikhail Kalinin: yeah I just wanted to put it another way it will like this block value and get payload bodies delay in high delivery when I hear from

you and that's

Marius van der Wijden: it's super super easy

Potuz: so do we want to include this in the next japnet this week or next week

Marius van der Wijden: I would hope so yes

Potuz: okay

Marius van der Wijden: I think Aragon was probably would probably be fine with it piso I don't know that they don't have on

timestamps yet so it might be bigger um rework for them

yeah

Danno Ferrin: under review

Marius van der Wijden: perfect

Potuz: so the working on timestamp is not so bad because you can just jumping on the devnet but it's already been running and it's already forged but the other one is bad because we're gonna bailed out on blocks that are missing or having the extra field

Marius van der Wijden: not really if we if we do the if we do the I did changed and also like this

phone

Potuz: you're gonna have to have the hash yeah right

Marius van der Wijden: yes exactly

Miguel yes

Mikhail Kalinin: um just want to hear from Aragon and Basu about block value and get payload bodies the confirmation and from them that wants deletion Hive from their perspective if you need time to think yeah just reach out and Discord

Andrew Ashikhmin: well it should be okay I just I'm not sure I think Julia mentioned that we have a draft Pi I have to double check whether it is that's the case but in theory it should be fine

yeah

Marius van der Wijden: so um for those underwear get Block bodies just Returns the block bodies uh of like

you you give it a hash and it Returns the transactions and withdrawals and um uh the other one sorry what was the other one a block value block value oh yeah yeah exactly uh you just return the value of the block basically that the the the transaction fees that you give to the to the coinbase and uh you you return that in in in in in the new uh in the get payload call so you have you have to compute that value already you just have to pass it to the caller

Andrew Ashikhmin: okay should be straightforward

and for bezu yeah come straight forward

to us as well I think

oh

Mikhail Kalinin: so let's just consider them to be included in the Ash and high spec and if we see any issues with that in particular delay in uh Shanghai because of more time needed to implement this the methods and two additions to engineer buy then we can we consider

yeah

Tim Beiko: sounds good anything else people want to bring up

quickly before we wrap up okay um there were two oh sorry Alex yeah

peace

Alex Beregszaszi: oh maybe you were actually bringing it up I um the 646 I wanted to just um 30 seconds

yeah go go for it um yeah

Alex Beregszaszi: yeah I'm actually not so 60 46 is a alternative to the previous self-destruct uh removal eips I didn't wanted to bring it up for Shanghai I really wanted to bring it up um just mention it that there's this alternative proposal and there has been

quite a number of discussions about it on ethereum magicians and um yeah I just wanted to let everyone know that um it would be interesting to discuss the self-destruct topic uh once more probably not on all codeps but you know in the coming weeks and months

Tim Beiko: yeah I think I I agree and I think that's something also like in like when we start looking for the next Fork uh clearly all teams felt like doing something with self-destruct sooner rather than later was really important and um and so that might be the type of thing we want to uh also like include alongside 4844 in in a future upgrade

um yeah so the link to the APS in the agenda uh Leo your hand is up as well

yeah just wanted to yeah quickly also support six six uh three it's a very small change that has been accepted in the past and depended on account versioning audio app or something like this and if you have UF I think it's a very um clear Next Step that would be great to add and it would massively Aid um every AVM high-level language and also users

okay yeah

Tim Beiko: so people also should review that one um and um yeah I think early next year we'll probably discuss all this cfied stuff alongside those two so I would I would

encourage folks to have a look um and then beyond that there were two other small things on the agenda we didn't get to that people should have a look at so first is a new uh endpoint uh called ether counts um proposed by uh Martin um so if people want to review that async and then second um there was a new EIP that uh wanted to discuss on the call but we've bumped it two or three calls now already so if people want to look async at eip5988 this is a pre-compile for the proceed on hash function which would help ZK Roll-Ups

um to be clear though you know none of these last ones are what um would be it would be for Shanghai but I think it's good context to know that they're being proposed when we start discussing um things after Shanghai earlier uh next year and then I thank you Proto for posting um your view of the the timeline uh on on the agenda I'll make sure to review that I haven't had time to actually read through this during the call um but skimming it quickly it seems uh seems roughly right anything else before we wrap up okay well thank you very much everyone

um there is a CL call next week as a heads up uh but then no awkwardevs until January 5th um we'll see you all there um yeah thanks bye bye everyone

hello [Music] foreign

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

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

[Music] foreign

[Music] [Music]

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