All Core Devs - Execution #205

Transcript

[Music] Thank you. Um, welcome everyone to ACDE number 205. Um, yeah, couple things on the agenda today. So, we'll chat about Peterra and specifically the client releases. Um and then there were a few things on the Fusaka front uh that people wanted to cover and then uh Kev had some follow-ups on these uh node requirements conversations.

Um so to kick us off um before we go into the client releases uh Perry, do you want to give a quick update around DevNet 6 and how that's gone over the past week? Yeah. Um so DevNet 6 is doing really well. um the participation rates close to the maximum what we'd expect and the last couple of days Ryan as well as um Justin has spent a lot of time debugging the map stuff. So earlier today or last night they were actually able to get ME blocks in reliably along with at least one with an execution request. Um so I think the MEV workflow is also looking good now. Um, and we will of course be

trying a lot more of it and making sure that it's robust over the next days. Um, other than that, I think most clients have also reached out to ask us to update their notes to whatever release they're using slash what they were planning on releasing and that seems to be stable so far as well. So, looking good. Nice. Yeah, thanks for the update on the six. Any other clients want to share anything here? Okay. Um then yeah, we obviously uh have the test net release starting to roll out. So for anyone listening, we're going to fork Heski on uh February 24th at epoch 115968

and then seapia the week after that at epoch um sorry on March 5th epoch 222464. UMP and we have some of the client releases that have started to roll out. Does anyone uh fear they may not have a release by tomorrow uh for their client? I think there's three that are out um already, but yeah. Does any team think they're not going to get one in the next 24 hours or so?

Okay, great. So, um I will keep an eye out for those releases and then as soon as we have everything hopefully tomorrow around this time, uh we can put out the blog post uh announcing the test net fork. Um and then on this note, uh Perry realized today that we do not have the system contracts deployed on test nets or mainnet. Does anyone want to do this uh over the next day or so just to make sure that we have all of the different system contracts deployed?

Okay, no volunteers. Let's follow up as on this, but it would be great if we can um if we can have those deployed by say Monday's testing call. Um, and then there's a note from PK. So, uh, Ephemery will support, uh, PectRA today. Uh, PK, do you maybe want to take a minute to explain to people what Ephemery is? I'm not sure how broadly known that is. Um, yeah, I can quickly give an introduction. So, ephemery is basically an uh, ephemeral test net that uh, resets itself every month. So um we have a static genesis and based on that we just increase the main genesis time and

basically reset the whole network to the genesis state every month. So we don't have any fund problems or yeah it's basically a playground so we can test things without caring about the history of things. And yeah, we're going to activate uh Electra today in the in the reset today and it's going to happen at about uh 7:00 in the evening uh plus 10 epochs because Electra activates at epoch 10. Got it. And if uh if people are want to run a validator on ephemery, do they have to register for the genesis?

Um no, the genesis set is open. We have a set of genesis validators, but we also have a deposit contracts. So, anyone can uh deposit validators and do their testing on there. Awesome. Uh, anything else on ephemery? Okay. Then and then one last thing I'll flag for Perra. Um we're trying to move all of the EIPs to last call. I've uh open a PR to move the MEA EIP to last

call, which uh depends on all of the other ones. Um, so a bunch of them have already been moved, but if you're the author of 611, 702,7251, or 7549, those four still need uh to be checked uh to uh to move to last call. Um so yeah, please have a look at those um if you can. And I think that's all we had related to Perra. Anything else people want to discuss?

Okay. So, next up, um, Fusaka. So, first off, um, Mario opened a PR against, uh, EIP7723, which talks about the requirements for the different stages of EIPs. Um, and this one adds some uh potential testing requirements. Mariel, do you want to give some context on the PR and what feedback you're looking for now? Yeah, sure. Um, so yeah, basically uh this is the link that I shared in the in the chat. Um the basic gest is that we want to make sure that when a EIP reaches the CFI uh stage uh of of maturity, we wanted to have a um eels uh

execution specs and east uh implementation. Um so if you take a look at the at the PR they are like uh suggestions at the moment for CFI and they are requirement for SFI uh for for the stage of the EIPs. And the idea behind this is that we want to make sure that the the EIPs that reach these stages already have something some implementation in Python that we can use to generate tests. And this simplifies a lot our uh our our our workflow and makes uh makes sure that we the testing uh of any is not the bottleneck to get the uh the implementations live. Um so yeah basically please just take a look

at the moment um it's it's it's based is the the the PR is just a suggestion at the moment is an instant draft but yeah and the the idea is that we want to remove testing from being like the bottleneck and one of the comments also in the in the PR currently is that uh this seems like an overhead for EIP writers but in my opinion uh this overhead is worth it because um by the moment that we want to like put the test for the clients to consume and for for the the clients to test their implementations, we should already have like the tests implemented and also being yields the center of the implementations for all of the EIPs

guarantees that we will be able to combine all of the implementations when the the time comes for the fork to become ready. Um so yeah in my opinion and uh this poses a lot of improvements in the testing workflow and and it will be like a a a much better spot that we are in the EIP workflow once the the testing becomes necessary. Um so yeah this that's basically just um if there are any comments please just uh feel free to come here and and and and and post them in the PR. I'll try to uh push it from draft into into non-draft uh in the next couple of days. Um but yeah, any feedback is is obviously welcome.

Any questions, comments? Um I kind of disagree to be honest. Um because I think this could lead to a situation where uh the ES team is basically the arbitra of opinions because they can choose to uh oh you're breaking up Marius um choose to implement something sorry um the team can basically choose to do

something uh or or like kind of prioritize uh the stuff that they are interested in and uh that there would be no formal way for us to getting stuff in if it so and do you feel this way about Oh, sorry. You kind of broke up a bit at the end, but I think we got the gist. Do you feel the same way about testing? Is it like about specs or just feels or sorry is it about like yeah just the the actual spec or like the idea that we

want to have tests? Uh I think it's a little different with tests actually because you can just write them on your own. Um why could you do this with eels though? Well, because you still depend on eels to merge it. Then if that's like the formal requirement, I don't know. Like and and also it's not everyone can write the Python implementation. But if they said they can't write the test, should we like it's if they can't write the tests, then this feature should not be allowed or may not in my opinion.

Right. And you think that writing the Python specification is a like qualitatively different requirement. I agree like maybe we should make it a PR rather than like a merged PR and then you know anyone can obviously open a PR against deals. Um and and you're not blocked on the team merging yet. Um yeah, I think I would be okay with that. with having like a PR right like making the requirement the PR to the repo.

Got it. Uh Justin, yeah, we had a similar um we had a similar talk on the Basu team actually about this and we kind of kicked around and steelman a couple of of concepts. I I appreciate the notion that having an implementation in a neutral um place like Eels does in fact have a lot of soft benefits, right? Um it it it helps client teams start on an equal fitting and it prevents client teams from kind of having a first mover advantage when they're implementing something new. Um and I think that's good for prototyping.

