All Core Devs - Execution #185

Transcript

[Music] time J

[Applause] h for

e oh sorry my bad okay YouTube audio should be back

Tim Beiko: um okay I was just going over what's in the agenda sorry about that um but yeah we're going to talk

about the scope of the fork today um and mostly focus on like what client teams want to see alongside what's already been included and then the last thing is yeah there's been a couple updates on uh a few specific eips so um we'll make sure to cover those and I think if we can end today in a spot where like 90 95% of the for fork scope is set at least on the El side um I think will be in a in a good place I know there were some discussions about like uh The Blob count in the R&D Discord so it feels like if we if we can get most of the scope done today you know maybe in a few months we can do a small tweak to the fork at like a simple EIP but um if we

don't want to delay things significantly all of the like big large changes should be should be figured out sooner rather than later so okay the kick us off um there's been uh there's a couple updates on just the eips that are already in the fork um there's been a lot of discussion around Max CB these past couple weeks uh some of which might affect um the El side Alex you put together a dock explaining how uh or what the implications would be and sort of questions around uh if we want that add El consolidations uh to 702 to help with Max CB you want to give a bit of context

on this

Alex Stokes: sure yeah so I don't know if anyone was on the most recent Maxi breakout call maybe if we give like a short update from that that would be nice um but yeah I was thinking I think the other stuff's probably more important to discuss so let's not linger here too long um and maybe if there's time at the end we can Circle back around But ultimately yeah so there's essentially demand from staking pools to change or at least like extend how Max EB would work with the introduction of uh another like execution layer operation uh for this notion of consolidating two

validators into 2 one and yeah the doc is just like a quick sketch of what that could look like um I think for us today mainly I just wanted to get it on people Radars and also just you know do like a quick temperature check like do we feel like this is something that we can do uh it would mainly be changing the predeployment

seem

Tim Beiko: like it and I guess the reason I

wanted to flag this early on is um obviously if this changes like the scope of of 702 we we need to consider that in like you know the the broader Fork context but

Alex Stokes: right yeah so I think there's still some questions on Max CB that we're figuring out the best way to handle you know there's like we could say hey Max CB is like big enough already there's nice to have features but we could put them in like a future fork or something like this um but yeah just something to to keep in mind that there might be and with this in particular there's not that much like there's a little bit more the CL has to do but ultimately

with the eel yeah it's all kind of contained in the

predeployment

Tim Beiko: in the chat about having a more generalized message bus uh by vili from from Lio um I don't know if you want to take a Yeah couple seconds to like talk to what that could look like

um yeah uh it's it's not ready right now it's like just in uh in the back of my head for now uh had the idea uh this night but um I think I'll try to bother Alex to uh review it uh when it's ready if that's okay

Tim Beiko: yeah awesome

thanks um okay so that was the first uh Petra update uh second Alex you had uh you had a 2537 BLS uh precompiled one as well

Alex Stokes: sure yeah so this can also be pretty brief um we've done a little bit more work on benchmarking the pre-compiled and figuring out you know if we need to change anything or what that looks like uh I think after some various discussions I think the EIP is pretty much going to be as is um there's this notion of like subgroup checks and this one is kind of I mean yeah like the core issue is we could put them into the pre- compiles

and things would be like harder to misuse by people you know users but uh they'll be more expensive so I think Antonio's done some benchmarking work and basically found that we can get them pretty cheaply for some of the promiles uh except for the addition ones so so yeah either way just wanted to give a short update there and yeah I think from there the main thing left would just be finalizing the gas schedule but otherwise yeah that one's moving along

Antonio Sanso: um Alex I just want to add something I agree with you with what you've been saying about subgroup checks I want actually to raise something that I spot today and it's not about sub group check but it's about the gas of

the pairings and it's something that danr has been mentioning uh a while ago so basically if you see the point evaluation precompile gas on 4844 it is 50,000 of gas and so and it is will be basically that is two pairings and D was saying that uh would be nice to have the gas of the 484 of the 2537 pairings compatible with that gas but in our case instead with the current gas two pairings corresponds to 151,000 gas so it's kind of bit awkward to have like the same operations

I mean two pairings in one side paying 50,000 and in this case 151,000 so I just spoted today because I've been writing the T vectors

and uh yeah we yeah

Alex Stokes: yeah I mean I I hear that I mean we could kind of claim that we're subsidizing the 444 stuff with the lower gas cost but yeah um definitely something to to look at

I will

Antonio Sanso: I will raise offline as well in the in the gab there's no sense to waste time here for this but just want to like to mention this

Alex Stokes: yeah thanks

Tim Beiko: okay thanks um and then the last

thing I wanted to cover quickly was um the devet zero so as I understand it uh no team has implemented like all of the eips that were included already on the I think on both sides there's still a fair amount of of of change in the specs but um is that a correct assessment are there any updates beyond that um yeah are are are there any updates Beyond uh just people are working on it or any questions or blockers that people have okay

um okay I guess anything else people want to discuss on the eips that are already uh included in the fork if not um I think the best way to do this with regards to uh what else do we include um is to zoom in on the few eips which seem to have like broad support although not unanimous uh at least the start um so every single team on the El side sent in a a sort of list of preference and and um stuff that they like really want to see in the fork stuff that they're sort of neutral uh towards and stuff that they're against um skimming through all of this before

the call um it seems like there's three that sort of stand out where most of the teams support them but there's still like some you know teams either objecting or or you know ambivalent towards it um so th those three are like 3074 eof and 2935 um I think it probably makes sense to start with just 3074 because this is the like most complex of them and I think if we went forward with this would affect sort of you know the the bandwidth and and and room for everything else um so on on that front uh it seems like uh Aragon Bas Su nether mind and wath were in favor of included

of including it and then um and then um um gu was the one opposed um so I I guess maybe let's start with like let's start with gu uh if someone wants to make the case like why they don't think it it should be in and then we can we can sort of take it from there um and reading your doc gu it seems to be about it being too big but also the interaction with burol I don't know if anyone

Guillaume Ballet: oh yeah I I can uh I can address this I thought we were talking about uh

another another one sorry uh yeah so there's been this conversation happening a couple months back and uh I raised some concerns that uh yeah it might it might paint ourselves in into a corner for a for veral later down the road uh I didn't see any uh any progress on this front uh the E spec uh is not uh when yes it's supposedly complete but there hasn't been some uh some any implementation to to speak of there hasn't been a test net there hasn't been any um any uh uh noticeable progress at least if there was the case uh it hasn't been brought to my attention um and we feel that that this

