All Core Devs - Execution #201

Transcript

[Music] that J welcome everyone to acde number

2011 uh couple things on the agenda today um most importantly we can hopefully finish uh the scope of pectra and um yeah be able to move forward with the specs um after that uh there was uh some conversations that happened around EIP 44s in the past couple weeks uh as well as uh 7639 about dropping history so we'll discuss that um then there was an edge case that uh ax want to revisit around uh capping the transaction size or sorry the transaction gas amount um and then after that uh if we have some

time left uh there were a couple potential ACD process improvements things I wanted to cover uh to kick us off uh Perry Barnabas either of you want to give an update on uh where Dev Nets are yeah so we have uh mik continuing to run um the grandine team has pushed a lot of fixes I think they're mostly okay now um there's still some problems I think in ethereum JS and Nimbus El so it would be great if those teams could have a look at it but we're at like 97 is% at a station performance I think we're mostly good on um on the makong front and we're mostly focusing on getting all

the PRS merged in for devnet 5 um I've list three open PR so it would be good if the relevant people could have a look leave a comment read through the pr and so on and the devet talk has been updated to also showcase where the uh tests are so thank you testing team for that um you can also see where the what the status of the tests are right now I think that's about it from us okay awesome um and so okay so the pr there's one around adding s says support to the Builder API uh and then two CL ones on the E it seems like the two open ones are on the

execution API um anything else I just refresh your page I just I just updated okay so on the uh e side okay there's an update to uh which IP is this uh 7 7691 uh is this the yeah so 76 okay this is the1 is the yeah exactly that's the 691 and we wanted to add the update fraction specification and I think ancar has already done that it just requires the I guess owner to merge it in okay great

um is 7691 actually merged as any IP yeah should be okay nice okay yeah yeah um okay and so this one uh so we agreed to the to the change um yeah we agreed to the change last week I don't think we added it to the Petra meta EIP so I'll do that um yeah after this call um and I guess okay as um aside from that I any other El PRS that you want to bring people's attention to oh

onar yeah I just wanted to briefly um say because um for the 7691 change um that indeed yeah it's only requiring like one of the VIP authors to to Bally approve but it's it's done and and then the uh there basically was this open question of like what exact um update fraction we would go with and we had like a discussion over the week and picked the number that's basically the middle sensitivity between um three and six because uh because basically right like we could have kind of most have six blobs less than the Target and three blobs more than the target so we Bic picked the middle sensitivity so now a very full block will have a slightly less than 12% increase in in basically in a fully

empty uh block will have slightly lower slightly more than 12% decrease um so that number is in there um and um yeah and that's that's about to be merged thanks uh Tony yeah I was just um in the process of reviewing the pr and it looks good to me there's only a small typo um and then we can basically merge it sweet okay any client teams have other updates or thoughts concerns they want to share about either meong or the current def five

spec okay um maybe yeah one point that L CL just brought up maybe he wants to bring it up uh 7702 TX I'm just checking again if anybody is looked into it or implemented it we are in the process of implementing it right now mind is looking into it um but others can comment on that if we have others here yes I'm here um there was a discussion on Discord

um specifically to to like client actually we had some suggestion but it seems the discussion sort of D where Discord was that it was in interop okay okay I see there 7702 uh transaction pool um yeah mer just linked it in the okay okay so yeah I guess as people work on it uh it'd be good to yeah share any updates or designs

there any other updates on the transaction pool anything else on the current devet five specs or meong that people wanted to bring up okay um then moving on it's worth chatting about the Petra uh scope changes so it feels like we're close to finalizing Petra in terms of scope but we've been saying this for many months

now I think it would be ideal if we could do so um I on today's call because then um if we're heading out for the holidays in like two three weeks we can be in a spot where we ideally have a final set of specs uh to work with and you know we can start writing tests and uh having clients Implement that and come back in January with uh sort of a clear Target to to implement on the CL it seems like everything is pretty much resolved or we resolved those things last week I think on the El uh there's three major open questions first is just uh BLS gas pricing there

was a lot of back and forth on that and uh need to figure out if there's this something we're happy with to move forward and if not what do we do second uh this came up on last week's call but EIP 7623 there was a lot of back and forth about whether to include it um alongside the other changes we've we've uh already included and then um lastly EIP 7762 which was an adjustment to the blood Bas fee uh that we also discussed last week and could quite get to a to a solution um so maybe yeah I I would start by going over the BLS one because that one's already included and uh we sort of have to fix and then we can

discuss potential positions after that is there anyone here who has a context on the latest uh BLS pricing back and forth I believe uh was it merik who opened the pr um yeah yes so I took Pav's numbers and I opened PR and in the link here we have nethermind BLS pricing proposal it would be great if it will be validated uh from other teams and I think um Pavo had totally different idea how to price um MSM operations but I I don't understand

fully the idea so uh we need to uh agree with Pavo about this have any other teams reviewed this or does anyone else have a strong opinion about the pricing just hello uh yeah um yeah so from the pricings uh at least from what we know from the current Numbers Never mind for G1 MSM would need to go up by 2.5x Basu

and geff would need to go up by 2X and evm one would need to go up by 3x uh for G2 um never mind's 1.5 GF is 2X and I think evm one is also 2x uh so we could go with these pricings it's just that they're more cost than I guess we'd like you mean by these pricings you mean like nether mines C like Mar PR um so we just take the worst case of like what everyone's already given us uh so for example evm one is 3x for G1 MSM so we just say G1 MSM we just put it up by 3x and this covers all of the clients

uh and then for a G2 MSM we can just scale It Up by 2X and then this covers all of the clients as well it's just that it's a more coarser uh way to do the pricing right and um what's the like do you have a sense for the impact like on users of of having this more coarse uh pressing scheme um yeah so I guess we don't know exactly because it depends on the use cases yeah um my suggestion would be to uh sort of commit to some sort of maybe even a course pricing and then uh