I think that encourages people to prototype in um a neutral a neutral place. And the the downside though is like well that's that's literally throwaway work, right? Um and that's a pretty big downside. Um well it's not though because it's a spec for Ethereum. It is. But if if if if I'm proposing an EIP and I work on a client team, I now implement it twice, right? So I I think that maybe we could rephrase this as an implementation is required at a client and you still need to have the EST tests implemented for everybody to validate against. And so then you get into a situation where the

filler of the test can be any client. And um I I don't know that all clients have have that capability. I would think they would. Um, but I think that might be another another approach that we could take here. Um, but I do like the idea of at least having a PR open and not having to to wait on that. Um, so I think the TLDDR is I actually see a lot of value in having a a neutral um prototyping ground there, but we do appreciate the um the challenges that Marius is is raising.

Mario, so yeah, I I definitely see the that this looks like a a like overhead and unnecessary work. Um the the comment I mean the PR comes from a space where like we've been in a in a place before where we have like multiple EIPs that are coming together into into into a fork and we have one implementation in in one client and another implementation for the EIPs in in in another. And the bottleneck there becomes that we don't have a single implementation that implements every single EIP. So when the time comes, I mean it's okay for EIPs that basically don't touch any other part. But for example, when we have important EIPs that like modify the

block header and invalidate other other EIPs or or mess around with other EIPs in any shape or form, it becomes complicated to like merge both both tests when you don't have a single source of of of of truth for the whole fork. So um yeah, well I agree that uh that it's it's convenient for the client to only implement once. Uh it's very convenient for the for the testing team to have like every everything in one place. It simplifies our work. It like makes sure that uh we don't make mistakes when filling the test because that has happened also in the past. Um so yeah, I think I think it's a bit big advantage for testing uh in my opinion.

Uh but yeah, happy to to to to re revisit it uh and and talk about it. Yeah, that's that's just my opinion from testing team. Yeah. Perspective. Sorry. Yeah, I think like yeah, clearly there seems to be more support to making this like a PR than a merged PR uh for EEL specifically. That seems reasonable. Um and yeah, I'm I'd be curious to hear from other teams and basically maybe on like the client implementation.

because like yeah I I I I don't I I don't have a sense for like what's the overhead of having an EELS implementation and like if you are proposing an EIP like I don't know is it like everyone else who's not a client dev would have to do this. So I I I'm not super convinced that like we should have a different requirement unless it's like I don't know time teams can save a significant amount of time by by just doing that.

I guess that's fair. Um you're you're right that that which hits the hits the fan will be spread evenly. Um I I can't really speak to like what the overhead of a particular implementation is right because it depends on the EIP. Like you know for instance if you look at Fossil and you wanted to implement both in Eels and then Basu and then you know the the um CL specs and then Tekku right those are going to be all very different uh amounts of work because you know that's an example of a lopsided uh feature that has a lot less work on the EL than it does on the CL. So, um I I don't know.

Yeah, I I find the I find the the point that everybody's is saddled with it somewhat compelling. So, that's fair. And uh one more question for So, for Mario, um in the PR, I think I left a comment saying we should have this be a should for CFI and a must for SFI. Is that still your perspective? So that when we CFI something meaning we want to include it in some DevNet you know we we have this be like a soft requirement and then before we actually include it in the devet this goes to a hard requirement.

So I changed that in the in the PR. So I placed the shield and and and sorry the yeah I I place both both com both both modifications according to your your comment. I mean when whenever it it reaches uh a state that is in CF5 um we we we step we step up anyway and then just make the implementation uh both in east and um so I think it hasn't been like a problem so far for for EIPs like it's it's not like we are blocking uh the the EIP inclusion in any way. uh but is but what what I would at least like to see in the in the EIP workflow process document is that this these two

uh repositories are mentioned. So but so it it's just in the minds of the EIP writers uh at least they they they would have like the idea they have to contact the the the maintainers and then make sure that uh the the the PRC is implemented not not by them but for example by us if that that's like a very big big plus in my opinion. one thing I wanted to maybe get folks's opinion on is when we say should here, that implies that there are exceptions.

And it may be the case that, you know, a line or two in that PR outlining what is an exception and how it works would be useful. My assumption is rough consensus, right? Um when we're talking about an EIP and we're debating it, someone will say, "Hey, this should have an implementation." and then somebody else says, "Well, here's a good reason why it doesn't." Um, I assume that is how that would go down and I assume that could be a potential point of friction that we should be aware of. Yeah, I I agree with that and I think it's worth like we can run through the motions and see what comes up. But um yeah,

um yeah, my question is uh about the prospect of uh of the growth of the team of that team, the the steel team or the EOS team because um yeah, they're they're like really understaffed. We like we on the vertical effort run into this problem. They did a great work. It's not uh I'm not trying to to cast a stone here. I'm just saying um I feel like this is going to be potentially a huge drag. So we would need to have people working on EELS or steel, sorry.

Uh you know that would be way more responsive to what currently their bandwidth allows. Well, I think sure we we we should scale that team, but also we should put it on EIP champions to write this stuff, right? Like so if you are coming with veral, it should be part of the veral team's like responsibility to write these tests basically and I think that's the only way like that's the only it's like it's the only way you can scale big enough where you want Yeah.

Yeah. you want like a self-s serve option and then at some point obviously you want the testing team to review that and and we should have more people to to to help with with that but um right yeah sorry yeah go ahead no I was say like yeah the initial testing and spec pass should be the responsibility of the EIP uh EIP champion yeah but precisely I mean I agree in principle and this is exactly what we've done right I spent most of my months of May last year doing this and then Ignasio took over uh we had uh the problem that you can't just drop in a fork the scope of Verco or anything else uh that big uh into into the test framework. you need to change the

framework which means we had to dig uh and once again the people working on the on that EOS team they've they've done sorry the the stateless execution spec test sorry right they've been doing a great work uh it's just that they had to do a billion things at the same time and uh it took us maybe six months to do something we could have done in a week and what was the what was the the cause of the difference there like not having someone yeah like input format I mean what was the cause of difference uh we we need to change the input format we need to change some consensus rules we need to

change a lot of things in the code and it's not designed for this and it's like building a new client uh I mean it's like it's like porting yeah it's the same amount of work we did for go ethereum that we had to do for for eels and uh um sorry uh execution spec uh but uh but yeah there's uh you know it can be quite involved and unless you're intimately cognizant of the of that code base you will need help from from that team. So yeah, and Peter, uh, yeah, just following up to Gu's point, um, I think I agree and I think that the ELC agree that we are like, um,