is a big change the initial design or the initial intent behind uh behind the prag was to make a small feature Fork ahead of veral um that really goes against this this objective and as a result we we oppose it

Tim Beiko: got it um I guess in terms of like the progress and the implementations does anyone on the eof front want to talk about that

Danno Ferrin: sure I can talk about it um as far as implementation Basu has a complete implementation um it's on a branch right now Mega eof um if you were on the calls um we we talk about it frequently R's implementation is almost

complete that's also the um there's also a uh uh status checklist we've been attaching with all of our updates for eof as far as which clients have been working on it um as far as the verical compatibility um one thing is that the current uh formulation of how we're going to store the story for eof fv0 is a bit of an overfit on the Legacy dealing with the whole jump test analysis leaking into there um we can continue to use that for eof if we need to there are better ways to store it but if we were to use the existing way that the storage was going to be stored in um it's 100% compatible it's just data all of our overhangs would be zero there's no jump Des analysis so as far as fitting EF into veral with that concern

um it's uh it's it's not ter terribly um difficult I mean there's better ways to do it but the way that exists right now can be done just fine and I know there's been discussions with um um as6 been talking about possible ways to do an eof V Zer where you could encode the jump Des encoding into it as a wrapper um but you know my understanding is that you know it was uh given us ideas to the verical team to see if they want to pursue it and there are other issues that were being pursued at the time um so the concern was uh implementations and vertical integration was there another one that that gim listed

Guillaume Ballet: uh yeah I mean when okay it's not exactly another one it's veral integration I I uh when I said I wanted

to see veral integration I wanted eof implemented on veral test net that's that's what I clearly asked for back in back in the day so uh yeah integration is is not happening it hasn't happened

right but at the same time if we don't

Danno Ferrin: that totally feels like gold poost moving to be honest but I'll let Tim talk

Tim Beiko: yeah I guess what I was gonna say is like you know we don't like we don't speculatively Implement eips on like the next fork and I understand that like veral is is a bit different here but it feels like the best way to actually get there is we would have eof as part of pectra then all the all the Petra builds would have eof and then veral Builds on top of

pectra and um by default it gets EF um so like yeah I I don't know like otherwise it you know we're sort of asking all the client teams to like speculatively Implement eof on the devet for two forks from now which seems uh like unlikely anyone would would prioritize in terms of resources um is there like a specific thing you're concerned about with regards to veral G where like why

Guillaume Ballet: yeah I mean like like I said so first of all no there was no go posting no go go post moving it was actually said uh on the during the ACD the last ACD we talked about uh and and second uh

what what I'm concerned of is that the the argument that was already raised back then is that we pent ourselves into a corner we Implement some uh some hand wavy version of of EF and we found ourselves blocked we realized there's a problem and veral can no longer happen I just want to have this cleared out that's all I'm asking

Tim Beiko: I guess what what would be the what what would be the the thing from eof like I guess yeah how is yeah what would be the thing out of from eof that affects basically how the veral tree is constructed or migrated that like you think is there like a specific area basically that you think

uh or a specific I don't know part of like the eof proposal that you think like oh you know if we do this thing then that actually overlaps with like how the veral migration happen happens or like the um yeah the the way State access Works um I mean

Guillaume Ballet: to be to be fully convinced I need to be able to have ANF test net that converts to to veral and we find out there's no problem um but even even having a proposal of uh veral enabled like even a spec would be enough I I haven't even seen this all I had was and wav thinks that this should not be a problem

uh but I don't even know how to implement this if I was I have no spec to work with so yeah yeah even having this I cannot agree

Tim Beiko: yeah on on on that front um so there is the Mega spec for eof but Dan do you maybe want to like dive a bit more into that like what the current spec um includes um what like EIP is map to it because I know that that has CH that has um changed a lot um yeah in the past like six months or so so I just want to make

Danno Ferrin: sure like yeah we're so it started out as kind of a modular um eof um because there was a lot of features we could add or remove out of eof and the ipsilon team is trying to figure out what the scope they

needed so they took all the parts that could be severed and they made separate eips out of them so that I agree that contributes to some of the early confusion about what eof is what features are in and what features are out um once's it an out it's been fairly well settled um the uh implementation metrics that I've been passing out um has all of the eips that are in um the uh there is a megas speec uh let me find I can once I stop talking I'll find the link for that on the ipsilon website that lists it in one concise unified document but historically because it was pieced out in separate eips um we have that there we go uh uh that's not the current one there's one on on GitHub um which we've been referring to in all our past meetings I'll find that one but um

yes that one um and we've been using eof um you know there's a unified spec and then we've been splitting it out to the EIP to respect the historical separation of it um so there is a spec um and it's been implemented we were writing reference tests they just merged a bunch of reference tests for uh the container format into EIP into the ethereum test uh Network the test the test repo uh just the other day um for some of the the things we the stage we're at is we writing reference tests for this um bases reference test uh apart from Bugs we find during testing um has has implemented all the IPS um reth is mostly there I know nethermind and G for Mega EO not for Mega for big EF which was back in Shanghai they had complete

implementations and there's just you know a handful of things that need to be changed to support um code introspection uh blocking code introspection and blocking gas introspection so the major work of building the container is is done for most of these clients um but I agree it's kind of a moving thing because we took advantage of being pulled out of Shanghai to put features that were requested for in to make sure that the one breaking change for ethereum virtual machine is done with all the things that we need now so that was bringing in code introspection rejection gas introspection rejection um and making sure that you know we had all the analysis we need for the things that we needed um and so that's why it seems like it's been moving around B because we took the time that we were given um by being kicked out of um Shanghai and

then not considered for um for Cancun to make sure that we had all those features in but what we have now is is is what we intend to ship for

prod got it um one one

Marius van der Wijden: one thing that like how how many new new up codes would um would uh this add or like how many how many new versions of up codes are being touched by this by the Mega um new versions of

up codes

Danno Ferrin: I had a chart um so if you're judging it by op code number it does sound larger than it is but all the implementation is reusing existing stuff

um so there's the three ones for the call that we're changing um we're adding 6603 Swap and dupen um we're replacing the jump op codes so there's another uh three there and adding a vector jump op code which is something that's been requested by a lot of um a lot of people so that there is we're only touching the things we have to touch because of the container format and these are features that have been requested since 2018 at least I think is that current list the Tim just back yeah so it's 18 I think

Marius van der Wijden: yes and like so my my concern is that for Every Time We Touch an up