we can use one of the other tools that are out there to figure out a new curve to use because at the moment we just don't have any uh we haven't like committed to any pricing yeah um I I would like to avoid the freea that's there but uh it's like the only one that we've seen empirically that covers everyone else and is uh so I understand like yeah evm one was was slow on some of these is that the is that the one that's covered by the 3x increase right uh so the other the next slowest one would be the never mind

proposal which is 2.5x uh scaling and I I'm not sure about this but is evm one used in production by any client like I agree we should probably go with the slowest one but yeah oh sorry no not yet but uh at some point later probably next year we would like to switch Aron to evm 1 but at the moment it still uses uh our goang evm which is essentially the same as the one in gu got it I oh nether mind uses the same library

but I guess I'm trying to understand why is evm one slower than the others and does it make sense to put our worst case on an evm that's not being used in production today or should we just use like whatever is um yeah like should we just use like whatever's there yeah I guess to answer the first question I think the reason why evm 1 is different or why we're sort of having some issues coming up to coming on to a good price even if they use the same libraries is because uh everyone's basing it off of EC recover but EC recover is not the same across every uh Library I see um

Ric uh yes so this is not exactly about the ev1 itself but about the blista library which is used by as you notice by by the never mind but also by R by is used by ref so yeah and and the benchmarks basically I I cannot I cannot tell anything about the the exact Benchmark results but this is not exactly vm1 but of the of the library us yes I'm not sure I understand the yeah the implication so this this means that that uh that it's not

only case for ev1 I mean this uh the problem with the with the library and that's all that's all I to say yeah right so never mind uses the same library but it's a 2.5x um so this uh goes down to the issue of EC recover not being the same across everyone because everyone's scaling it based off of EC recover and yeah and you from gu or Basu have had time to review uh okay so uh Jared says gu would be good with nether mind's proposal um my sense is if Basu is also good with it we should move forward even if it's

like slightly underpriced for evm one sorry just for clarification is this the proposal to repic across the board um or we just talking this the pr I just linked oh I see this is to repic the G1 MSM um for 2.5x um I guess uh is there what do people think about the proposal to

commit to at least like let's say the 2.5x or the 3x and then uh wait for the gas cost Optimizer tool to possibly give us more finer grained numbers but just commit to at least something okay and there's a proposal to agree async I guess um yeah M how how much time do you think we need to agree to this I think if we could get the consensus on your PR as like a worst case that we maybe or as like a base case that we maybe

modify later on but that you know assuming there's no major issues to move forward with today that would be better but yeah is there a reason to like push this back a sync before we we can make call I'm not sure I'm just seeing that there is no uh clear number and we can discuss whether it should be 2 X or two and half but it's seems that I will agree quickly ASN but we can try to discuss it here as well just just DEET we should uh agree

before devet 5 and have and we should have final pricing before defit fight that is that is my proposition yeah and okay so basically said the main person who reviewed this is is not on the call I I think it's fine to move it async but I would try to speed it up a bit more than just before devet 5 if we could get to a resolution like on Monday's testing call at the latest that feels good um yeah and this is a resolution on the forer grained uh estimation that we can then make more finer grain later on uh so basically the 2X or the 2.5x or

whatever I would try to get us to like as final of a pricing scheme as quick as possible um Stokes yeah that what you want to comment on as well oh yeah I was just going to say I think Kev was suggesting moving ahead with this for now and then yeah if people want to take another couple days to like finalize uh something maybe with more fine grain analysis that's seems like a way to make progress today because it sounds like this PR gets us directionally closer to what we all like right yeah as I understand it the only concern was evm one for one of the pricing schemes but I think if all of

the production clients are fine with this number we should go ahead and merge this one yeah I would agree yeah maybe yeah the one thing uh so okay uh it's probably worth getting a sanity check from Basu on it as well but assuming that uh Basu can give it a plus one async today or tomorrow I think we should go ahead and merge this and then uh yeah we can discuss finer grain uh pressing schemes async as well and potentially uh on the call on Monday if we haven't come to resolution okay uh if someone from the

basic team can can Gary and let him know to review this uh as soon as possible that'd be great um but yeah assuming there's no objection there we'll go ahead and merge mxpr uh sweet anything else on BLS okay um I guess I could ask I could ask a quick question uh if anyone has a BLS signature verifier that works with the latest uh for Petra uh I guess just yeah let me know on Discord or something um I have something from a while ago I might

try to update but it might be nice just to have like a sense of like in to end cost uh for this thing okay um okay next up on the agenda was EAP 7623 um I believe Dano you raised some issues on E magicians and then Tony opened up a PR to address them yeah Tony do you want to give a quick recap on the L changes yeah so we discussed that also on ACD last week a consensus ler call and the main contention we always had with 7623 was more like not about the

mechanism but more like the scope of pectra itself and regarding deno's um suggestions so um I included them and Incorporated them into the AP you can now find um more elaborated backwards compatibility section and also security considerations um including the concerns we clarified um that um William raised um a few months ago about the gas Sheltering and yeah I would I would now really propose that we um include it and ship it in defet 5 and especially in light of current discussions that happen in the community about the potential gas

limit increase and also we agreeing on the on the blob increase I think it would be important to to um yeah make sure that we uh um limit the El payload size thank you um there's a couple plus ones in the chat for 7623 um and yeah this PR seems to have address the Dano's issues I guess does anyone think we should not include this I'd like to hear what e clients think in

terms of implementation complexity I think that uh it has a lot of Merit on a security fronts but I would just want to get a sense of you know is this going to add weeks of delay to pectra or something like that okay so Rett says the impact should be low um I guess yeah any the other team have a sense of like does this take out hours days or week to implement uh same okay based to ethereum JS also say it's a low impact um and then like client says it adds complexity uh when when reasoning about transaction costs and may

introduce some weird gas Sheltering schemes um I oh yeah and a good question from Perry like uh on the testing side do we have a sense of how big of a lift this is to include no sense as of yet but I think it's not going to be so straightforward I hope I hope it is but um I don't have like a a clear um idea we we have made some preparations for this for this