understaffed. Um, firstly, we like um have hired um, and we are likely to hire further, so that should improve. Um, also I think we've had a problem that like a lot of what we've had to do is just been catching up with all the work that um has happened already um and so we've been like behind the curve and so I'm hoping that once we get to a point where Eels is like ahead of all of the other clients um in terms of what we're doing and the clients are busy shipping um earlier forks and we're starting to think forwards to later forks that that should also improve proof situation.

If people want to work with eels, who should they reach out to Muriel? Yeah, I just wanted to echo uh Peter's comment. Uh same thing for for East. So, it's a pretty it was a pretty new repository last year and uh we've been working hard on trying to make things like easy to to improve and easy to modify and there it has come a long way uh since since last year. We've been working a lot of of of framework updates and everything to make it easier for us to implement this faster for you. And uh I think I think I I agree that we are in a better spot and we should be able to deliver things faster uh now. Um but

yeah anyway um who should you uh refer to if you want to? Yeah I think anyone from the from the eels or east team. So myself, Peter uh Sam uh or for example Spencer or Dan from the east team. uh you can reach out to anyone from us if you want to contribute and we will uh uh of course help you out and and and and yeah welcome your support. Okay, thank you. any other comments on this?

Otherwise then I think uh the next step would be uh yeah to incorporate the feedback from this conversation in the PR and then uh give people maybe a few more days to review and we can probably get it merged in the next week or so. Okay. Well, thank you, Mario. Um, next up, I wanted to bring up the Petra retrospective thread. So, I believe every client team except uh two have put in their their input. Um, I think uh I think Aragon and GU were missing, but everybody else had shared their views.

Um, I went through it two days ago before the last few client team uh, updates came in and even this morning rereading the the last the last three, it seems like there's three kind of core things that come up over and over. Uh, one is people want quicker hard forks. Um, it seems pretty universal. No one is arguing that we should do longer that there were a couple like proposals for like six months but I think in general um yeah people want to see a higher frequency of hard forks and then um the the cority to that is that you you need to limit the scope of what goes into a fork uh quite early on to achieve this.

I think um the other thing that comes up a lot is uh literally the conversation we were just having agreeing on what's like the technical standard uh that we want to have for uh including EIPs. Um in this fork there were uh there were a couple cases where we probably would have uh made different decisions had we had like a more thorough understanding of the technical implications of including something. Um and then there's many different uh comments and suggestions for just at a higher level how we could change the awkward dev's process ranging from like you know formal working groups and a completely different structure to a bunch of uh smaller tweaks. Um

my like high level proposal when after reading all of this would be something like we try to uh we try to separate like what are the things we can do right now and then what are things we want to take more time to review. Um and my sense is the one thing that we can probably do quite quickly is uh this idea that uh we could agree to li finalize the scope for a fork once the other fork goes live. So we have a fork that's about to go live uh with Pectra. Um and then you know if we wanted to use this as an opportunity to finalize the scope for Fusaka to only what's already included this gives us

time to in parallel start debating what should the technical bar be for EIP coming into the fork after and then other process changes uh that we want to make and um hopefully you know like through this this time uh where we're working on Fusaka we can finalize that and then try to ship Fus Saka in something like six months or so. Um so I'll pause here curious how other people feel about all of this if there's um yeah other things that uh yeah people feel strongly about.

But yeah, my proposal would be we would freeze the scope for Fusaka basically nowish and then this gives us some time to start debating the EIPs for Amsterdam and how we want to change the process but doing so without delaying um implementation and shipping to Saga. So, so one point I think that was under represented in in that thread was the coordination costs. So, I point so there's two from a couple of sources. I

mean putting aside uh for the moment the development let's kind of assume a magical software development process where all the teams immediately magically produced um the working output instantly. Okay. So there's still the the test net and the mainet uh schedules. Now we know from the ongoing discussions with L2s that we're targeting what 30 plus days now for apparently last test net my understanding uh maybe I'm wrong to to mainet deployment uh right wrong I don't know but that seems to be what that's heading towards so that's a month right there of of wait of kind of development dead time wait

and and the devets themselves that's two or three weeks there so with when you have a year approximately then that's not a huge overhead when I but I think there's a fixed cost right now we have of this and that fixed cost my main point here does not primarily come from the development process itself it comes to the fact that it's being sort of deployed in a decentralized way by end users whether these are L2s have to integrate it whether these are homestakers etc so that there's some minimum time which makesense yeah and my sense is that fixed cost is like on the order of call it like a month maybe six weeks where um you know like yeah if we were talking about

forking every month I think that would be problematic. I think if we're talking about going from you know 12-ish months to sixish sixish months that's doable and the other thing as well is if you know we're just quote selenium waiting for the fork to activate uh if we really want it to be uh optimizing then you can just start working on the next fork you know by the time that the first test net release is out or whatever um and you get like another month. I'm not sure that that's super practical, but um yeah, I think if going from 12 to six months like the fixed costs don't dominate, but if we go from like six to three, that starts to be like a like a bigger questions.

Okay. I I mean I think that's at least defensible. Yeah. I would say once you start going to three, it's if you're saying four to six weeks basically that's like half the time. Yeah. Yeah. Exactly. is like very I mean at that point of course people can talk about you can pipeline this or that with oh it's not just N plus one but also N plus2 and three and people can get pretty elaborate about this stuff because whatever uh but but the point is I don't know that I see the ROI in going that far for sure I think I think there is a four and whether six months is at four maybe but yeah yeah and I don't think I just don't think we're that good yet like maybe in a year or two we can talk about going from six months to three or something

But yeah, I I I'm very skeptical that uh we could pull this off even if we tried to did this today. Any other thoughts, comments? So I guess back to like the practical suggestion like if we agreed to freeze fusaka this means currently eof and pieras are included in fusaka. Um those would be the two only things we would freeze the scope with this and then we

can start discussing you know the scope for Amsterdam uh basically in parallel and I think prior to discussing the specific EIP form we'd want to um we we'd want to discuss like okay what's like the technical bar and what not um yeah um then Oh, then Anscar.

Yeah. So, I I think overall I'm probably in favor of freezing the um Fusaka scope um now, but I just wanted to briefly make the argument. So, for me, for example, I think we should definitely ship Fusaka purely based on Pas. So meaning that if Pas is ready and UF is not for example I think UF should go back out of the fork. But on the other hand it could also be that like pas just still make takes a while and then that basically the E is just sitting there idling for for a long time. And so in principle I don't think there's anything against that. It could be possible to say we we keep having just dev separate devets for features that for now are scheduled more for Glam Sadam on the outside. But if at some point we realize we have the time and the test dev nets

are already stable for some other E features, why not bump them and move them into the existing um Fusaka scope if again if if just on the E side that that that ends up being reasonable. Yeah, I think my sense is we're almost never in that position. We're often in the position of things not being ready. But like if we this fork is kind of nice because pure das and eof are so isolated from each other. So like yes we could probably make a call if you know pure das is going to ship one month after eof and we want to add one more small thing to the e we can probably do that but I wouldn't want to pre-commit to this before we're in the spot where things