code uh there's a risk right and I don't know we we're we're talking about sorry we're talking about um um I don't know the the TLO T store repricing that is one single op code that has like a whole debate around it um or we we did the analysis for the payop code and we found out that it can be like called in like 25 different contexts and um and they each interact with with each other and just making a full table of in which cont can this one op code be

called is already kind of extreme work and so I I just don't see that our like spending our time there is more beneficial than than spending our time uh on other features and this is this is not and this is not only like the time to implement it but especially the time to uh to test it to make to Benchmark it to make sure nothing breaks um yeah that this this is kind of my view I don't know anything about don't

know much about worker so I cannot speak on on y's concerns about worker but those were my concerns when when saying uh we wouldn't like to get URF in

Danno Ferrin: okay so it's it's too large as the complaint and that in some sense that's a bit frustrating to me because we came up with a smaller patch um back in Shanghai and then other people requested it to be larger and we just can't get a consistent request on what people want out of eof um from the allore devs group so that's it's kind of frustrating to hear that from both sides and they're both valid complaints but you know the other option is to aify as it is now and I don't think that's a good place for ethereum I think it's going to put um it's going to drain the mo of what we have for the evm and the greater evm

ecosystem if we freeze it where it is now

Tim Beiko: I guess on the on the testing front like is this something that we have like significant test vectors for already like for example you know if we are changing the behavior of like 18 up codes um do we have like reference tests for all of them part of them none of them at this point what's like the the status there

Danno Ferrin: so that's where I'm working at right now writing the reference tests for these and helping um ipsilon write the reference tests and get some of these features out we just pushed a bunch of tests for the uh the newest test surface would be the uh container format and back in Shanghai there was um

a fuzzing setup done so we could test the container format from a fuzzer and found a lot of stuff um as far as fuzzing the op codes um the same fuzzing Frameworks that work there can be easily adapted I think the best work we're going to get in addition to writing deliberate reference test the test the spec is written is the fuzzing and that's where we're going to find all of it those um you know the fuzzing stuff is is an understood problem just needs to be adapted for the structure of the eof um and you know a couple more things written to make sure it works well with the eof

Tim Beiko: got I guess one thing I'd be curious to hear as well is uh so it seems like w and nether mine uh alongside with basically both have pretty Advanced implementations like um do either of you

want to talk about like what you see as the current state and like the current like potential risks or open issues yeah

Merck

Marek Moraczyński: yeah so we are not against e and it definitely adds value but the previous commitment from fin teams was to do small fork and do verle 3 as soon as possible if we add EF here then we can think about Petra as medium or large work and our implementation is up to the latest spec but uh e brings a significant risk of consensus of consensus issues which will

require lots of testing and it it cannot be rushed so on the other hand we know that if we do not ship EF now uh we will wait two three years of uh C on Main so that is why we are um we we see two options here uh we can Implement a medium large Spectra with ef and sacrify testing capacity for vericle and maybe IP for force uh continue with uh verles in parallel and immediately after pectra uh focus on for force and even more

focus on verri or just do as we planned before so small pectra work on ver verle parall delay e and release it after verle hard for I I think both options are good but yeah that is how we see that

Tim Beiko: got it um and yeah I don't know if anyone from W or argon has thoughts you want to share

Georgios Konstantopoulos: uh I'm not sure if dragon is on the call this is Georgio from re uh we already have a work in progress eof implementation and we are generally

supportive of it we hope to have something done and merged in the coming weeks

Tim Beiko: okay and uh yeah anyone on the Aragon team

uh so for Aragon uh we have parallel Works going on for both veral and e so uh we favor e for uh Petra because verle uh seems to be pushed uh and I know why you know the scope is increasing uh but I think we can pull

through uh that's about the comment from

Aron

Tim Beiko: got it and then yeah in the in the chat um there's uh there's a comment about um yeah like the cross client testing being the bigger lift than the actual implementation so like it seems you know from this that like most client teams can get uh yeah can get an implementation fairly easily but then testing things uh will be will be uh will be a lot of work um I feel like instead of making a

decision on eof right now it's probably worth covering some of the other eips that people were like on the fence about and see like getting more context around those um and then coming back to seeing like do we want to include any of them or eof because eof being so big uh I think means like you know if we go forward with it there's probably a lot of stuff we have to push out so I want to make sure we understand what we'd be pushing out or trading it off against so any I guess any other just like comments thoughts on like the Readiness or concerns around EOS EOS eof okay um yeah thanks everyone for for

sharing your your thoughts on this um the next one that um pretty much every team seemed to be in favor of was 374 um the one caveat so re had a R's preference post was was a bit old it was from like January so uh their stance was like we want one of the account abstraction eips but not really uh uh you know specified which one um in January we were still going through a bunch of different ones and debating them um it seems like 3074 is the one that all the other teams would would prefer to see today um so I guess maybe maybe to start there like on the red

side like assuming the other trying teams like 3074 and would want to move that one forward um is that one that like you're still comfortable with and and would be happy to to see as part of fork

R

Georgios Konstantopoulos: is supportive of 374 and only 3874 3074 for the next hard fork and we already have it implemented and tested

Tim Beiko: okay um so I guess yeah do you any of the client teams feel like we should not do 3074 in the next hard Fork I know in the chat a bit earlier there were some concerns around some of the uh security risks and then a bunch back and forth there I couldn't read but uh we've

talked about the security risks of 3074 for a few years now um do people feel like we're happy to move forward with it even you know being aware of all of those um the does anyone have any more objection or things you know that they feel uncomfortable with

Danno Ferrin: my objection was always safety oriented and to move to require the current notes to allow it to um require the current notes allows for single action revocation which is what my big ask was and that's been delivered so my past concerns on it have been resolved by that action

uh

PR

Protolambda: hello I'm in favor of the EIP but I am concerned about the The Edge case of not being able to enforce as a as a contract that some data aesthetically declared in a transaction like the top level call detection the lose with this EAP um I drafted a e for a replacement but there might be other options too um having some sort of you know fallback for this feature would be really useful

Tim Beiko: uh Marius

Marius van der Wijden: so uh why I'm General in favor of

uh 3074 one thing that I would like to remind everyone of is that like it's something that came up during a lot during the our work on inclusion list and I'm not sure if all the client teams are aware of it um but with 3074 um the design of the miner is kind of more complicated it makes block building more complicated because you can have transactions that invalidate other transactions um and you don't have that right now well you kind of have that right now but only uh with transactions that are from the same sender with uh