exact IP in our repository uh but still uh we need to to to check and see probably a couple of weeks indeed just to implement tests okay and how how do you feel about the rest of the the fork so far like is the rest of pectra in a relatively good spot or yeah yeah we have PRS for everything right now um for the5 at least what has been included um it's looking good uh we probably going to be able to make a release uh soon uh but yeah for 7623 I don't think that should be a blocker um but if anything comes up I I can sure just signal it got it uh

Daniel yeah I I just wanted to propose that maybe instead of including it into defet 5 we go ahead with defet 5 as is and included in the definite six to not block the testing of def not five because if it's going to take uh a few weeks um maybe for the test I don't know I I I I I don't think we should wait that long yeah I guess one question is yeah how quickly do we expect to have devnet 5 if we if we think we can launch devet 5 in the next week or two then I would agree with this but if we think devet 5 is going to take another few weeks I would bias towards um having devet 5 be the final Dev net

um okay yeah so I I guess yeah does anyone think like we could launch devet 5 in the next week or two maybe maybe it makes sense to talk first about the other EIP that's potentially included inra because this would change the the scope again okay yeah so I guess assuming we yeah like independently of whether this is a Dev 5 or devant 6 are we happy adding this to pectra we've discussed this many time um my sense is people generally want to add it but

there's concerns about the scope and the size and people today feel somewhat optimistic that uh it won't cause too much of a delay so I would lean towards including it so that we can finalize this spe but yeah anyone have a strong objection against that I think the main blocker is 7742 still on implementation side so if this is a very small implementation on the side then uh like why we might not even be ready with 7742 uh before we would be done with this new EIP and uh 7742 you mean the El or the CL work that won't be

done I like I haven't heard any kind teams that are like 100% done with it okay is there anyone done with it okay so I guess okay rest is 95% of the way there um b 2 is also closed but not done um okay so I guess if teams are mostly done with

7742 and think that 763 is not a huge lift I would move forward with it um we can discuss maybe the devet 5 versus potential devet 6 spec uh after once we have like a better sense but yeah I think to to make sure that we actually have a final set of like specs to Target now basically uh it's better to make the decision and move forward on that than to delay it another couple weeks any objections through 3 7623 no objections I do wonder if we can go ahead and include it now and then

essentially it out if it looks like it's a bigger lift than we thought in a week or two yeah we always can maybe we can give the testing team some time to look into it and um we essentially want to block if if they are to say that they would take another 3 weeks to have the tests for uh 7623 then we don't want to block devet 5 just for this one EIP we can continue without it and then do the testing um in parallel but if it's easier than we thought then I guess we can include it right now that makes sense uh Mario we can have a an estimate on Monday's testing call okay if that's

okay yeah perfect so I think if uh yeah we can move forward included in the fork and then on Monday's tting call we can iron out what goes at devet 5 versus a potential devet 6 okay sweet um um last uh candidate for this Fork is EIP 7762 um which is the minimum blob price increase uh we discussed this as well on last week's call couldn't quite come to a a decision anyone have thoughts about what to do there

uh Tony yeah we discussed it on last week's um consensus leer call and we basically said we don't want to do all the changes that were proposed at once in pectra um I think there were some discussions about um picking out increasing the minimum blob base fee and only shipping potentially and yeah I'm indifferent about that one but yeah I think we should stick to not including all the Bas feed changes in pectra uh ancar yeah so um basically yeah I think the decision is indeed to like not not

not ship the big package of of Base fee of of of flop fee changes but but that's also not the CP the CP It's Kind shape is two things one is just the uh minimum price fee increase minimum base fee increase and that's literally a oneline change but then the the AP was modified um um based on feedback last week to also include a excess gas reset um you can have a look um at the at the EIP it's still like very small um it basically like the the the the gas the EXA gas reset is basically just like a like one if statement in the in the calculation where basically if if basically we are at the fork height um return zero

otherwise normal calculation um it should should like a minimal extra implementation overhead in addition to this on line change so it's like maybe a four line change now um I think given that it's so tiny um and it has like a meaningful Improvement to to ux for for rollups um and they've been signaling that this would be valuable for them um I I would be in favor ofing it um yeah and maybe one more thing which is like in terms of complexity of test cases if there's already going to be changes to the update rule I think the additional test cases from including this CIP along with The Blob increase

which will adjust the rate of change will be pretty minimal because you'll already have to change the test cases for that oh yeah that I forgot to mention this this is actually a really good point and that was one of the questions that did come up in the uh update fraction um change where we're actually specifying the point of the hard for is a little bit annoying and that would completely go away if we mat the CP because then it just gets reset to zero at that block so we don't need special uh specification of of of of that block so actually I think it actually makes testing probably slightly simpler even okay um has any El team reviewed

this okay ethereum JS seems in favor anyone else have thoughts or comments on it I do have a question are we talking about just raising the minimum fee or these other things in this PR um only only the only the fee so the pr in the agender is the pr I made um thinking about fusaka where we kind of if we don't do it now we might do all all of them at once or nitpick the ones we want to do for Paka but if we if we

agree to do it in Packa then we would only do the increasing the Min base fee and reset the excess C okay and we just don't have the pr for that yet I think Ana has one it's it's already merged it's like the K State of the E so like the decision is about the C state of the a no PRS like no PR the C state of the a is okay I think we said the wrong link I I try to find it yeah okay sorry I also thought that the decision was about the uh yeah the the the open PR by Tony it looks like it's 9090 was the pr at least yeah yeah okay so

we okay and I'll post the e as is uh oh thanks I'm on okay yeah so this is much simpler I think out of yeah I could see this it does out another EIP and it does add a little bit more overhead of testing and complexity and the downside of not doing this is we stay in this awkward world where sometimes the blobs are effectively free and sometimes uh they

get repriced very quickly I think the problem is more that they get repriced very slowly and we see yeah sorry yeah okay relative to Market yeah recently and and then what happens is when they when they repic very slowly and now it's happening like every 20 hours or something where we have like a three-hour period of price Discovery and a 3-hour period of um going back down to less capacity overnight When there's less demand so okay yeah in that three hour period we're like basically defaulting to First price V market right and that's a problem because rollups don't want to think about volatile fee