are going so well that one of the layers is wondering what to do. Um that um yeah I would I would want to include the two mod x um issues in um uh fusakappa the one where I set the upper bounds and also the repricing because they're they're like bug fixes rather than features I would say. Um, if we're, you know, if we're expecting validators to go free form on gas increases, they're like problems.

So, not to yeah, not to get into the weeds of this specific change too quickly, but I do feel like um yeah, if we open the door to one small EIP, there's a risk that we get six small EIPs coming in. Um so, I I would want us to think about like, okay, what's the right way to do this and when do we want to add uh such a change? Um yeah and and again like maybe this one is like yeah if this is more of like a security fks a security fix then like you know a new feature then um yeah sort of bug fix rather than um

feature. Yeah. And then there's already a comment in the chat about the other pre-ompile whatnot. So like I think this is the big challenge like do we actually freeze or not freeze and then if we have like something like a soft freeze or whatever um then yeah we'll be back in the same situation where we didn't actually freeze the pork like time. Yeah, I mean I think we are overreacting to the situation that happened with Pekra in a lot of ways because we're kind of going from this place where with Peterra we sort of continued adding stuff in sort of trying to do a

lot of stuff in parallel and it sort of blew up in our face and now it seems like we're coming back and we're like going even farther on the other end and we haven't even shipped this fork yet and we're talking about freezing the spec for the next fork. which you know this is like a year out and basically nothing in the fork at least on the E side is really related to any of the things that are have been hot topics for Tekra or in general right now things like improving the censorship resistance increasing the throughput of the EVM all of these things so I find it difficult to say like we're just going to freeze the we're going to freeze the fork right now when you know that kind

of means that we're not going to have any of these things that feel important today for 2 years. You know, we can say we're going to try and do these 6 months forks, but like the reality is it's not going to happen almost certainly. So like even if we do eight eightmon forks, it's like that's 1.5 years minimum before we start seeing some of the stuff that feels important today. So it seems too early to totally freeze these things. Um, I also think that like the things in the fork are not really that important. Like pure DOS is clearly one of the most important things for us to be doing right now. We want to increase the throughput that the chain can can handle. And it's not just a CL change. Like we do need to think about

how to improve the transaction pool on the E. And if we're doing other stuff, then that's time that we're not going to be able to spend working on those things. So I think that like eof on the EL does not really make much sense given like where we are today. We're also in this moment where ZKVMs are advancing rapidly and we don't know what the end state is going to be. So I don't see a reason to make a massive change to the VM when we don't know how ZK EVMs are going to interplay with this in 3 years. So I think we just need to let the dust settle a little bit. We need to try and figure out what EIPs fit best with the goals we want to have in the next 12 months and then go from there.

So there's a couple hands up I guess just two things I'll flag. One is yeah to the extent we spend many months debating what goes into the fork it will delay how we how quickly we ship it. So if we want to at least have a chance to ship it in 6 months, then we need to like effectively not be debating the the scope. Um yeah, we need to ship stuff that matter and things that are important today. And I think that like just shipping stuff at a cadence just to ship stuff is not really moving the needle for this project.

So and the Petra is not live. So like you know we still have call it like you know a month a month and a half like to what extent would that be sufficient to actually finalize the scope like if we think there are other things that are important or like that we need to prioritize or new things that we need to prioritize like what is the blocker to making that um making that decision in like the next six weeks. Yeah. Uh, Roman.

Yeah. So, my my immediate reaction to what life clan has said is that like we would never get to a faster pace if we don't commit ahead of time to to the scope. And uh I agree like we can use the all of the time remaining until the pectra lands on mainet to to still finish this discussion if it is unfinished. But uh otherwise like when factor lands we should not just keep debating EAPs that are not ready and oh sorry yeah

sorry yeah and if if these EIPs are really important then we can already start working on them but for for the fork after like uh otherwise we'll never improve the pace. Thanks. Uh pot. Yeah. So I think it's it's true that not agreeing on the scope of a fork delays it slightly, but I think the actual bottleneck here is on testing. Uh and I think it's unreal to expect that we first need to agree among all clients on what we're going to implement. have a devet among all clients and only then we actually spin a proper devet. I think if

we want to increase the throughput of forks instead of like arguing forever about what has to be included and what's not we should like try to have devets of features when just a few clients are ready and stop waiting for other clients to be ready. we should like agree on having several deaf nets in parallel and as those deaf nets starts maturing other clients can catch up but I think it's on the testing front that we need to focus our efforts to increase throughput and we should be we should stop arguing about forks um spec uh scopes because that's really a waste of time uh we should more be concentrating on shipping

coding and start testing earlier even if some clients are not ready. So I guess yeah maybe two two uh thoughts there. One is like uh yeah so we we we already do kind of do this to some extent like you know pure das and eof and veral all have dev nets. One one thing though is like I I don't think I think a devet or like testing should be necessary but not sufficient to go into a fork. Like I don't think we want to move to a spot where like anything that anyone's able to put on a devet is something we want to include. Uh you know at the very least we might make bad decisions and like it feels like also like a DOS vector for all core devs.

No I didn't I didn't argue that we can we can have in parallel the discussion of what's the scope but I think the our bottleneck today is testing and it's not scoping. So we should be testing and then in parallel we agree whenever we feel okay the next fork is eof and pas and we have this already tested enough we can just ship it immediately we should stop. Well that's kind of I guess that's kind of the like how would that be different than the the world we are today like we have devets for eof and pure for example. Um I think I also want to bring up the point that Maret for PF and PR DAX. We have some devets

on efas. No, we have a devet with multiple clients if not all CL's on podas and all ELS on ef. So that is the canonical devet. We have a breakout spin up last week. Exactly. Both of them was spun up last week and we have four podas devets and the third one we also realized a lot of things that weren't working. The fourth one had a lot of reworking clients implemented. So this is all part of the testing cycle is what I want to mean and I do want to bring it up to Marik's point scoping is the issue. If today ACD was to agree that fossil IS whatever is the other feature that we want to completely um spend our time on then we

will be spinning up a fossil devet as well. The moment there are two three clients whatever there is there will be a fossil breakout room there'll probably be an eels implementation east implementation we'll onboard the whole thing but the problem is we as ACD need to agree these are scope topics or features that are worth working on ASAP and that's what we would assign testing priorities on and we can't have that for infinite number of features right now it feels like we're positioned to do three and I guess we need to agree on if we want to do five or six but that number and what the scope needs to be needs to be decided.

Thanks. Uh let's see Peter and then uh Lucas. So I think this kind of comes back to the discussion we were having earlier um about like um eels and stuff. So I think the world Eels would like to be in, which we're not in to be clear, um would be one where we could clo where we have like a list of like proposed features that are ready with complete EIPs and with um Eels implementations that are merge ready and with um tests that are ready. And we could just say to all core devs, we're going to close the gate to new features now. here are the options that are sufficiently developed to get into the next cycle and then we can like