low ances and um with um with 3074 basically transactions can invalidate arbitrary many transactions and the transaction c um it can be mitigated by by the transaction pool it's just something that um that we need to think about uh when when when designing our trans section pools to to make them V ready uh sorry to make them ready

Tim Beiko: got it um and then uh there's a there's a comment by yav uh about the blob inv

validation I know there's been like a lot of back and forth on this um yeah y have do you maybe want to just give a quick overview and then yeah we can take it from there

Yoav Weiss: uh yeah the concern we discussed and I think we we discussed it on Discord already uh is around the invalid around the denal of service against the M poool using U by sending a lot of blobs and then invalidating a large number of blobs from a single uh from single transaction using a value transfer in 3074 o and O call so uh so we have a rule we have a rule to protect against uh against that using blood

using uh requiring a 2X 2x fee increase for blob for replacing a blob but here we can bypass it for a for a large number of transactions now as as Matt suggested H it's already possible to invalidate to invalidate them by sending a a private transaction to a builder uh that replaces the current blobe but This only affects uh This only affects the blob from the blobes from one EOS and it's also more expensive because you need to pay the block Builder whereas propagating a lot of mle transactions that each of them invalidate many blobs is a much cheaper

attack

Tim Beiko: um Marius are you did you want to respond to this

yes okay

Marius van der Wijden: yes I want to respond to this um yes uh that does have implications but um at least and like we created a Benchmark for it or I created a benchmark for it in in the guest case and I think it takes around a less than a second to uh if I create a block full of e uh 37 sorry 374 transactions that invalidate uh the maximum number of block transactions um the thing is in in gu we in our block pool uh

implementation we don't delete the block transaction we just tomb storm them and so uh sending sending these kind of attack uh transactions does not make us do a lot of work um it just means we have bunch of junk on the disc that is not cleaned up that is overwritten the next time we we we write uh correct block transactions it does one one one one thing that that might be concerning is um if we do reorgs or like how this interacts with RoR I haven't tested that

where we kind of have to resurrect all of those transactions

Yoav Weiss: and uh did you also uh did the test also cover the peer-to-peer the communication layer uh like the load on communication layer of propagating a large number of blobes that end up unpaid

no

Marius van der Wijden: no but like you can kind of send them right now um we have to prevent spam on the on on the on the networking layer anyway um and the way we do it is

just check if we have uh like if the if a transaction is a blob transaction and if we have the band with to download block transaction and then we fish them so this like uh this this case is not worse than just someone announcing 10 gabt of block transactions to us I think

Yoav Weiss: all right thanks for explaining

Tim Beiko: okay I guess yeah given this um yeah I'd say um 3074 was probably the EIP that had like I think it was the

only IP that had basically unanimous support from all of the client teams um to be to be included so does anyone object to including it um I think this is one we can probably make the call on right now if if we're happy with it so any objections to including 3074 in pectra otherwise I think we should move forward

I

I was hoping to hear uh what 374 plans to do with origin if they could clarify that

Tim Beiko: um yeah I guess if someone has a quick response but if this is a okay it's in the EIP so I

think yeah let's yeah let's have this offline I think everyone has like reviewed the EIP and um all the client teams spend time on it so if there's no objection um yeah let's um yeah let's move with uh 3074 in Petra um so that's one down um the next okay so yeah 374 is in um any final thoughts comments I think we're good on this one okay and the last one I want to make sure that um we cover that a lot of teams brought up is

2935 um so this is about saving uh the block has in the state um basically uh I think like G nethermind basically were in favor uh Aragon was like ambivalent about it and I I don't think we discussed it when like uh Rett put it right up together so um yeah I guess I'd be curious to hear about either uh oh and sorry eum j also in favor um I'd be curious to hear yeah either Aragon re any strong views on this one sorry which one uh 2935 which is about adding uh the block hash as part of a contract in the state um and this

was especially useful in a veral context now where it can allow us to keep uh the block hash op code um or to yeah to keep the

blackash up code behavior

Georgios Konstantopoulos: um yep uh R neutral positive same simple change it's very similar to how the Bon change is all the beon route thing is also implemented if people wanted were down

yeah um Aron for yeah uh yeah

similar views uh it's small if uh the bigger ones are not included we can give this one a go uh you

know that's RV it's it's not going to make a a huge difference

Tim Beiko: okay but but so say we did like eof for example you think that would like maybe be too much so you'd rather like there's like a trade-off between like doing the small one and then potentially having like a bigger one included is that what you're saying

uh yes so if you potentially are thinking about T I think most other eips uh can sort of jump out of discussion uh for the next hot folk maybe okay and given the fact that you know we're not in a rush to do verle anyway so uh later on we may or may not make small changes to the EIP uh and

Associated things like testing and stuff so it's going to evolve again in our opinion got it for the next hard FK when you know work is actually implemented

Tim Beiko: got it okay

I have to I have sorry

Guillaume Ballet: I have to descend with that it's currently being used on the veral test net the the IP as it is specified will not evolve um there's there's no there's no event that let us anticipate that this will ever change it is currently being used on the

veral testet

Tim Beiko: okay nice um I guess yeah if we feel like this we might want to like uh

um that that this you know we might not want to do if we do other larger things I think I'm happy to like go through the other couple eips that we wanted to discuss and and we can end up uh we we can come back to it and and make a decision a bit later any objections there okay so these were okay so these were like the three big ones that uh basically all the client teams had like uh preference uh towards um I think um there's there's a couple more that uh people posted updates on that it is worth probably covering real quickly um let's start actually yeah um so

vitalic had won 7667 uh which proposes to change a bunch of gas cost to make them more H snark friendly I don't know if uh if italic on the call but um I think that the EIP itself is pretty straightforward so any thoughts from client teams about this one um okay if there's no oh sorry D yeah please I didn't see it

Danno Ferrin: so um on some of these magician threads um it seemed like this also be pushed out to um one of

things he pitched was having a lot of gas changes with the vertical fork and Osaka um since we're dramatically blowing up the gas schedule with the way that we're accounting for trees and storage um it seems like a good place for it um since we're going to dramatically blow up the way we charge for hashes so I mean I think that's one that um we could list as you know good we just need to schedule it and get the exact um values for it down I I kind of agree with it

Tim Beiko: any other if it has a place I don't know if it has a place in um Prague though yeah any other client teams or people have thoughts on this

uh oh the D might pop in but yeah I also um um oh actually yeah Carl yeah

Carl Beekhuizen: I um I think it's a a good idea from the perspective of um snuck ifying stuff but it is very extreme I think we need to like do a lot of Investigation onto the impacts of this uh hashing is one of the most core uh features that pretty much every smart contract uses at some point and so I think we need to be very careful about doing the analysis on exactly what's like who's affected and how much um it's something we've had from the very