markets well it makes it so that there's like if the rollups are charging their gas they have to charge their gas on the rollup based on a first price fee Market which nobody understands versus saying okay your your gas on base is a function of what the base fee is on eth today or what the blob base fee is on eth so it would be it's like much easier for the Roll-Ups to read and provide gas pricing for their users when it's just the number from the controller rather than the number from the controller plus whatever is going on in the first price fee Market which is also complicated by whatever else is going on in me land on that particular

block right I mean I think the strongest kind of argument I've heard is what like Clan said here in the chat uh it just early and presumably we will hit quote price Discovery for the blobs and this issue will just go away um I think like we are at Price Discovery it's just that the demand is much higher during the day and so you can't have like a situation where demand doubles and then we're like using six blobs during Eastern Time 9:00 a.m. to 5:00 p.m. and then also be saturated at night and so there's always going to be like an awkward period

between like whenever that switches on and off is going to be an awkward period and we'd like to make it as small as possible I don't think we should Orient the ethereum fee Market to be us focused well this PR doesn't do that though yeah yeah I that's what he's saying he's saying that no one uses blob quote during the night no night wear right but it's more that the whenever no one uses blobs or whenever people decide to use blobs again we're too slow to adapt right like yeah and I'm saying empirically you can look at the data and that's

happening every night rather than oh we have like if it was once in a while when there's an air drop I think that would be a different story like I said this is very early in the story of lobs and I don't think that we need to come in and start meddling with the actual price mechanism right now let's revisit it again next time that we have a fork and if it's still having problems it's possible that it make sense to do but it's so very early on this process still then yeah but aren't we like proposing doubling the blobs it's just going to make it worse it's not like we're not Ming there are already several changes

to the controller happening as well as a blob increase in the fork and we have very strong theoretical reasons why this would increase price Discovery with very minimal changes to like in total this is at most $100,000 a year change to the blob prices but we think it will make the speed of price Discovery much faster and we now see in the data that this is happening very often so we also thought that price Discovery was just going to happen one time before we implemented blobs and that was clearly we can yeah so I'm not I'm saying that we how can we

clearly that this proposal will fix all the problems in this blob market like I don't know that's clear that this is the case that's not what the proposal claims to do it claims to be an adjustment which is low overhead and we know will improve by some Factor will not make the blob Market perfect but it will improve the blob Market um onar yeah I just just wanted to say I would really strongly recommend adding the C it's a small change and it really the situation will get significantly worse from today to to this just because with this change in in in throughput we now maximally can can increase the base fee by 8% per per block instead of the

the today's 12% so it just takes significantly more time to ramp up um and so basically having to oscillate back and forth between the the like one way and and the efficient kind of market clearing base feed just takes much more time now so it's basically worsening an existing problem which is already not great for rollups so rollups really from talking to them quite quite strongly would prefer us adding this and yeah like testing testing complexity is basically zero because we already need the tests for the for this part of the of the calculation logic um and implementation overhead is very small so to me it's like a very clear cut case um I'll highlight a comment by per saying like yes every EIP we add even if

it's small um you know they're all small changes and we have probably somewhere between like 12 and 15 of them in the fork right now um it will delay shipping pectra um so like if we decide to add this it's fine but it also means that uh we ship whatever scaling increases through blobs and you know adjustments to the Bas Fe slightly later um and yeah we should be fine with that um yeah yeah I just want to also add that the

point is that this will delay stuff the question is is the tradeoff worth it the answer can be yes but it is an honest question is this the trade-off we want to make yeah yeah I think what ncar is saying in the chat is exactly right that the actual like if you look at the actual implementation of this there is a oneline change to a constant and there is like a three line change to reset the excess gas and then the testing implications many of the tests are overlapping with tests that must already take place because of what's happening with the other EIP which is adjusting the controller and so

I doubt that there will be much marginal effort needed to increase like to to provide those tests there because they're already going to be needed for the other rollup EIP that's coming in this sport how how big of a change is this assuming we add it after um as much um yeah as much as I would like to have the spec finalized today um it doesn't feel like there's like super strong consensus that move forward with this um but assuming you know we did and then in a month we're feeling good about things and want to add this in are we like duplicating work or like making your

lives Harder by not making this decision today well again I said that I think there are a lot of tests that are like going to be needed for the other blob VIP which are changing the controller those will need to be Rewritten with this change in mind but the code itself is again just for line change so I don't think and I think the blob reset should happen anyway uh because we're increasing the number of blobs anyway so really like the marginal contribution is a on line change to a constant but then on the testing side those will need to be adjusted yeah another comment uh I don't

know if any like rup contributors are here right now but given that they're kind of the user of this future it'd be nice to hear from them I do wonder if like their rollup teams here you know the like sense of consensus would be maybe a bit different as then it would feel like there's like a bit more support for this I do think I'm weakly in favor for what it's worth um okay ongar says there's roll call next week as well um I would maybe just kick the can down the road for one week with this one bring it up on roll call have a better view of

what the current state of things is including 7623 and the 69ine changes um and then make a decision on this one next week um ideally if we can have a sense of like um yeah of of testing complexity and if we actually do you know save some some like overall testing efforts by adding this as part of the other changes to the fee Market um been great maybe we move forward but it does feel like it's worth taking an extra week to just think about this specific one and hopefully have every other change yeah locked in today um yeah anyone feel like we have

to make a decision right now okay so let's uh yeah ongar if you can bring it up on roll call I think that'd be quite valuable if we can have uh clients and testing teams review it um yeah in the next week that'd be great and then yeah I think on uh ACDC we can finalize this one but then get all the other eaps sorted today yeah sounds good to me okay there's some comments in the chat saying we finalized today so do we I'm skeptic if we finalize today my

sense is then we don't include this um because the only way we can have DEET 5 this year is if we finalize today if we ship it or if we skip one more week then we not going to five this year anymore yeah and I guess okay Perry has another suggestion that maybe you know we can freeze devet 5 and make these changes later on I do think it's worth bringing