close the gate. Now the problem we have is that if we want to add anything that um isn't eof um or podas then um those developments like they're not quite ready, we don't have eels, we haven't written tests yet, so we can't do that. So like the long-term goal should be to be making the scoping decisions um about at this sort of stage, you know, towards the end of the previous fork, we should be scoping the next fork. But we can only do that if we have like a bunch of teams who are effectively laying the groundwork for everything that is incoming.

Thanks. Um Lucas so from another main perspective the scoping is even a bottle bottleneck more long term. So for example, if we had a rough scope of Amsterdam and I don't expect to have a uh you know final scope of after Amsterdam, I expect this to change but if we have some rough EIPs that we uh that are most likely for inclusion uh in in Amsterdam and okay we have vertical trees but there are some question marks around them. uh then uh we could also uh even now or or in a in a short term uh provide some resources to work on them. So scoping even long

term uh and again I'm all for you know uh adding changes and changing the scope if really needed uh if there's a good reason for that. uh especially I'm not expecting finalizing for example Amsterdam scope uh soon but just having some uh some rough agreements on on maybe a leading EIP uh would be really really helpful for us to accelerate even further right so then like yeah I think if we want to start having that conversation for Amsterdam we need to finalize the scope for Fusaka so that we can uh move on with that Um, I guess based on

all of this conversation, my proposal would be to still try to finalize the fus scope before goes live on mainet. This gives us three more uh ACDEs and AC/DC calls. Um, and I think a realistic timeline then would be we want all of the EIPs to be proposed uh by the next call. So people have two weeks to like propose in the EIP and then we give clients two weeks after that to review them and to share their views of what they think should go in like we did last time. So two calls from now or a month from now. Um we sort of have clients views and we can spend most of

the call discussing that and then I think for the call after that we basically finalized the scope for Fusaka. Um, does that seem reasonable to people? I mean, I do think the clients are kind of busy right now shipping a fork. So, it it feels not the best to also say, hey, at the same time, you know, do the whole planning for the next fork. Like, I get we want to be doing these things quickly, but like there are only so many people in this process.

And when do you think so you think we should not start like the quote real planning until PCRA is basically done? I mean, maybe not when PCRA is on mainet, but I think that it's most likely that we will only be able to put full effort into thinking about the next fork once we have the test net sort of live and that's still, you know, a few weeks. Yeah. Two weeks from now. So, I mean, like, yeah, we can also push this back like, you know, plus two weeks. So like you know we can focus on the test net over the next two weeks then and people that are not client devs can also propose EIPs in this period but

then basically have like the deadline to propose an EIP be like a month from now which is two weeks before we expect mainet to ship. Have the deadline for like teams to share their views on on this fork be like around the time that Petra ships on mainnet. and then have like another two weeks that after that where we finalize the scope. Um so it's like midappril we'd be finalizing the scope which is a couple weeks after uh a after picture. Does anyone think that's too aggressive

of a timeline? Okay. And then I'll make this clear um after this call, but I think if you want to propose an EIP for Fusaka, the next month is your window. Um to the extent that client teams have uh spare cycles, they can start reviewing these. But then uh we don't really expect like a full review until live on the test net. Um and then um we'll give ourselves like a call or two to to discuss amongst those and hopefully finalize the scope by mid

April. okay. And then uh yeah to get a bit more in the weeds uh Dano had an update on EOF that he wanted to share uh both on the status and the scope. Um, oh sorry before we do that I just saw uh Lucas and Ansgar do you want to share final comments? From my perspective midappril seems long quite a long time. I would rather have it earlier. And second comment, I would also like to hear some time scale about scoping Amsterdam like when uh not now but like uh when we will be scoping

uh uh Osaka. I would like to hear timeline when for scoping Amsterdam. Yeah. And my hope would be I don't know maybe for Amsterdam we can try to finalize the scope before Fusaka ships or something like that. Um and yeah to Dragon's comment like I think we should do scope and so what I'm proposing is in the next month people propose EIPs. So to propose an EIP you open a PR against the meta EIP for the fork. So it's EIP7607.

There's already a bunch there. In the next month people do this. client teams review this async and then share by uh uh six weeks from now their perspectives on all of these different proposals and what they'd like to prioritize. I think it we will have to discuss this on the call. So like but we can at least do a lot of like the early triaging work async. So if there's EIPs that no one actually cares about, we're not going to spend time on them. And then um and then yeah hopefully by having these like async opinions we can um accelerate this and I think it's optimistic to say that we'll agree to everything in one call.

So uh but I think the call after that we're probably in a good spot. um Anscar yeah I would just say um and understand we didn't really have a conversation about like what should be road mapap priorities and whatnot and that's maybe a bigger conversation but to the extent that we agree that pas right now is top priority in at least in the in terms of the near-term features then I would still think it would be nice if today we could agree on this framing of we will chip faka whenever pas is ready no matter what meaning that if in six weeks we realize that pas has progressed a lot during those 6 weeks and we're basically ready and it's just too late to add anything else then even though we said today we'll only finalize in 6 weeks we

will still just close it and not not add any new features and just go ahead and the the reason I think it would be really important to make that assessment now and basically say that's how what we'll do is just so that in those six weeks people already realize that it is worth trying to push on pas as fast as possible because we are not just going to you know have to wait afterwards anyway right like basically because if if we don't do anything Now for the next two months it will basically be in this phase of like yeah but you know there'll be one more round of discussion around scope anyway so no reason to like prioritize it over anything else. So I would personally still want us to say Fusaka ships the moment PS is ready.

Any thoughts on that? Seems reasonable to me. Okay. Okay. Uh now, Dan, then do you want to give an update on where things are at with EOF? You're speaking. You're muted.

Yeah, you're unmute. We can't hear you. All right. Yeah. Okay. Now I'm not muted. So I put um some of this to put that together and I put it in mind with some of the discussions that we've been having um around how we should handle scoping and with the goal that you know when pure is ready we ship. Um so I have right now the test net for OAC split into three separate stages. OA one pass test net zero shipped yesterday. Um we have the old pectra spec running finalizing. Um there's one bug relating to 7698 contract creation which is the right time we've been able to find it. This is exactly where we're supposed to find it.

Um it's kind of an issue that'll come up a little further down the the specifications as to whether we should fix it or not. Um so the next step would be Osaka one which is to do cleanup. There are some spec changes we wanted to do that we froze because we wanted to ship with Petra and these are mostly inside baseball for EBM stuff. You know we're changing stack orders, we're changing our hashing. Hashing is actually kind of a big deal, but I'll talk about that uh in in Osaka too. And just some minor things about, you know, moving moving some of the pieces around. And the goal for this is to have this ready um about the time the mainet fork activates. So that's going to be uh sometime in April, I guess. Um so that's what our current plan for our Osaka 1. Now what we got this this this