beginning and I think as a one of those assumptions that's very much baked into the um many

many contracts yeah marus

Marius van der Wijden: yes I kind of feel the same way um and I think like I don't think we should uh we should price stuff for a potential future um but for the costs to the notes right now and the cost to notes right now uh the pre- compiles are kind of or the the the operations are kind of priced correctly so I think if if we

were to reprise it it should be at a point where we either see a bunch of of ZK EVMS or we even think about ZK evm ifying um mayet itself so um yes that's kind of that would be my my point

Tim Beiko: got it um Dan know did you want to respond to that

Danno Ferrin: I just wanted to say that the hashers are like the most impossible things to optimize because almost all the clients are already using well optimized implementation so speeds never going to go up on these um maybe to get the VM to access the hash but um if we need to increase the GPS um then a

change in the gas costs um would be valuable but I generally agree that Frog's probably not the right place to do this

Tim Beiko: yeah I guess on I had a a suggestion in the chat where like um we are going to repic at all the things with veral already in Osaka um I think in terms of just like user experience if we can if these changes are not urgent um which it doesn't seem like they are because they're mostly to help you know lt's working on ZK EVMS and and whatnot it feels better to bundle all of the large gas cost changes in like a single Fork um not to say we can never change gas costs again but uh for people to

know that like this is when they should pay attention and that there will be significant changes like across the board um rather than trying to like make tweaks in like one set of prices in this fork and then the whole other set of prices in the next work um Carl

Carl Beekhuizen: yeah one quick addition on the L2 side of things um like I don't think we should be making L1 decisions uh based on for for the evm based on pricing that l2s I think can figure out a way of sorting out themselves or we canate way of sorting out for themselves this should be based on the the needs of L1 for

now

Tim Beiko: got it okay so yeah I think we can move on from this one wait um oh please yeah sorry

Vitalik Buterin: I just turn at the right time just great yeah I mean I think uh one so one important thing to keep in mind here right is that I think people are like it's very easy to underestimate the extents to which L1 itself is actually not that far away from being ZK starked right right because uh like right the L1 the cost of staring 30 million gas like for average case stuff has already gone down from I think like something like five hours a year ago to like 20 minutes now and then it just keeps on decreasing

very quickly and and so I think it's very posible to or believe that know even within one or two years we'll have the capability of proving the ethereum one in real time right so I think it's just important to mentally adapt to the fact that like there's no such thing as a distinction between ZK chains and non-z chains like we are basically now entering a mode where every serious chain is a ZK chain and so like ZK friendliness is not something that is unique to l2s it's something that is going to be V well with L ones as well um especially given

the uh underlying goal of trying to increase the ease of verification uh with things like The Verge and trying to support more properly verifying full light clients and and so forth right so I think this is something that is that is super L1 relevant and I think uh the again the goal is to try to like figure out like like basically we really need to worry about the worst case uh rather than worrying about the average case because especially for L1 applications of this actually in a way

it's more important for L1 than for L2 right because for an L2 if you have like one or two long blocks then you can just a lot of applications that really depend on having a like a very fixed upper bound like a theoretical maximum number of milliseconds that it takes to to to create a stark proof of an1 block right so like for example if like when we get it let's say between two and three seconds then you know that gets us to the point where validators and block Builders will be able to take advantage of it so that's how I see the value of that um I see that there's some

discussions in the chat on like receipts and mor Patricia trees and which definitely also has touches on this topic quite a bit I think uh so aside from hash up codes the other two places where a block did have a huge amount of hashing in it I think as I wrote in the EIP spec is number one is the mirry which we're thankfully getting rid of uh with veral trees and number two is receipts and with receipts there's also this uh one very particular annoying challenge

that there's like these hu like these huge individual hashes that could come come up if there's if there is a receipt who's log data is is really huge and I mean of course moving over to SS hashing the receipt structure is going to reduce improve things a lot there but fortunately I did the I did the math and like glog data is already kind of almost at the point of being high enough that it's not the not the primary issue in terms of like bounding ZK proving cost of a block in terms of b z improving cost of a block it does feel like the worst case is just like blocks toate a huge amount of hashing in

them

Tim Beiko: yeah thanks for thanks for sharing um all that all that context I guess this and then based on a comment in the chat around like should this be like a good r as well um if this is something that's like important on you know not maybe the next year timeline but like the next uh few years as like the the the speed of verifying uh go goes down um One path forward is we could try to get this implemented on l2s first um as a signal that um you know they like they actually like endorse those those gas prices and you know they might argue about them and tweak them

and whatnot um and then tentatively commit to doing this in the next Fork um alongside with all the other veral uh repricing so this means that in say you know the next year we can try to to to run like with a version of this on some of the l2s um get them actually like using you know those those values and production and then that'll help us like refine the actual numbers and alongside with the vertical gas cost gas cost changes we can include either those as is or you know whatever tweaked version of those in the next Fork um did people think something like that be reasonable

Vitalik Buterin: yeah I mean one thing I want

to just like also clarify is that like I think it's totally fine if this happens let's say like to in the second next fork in instead of being in the next Fork because uh like there's no point in just solving the evm hashing issues if we the worst case is like 300 megabytes of hashing in the M tree anyway um so I think like realistically the biggest kind of short-term ask that I would love to see people doing over the next month is um actually just like a much more dedicated benchmarking eort figure out two claim two things so

the first thing is basically like what what is the effect on existing applications of uh raising the cost of both cck and other op codes by a particular amount and the second is uh like basically figuring out like on existing ZK ZK VMS what is the uh like what is the extent to which this is a bottleneck like basically what is the fact of factor n by which we can make hashes more expensive at which point something else actually becomes a b neck right and like those two variables are going to be key in determining like what actually is going to like like like both

what parameters make make sense for this and if the results end up being unfavorable also what kind of approach makes the makes the most sense and I know one thing that's come up over and over in these discussions is like l2s want to signal from L1 that they're actually serious about it because otherwise they don't want to spend the time and and whatnot um so I I I guess my suggestion with this one would for this one would be can we just CFI it for the next Fork um alongside all the other veral stuff so that um you know l2s know that like we plan to do this um but also that it's should sort of be on them to like push this forward

before the vertical Forks that like we're kind of happy with um yeah with with the numbers and and um what not but yeah do you think that would help just yeah send a signal to the

AL folks