this up on roll call and seeing like how um yeah how important it is for rollups um so I guess what we can what I would do is yeah assume everything is finalized except this thing not have this be part of the scope for devet 5 um and um and yeah on Monday we can move forward with like specking out the dev Nets um yeah and and then on next Thursday you know we may decide that we don't want to include it because because everything else is in Net 5 and we think that that's like a good thing to ship with um but yeah it feels like we need to know a bit more both on the devet

side and on the uh rollup side um Daniel and then onar uh yeah just for clarification does this mean the proposal is not included in definite 5 and then maybe have a definite six for this one EIP I mean devet numbers made up we can have as many as we need to um yeah yeah it's more it's more the overhead for for testing the T correct so and I think look if we if on Monday we decide that everything that's been included so far makes sense to have in devet 5 um then at the latest on Thursday we decide whether we want to add this to

devet 5 not add it at all or have a separate Dev net I think if if on Monday looking into all this we already realize we're going to have two different Dev Nets then it does change things a bit but if we're only adding a second or a six devet for for the CIP then yeah we may be less inclined to move forward with it um okay onar yeah I just want to say like that seems like the worst of all worlds like we we should just decide today because if we say oh we going to decide next week but by next week it might be too late for deit 5 and and then we not going we might not want to give it open a new definite for it then we're basically saying well we're rolling the dice on whether there's still room to

include it so at that point we might not to include it that's exactly what we're doing like we are constrained by capacity um so yeah we sort of have to understand a bit better how much capacity we have and what the impact is before making the decision well we but by by by delaying it we change the cost like right now the cost is small but existent I acknowledge that because it does require extra changes but by next week the cost might be much larger because it requires an ex entirely new devet would of course be unacceptable cost right but I think if okay I but I don't think that we can know today

whether or not this requires an extra Dev net and I think that's my point is we yeah but that all I'm saying is then we should understand that by making this decision we are likely pushing this out of pectra we at least risking that it's good chance that because of course if it requires a new definite we will not include it so basically we are saying we just rolling like and it's fine if people basically prefer it not to be imp but then we should just make that decision I think it's a fake it's it it feels like it's you're implying that it's a lower cost you're basically saying ah by not making decision today doesn't mean we are not including it but it means that it might not be possible to include it anymore so we should just make the decision today and it's fine if

the decision is not to include it but then we should still everyone should be aware that that's the decision like we should not we should not make this like oh maybe next week there might still be room to include it like either we include it today or we don't include it right okay so I think if we want to make the decision today then clearly like we don't have enough consensus to include it and my sense is there's a small chance just this changes in the next week if we ask rollups and we have a better sense of the devet if people want to make the call today and just not include it um then great I think we can move forward with that but I I don't feel like we do have consensus to include it um my sense is like there's some client teams that are opposed we

have like a fairly High burden on the testing and devop teams already so I I get yeah actually yeah do all the other El teams want to include this yeah I know it seems like gu is pretty strongly opposed nether mind is in favor Bas is weakly in favor

I if we didn't have a bunch of other things in the for wasn't already so um yeah so full and we weren't BCT by testing then maybe but my sense is it doesn't make a ton of sense to move forward with it as is yeah I don't anyone else have a strong opinion and yeah like I'll like

highlight Mario's comment that like this does require um yeah significant tests uh yeah significant significant testing effort so like I yeah I would lean against um my personal preference is that we can revisit this next week but um yeah if people want to like close that kind of worms today we can also just finalize the spectroscope with that okay um then yeah I would not include it

today um and we can discuss a bit more I think if we want to have another conversation about it uh next Thursday yeah I don't think we have enough uh yeah consensus to Mo forward and um yeah we already have a bunch of other things that we've we've included anything else on pectra okay so let's uh yeah review the different changes um have a conversation about Dev Nets on Monday and uh figure out where we stand and if we can get

devet five shipped by the end of this year okay um next up uh history expiry the other thing uh at the top of our priority list uh Piper you shared a document on the agenda do you want to give some context on this yes hello everybody uh we made a decision at the R&D workshop and we've got all execution client teams on board for dropping uh uh for imp um rolling out uh what we'll continue to call for fours um with a timeline of of dropping a significant part of the history by May 1st of 2025

there's a document Linked In the PM repo issue today it goes to a hackmd document that gives kind of like a summary of everything that's going on here uh the official EP number for this is 7639 so we're going to have some fun confusion here as we continue to call it four fours and the actual Eep number is a little bit different uh thanks to like client for getting 7639 updated uh it specifies a new version of the eth protocol protocol version 71 uh for which um uh clients will be allowed to stop responding to uh certain messages about history uh the exact thing that we agreed on was dropping

block bodies and receipts only for preem merge data so that does not include the header chain that does not include any data after merge and loose estimates suggest that this accounts for a couple of hundred gabt of dis space this this gains us some amount of leeway here on that 4 terabyte hard drive limit that was coming up on on everybody um the agreement in terms of what consensus was made was strictly about clients no longer being required to respond to this data over Dev P2P um after that drop date um the exact implementations that clients will be

taking uh with respect to how they handle this data um are kind of up for grabs every client uh is able to kind of make their own decisions we've still got clients who are implementing full sync so executing all blocks from Genesis uh they'll be implementing their their own plans for how they fetch retrieve um deal with all of that long history data um and then we've got other clients who are going to be implementing uh portal net uh portal Network clients uh for the portal Network history Network um in their in their clients for being able to serve things like Jason RBC uh that's the highl overview for this

um I've got some chat messages I'm pulling up here um cool um I I I don't know what else anybody wants we met with all of the client teams during Devcon I think everybody knows what they're doing um the time to start working on this stuff is now soon so that so that we're ready um uh like client has pointed out that for this new protocol version we need to warm it up and so we need to not have it just turn on on May 1 but I think client teams need to have versions of their clients out before then that allow for both the old client version and the new client