thing set up designed for is that after Osaka one um we could ship any of these features if if if puras is ready then whatever is down the list gets bumped out to the next fork um Amsterdam and we ship what we have today. So the next list is priority listed features that are feature ads although I'm contemplating um putting these first two into Osaka one because they're breaking changes and they're essential. So all of these are driven by um community requests for some of the features that they need um to for uh that they want out of um eof that are mostly strictly additive except for TXre um but otherwise add value for things that that people need. Some of the discussions came from people I spoke with at in Bangkok at devcon. So the first one is

to restore TXER into the spec. We pulled it out for scoping issue through PCRA. Um and as in combination with that we would also remove 7698 the contract creation transaction and that would change how we would bring EOF contracts onto the net. Um after this I'm going to talk about um predeploying a contract which it dovtales in with a pre-ompile issue but the idea here is you would call a specific fixed pre-ompile contract rather than having a creation transaction you'd have an init transaction. So we would be able to keep the um the existing contract creation logic unchanged um and then we would move on and um just have one way. So we would undo some of the places where we currently have the

one integration bug that we have in the test net that is exactly the right time we expected to find it um in testing processes working there. The next one is that the request would sourceify to add a metadata section to the ef container. This is just container of code that's only in the contract and not visible by execution. This would be used to identify where you compiled your code from. And these next two are from from a lot of different groups um open Zeppelin and others um to be able to add some some light level of introspection. We're asking critical things like what is the type of the code? Are we talking about a contract, an eof contract, an account or an empty account? Um and also to to look through the delegation, see what is this being delegated to? And one of the use

cases would be like a smart proxy in eof. Um, there's an EOF rule that says you cannot uh ext delegate call to legacy. You need to make sure you're not going to accidentally ext delegate call to legacy. And now with Petra, there's a new way to accidentally ex delegate call to to legacy. So, we would add these two op codes in there. Now, these three are strictly additive. They don't break anything. The top two um are going to break things um but that's by design and that's that, you know, it's trying to make UF the good final thing and make it a lot more stable for for the legacy code. So one pitch is to move this into um into Osaka one. But the big thing about this is that these are all priority ordered and if we are at a feature we've only shipped one of these

in a devet and it's time to ship a pure we cut it off and we ship it. Um so there's a couple of other uh PRs uh EIPs that I think are good to add but not necessarily in Osaka. I mean if Otaka was going to take all the way into 2026 I would say let's just add these now. um and create delegate op code and changing the contract size limits. So, I think this is a good example of ones that we're going to push out to Amsterdam, but that definitely need to ship as part of um um increase the quality of life for developers, but they're not urgent to ship now. And there are some features that I would say are out of scope. Um ext data and ext data size and copy. We need to get some um metrics from what's executing on on the net. um when we ship

EOF 7701 native account abstraction with EOF. I think that should be part of a more broad-based account abstraction fork. Um a more more holistic thing. I don't think the suspect is quite ready, but I think it needs to go in, but it's not going to be ready by by the third quarter. And also tweaks to gas introspection. Um some of the stuff that's going on with the um uh the repricing group and some of the issues relating there. Um, I think the safest route is to keep gas introspection out of EO and wait until we see how that develops. Um, there are some people who use it for anti-PAM and anti-abuse. Um, and in the meantime, they can continue to use their legacy contracts. So, those are things that we might want to do in the future, but they're definitely out of Osaka scope. So, that's that's that's

basically the plan is that we wouldn't ship these in in Osaka. I'm not going to pitch these, but I have a PR out to add these three and ultimately remove one from the Osaka scope. Um, so let's pause there for questions before I go into the um the issues with uh pre-eploying a contract. Any questions? Andrew. Um, so I'm thinking if P and UF are completely independent, why do we have to tie them into a single release? Like can we release C independently of ELS?

we and then we can release ef when ready uh like maybe uh sometime after u uh ps um but we just haven't yet and I think the overhead of doing forks um we should try and um amortitize the cost as much as possible across the different levels of forks so shipping them together I think is the right solution not for technical reasons but for process reasons Yeah, I think like if it starts to be more than a month difference, you should probably split them. If it's less than a month, it's probably lower coordination cost to put them together. I do think if this is something we want to maintain,

it it changes uh what we should include in the fork. So like if both EOF and Perdas uh are like independent and can ship you know with a CL only or EL only fork uh and we want to keep that then we should not add any EIP in Fusaka that actually requires coupling between both uh the E and CL because that'll be much harder to remove. Um, yeah, simple question. How many forks are going to are we going to need to ship EOF like the the end product?

One, um, everything else beyond that is quality of life improvements. Um, you notice that there's always new versions of Visual Studio being shipped, new versions of like Java and Rust and all the other languages being shipped. Um, so the main container is going to ship in Osaka and what we're adding there is quality of life that makes makes it better for people to use, but the core will ship in Osaka. But there's something there. Yes. Yeah. Like EF was already a quality of life upgrade. So what's the difference between what's being shipped right now and what will be shipped in the future?

I mean, this just feels like a mass um let's oify everything now question. And the answer is why don't we oify the EVM? uh because developer experiences and developer expectations continually grow and change. Um we need to add things like EVM Max which is separate from EOF uh to improve our our numeric speed, we're going to need to look into adding an SIMD type extension uh when it comes time to add post quantum signatures to handle large lattice map. And so adding these features, there's always, you know, a need for quality of life. And just because it works within EOF doesn't mean that EOF is incomplete. Um, EOF will ship and be fully functional in Osaka as we could ship it now and be fully functional. Um, Osaka one is just spec things we want to get rid of from a

potential EOF works talk since we have time to fix it. But if we needed to, we could ship it today. I'd rather not, but if we needed to, we could ship it today. Yeah. But once again, the question uh is how much like, you know, when when do we stop basically when we do we consider the thing is finished? That's what I'd like to understand. The EVM or EOF? No, EOF because EVMX you don't need EF for that. Everything you just quoted, we we don't need EF for for that. When do we have EF shipped?

Oh, asked and answered. No, you said EF in Osaka and then there's this billion quality of life things that we can add later. It's not it's not the same thing. These are things in addition on top of eof, right? And I guess the question then is like yeah, do if we have eof, do we see that as the path to add further EVM features, right? Like something like EVM Max, would we imagine doing it just in EOF or are we going to want to do EVM Max in the legacy EVM as well? Because if if we see EOF as um all of the future all of the the um like yeah the platform on which

we ship all future changes then obviously it'll never be done as long as we're improving the EVM. Um but if we see it as like one of two things we have to maintain forever like legacy EVM and EOF and that when we do something like EVM max we're doing it across both um that's like a different outcomes. Yeah. I mean EOF is versioned so you can extend the EVM in future versions without like impacting prior deployed contracts with EVM uh EU.