Vitalik Buterin: yeah I think I I think so I think like I think the thing that the ecosystem needs is just like a signal of like seriousness that know things are moving in the direction of zek starks being like a a first class thing that everything get is is getting designed around and the resource costs are going to be adjusted accordingly and like both for both for ler 2s and I think

ultimately also for L1 focused ZK evm designers and I mean the other third target of course is like solidity and app developers to get the ball rolling on kind of reoptimizing applications around some some of these adjusted costs

Tim Beiko: right so yeah I guess does any client team oppose making this EIP 7667 CFI for like Osaka um and obviously if if we get to that Implement in yaka and we see some issues or the ZK uh approving time has not gone down or what ever we can always kick it back and another or forth but I think

this sends a good signal um and then allows hopefully some of the L2 teams to like make progress on this in the next months uh to yeah to finalize the numbers and do the analysis also against L1 any objection to that okay uh cool so yeah let's see if I this one for Osaka alongside the other

verps

Tim Beiko: um moving on uh the other one which had an update was 7623 um the biggest question there was a lot of the numbers originally were done pre denune and so uh we didn't really see the effective blobs uh on on those

numbers and then Tony reran the analysis um I don't know if Tony's on if you want to give a quick update

Toni Wahrstätter: oh yes you're here yes I can do that yeah so the the result is basically that the El payload size um we got it under 100 kiloby so the El payload size was previously before for it44 it was around 120 kilobytes and now the average is around 90 or between 80 and 90 and 90 kilobytes so kind of the gap between the maximum possible El payload size and the average um became bigger and yeah I just wanted to um start the discussion on 76 to free um I

already SED some client team's favorite um some didn't had an opinion on it yet and yeah especially um thinking of increasing the gas limit or increasing the blob count I would say that um the EAP is a quite good fit to go in parallel

Tim Beiko: and Ben

Ben Adams: hi um yeah I think it's there's like a a hidden problem there's a there's a hidden problem if gas limit does increases which isn't under Dev control um then because degenerate blocks can be created

full of zeros um it would be good to address it just to diffuse that as a potential problem

Vitalik Buterin: so my understanding is that like basically all of our infrastructure or peer is like wrapped in Snappy compression or some equivalent already is that the case or like not the case

Marius van der Wijden: um the one one of the issues is uh Jason so if you get Jason um the block data is Jason then it doubles up in size and it goes to like 13 megabytes for the large

blocks

Vitalik Buterin: right but this is independ of like the zero bite issue right that like if you get Jon that's just like a dumb factor of two increase on anything

Ben Adams: yeah and and you you have that between the CL and the E so um it's like unnecessary strain from if somebody wanted to create a degenerately large block

Vitalik Buterin: right but right but I guess just to clarify like that feel like an issue that's dependent of like of how details of 7623 work because it's like a 2X penalty that we suffer regardless of what happens

or

Ben Adams: um yeah but the

7623 would um prevent that from being a problem because it removes the oh I see the the excessive large

BLX

Vitalik Buterin: I see like like you're basically saying that like there's yet another domain where capping the worst case is a really valuable thing to do

Ben Adams: um yeah completely

because if if yeah

Vitalik Buterin: makes sense yeah um by the way I just in the in the chat Mario Vega says that there's a concern with 7623 it adds a condition to make it a TR transaction invalid after it has been um executed and just to clarify that the uh the EIP does not

work that way right so there is no way that with 7623 transaction can get retroactively exec made invalid after execution like basically all that 7623 does is that it changes the uh right it changes the refund or the rules around like refunds and how available gas is calculated based on call data

and uh B B and based on the

Tim Beiko: you're breaking up a bit falic but I think I think we got the gist of the

last comment but like yeah um yeah we changed the pricing and so you still have to pay for the worst case pricing and um you get a refund

Vitalik Buterin: right the the gist of my comage is basically that there's like like there isn't some possibility of like retroactive invalidation that 763 introduces because that's just not how it works

Tim Beiko: got it any other questions comments on it

Carl Beekhuizen: quick one uh this came up on roll call yesterday and while not every L2 was represented or had someone present um it seemed like no one had any major

issues with this EIP on that side

Tim Beiko: nice thanks for thanks for sharing that um okay I think it's probably worth just covering real quick a couple more updates and then uh trying to keep at least 15 minutes to like make some final decisions um there was a comment around changing origin Behavior I know we discussed this in a past call and it didn't seem like there was too much uh support uh but I guess do any of the client teams feel quite strongly about this

okay if not

Danno Ferrin: um so sorry one thing that I had asked for um they had come on to the UF call um is statement from Security Professionals people actually using this what they think about it I think as client teams it's mostly an implementation detail and we don't necessarily see the higher level implications of why it's important to ban it or why it's important to keep it so I think what we need to hear from is security researchers to say is origin bad good should it be banned should it be change or not I think that's the level of input we need to make an intelligent decision on this

well I do want to make the distinction really quickly that we're talking about two different things there's the aliasing solution which is 7645 uh Alias is origin to cender I just

posted them in the chat the second one is Banning origin and eof um which is not really a full ban because Legacy deployments are still going to be available uh but it would start us on the path of um getting rid of it Banning it you know eventually and then the third option is to do nothing and let um Let each account abstraction solution as 3074 has deal with origin in its own way

Tim Beiko: uh I guess let me just pause you here because we have a lot of stuff on the agenda So like um yeah unless I think unless client teams have like a strong opinion on either of these I think uh yeah we could probably just move forward and

continue this conversation offline um so yeah any um okay yeah there's a big comment in the chat but it's not about this um yeah any comments from the client teams on Origin if not okay there's two more um changes these aren't like super related to the El but I do want to flag them um because we have been talking about them in in the past uh bunch of calls um first uh so inclusion list this came up a bunch in the chat today so none or at least definitely not a majority of the El teams you know showed strong support

for inclusion list a couple of the of the documents sent before shared that like people think it's it's a lot of complexity and there's still some open questions in the spec so I guess yeah does anyone feel very strongly on the El side that like we should do this otherwise it seems like the default path at this point is um at least from the El side like not including this in pectra um yeah anyone want to make a strong case on the other side okay so I think yeah unless um unless on the CL side next week we see like a a really strong uh support for it

then I think we can uh we can consider it excluded from from this Fork um but I think that um yeah this is like mostly a CL conversation and and obviously has some e implications but I uh yeah from the El side doesn't uh doesn't seem to have a ton of uh ton of support now and then the other one ongar uh and and and Casper I know on the last call you wanted to take like a minute or two to talk about the issuance proposals again even though they're uh mostly CL changes um and we didn't have time last week or two weeks ago but do you want to take a minute or two to go over them now