version to exist at the same time I think that's probably most of the information here thank you Piper um Andrew has his hands up um yes so I think uh one one comment is that we need to finalize ether 6 69 uh and uh um um I think on our side we have some concerns about it's like is 69 compatibility with with polygon uh so but we have we need some time to prepare and we can do it maybe the next all cevs to discuss e 69 why why do we need to finalize e 69 because

then it's kind of is 70 and this 71 build on top of that um and another comment is do we actually need a new protocol e E71 to explicitly like prohibit uh answering to a historical block request like isn't it a of no kill I was going to ask that exact same question I don't have a strong opinion on this um potentially we can either answer the call answer that question quickly today um or asynchronously in the history XPR Channel if client teams want to weigh in um does anybody have a strong opinion in favor of a new

protocol version um yeah so uh like given that uh three other clients or four clients are going to implement 7801 uh the like 7801 is going to be like e a sub protocol and uh like everyone can then seee serving history pre-merge history on E uh protocol um the reason uh we want it to be a subprotocol is for E protocol to be not uh affected by um clients potentially uh calling uh uh like

clients that do not support 7801 um uh yeah since 7801 could potentially allow you to encode the bit mask into the enr um so like we want to not give the assumption that uh all clients are going to support uh serving uh on uh historical blocks through 7801 and that's why it has to be a subprotocol u so other clients not serving don't get hammered by request that they can serve uh correct but I I think that that's a little bit so it sounds like that's a little bit in favor of not implementing a new eth subprotocol version um it seems like that that that

that can happen independent of whether a new eth sub protocol version gets no because you when you implement a new es sub protocol you you you declare the the the new subprotocol right you declare that you support it and that means that you are serving these historical blocks if you don't declare it then no one will ask you for these got it so I'm talking about the eth protocol version not whatever new uh protocol version 7801 goes on so so since since some clients are going to drop blocks and most nodes are going to drop the pre-merge blocks it it wouldn't be fair to anyone to keep saying hey I might have the blocks or I

might not have the blocks so we say Okay anyone who's in e70 or 71 um like will stop serving pre-merge blocks this is the idea and if you want to serve fre blocks you just implement the subprotocol sorry and so and so in this version of the world anybody who's on eth 70 May or may not serve the block history and anybody who's on eth 71 definitely doesn't serve the block yeah um that's why if you if you go to the AIP it says CES serving it doesn't say you may seiz serving no it says must stop serving if you go and look at the

language used right it's very strict yep we can modify the language but this is this is just for E71 like you must not the premerge history on E71 um we can make it clear that you can serve the history on other protocols versions and so then we get I think the endgame of this is that we get a sharded eth protocol on um uh between the the clients that do and don't serve historical blocks seems like a problematic state for things to end up in where where there's this option of staying on the old prot and and and continuing to to serve old

blocks and kind of separate I don't know um um yeah I I don't like this B bation in protocols maybe we can uh like make e 70 generic enough to allow for U clients who don't want to store any any historical uh uh blocks to to like explicitly say so I mean it's it's if if you just don't put any ones in your bit mask that means you don't have any history that you don't want to serve this is this is easy to implement if we want to do it that way but if we want to uh encode the bit

mask inside the enr uh then uh that's uh a little bit different but uh I think uh I'm fine with the handshake the handshake is not that expensive and uh yeah it doesn't need to be encoded in theyr so uh yeah but I think G team still in favor of having it as a separate protocol regardless of if we do it in this way or not uh just because they want to keep the network uh like all I don't know um all all keeping the same thing light client you can

maybe say why sorry I didn't quite understand the like so so what what's being said is uh like let the so instead you change the language to say instead of C serving history we just whoever wants to serve it serves it and whoever doesn't want to serve it he's allowed to not serve it and that's it and we don't have a separate subprotocol for serving history um yeah are you saying eth a as the sub subprotocol yeah they don't the people are are are not liking this eth a idea they want to keep it in E uh 70 or 71 what was the argument against eth a like

isn't it just a string that's in the handshake like I personally don't really care that much eth A versus another eth version but it is just a string so I don't really see why it's major issue people from my if is a is fine what I don't like is if we have e 70 like for for for this shed block proposal and then e 71 for actually stipulating must not of blocks because then we have a bifurcation in protocol I'm sorry I'm sorry okay okay so maybe there is a confusion that's why

I asked like client to change his protocol version to 70 because we're going to not use the 70 version because since it's a new sub protocol does not confirm to the same versioning scheme as yeah U the eth version eth protocol version so to to to round this back up because I think that we might be at a at a point where we have where we we do actually have an agreement 7801 goes on a different sub protocol it is not part of the eth sub protocol anybody who's doing 7 801 things is on a a new separate protocol with a separate string that isn't eth and the question here is is there opposition to doing um 4 fours

without bumping the eth protocol version by by keeping the eth protocol version at 70 and just having the drop off date happen and at that point clients can stop responding to those messages oh we need to bump the we need about the version we don't want to stop serving history on a specific version because then when you connect you don't know if they're going to have the history or not and if you haven't updated to your client and you're trying to bootstrap you're going to start trying to download and if everyone else updated you're not going to be able to ever connect to the network isn't that the same case though because clients like like isn't the same case true whether we bump the protocol version or

not because if you don't update and you connect to the network and everybody else is on the new protocol version whether or not the difference is that the difference is that everybody can serve both so you can connect on the new version I know but hold on even if you connect on the old version because you didn't update you're connecting to a bunch of clients that dropped the history and are no longer serving you that data well they don't have to drop the history I understand if you're if you're serving e68 which is what we're on right now then you would have the history if you're serving eth 71 you might have the history but you're not

going to provide that history over E71 because the specification of that protocol says you will not conserve that history so so if I understand correctly the case that you're concerned about is an unupdated client connecting over e68 or whatever the version is and expecting to get history but not getting it isn't that true and both of these cases that it will be connecting to clients that do not have the history and thus won't serve it or it won't have clients that it can connect to like isn't aren't these the same whether we bump the protocol version or not I think that if you bump the