All right. But the comment has been made last year that we don't want to develop too many uh yeah to deploy too many versions because otherwise that's a maintenance burden and it definitely is going to be I mean we keep adding op codes to the plain old EVM. It's just the same different we're adding op codes to eof. I mean when's the EVM going to be done? Yeah. Um yeah um on that point I I had a question for Dano. So specifically um because it's kind of desirable to try to like have one version of EF that then keeps um being approved until maybe a couple years down the road we might consider having a second version or something. Um we we we talked a bunch like a year or

so ago about this distinction between uh basically it's always easy to add features to the existing kind of UF version because that just adds new op code functionality something that just like existing contracts that are already deployed don't happen to use but they don't break versus things that basically restrict the existing behavior which is much much harder to do in a backwards compatible way. So I was just curious to what extent is this all designed from a mindset of making sure that the Ozaka-1 version already has all of the types of restrictions that we would need so that from then point onwards whatever we end up shipping together in Osaka or bump to the next fox could always be added to the existing UF version without basically requiring a version bump.

Yeah, I think you described our strategy quite nicely. I mean, ever since Shanghai, our big what took so long is we need to figure out all the things that we needed to change and ban so that we don't have to change and ban stuff for like 10 years. Um, so that's why I got rid of gas introspection. If we get it wrong, we can always read it. That's why we ban code introspection. Um, we can always read op codes if we need to. Um, but basically um once once I get the um the treate and remove the contract creation 7698, that that should be the end of backwards compatibly breaking um changes. Barring a security issue, I don't see us doing it. So everything described after then is strictly additive. What used to be banned is now suddenly eligible. So we have the XT code type. Previously, it would cause

validation to fail. And after we add that, then all of a sudden it would succeed. And it did nothing to change or or remove or detract from the previous edition. It's strictly additive. So anything that's going to be taken away is going to be in the first 1.0. And that's what's going to ship in Osaka. We ship EOF in 1.0. the stuff that we're taking away from the EVM for security and enhancement purposes, we're done for at least five years, ideally 10 years, maybe 20 years, maybe forever. But barring a security issue, we're not going to be pulling stuff out of EOF once it ships in Osaka. And that I consider to be the 1.0. All the features we add after it and structured to be designed this way are strictly additive.

They add add features to it. They add value. They don't remove other existing behavior. Okay. I guess um can I talk about um the pre-ompile issue? Yeah. Yeah. Let's cover that one and then move on. Okay. So um one of the things that we would need to do so as as background for this one of the things that consider for inclusion is EIP 766 um which is to write um a contract here it is that basically covers what the old um identity pre-ompile does and to

effectuate this EIP we're going to have to pre-eploy a contract in a pre-ompile address and that's something that we're going to need to do in this in the fork to make this happen and to get rid of all the pre-ompiles we're going to have to have a means to bring this So I would like to as part of EOF utilize it to bring in the TX create and put in a towh hold contract um at one of the um where's the tool contract? So put in this create or tohold contract at one of those pre-ompile addresses. What this allows us to do is allows us to get rid of EIP7698 which is how we've been modifying the contract create transaction and everything that comes in would come in through the new init code transaction type and we call the pre-ompile

contract. So all the logic of bringing an e of bringing eof into it um would be com would be condensed only strictly into runtime code. This is a chicken and egg problem. If we have one contract that can deploy via TX create or efreate, then we don't need to have any other special handling. So we bring this contract in that does TX create and we can get all of our Tohold contracts. One of the neat things about this is because of some of the changes we're doing to the hashing as part of Osaka 1 um is we're able to to get more reliable addresses um from users not depending upon their nonses. Um, so with this tohole contract, we extend this out to layer 2s. We can very reliably get known addresses at known places if you use the

same account regardless of whether or not you're using um the correct nodes number. And that'll make creating the same contract numbers across multiple chains a lot simpler. It also allows us to retire um Nick's uh Nick's method um that we've been using to deploy all of these um system contracts. So we don't rely on those. we don't rely on uh accounts that have fake keys or unknown keys. We'll be able to have anyone deploy these contracts to that fixed address using using a to hold contract deployer. So those are the big advantages of why I want to take advantage of this is because allows us to to pull an EIP out of out of Osaka and allows for stronger um crosschain address to holds and this is honestly this is a request coming from the zero

people. Um they brought to light just how important it is and I think we can achieve it with this change. Any questions, comments? Uh, Robin. yes. Uh, actually my comment is on EF in general. So, I don't want to hijack discussion. If anybody has a comment on this thing in particular, uh, we can move it online. It's a very inside baseball discussion about should we deploy pre-ompiled contracts into as part of the fork or not. And this, you know, we're going to be doing it for um

have to do it for pre-ompile. So I would like to do it forward. I just put this idea out there for discussion. Come back in two weeks. But if we want to go back to the eof discussion, maybe we should go there. Yep. Um my quick comment on given the chat discussion is it would be my strong advice uh as Tim said for gift team to put out their opinion online for everybody to reflect and and to make comments to it and like I don't want to open reopen this discussion if this is something given this is something that we already discussed multiple times basically

so to make it really clear uh this is this is something that had been asked of us uh you Osaka. Oh, sorry for uh for Petra already. We had a discussion that we didn't want to speak as a team. Uh we might revisit this but our um our opinions are well our individual opinions are well known. I do think there like look if we are going to have a discussion around scoping it would be good to have like your comprehensive view. So like I understand a bunch of people in G are don't like EOF then you know that's fine. Um, I think you know if the like there's two

reasons like one is like if you think it's just like a bad idea overall then it would be good to have that articulated or at least point to like where it's been articulated and then two if you think there's higher priority things that we should be doing to Fusaka then yes it would be nice to also get this communicated um and to move as much of this async as possible. If you all want to write one blog post per person rather than one per team, that's fine. But um like yeah, I think having like a clear record of like what is the thing you object to and what are the other things that you think are valuable to do in the fork uh would be helpful to move the conversation forward. Um, yeah, as I already wrote in the chat,

um, uh, I kind of refuse to like be lumped into a voice of gap. I think I'm I'm here as an individual and um if I if I feel like I need to speak up uh against the common like the common voices um and if I feel like I don't know my voice is different than uh the voice of the guest team then I I will continue to do so and I think it's very important um that uh like I think it's very important that people have faith or that the community

has faith in the individual people stewarding the protocol instead of just the team name. Um because I think the the team name can be switched out and mean different things. Uh so I I think it's kind of weird to require us to state our opinion as a team. um because uh I I myself feel like I'm an individual here and uh I want to be recognized as an individual and I think it's very important to have um uh to have distinct opinions um and uh the the point about us writing down our individual opinions um I can agree with