Ansgar Dietrichs: uh yeah sure uh thanks um so I think

basically I just wanted to briefly mention because some some people here might have come across kind of that conversation on on on Twitter or or other kind of places basically we we proposed a while ago we we had some research on kind of the the long-term direction for kind of the etherum staking um system we personally see some arguments that that's kind of idea for a while to go to like a targeting mechanism where basically the staking ratio would would stay at within a prespecified range instead of being allowed to to to keep climbing upwards um we see some arguments for that um of course that's kind of still in the research process um will will take some time to to to figure that out and see see what direction we end up wanting to go in just because it is much harder to

potentially reduce the staking set size after we already have drifted upwards to say 60 70 80% um we felt like there might be some arguments to be made to already have some tempering of the of the issuance in the in pectra um just to basically slow that process down and give us more time to decide um after proposing that it turns out that um there's been quite a quite a bit of kind of community push back um clearly you know any any change like that would require really broad Community Support so right now it's not in a place where it would be in includable in in in Electra um it's it's a really small change of course it's it's like it was

designed it's it's basically two lines change the spec so so the idea would be that we we will keep pushing for for what we you know the case that we see for it and if we if we are successful in convincing convincing people within the next few months we could always add this very last moment um again right now we're not on a path towards this but um but I just wanted to make sure it's it's mostly a CL side issue but of course um it would require really Broad only Community Buy in but also all CS Buy in both from the El and cl side just because um it's it's not primarily a technical change but I'm a philosophical one so I just want to briefly kind of give give give a quick kind of summary of of where we at there that's all

Tim Beiko: yeah thanks thanks for the update um

I don't want to open the scan of worms on this call but I think yeah it's definitely something people should uh be mindful of and and uh pay attention to but yeah we should have the bulk of the conversation on if and how to change this on the C call um but yeah uh El team should should definitely share their their point of view there um okay so I think this covered all of the eips which at least had uh a couple of the client teams supporting them um explicitly all of the ones which had like notable updates is there any like EIP or proposal that

people feel that I've missed if not I think it's worth taking more time to dig into um eof 7623 2937 and um yeah figure out like next steps for the for the three of those but yeah before we do that anything else people wanted to bring up if not um okay so I think eof is the one with the highest uh uncertainty and also like most consequent most consequential whether we do it or not um there's been a bit of chat about it uh as we were

speaking um I think the I I think that like the the question around so I had a question around you know whether we could potentially do this as part of veral obviously I understand understand that there are two large changes uh in in the same Fork but they seem relatively isolated although maybe that's not the case um as as per some of the comments um and then the other the other thread in the chat was around the testing complexity and you know whether we should do something like try to get it implemented and tested in say the next month or so and then uh if we realize that we're you know we're

nowhere near um getting it finalized then we can we can remove it from the fork um but yeah I guess the client teams have changed or updated opinions on like whether it would make sense to um yeah whether it would make sense to like try now to like get it included in Dev Nets doing cross client testing and you know that we feel confident we can actually get there if we prioritize it or does it make sense to potentially include it alongside veral even though they're two large changes and this gives us like way more time and yeah any thoughts there

h g

Guillaume Ballet: yeah so uh forget about including it

alongside veral veral is a huge change uh it's going to touch roughly I mean this is the the gist of my concern it's going to touch a lot of the locations at the same time this is uh two big complex areas that are going to have uh strange interplays we this is way too risky I cannot uh I cannot support that

uh Georges I

Georgios Konstantopoulos: I just wrote it in the chat but just in case uh I would feel like a eof is an evm change it's not an integration change it means that we can

test it in isolation can fuzz it very heavily and we can have very clear boundaries around it I think on the testing point I think we double click on what the testing looks like and Define requirements for it and the other thing is that in general eof is good for performance it's good for tools it's good for a lot of things and I feel like people have some implementations of it already maybe not published I don't know but like for us it was pretty simple to implement honestly one mon job um and I feel we should take a very clear-headed look at it

Tim Beiko: um yeah

Mario

Mario Vega: yeah so my only concern here is that right now the current set of tests that are written are in the ethereum test repo and this makes it a little bit more complicated than what we have been doing in the past couple of forks that is using execution spec tests which makes it more easy to review and understand what is currently the coverage for youf so um my only concern is that we need to make Dort uh of the tests of eof to execution spec tests because otherwise we are not sure of the coverage we're not sure what's really tested or not um and this is going to take a while uh because currently

testing team is um with constraint bandwidth um so I would say that if we want to make this EF happen we need to have uh this set of test in in in the new repository that's my only ask I would say

Tim Beiko: and oh yeah I guess Daniel do you want to answer to that

Danno Ferrin: so I mean I guess this is what I have to say is kind of a meta summary of what's going on all the concerns and objections are around scheduling and complexity and difficulty not about the merits of eof and there's any talk about merits it's generally positive does this warrant moving e F to CFI but not necessarily scheduling it for Prague and we can extend the Prague discussion to

see how testing and implementation is developed

Tim Beiko: I guess the only concern I can see with that is say that we say okay eof is CFI but then we also do like say 7623 and 2935 it's like like can we say eof is like a mediumsized uh set of changes like if we if we CFI it but then include like a couple small changes are we taking up all of the teams bandwidth basically um and yeah it does feel like there's a trade-off there right

Georgios Konstantopoulos: sorry for jumping in one thought for us all to be present is H going

faster and also uping our bar and being more precise about the size of each change and the historical hashes change for example is quite small and I would hope that every team including ours can implement it in a small amount of time and that we shouldn't really think of them of these features as um big burdens almost eof yes it is a lot of work I also think that because of the isolation it is much easier to test same thing for the block historical block hash but would strongly encourage everyone to you know let's try to go the extra mile and stretch all ourselves together in this

Tim Beiko: so I guess maybe a a thought um of

like how we can move this forward is we have the spec right now for Dev Net Zero which had all the current uh eips included uh We've added 374 to the list so we should probably have that in the first devet um I think we can make a call on whether or not we want like 2935 and or uh the call data repricing one um if and and then what I would do is CFI eof um and then have the teams working on devet zero in parallel to um the testing stuff being figured out like I suspect it is worth taking a couple weeks to like look into you know what's