protocol version it becomes explicit whether you're going to be able to connect to these nodes or not and it would be nice if we could have this before the Prague hard Fork so that we have full acceptance of that wire protocol so on May 1st when we start allowing clients to drop history it is explicit whenever you go update your client you can go find peers that will not you will not need to request history from and if people decide to like continue running nodes that download the History because for whatever reason they haven't updated their node then they can still connect to those nodes and download the history when they need to I don't want there to be a situation where we just stop serving the history and someone stop serving the history and

after the product hard Fork someone just has a binary that is Prague supported but doesn't drop the history and they can't find a peer that they can download the history from okay um I think that we just need to do a bit of async discussion here uh on the exact rollout plan for this because this is all just um specifics in the in the actual implement ation um and it doesn't seem like we have a clear consensus today and I don't know if discussing it further in the call is the best thing um what I'll do here is try to get a write up posted of kind of the two different approaches and get it out there and see and see if people want to

weigh in on on which direction they want to to go with I think it makes sense to do that I have a question just to make sure I understand what what is the rationale for not having an explicit separation like whether it's 70 and 71 or 69 and 70 like what do you gain by not having an explicit tell that there's a different protocol version that people are running um I assume at some point we'd want to deprecate the E protocol versions that serve full history so yeah I think there's two things one is that there isn't much of a difference in the actual protocol version uh the the the protocol definition it's just

the semantics of it of what the client does behind the hood but it doesn't actually change the payloads at all so in terms of the actual messages they're all exactly the same it's just about the behavior of the request when it comes in and then I think the second objection was that um was just about added complexity there's some cross network uh compatibility things that I think Aragon brought up okay that they're working on um and so just having another protocol version to work with I think was just adding complexity to their stack um I may have misunderstood that Andrew yes so uh yeah two two two points one is that there is this protocol e 69

which we discussed at some point but it's not finalized yet and it's not it has some um pre proposed merge cleanups and uh we realized that it might be not not play play well nicely with with polygon so but we we we need to think about it more and uh maybe discuss it again but basically is is 69 is uh not relevant to to 44s it's just like it's like sequentially it's it's something that we we should finalize if we are talking about things like e70 right got and uh uh why

uh uh um I also think that uh we need we need one one one one s single protocol to actually um uh that works for all um notes either they uh store some fraction of historical blocks or not uh because um that will solve this this issue when you need to download historical uh blocks that should be like you it should be explicit uh in your peers like which block your your peers have uh and if we if we do things like 7801 concurrently with uh a new version

of the protocol that actually prohibits Serv historical uh blocks that creates a bifurcation in the in the network uh because then if you want to improve the the protocol then you you kind of how how do you do it your protocol name space has split into two so I would my strong preference is to actually to have a single uh protocol say is is70 that works both for clients who decide to store Shard of historical blocks and who don't okay got it um okay so I think yeah Piper if you want to write

something up um and post on Discord that'd be great we can continue uh this conversation I think but yeah it seems like we're at least moving forward a bit anything else on History expiry not for me sweet okay do we need to are we going to need to do this I mean if we decide to have this additional for wire protocol like I think it is kind of important that we roll this out with Prague how do we sort of add add that to hard

fora I had a point about this at the end of the agenda but I think in general we should start adding non uh consensus changes to meta hard Forks um yeah maybe we can discuss that at the end but um we have done some things like this in the pass like with the self-destruct deprecation but it does feel uh important to Signal them but I yeah before we get into that kind of worms um there's a couple other things but yeah that's an important discussion anything else just on uh the actual spec or technical changes okay uh next up ax shared this

on the agenda I don't know if he's on the call EIP 4803 so a while back we discussed adding a bunch of bounds to uh constants in the protocol and we we did add a couple um and this one I think was never confirmed um so uh yeah Alex you want to give some context yeah the the one we actually uh merged back a couple of years ago was 2681 uh limiting the account nons um and there was another like a larger EIP uh

called 1985 uh which was proposing bounds to pretty much everything and at the time uh we agreed to this uh the account nons limit uh we also agreed um to split up this 1985 into individual smaller changes and the limiting transaction gas maximum is one of them um this EIP is proposed to be enabled from Genesis and what it does is uh no transaction can have a gas limit higher than 2 to ^ of 63 minus 1 um and the reason for this is uh it allows um simplifications in the

EVMS um with using 2^ 63 it can be handled as a signed number and checking whether an outof gas condition is reached is a matter of checking whether um the gas became negative the reason this could be enabled from Genesis is that most of the clients including go ethereum already do internally um they take the gas uh value as a 64-bit number and the second reason is it it is to create transactions with a limit higher than this um because you need to to pay the the or have the the funds

available up um at least this is the case on mainnet um it may not be the case elsewhere um although it seems quite unlikely that um you know this condition would have been hit outside of main um that's the the EIP there's a bit more detail in it not not too much more um and my question is you know whether there's like any strong reasons against this or should we consider um yeah spending more time on maybe any of the the questions any of the analysis questions um and eventually enabling this one quick question I have is why use a different constant for this and

2681 like one of them is 2 to the 64 minus one the other one is 2 to 63 minus one should we just use the same number everywhere um the reason to go with 63 because then it can be a signed number and the the gas out of gas check is uh is much simpler so I guess yeah there's a comment by Barnabas around like just testing and inclusion in the fork so even if we retroactively add this from Genesis we need some tests uh for for this so it feels like a bad time to uh to like add those tests given we have a bunch of stuff for Spectra um but that aside you know assuming we got to this

when Spectra was uh done do people have any like conceptual objections or design objections it would be helpful to see if there could be some sort of example to see how you're using this negative Val gas value like I kind of understand that it's possible to use this to know that it's out of gas but if you could link to some sort of example where a cent is doing this and like what the implication that would be helpful for me evm one was doing this but the way you could do it you just subtract the the gas and you check whether it's a negative value and internally CPUs would usually have specific instructions for the