um but that will require a lot of time that we cannot spent on working. Um, so yeah, but I don't think I don't think we should require teams to put out these blog posts where they like have to discuss internally and if there are minority uh opinions in the team, they will just not be be present in these blog posts. When people say like we want to move more of the process, I think that's basically what they mean. like what do you the alternative is we have every single one of these conversations on a live on a live call with a hundred people and I think I think it's fine that like we um I think it's fine that like we have individuals

who like speak as individuals and share their opinions but I do think that to like move the process forward in a like somewhat efficient way it's extremely valuable to be able to reference this async and to like yeah be able to, you know, have like a read on it and like not waste time on uh not waste time on like a 100% call if everyone disagrees with something or everyone agrees with something. Um yeah, you can always include dissenting opinions in the opinion. Yeah, or look, you can write like seven blog posts for GU and all link them together on one ETH

magicians post. I don't think that's like the the um I don't think that's like the blocker, but um I do think like yeah, having a clear record of the opinion async helps move the conversation forward. Um and I I strongly agree we shouldn't like force a single way to do it and we shouldn't have like a template that people fill in or whatever. Like it's fine if different teams want to voice that differently. Um but there should be something. Um yeah and yeah also like just to be clear at the end of the day like we will have to move forward with a decision and people

will disagree um with that decision and like there's nothing we can do that'll get 100 people 100% of people on board. That said, we only have 10 minutes and we have one more or two more contentious topics to cover. Um, so I think we should move on from this. Uh, I posted the dates in the chat earlier, but I think again we should try and have a month from now be the deadline for people to propose things in the fork. Two weeks after that be the deadline for teams and individuals to voice what they think is uh should be included. What are their preferences? spend a call on March 27th discussing this and then hopefully two weeks after that on April 10th we

can finalize the scope for pusaka. but yes moving on Kev uh you wanted to talk about uh max blob flag and uh your node requirement EIP. Um yeah sorry it's still booting up. Uh yeah, so the Max Blobs flag, we spoke to the rollup uh the roll, we spoke about it on roll call uh because in the last uh AC/DC, someone noted we should ask how the rollups uh feel about it and I think and Zagara can give a summary if he's on the call.

Wait, sorry, I literally just was away for 20 seconds. I heard my name. Uh could you give a summary of sort of the feedback about max blobs in the roll call? Ah yeah. Um so basically um we presented the uh question and um gave a little bit of of an overview of the kind of the trade-offs. Um and so far we only got feedback from a few elus. The others were signaling that they basically want to have some time looking into this. Um the feedback so far seems to be that it would be mildly inconvenient to potentially introduce some additional instability in the um blob fe uh behavior. Um but that if that for

example would be a requirement for some additional blob throughput. So if if there's a scenario where basically uh having this flag would later on allow for for for more of a headroom for for increasing blob throughput, then that would be a um trade-off that they would feel like would be um they would be strongly strongly in favor of. Um yeah and that of but that yeah so basically that that that's it like mildly inconvenient on the fe market side but as a tradeoff um reasonable.

Um cool. Uh and I think in terms of ELS we've not gotten an opinion from Aragon um about how they feel. I don't know if anyone from Aragon uh wants to share their opinion on it. Maybe they're not on the call. Oh, nope. Uh, yeah, I guess we can get that

async as far as I know. Uh, all the other clients are okay with the flag if the ER clients unless someone wants to say something else. Last call. didn't Yeah, I think maybe like yeah if we don't hear back from like Aragon in the next day or so we can move forward and merge this.

Uh cool. Yeah, I can also ping Aragon again to see what how they feel. Um okay, cool. Uh yeah, so the reason this flag was uh sort of brought up initially was uh due to sort of we've having discontention between homestakers not being able to sort of follow on with the full throughput and then this sort of allows them to choose a lower throughput than what the system can allow based on their bandwidth requirements uh bandwidth restrictions sorry. Uh so then I'd like to move on to the hardware requirements doc and ask sort of maybe Nixa if you're on the call sort of your opinions about uh max blobs

with relation to the uh bandwidth for bandwidth uh document now uh since that was sort of the main feedback about the current numbers or anyone else. Uh yeah, this school has gone pretty quiet. Yeah. Okay. Well, if no one has strong opinions on this, we can I I will say the I have no I have no

push back against um Max Bob uh flag, but I do think that it's important to sort of spec out what difference that's going to make in terms of rewards because if it um economically disadvantages um smaller stakers, then we might as it's it's almost like we might as well get rid of them. Um, if we're saying you can participate, but your rewards are going to be lower, um, then we're essentially just not valuing the same and eventually they're not going to exist.

Um, so I think I I disagree with that. I think there's like two when we say homestakers, I don't think we should conflate sort of homestakers who locally block build with home stakers who use me boost. Uh, that's the first one. Um, if you're using me boost, you're still sort of contributing to like decentralization of stake if you're a solo staker. If you're locally block building, that's for censorship resistance of transactions, right? So like just even if you're like contributing like free blobs, you're still you're still uh sort of contributing to the decentralization of stake in terms of the difference between locally block building and meth boost. I think it's like large enough that sort

of reducing the difference between me boost and locally block building is large enough that you're already taking this uh deficit, right? Sorry, which which are we talking about, max blobs or building locally? Because I I think those are two separate issues because not building locally actually makes you more profitable, but if you're not including blobs, I assume that you will be less profitable. They they are the they're exactly the same thing. So in MEV boost, you won't be limiting blobs at all because that's all coming from the builder. Whereas it it's only when you're locally building where you're already less profitable that this flag would would take effect.

Ah, I see. So yeah, you're already not profit maximizing. And I guess there's a question in that I had in the chat is like what I Kev, do you have a sense for like what the two deltas are? Like the difference between mev boost and no meth boost and the difference between like mev boost or no mev boost with blobs and me no mev boost without blobs. I mean if we're realistic um blobs hardly pay anything anyway. that it's not ready. I also I do take that back if if it this is only relevant when you are building locally because anybody who's building locally already is um taking the hit.

Right. Um any yeah I was going to say I think we've yeah we're all on the same page about this one and also you're potentially you can you will have more slightly more bandwidth because you build smaller blocks because there's so much private before anything. Anything else you wanted to cover, Kev?

Um, we have like one minute and I feel like the local block building part was the most contentious, so I might just uh try to roll it over to another call again. Um, but it seems like local block building is okay. Yeah, I don't see any. yeah, I don't think Yeah, I think that was the main contention. Yeah. Okay, cool. Yeah, and yeah, thanks for doing this work of helping us wait through these contentious questions. Um, yeah, I think it'll be good to have a formal uh formal definition at the end of it.

Anything else people want to bring up as we wrap up? Okay. Well, thanks everyone. Um, and yeah, uh, please share your client releases as you have them in the next day or so and we'll announce the petra test net hard fork. Thank you. Byebye. Bye. What's up?