the testing infrastructure we need um and and and whatnot and then then if we're confident with eof we can take we can add it to like the dev net after that um but I think having your first Dev net which is like everything that's already included which is non-trivial plus you know a couple small tweaks that we we want to do in parallel figuring out the eof testing situation and then making a call about whether uh we want you know whether we think that eof can be included with like minimal overhead um that seems like the right path forward um because I guess otherwise if we start working on eof and

realize the testing effort is going to take you know much longer than expected we've sort of wasted this these next couple weeks um so yeah does that generally make sense to people CFI and eof um having devet zero not include it and then in parallel to this uh trying to to figure out on the testing side like what exactly do we need and and what's the amount of work required and ideally doing some or most of that work okay no objections so um yeah no objections so let's move forward with that um so CFI eof um I'll need to get a EIP number from you all at

some point worst case I can just add the old ones there but um it'd be nice to have um um yeah like an an EIP that tracks the the latest spec um and then yeah I think to everyone working on eof like uh please paint Mario and ask him exactly uh what he needs from you in terms of like testing support um I think he'll be happy to walk through like uh yeah exactly what what we should be migrating and and how we should be assessing coverage um and then given that um 2935 is probably the most uh oh okay sorry before we do 2935 there's another comment in the chat

around uh stopping to serve history um which is another like non-trivial change so I I guess like clients do you want to give a overview like what do you see as the effort to do that like what you know um to what extent is this like a big ask for teams um yeah

Lightclient: I think it's a a relatively small ask I think the maybe big change is that clients might have to change their behavior for how they start sinking um from scratch so they won't go and request blocks before the the merge

so they'll sort of stop once they get to that merge Point uh during the back fill um there'll be some changes for the eth wire protocol I don't know if we'll need to I mean yeah we'll probably need to update the eth wire protocol and to say that requests for headers and bodies before a certain point will not be accepted or responded to in general these are pretty pretty small as from client teams I think the biggest thing is like as we've talked about in the past is making sure that we want to making sure that this data is available and we have H we have efforts on making that data available with era format and having people provide that data if clients want to continue

supporting the pre merg data they wouldn't need a way to process the era files none of this is particularly difficult I think some of their clients have already implemented the eror format and it's not a huge request it's not a requirement but if they want to continue serving that data to their users um they would need to come up with a way to ingest the data

um m yeah I

Marek Moraczyński: I very like this idea but there are a few probably more problems first of all we need to check uh with Cal clients how they are handling deposits because deposits are included in checkpoint syn but but if uh SE um SE

client do not use them then uh they have to start doing it before we drop history then another thing is I I I think it might be even more problematic for clients like ref or Aron when they thinkinking from Genesis I might be wrong so um please clarify if I'm wrong here and generally Arch I syn might be a little bit problematic after after that but uh we could import data from era files I don't how do you see that

light L

Georgios Konstantopoulos: sorry Mark can you articulate the

question or the risk for the igon architecture that

appes all the

Marek Moraczyński: so my question is if it is not problem for you if we drop uh all blocks pre merge all blocks and you will have to start syncing from after the

merch

Georgios Konstantopoulos: ah I see um it is true that neither and somebody from Aron should also weigh in on this it is true that the snap Sy uh functionality is not uh as is supported by the architecture we had a conversation with that in the ACD

Channel with Felix from guest and that is because the snaping protocol gossips sha instead of pre-images and it and an execution in Wrath and Aron are is based on preimages of the keys so there's no way to map back from the chat to the preimages um there is an interesting question to what extent with veral uh we can also and this might already be part of the veral spec my apologist if there's an interesting question to what extent this kind of Sy is is kind of like we can do snap syn perhaps in re or Aron with verle I don't know if that is possible I think that's a question that we want to explore in the coming weeks or months um

so that said it means that we cannot support snap sync which means that it hurts our ability to sync from scratch over P2P um and uh I would love to have a conversation about it we don't feel too strongly about it it's possible that you know we can maybe host premerge history somewhere and maybe that's fine for us um yeah that that's roughly how I think about it so I don't have a very strong view um but yeah and to the extent that you know we get a an archive format whether it is era or something else uh that might help I think on that on the archive format there are interesting questions around a what is the optimal file format whether having

an optimal fire format matters or whether we should move forward with something that just works um having clear requirements for the archive format which we have asked in the chat and we think the conversation still needs more work and finally on the thein method of these networks where I feel like it's great to say that we have portal Network as an answer although there I think we need to get again more precise more clear on timelines and really really be clear about the dependencies between these three the interplay of History expiry picking the right file format which might be a simple decision and a dissemination

Tim Beiko: um okay I want to just go back to the other eips because we only

have two now one minute left um I don't think so math has a draft EIP um out I think we should review that but I don't think we should make like a decision about including the draft EIP even in the fork even though there seems to be like a rough consensus towards like clients generally want to move towards that and it's more a question of when and how rather than if um before we wrap up I guess uh 2935 feels like something where there's pretty much broad consensus no objection as far as I can tell and um and and it's fairly simple does anyone oppose including that in the fork and also having it part of

defet zero so that we can get it prototyped as soon as possible if if there's no objection I think we should move forward with that so including 2935 the the so marel this is the block hash in the St so like the same thing as 4788 um basically but with a different value um and then the last one so 7623 um there's a lot of discussion about that about blob size increase and and whatnot um I feel like we should potentially CFI 7623 but not includeed yet there's probably some more

discussion to to be had there so does that generally make sense to people okay if there's no objection um we can do that so to recap um we uh aside from all the stuff that was already included in the fork um we added 374 2935 both of which will be part of the definite zero spec um eof and uh 7623 We've CFI um so we'll continue sort of looking into those in the next couple weeks and then uh if we feel highly confident in them we can we can bring them in later um and I think the other thing I want to flag

is uh Prolo zip uh to to deal with some of the issues with 3074 that's also something we should keep looking at um if we're already over time it feels a bit late to to maybe cfy it but um yeah I think at this point though um in you know there's probably small things we can bring in the fork as we like uh find analyze things but generally if eof comes in that would be like the last big change and everything else that's there should be uh yeah kind of the the bulk of of the the Petra Fork at least on the El side um yeah any final comments

thoughts okay well yeah thanks a lot everyone um yeah I will talk to you all soon and uh make sure to get all the specs updated

Georgios Konstantopoulos: um and yeah Tim could I kindly ask you to in the all coure devs Channel could we get a written articulation of what got confirmed what is CFI and what are next steps for us to further discuss with precision and clear data driven articulations of where we need to do more work

Tim Beiko: yes I'll post a recap uh in a few minutes thank you team cool of course thanks everyone

thank you thanks thank you

thank you byebye s

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