negativeness check um so technically it can be cheaper um I think definitely this can be one of the the points to debate you know what is the limit 63 or 64 and and um that is that is a valuable discussion to be had um setting that aside um can we at least agree whether conceptually putting this limit is something people would agree with or there's strong reasons not to I think the 64 versus 63 discussion is something we can do I think okay so it seems like there's not objections I guess in terms of Next Step

um Alex if you're able to open a PR uh we have a meta EIP to track these like retroactively applied e PS um so I think the yeah what I would do is just open a PR to that EIP to like list this one and then um yeah we we don't have to merge the pr now but in a couple months once we're um once we're through the pectra test St we can uh yeah we can revisit it and hopefully have like the 63 versus 64 bit figured out and Yeah Alex um sounds good um I briefly would like to respond to what Ben yeah

mentioned EIP 7825 and actually left a comment inther magicians regarding this 7825 uh proposes to introduce a lower limit uh a limit of 30 million um and my comment was that I think the the pr I'm proposing can be enabled retroactively um whereas 20 70 uh 825 is probably something you may not be able to enable retroactively um but the two are kind of related and uh I think essentially you could have both at the same time one specifies the hard cap um and 7825 is more like a soft cap on the you know one is an implementation detail

and the other is a limit which we may or may not change over time yeah and I think uh 7825 if we we we can never retroactively apply because you could imagine someone like you know the EIP hard codes at the 30 million now um so like yeah if the gas limit changes and like someone uh you know we decide to include this we need to have a specific blocks where like we actually activate this um yeah so I think they're yeah they touch the same thing but they're different like scopes of implementation for sure um okay anything else on um

4803 okay well yeah thanks Alex uh let's yeah open up a PR against uh The Meta EIP for retroactive Eeps and then uh discuss the specific a constant ASN um anything else uh about I don't know EIP specs that people want to discuss before we move to the award process stuff we have only three minutes left um okay then I'll try to get through these quickly but first um so okay so we discussed this in Bangkok uh three ideas came out of the award devs process Improvement sessions one is ADD adding a decline for inclusion status uh to Mela eips for hard Forks the idea

there is that um you know we decide to accept stuff into a hard fork and we never we don't have a formal way to reject something from a hard Fork we sort of implicitly do so by just not accepting it um but it would be valuable to be able to Signal like this is not something we want to do in the current Fork uh it doesn't mean we never do the EIP obviously anyone can work on any EIP and they're free to prop CL it every time uh there's a new Fork but we do spend a lot of time discussing eips and their inclusion in Forks so having a formal way to say we don't want to uh include this one in the current Fork would be valuable does anyone disagree with having this status we it we we don't have to like use it

and like we wouldn't like retroactively use it but it's something we could just have in the future okay uh 2+ one so I'll merge the pr other things so this just came out as well um adding non-consensus changes to meta eips so um we have meta eips for hard forks and it's clear uh you know why we need them because there's this set of changes that happens at a specific block but one challenge with that is it means our process often biases towards things that have to activate as a at a specific block um so you know we uh for example 44 is the best example where we spend years talking about it and it somehow doesn't get quite prioritized because it's not

on the same list as everything else and we also have this other category of stuff like you know neutering self-destruct and other like potential protocol changes we want to make in the future that we um don't have like a formal way to announce so the proposal there is that we start including non-consensus changes in hard forks and that for something that's a non-consensus change like say 44s the uh basically the implication is that clients will have this featur ship at the latest for the hard Fork so it's fine for teams to ship something before the fork goes live it doesn't all have to activate at the same time but people can assume that on mainnet you know something like 44s or whatever the new EIP number is um will at the lay list be

activated by them um yeah any I think that makes sense I guess one thing to note is you know we still have the ability to ship things like this uh without works but this is sort of addressing the false positives depending on how you look at it correct um so I yes so we have like we can ship stuff before and what that would look like in practice is just whenever there's a hard Fork we can just add those things that we shipped previously to the list and tell people like as of this block all those things are active on the on the protocol yeah that works and I think

historically our problem is more we don't ship the thing then we ship too many things between hard Forks so I'm happy to revisit if if we you know were only shipping networking changes and that's it and Puja just wanted to make sure here like uh this is for the proposals which are going to be shipped before the main hard fork and not those proposals which are going to be retroactively added for yeah I would keep those separately actually yeah because the retroactively added theps every block from block zero should Implement those protocol rules so like for example the transaction capping and we can only add those if it's true that in the entire history this condition was

not broken um whereas something like a a you know dropping history we we like this was not true of the entire chain history and so even though on the consensus level it's not something the protocol sees it feels more accurate to say as of this hard for this feature is live even though it's not like a consensus change um yeah and just one last point on this still in the meta ape we are going to add just the core eips and not the networking eips no my point is that we would add all protocol changes whether or not they're Corey IPS since the last hard fork and then we

can also decide so like we can both retroactively do this like we ship you know to e protocol versions since the last hard Fork we should add them but if we decide like four fours is our priority and we should do that and not you know ship a bunch of Corey IPS we can like proactively decide to focus on that instead and that's the main thing that I think we should address is that we we tend to bias towards things that can um yeah we tend to bias towards thing that like are core changes because that's just what our prod our process is built around thank you for this right now um um I might want to revisit this one one more time and if I have any further question

we'll get back to you thank you okay sounds good okay um and then okay the last bit we won't have time we're already two minutes over but something worth uh discussing on a future call is um how things like CFI and propose for inclusion and schedule for inclusion relate to devet uh stages is as we've seen today like that's a big part of our constraints so um yeah it might be worth considering whether we want to explicitly tie Something Like We Only SFI something once it's part of a Dev net spec or we only CFI something if we think you know we will include it in a Dev net or something like that and we have a rough sense of those things but

they're not 100% aligned um but again this is a bigger can of worm so we can bring that up on the next call last thing before we wrap up I know we're already a few minutes over uh award Dev holiday schedule so we'll keep the testing call on December 23rd cancel ACD on the 26th cancel the testing call on the 30th and then on January the 2nd uh we'll replace ACDC by another testing call for people who want to show up um and yeah that's it for today thanks everyone and talk to you all soon thanks bye bye thank you than

oh