All Core Devs - Execution #209

Transcript

Tim Beiko: Okay, Josh, you wanna move us over.

Josh Davis: You are, live.

Tim Beiko: Thank you. Welcome everyone to acde number 2, 0, 9. So a couple of things on the agenda today 1st any updates on Petra. And specifically, there's a minor change around the 7, 10 0, 2 receipts that we need to discuss. Then we'll spend big chunk of the call, I imagine talking about Fusaka our deadline to finalize the scope was today, and then potentially expect extending into next week. Cl call as we discussed last week. And then finally, at the end, I had this proposal around reconfiguring all core devs. So we can discuss that. And yeah, I guess. Before we go into the 7 7 0, 2 receipts, proposal, any devnet or implementation updates on Petra that people wanted to share.

Piper Merriam: There is a Pr. Open for the E. 69 Dev. P. 2. P. Protocol that it would be really good for teams to review quickly so that we can get that finalized.

Tim Beiko: And this is about the drop in history.

Piper Merriam: It's related. Yes.

Tim Beiko: Yeah. Do you want to post the Pr. In the chat, please? I'm ben.

Ben Adams: If 69 doesn't actually need to happen on a hard work, does it?

Felix Lange: Well, it'd be pretty nice if we had it.

Ben Adams: No, I mean that. Yeah, I mean, it can happen anytime, I assume.

Felix Lange: Well, it's more like if we get it in now, it's pretty sure that, like most people are going to have it after. So it makes it a lot more available.

Ben Adams: Yeah. but I mean it, doesn't it? It's not. It doesn't alter the timeline of the circuit. It's not like a your risk coming up.

Tim Beiko: And I guess, yeah, on on the timelines point. So the expectation is that by the end of next week, early the week after we have, the client releases and then the announcement for the fork should go out on the 20, second or 23rd Is that still reasonable. No major concerns or issues round up. Okay? then. Yes. There was this point raised around the transaction receipts for 7 7 0, 2 I'll post the Pr. In the chat here. Oh, thank you. Yeah, Lucas, do you wanna give some context on this.

Lucas: Actually, this was written by my colleague Nicholas. But it's a pretty small change for context. we just want to add the results of the authorization into the transaction receipt. So for context, right now to identify whether the authorization has passed. we have to do if get code to check. So we thought it'd be a better developer experience if we can add this success or failure in the authorization. Oh, success or failure of this authorization in the transaction receipt.

Felix Lange: Sorry to just speak up, but I think it's not possible this way, because then we would have to actually store this right.

Tim Beiko: What do you mean by store this.

Felix Lange: I mean, the thing is that the success or failure of the authorization, I guess, depends on a couple things. So this field would have to be stored by the clients into their respective databases in order to be available within the receipt. And I'm not sure if it's possible right now to make such a change like we're pretty late. And at this point we're just waiting for, you know, like the date to arrive of the fork, so we can no longer make these types of changes where we just, you know, like, adapt some fundamental like this is not a change. That is just an Rpc. Api change. I feel like this requires some actual changes in the client to make it work.

Maybe I'm wrong, but seems to me like might be too late for this one.

Tim Beiko: Right and and, like client, says in the chat, it depends on the current nonce.

Felix Lange: Yeah. So that's the thing like the validity of the authorization depends on the nonce. It depends on the signature validity, and I guess it's kind of it. I guess there is another check in there somehow, like it cannot be. I guess you can override a delegation, but I vaguely remember there was one other one. So the main thing is that these are conditions. I mean the signature. Validity is never going to change, so we can determine that statically from the transaction, we could at the time of serving the receipt on the Rpc. We could actually basically parse the signature again and validate it. And if it's wrong, then well, we're not going to have is not going to be, you know, passed but the but the other thing with the nonce, then we would have to check, you know, in what was the state at the time of the transaction inclusion, and this would require, like an archive node, to actually know.

So we, the only other thing in order to really correctly serve this for all time, is we would have to store the success into the receipt itself into the client database. And, like, I said, we can no longer make this type of change now so late in the pipeline.

Tim Beiko: So. And so I guess, yeah. And so in practice. Now, what the what you have to do is to call, get code and then parse the response. I guess. Yeah, I'd be curious when in the doc. It says, you know, you need to parse the response. But is it just checking that. There's now code in this doa, or you're matching that against some like expected delegation template. There.

Lucas: Okay, I guess because we're not call deaf. So we did not fully recognize the the implementation details. So yeah, we thought it would be a minor change to improve like the developer experience. But if the risk is too high, I guess. this can be this can. This should not be considered.

Tim Beiko: Yeah, and I, yeah, and I guess I'm trying to understand how bad is it on the developer experience perspective? yeah, like is from my, it's like you're doing one extra Rpc call and then matching the data against this.

nic: Sorry. Let me jump in here. So I am the original author of this proposal. So I think the the feedback that we got from the team is that it kind of breaks away from the current. Validation cycle of wallet provider, where, instead of just getting the result through a transaction receipt. There are additional steps just to accommodate this spectral workflow. Yeah, this is why this is the original reason why we propose this change to the Api. And like, look, I said, we initially thought, I mean, we're not called this. So we initially thought this would be a small change just to improve the quality of life. But if this is as big of a change as Felix has mentioned, maybe we can reconsider the workflow on our end, and maybe just work around going through to our PC. Calls.

Tim Beiko: And I guess one comment in the chat as well is that we probably don't need a hard fork to add this if we wanted to in the future. So I would lean towards not adding this for now, because, yeah, we are pretty close to to shipping the fork but then, if it is like a major pain point, this is something we can add to clients, after the fork, and I assume this is also something. This would not be ideal, but this is also something that, like some clients, could support, and not all. yeah, Felix.

Felix Lange: So I have 2 opinions. 1st of all, this shouldn't be something that some clients support and others don't. We've been fighting a lot against these types of, you know, like customized Rpc extensions. And I think from our point of view, it's not really something we should be doing anymore, because it's causing us a lot of trouble actually, with these incompatibilities. And then the second thing is that it would require a hard fork if it is supposed to be stored within the receipt officially, because changing receipts is always a hard fork. It changes the receipt hash as well, so it has to be coordinated. That's kind of the thing I mean. The clients could in theory store it somehow in the so the way it works in most clients is that they only store

for receipts like the minimum amount of information you have to store for receipts is exactly the information which is generated by the consensus protocol. So it's just a couple of fields, and then the rest of them. You can kind of derive some clients store additional information in a database about the receipt, some stuff, so they don't have to derive it later. And this is something which is possible, but it comes at the expense of making the database larger. So it's something to know, and then you can also no longer validate the receipts that you are storing against the consensus directly, because the consensus only secure certain fields. So this is just something to know if we want to add it to this critical set of of fields which is secured by the consensus. It's going to be a hard fork to add it.

Tim Beiko: Okay. Roman.

Roman: Can we maybe consider adding it only for the like? A few recent blogs. and then it would be trivial on both archival and full nodes to drive the skill.

Tim Beiko: So the receipt. How would that work in practice.

Roman: I mean, we would not store it in the receipt, but we would just have this field on the Rpc.

Tim Beiko: So you and and you. yes, kind of like the block hash, I think you can only query, for, like, what is it? 256 bucks, or something like that, so like a similar design to that.

Roman: Yeah, but because, as far as I understand, like you, you only care about like authorization succeeding in the moment when you're submitting it.

Felix Lange: So if you, if this is what you care about, then you can. If this is the workflow to basically just ask directly after submitting the transaction. If it has worked, you can always work around it with Json, Rpc. Advisor, sending a batch with 2 items. One would be the get received and the other one is, get code. And then if if they you know. it is probably going to be okay.

Tim Beiko: Okay? So I guess yeah, we should not change to specs now. It seems like there's workarounds. what's the best place? Is there like an Eth. Yeah, there's an Eth. Magicians. I guess it's a 7 7 0, 2 eth magicians thread. But yeah, maybe we can just move the conversation there to figure out. If there is a simple Jason Rpc, change, we can make that doesn't require a hard fork that would make this flow easier. And if there isn't, then also just defining what's like, the best? yeah. The best way to to efficiently query this data.

Lucas: Alright. Thank you very much.

Tim Beiko: Yeah, thank you. Okay, anything else on Petra that people wanted to discuss. Sweet. So yeah, I guess this means we're wrapping up Petra. Again. Yeah, please have your releases out by the end of the next week or early the week after that, and we will get this deployed for anyone listening. The Hard fork is scheduled to happen on May 7.th so plan to update your notes before then. Okay. So next up Fusaka. So we'd agreed that we would finalize the scope for the fork as we wrapped up Petra, and we'd set a deadline of today, I think. On the Cl call last week realized they might need an extra week to do so. And then hopefully, we can get

the El side of things finalized. On this call. And 1st before we get into like the specific team preferences. I realize we didn't quite define. We didn't define super explicitly what finalized would mean. Reflecting on it after last week's call. I think the good a good bar for this should be that we decide what's the final set of considered for inclusions eips ideally today. And then everything else that was proposed kind of by definition gets declined for this fork, and then for anything that's Cfid we would only move things to to be scheduled for inclusions. Once we're ready to implement them in devnets. so effectively like the the deadline today would be for proposals for the fork. Then we're working from a smaller set of things. Based on what we can actually implement. And I think the one thing that literally every single team agreed on with regards to their prioritization is that we should ship Fusaka in 2025 that peered us should be in it. So any inclusions we make beyond that should not affect this.

yeah, I guess. 1st of all, does this seem reasonable to people? To anyone have like an objection with the process like this at a high level, or is it unclear in any way? Okay? Let's go then. so given this. Yeah. All of the El teams shared their preferences. on the last call the last El call we'd already we'd already Cfid. Or sorry we'd already specified one other. Okay, sorry, my bad on the last call we Cfid one other eip for the MoD Xp gas through pricing. Let me just post the list in the chat so as it stands today, the only things that are scheduled are pure das, and then the devnet, 0 and devnet one. Versions of eof the things that are Cfid are the r. 1 precompile, rip. 71, 2, the devnet, 2 eof vips, and then this MoD. Xp gas cost increase

in terms of like the the things client teams kind of signaled that they would like. we I don't think there was anything else that was effectively supported by teams unit unanimously. The let me look through the list with like the other broadly supported ones were so I guess the yeah. The other ones around addressing MoD. MoD. Xp. Where also popular. So let me get the exact number the upper bound limit on MoD. Xp, so 7, 8, 2, 3 was kind of the other one that stood out. yeah, as as like broadly supported. And then, yeah, maybe I guess as the next step. If some of the client teams want to share, like in more detail what they'd like to see

what they'd like to see included, or like Cfid beyond this. That's probably a good, a good step. Yeah, Ben.

Ben Adams: Since it was brought up at the the start of the call and support. If 69 But I'm from 2 points of view. It's, you know, helpful, but also from the point of view it it's not contingent on the Fork timeline, so it'd be nice to get into the fork, but it'd be good to market as a a finger.

Tim Beiko: So 8, 69, didn't we just say we wanted that for Petra.

Ben Adams: Deirdre.

Tim Beiko: I mean earlier on like, was it? Weren't we talking about this like 5 min ago, saying it would be nice to have.

Ben Adams: I thought we were saying, but yeah, okay.

Tim Beiko: So, okay, so, sorry. So, so for each 69. So.

Ben Adams: Pre merge fields. It's the 1st one in the list.

Tim Beiko: Yes. So okay. So earlier, when we were saying, we want to have this done. my understanding is we wanted to have it done for the Petra releases, so that the everyone who updates at Petra has this activated is that not correct?

Ben Adams: Yeah, that'd be nice.

Tim Beiko: Okay. But like, yeah, I I guess. do client teams generally want to try and get this like when we say Petro means in the next week is this, that was my understanding of the earlier conversation. Is that correct? Yeah, Andrew.

Andrew Ashikhmin: Well, so about dropping pretty much block bodies. Then. So where we are going to experiment with it on Sepoli. But we are not making. Probably we won't be making a a release in the pector timeframe. We'll have a release, maybe a month or 2 later. but also about it 69. It's it's nice if if 69 specifies the available block range and we'll implement it at some point, probably. But again, for dropping free pretty much block bodies. It's it's not strictly necessary, we will just probably reply, with new block bodies on E. 68.

Tim Beiko: Okay. okay, so we won't have all the teams with 8, 69 before Petra. But teams are actually spending. Yeah, spending time on this. and yeah, it because it doesn't require a hard fork. It's kind of awkward or to include it. But I yeah, okay, I I think we can probably table that one for now. And just accept that teams will be working on supporting this and figure out the right place to to put it, but I agree it should go live before yeah, before Fussaka Felix.

Felix Lange: I just want to make a quick comment, Tim. So here's the thing, right. We've had it in the past that we've included an eip. I don't forget which one it was that was literally just signaling the intent for us to do something.

Tim Beiko: Yeah, this.

Felix Lange: I feel like this. If we can do that one, then we might as well go with the E. 69.

Tim Beiko: Yeah, I think that's fair. Like, I, I think, yeah. we can figure out the right way to frame it. But I think saying, like, yeah, we want 8, 69, if not before Petra. Shortly after I'll find a way to put that in the in the specs. But I don't wanna spend too much time on like the logistics of that now, does that, I guess. Does any client team disagree that they'll be supporting E. 69 in the next few months. Okay, so we'll move forward with 8, 69, and yeah, I think to the extent some teams have it before Petra. That would be good, because it means all the people updating for Petra will not be able to use that.

there is like, yeah. One one interesting question in the chat around raising the gas limit, which is another thing that's been discussed. it's kind of a weird topic, because there's no vip for this right? It's not something that the clients control. But it is something that takes work like marius comments that you know, get has some memory issues now at 60 million. And so fixing those things is something that takes like client teams bandwidth. so is that something that we should somehow also incorporate in this and like, yeah, I I don't know if we should have just like some placeholder Eip that says. try to get the gas limit to a hundred 1 million dollars or 100 million gas, and then fix all the bugs that come up as part of that. The clients have thoughts on how we should best approach this.

Hi, yeah, Andrew.

Andrew Ashikhmin: Yeah, I think Julia has written an IP on how to do it in a kind of manageable fashion. I just okay. I don't let me try to find this.

Tim Beiko: So, yeah. So Julio's vip was like, how does the gas limit actually upgrade on on chain, which I think is different from saying, independent of the mechanism. We just want to reach this number and fix all the bugs like Julio's. Vip didn't make a recommendation about like what it should be. It was more like we can go from X to Y and like, here's like a mechanism to do that gradually. this feel different than saying, we want to reach a hundred 1 million gas. And that's like our priority. And there's, like, you know, the mechanism by which it it it gets activated doesn't need to change necessarily. But saying like, Okay, get feels you know, like, get feels like it. You get to spending time on this Om issue, and then never mind us some other issues, and they're spending time on it.

yeah.

Andrew Ashikhmin: Yes, so I I like to be honest. I think that we should do it post Fussaka, but but probably it's too early to discuss Post Fusaka, but I would do it in the 1st fork after Fussaka.

Tim Beiko: So you're saying you would not want to raise the gas limit before Fussaka.

Andrew Ashikhmin: That. That's my personal view. Yes.

Tim Beiko: Okay, yeah. I guess. Yeah. Danka, do you wanna give your perspective on this.

Dankrad Feist: Right? I mean, I think, yeah, we we should really try to. I mean, I think we should just see this as independent of the Hard Fork schedule, but still, like I think it's just relatively urgent, and it's not. not good. If this always falls behind and like what we are working on is only the things that are in the A piece. And then we ignore this part. So I think, like. yeah, on a relatively short timeline, getting all the hurdles out of the way that technically limit us to below 100 million seems very high value. Also, in terms of our signaling to the community that we are actually taking this seriously. And this is not just like

everything slides back after there was a big I don't know public discussion about this. And people felt like we're finally moving and scaling their one as well.

Tim Beiko: Yeah. And yeah, comment in the chat saying, like, you know, we, we probably don't need to make a final decision about this today. I would agree. But I also want to avoid the case where we don't think about this, and we just add a bunch of vips. And then we say, you know, we don't have any bandwidth to think about the gas limit. yeah. Oh, yeah. I'm sorry.

Ansgar Dietrichs: Yeah. Then maybe just as a quick Meta comment, like, I do think in general, that going forward on the El side, we should given that we just in the past specifically made the choice not to scale the El right, like the L is basically other than this 1. 20% bump of this year is still at the same state that it was at the merge and at the merge. We basically stayed at the same level that we were pre-merged without, except for this small kind of block, like block time shortening, I think. Kind of now we're starting to line on this decision of changing that. And so if we change that, that just means that we need to be aware that from this point onwards a significant portion of overall el bandwidth

development bandwidth will be consumed by performance increases. And so that just means that the overall shipping bandwidth of new features is going down. So yeah, so I think, basically for any new hard folk, we should just basically have on the El side, lighter, lighter than we basically think we can do. Because, yeah, the the other focus should always be implied. Increase in performance.

Tim Beiko: Ben.

Ben Adams: In light of that direction I'd like to pose for inclusion the transaction gas cap limit so that we don't. If the gas limit does block increases to say. 60 million. We don't want a single transaction that uses the entire block. It's bad for paralyzation. Further optimization. And we? We also don't know. There, there are unknowns in, you know. There might be an end. Something that's n squared, that suddenly becomes, you know, a problem when transactions get that big.

Tim Beiko: One question I would have it'd be good to hear what other clients seem to think. But like. Why should it be 30, and not 10, or 15, or. You know.

Ben Adams: Low, low lower would be better. But I think the idea was we haven't done any analysis, and you can currently do that. So.

Tim Beiko: So yeah, 30 is is our worst case today. And we live with this. Yes.

Ben Adams: Last 36, but.

Tim Beiko: Oh, yeah. Yeah.

Ben Adams: Hour would be, would be better.

Tim Beiko: Andrew.

Andrew Ashikhmin: Yeah, also, 30 million is the limit for Cisco transactions.

Tim Beiko: Okay? Yeah. Like client. You have a comment about the count. Abstraction.

Lightclient (Matt Garnett): Yeah, I mean, I think we should see how 7,702 plays out on Mainnet before we make any kind of decision on limiting the amount of gas per transaction, because there's a very real possibility that the number of transactions per block goes down significantly after Petra and most people are being bundled in a single transaction that is, more than 30 million guests.

Dankrad Feist: But what's the downsides to bundling this into 4 transactions of 7.5 million each?

Lightclient (Matt Garnett): Well, you pay more gas for storage reads. since you can take advantage of the warming.

Dankrad Feist: For example, if we want to parallelize, then we need to cap the size of the transaction, because you can never parallelize 1 30 million transaction, but you can parallelize several smaller ones. So I think, like. it is just essential to do this, and we'll have to like people will have to pack them into smaller transactions.

Ben Adams: Also it means if if it's a 30 million, if it's a entire block transaction that would imply that it's a single bundler that is dominating, you know, pushing out everybody, everybody else.

Lightclient (Matt Garnett): That's not true. That's the entire design of 4,237 is to have a way to get to the transactions of the person who's building the block so they can bundle all of them.

Tim Beiko: And I guess, would you? Do you think that's a concern, even with a 30 million? Guess it like if we or and we can make it 36, whatever. But, like, you know, if we ship 7, 7 0 2 tomorrow, there is already an implicit cap of 36 million for a single transaction. So should. We also have, like the cap and protocol on the transaction size, so that if we increase the gas limit, we're kind of not implicitly increasing the transaction size limit at the same time.

Lightclient (Matt Garnett): I mean, I think we should just see what we can do with transaction parallelization. First, st before we start putting strict requirements. The protocol for the size of gas limits, like, it seems like we're preemptively talking about this.

Tim Beiko: Yeah, I guess. Yeah, to answer point in chat, we're trying to decide if we want to. Cfi this so like, I don't know how the it seems like they sue.

Marius van der Wijden: I'm strongly in favor of sifying this and of doing this because I think it's just It also becomes a thing of fairness at some point. If if these if these Bundler transactions can price out anyone because they can build the full block of of transactions, I also don't think it's it's super fair. So I would rather have them send 2 or 3 transactions. And then the likelihood that someone can can get there in their transactions. And it's it's increasing.

Tim Beiko: Yeah. Lucas.

Łukasz Rozmej: One last thing, this cap is relatively easily to increase or lift in the future right? So, cap to something that we have now, and just to be safe, and then we can iterate on it.

Tim Beiko: Okay, then, yeah, I think we should at least cfi it. And we can. We can. Yeah, decide if and how we want to implement it at a later date, but it seems like there's some support for it. And then, if to the extent we actually want to raise the gas limit. It can be helpful. yeah. So I would. Cfi, this one. And Carl, yeah, you have a comment. About 7, 2, 1, 2.

Carl Beekhuizen: Yeah. So curl of butts recently found that back for 7, 2, 1, 2. That's the r, 1 free compile. Add a bug edit. and so we will need a new rip. Slash eip if you want to ship this which is basically the same thing to put the same address. But with this. patriots very minor, but should be done.

Tim Beiko: So? Why.

Carl Beekhuizen: Ended up being in being yeah, in terms of.

Tim Beiko: Why can't we just update? Yeah, why can't we just update the spec? Because the spec specifies the address. And we need to change the address to fix this bug, or.

Carl Beekhuizen: No use the same address. But the problem is that the this has already been hit on one of the L twos, and so.

Tim Beiko: Oh!

Carl Beekhuizen: Me too.

Tim Beiko: Okay.

Carl Beekhuizen: Like in terms of activating things. Whatever we need, we we need a new number to redeploy the same address for their sake. Those yeah.

Tim Beiko: That seems. Yeah. I mean, I think, yeah, we should treat this as though it was like just fixing a bug in the specs. I don't think we should.

Carl Beekhuizen: Yeah, it. It doesn't change. It doesn't change anything from.

Tim Beiko: Yeah.

Carl Beekhuizen: The the l. 1 slash eip standpoint. It just means that there'll be a new number for it. But just to expect that, and.

Tim Beiko: Yeah. Yeah. And I think, yeah, if you can just open a Pr, once we have the new number to, and like on on the Meta vip, and just explain this. That seems reasonable to just swap.

Carl Beekhuizen: Absolutely. I'll do that.

Tim Beiko: Yep. okay, I guess. Aside from the transaction limit cap, are there other vips? Some clients felt strongly about stiffying today? That yeah, we should add to this list. And I posted the full list of what's been proposed in the chat. okay? And if okay, yeah. And as I see, you have a comment. But I yeah, the Zoom client teams first, st and then I know that there's also 2 Vip champions here, so we can. We can do Onsgar, and then the 2 IP champions after. But yeah, like clients increasing the code size which one is this

or the contracts up.

Marius van der Wijden: 7, 9 0 3 sorry! 7, 9, 0 7.

Tim Beiko: 7, 9, 0, 7.

Marius van der Wijden: We? We are kind of against 7, 9, 0, 3, because it removes the entire limit, and we are for 7, 9 0, 7, which increases the the code size limit. but also adds, adds additional cost, and it's not unbounded.

Tim Beiko: Yeah. Charles.

Charles Cooper: Yeah, I'm the author of both of these vips. I think that. Well, I was given the feedback that it could have a limit. A little bit later. I think it would be okay to add it as like one x or 2 x the limit in the runtime code size limit. I don't really see a need for it, because the Init code limit is already basically, the Init code doesn't incur a read from State. and it's already paid for by memory expansion. But if people are more comfortable with the limit, I'm happy to add that in.

Marius van der Wijden: The problem is that you can just create really, really big contracts, a really, really big init code and then execute certain attacks because of that. So that's why. Why the.

Charles Cooper: That's.

Marius van der Wijden: Jump Destin notices.

Charles Cooper: It's already metered. So it's like paid basically per word.

Marius van der Wijden: It would still.

Charles Cooper: I ran benchmarks, and the cost to do jump desk analysis is like very much linear in the size of the code. So I think that a linear cost makes sense.

Guillaume Ballet: Did you publish those benchmarks? Because I remember so that was back in the day there was a great Colvin. We haven't seen him in a while. He he was actually having an opinion about this, the ability, the possibility to Ddos this stuff. Maybe I'm misremembering, but it would be very important to to figure out if that is true.

Charles Cooper: Yes, the benchmarks are published, and there's a link to them in the youth magicians discussions today.

Tim Beiko: And I guess yeah. So, Charles, if assuming the client teams prefer 7, 9 0, 7, and you're an author on this one where you? Were you happy with 7, 9. So 7 like you have, like a preference for 7, 9, 0 3. But are you also happy with 7, 9, 0 7.

Charles Cooper: I think they both need to go in, because without an innate code size increase, you can't practically deploy larger contracts.

Tim Beiko: I see any other client. Teams have opinions on this one or.

Guillaume Ballet: I'm not another client team, but I do have an opinion. When we redid we did the redesign of the tree. Whatever is going to be for call binary. Blah! Blah! We are trying to store everything in a in a single leaf in a single 32 Byte word, and we only have so far 2 Byte reserved for the for the code size.

Danno Ferrin: Then we up to 3 in a design session. A few months ago I brought this issue up.

Guillaume Ballet: Going in.

Danno Ferrin: A few months ago I came on call. And didn't you expand it to 3 so we could get 24 Megs instead of just 64 K.

Guillaume Ballet: Yeah, so that's what I was gonna say, we, we could expand it to 3 Byte, we have some reserve space. I just want, I mean, but there's still a limit, right? Even if it's even if you make it 2424 MB, it's still It's still going to be limited. So I would prefer not doing this, not having an unlimited code size, simply because because I mean, I don't. I don't care if it's 20 MB, or what, I just need something that's gonna fit in a reasonable amount of bytes, so that yeah, so that I don't have to redesign the entire gas cost for for Eap 4,760.

Charles Cooper: I see what app. All right. Go ahead.

Danno Ferrin: So if this is combined with the transaction size increase, and there will be a fixed upper limit to how big a contract could be because we have to pay 200 gas per byte, and that comes out right now to about a hundred 40 some odd Kilobytes. So there will be a functional limit, if not an explicit spectrum limit. So as long as we keep a transaction size limit and we make the init code a function of that transaction size limit, we'll still have limits. It's going to be the gas size, the size of the transaction, driving those limits rather than an artificial. Let's give contracts a small limit.

Charles Cooper: Yeah, init code. Never. Actually. I mean, it's correlated with the runtime code. Because typically the way net code works is you just like copy a bunch of bytes to memory and then return it. But it's not actually physically stored in the State. So like Dana was saying, like the limit on the Runtime code is like what you really need.

Marius van der Wijden: So I think no one is against raising the code size limit as far as I can hear. But.

Tim Beiko: Still, one abound. Yeah, yeah.

Marius van der Wijden: We're we're not clear on on the bonds yet. Yes.

Tim Beiko: Which so 7, 9 0. 7 in. Proposes an increase to the bound right.

Charles Cooper: 7, 9 0, 7 is an increase to the runtime code size limit, and it hasn't found.

Tim Beiko: But not even no sorry.

Charles Cooper: Right and 7, 9 0, 3 uncaps in that code.

Tim Beiko: But I guess, yeah, the question is, would people prefer? Would people be okay with a larger but capped edit code size?

Lightclient (Matt Garnett): That's probably my preference.

Tim Beiko: Do any other client teams have opinions on this? Okay. So then, I guess, would that mean Cfi 7, 9, 0, 7. And then. either modifying 7, 9 0, 3. To have a proposed limit, or just adding a init code limit to the 7 9 0, 7 Vip. I don't know if people have a preference for for that.

Marius van der Wijden: I would do it exactly this way. Do 7, 9, 0 7 into Cfi, and then we change 7, 9, 0 7 to have the same in a code limit as we have right now, which is twice the size of the of the Max Contract limit. which I think is reasonable.

Tim Beiko: Does anyone have concerns or objections about this.

Danno Ferrin: Not necessarily concern or objection, but I wanna make sure people know that there's going to be an extra charge per word over 24 K. Sounds reasonable to me, but I just wanna make sure people are aware of that.

Tim Beiko: Okay. Hi, Ben.

Ben Adams: Weren't we concerned about this? About 2 years ago? I think I think it came up to increase contract size.

Marius van der Wijden: Yeah, that's that's when back in the day it was unlimited. And that's why we added the for 24 K limit. And now we are increasing the 24 K limit to something bigger.

Ben Adams: Okay.

Lightclient (Matt Garnett): So historically, we've just had the expectation we would charge the contract size as this constant loading from disk cost, even though the size can differ. And so the limit had to be something that was commensurate with the amount that we were paying. But the cip changes it to be a dynamic cost. The problem with that has historically been that we don't have the size of the code quickly accessible in the State anywhere, so you would still have to load the code and determine the size which defeats the purpose. Of course you could have an additional index in your state database to look up the code, which is what's proposed by the cap. In the past. We've been against doing this because if you want to create some State witness mechanism, then you would still have to provide the entire code because you can't authenticate it off.

you know, off consensus index. But because we know now that we're going to need to chunk the code and do things in a smarter way with contract size. I generally think it's okay to have this index and rely on it for the consensus operation.

Tim Beiko: Okay. yeah, thanks everyone. It's okay. We'll see a 5, 7, 9 0, 7, and then add, this extra. Yeah, in the code limit. Any other eips client teams feel strongly should be cfi'd So we have 7, 8, 2, 5, 7, 9, 0, 7. Okay, if not, then. Yeah. Hadrian has been waiting for a couple of calls to present any. IP, yeah, you wanna go ahead.

Hadrien Croubois: Yes, thank you, please. Can someone else want to go ahead first, st and I can find somewhere where I can speak pretty because I cannot be in 5 min.

Tim Beiko: Okay? Okay? Well, then, in that case, unders had one. And I think Onsgar had another related proposal. So let's do those, and then we'll do Patreon and is Anders on the call. I probably saw him in chat is on theirs.

Anders Elowsson: Oh, yeah, hello, yeah. Yeah. Hey, okay, yeah. Okay. So I used to give a rationale for the Ipa. So so essentially so, the price of blob space is determined by the price of of the blobs, you know, controlled by the blaze fee.

Tim Beiko: Eip what's the number? Sorry? 7, 9, 18, right?

Anders Elowsson: Yeah, yeah, exactly. Exactly. Yeah.

Tim Beiko: But yeah.

Anders Elowsson: So the price is determined by the price of the blobs, you know, controlled by the blob-based fee and the price of the blob current transaction. So a simple demand function, then, is quantity of blobs demanded as a function of the blob-based fee and the cost of the execution gas. The current fee market does not operate on this demand function. It only accounts for the blob-based fee, and because of this the fee update range becomes insignificant when the T-sco dominates. So the fee market then stops operating correctly and fails to converge on an equilibrium. So you end up in this situation, where the base fee may increase by 10% per slot, because the blob space is increased by 0 point 0 0 1% per slot trying to attain equilibrium, which, of course, is not happening, because the Tx cost dominates. And so this Ap. Resolves this by stopping the blob-based fee from falling further when it no longer has a dominant role in influencing demand.

and this is achieved by adding an if statement to the calculus block gas function. So if it is cost, Dominus do not subtract target block gas and instead increase excess block gas moderately depending on gas usage and otherwise proceed as normal. So I was thinking that considering for cycle will scale global space a lot. You know, this is a simple change that can be done at the functional free market.

Tim Beiko: Thank you. Any thoughts, comments on this. I know. Onskar, you had the another proposal.

Ansgar Dietrichs: Yeah, maybe I mean, I, I can give just just for context, right? So basically, the observation has been for a while that the Blob Fee market is a little bit inefficient in that, that the price, whenever there's not enough demand, hovers around at one way, and then it just takes a very long time to ramp up, and there was this very simple erp to fix to address this by. Originally Max Resnick, and then David and I kind of took that over now that Max is busy with other things and other ecosystems. and that would just set a kind of constant floor that's still very, very cheap, but just closer to the reasonable range, so that it doesn't always take so long to ramp up.

And this is kind of proposal now that he just proposed that came out of very recent work by him. And that's a bit more nuanced. Basically, the idea is to say, well, every every layer 2 that wants to use blobs has to send a normal transaction anyway, blob transaction. And so it already pays normal gas price. And so most of the time that completely dominates the price of the blobs. And so why don't we just use that as like the floor of the blob fee as well, I think that personally is very reasonable. The only downside I see is that it's well. 2 downsides there, I see one is that it's a bit more complex, at least conceptually. And also, I think.

not necessarily has had that much review. Yet of that mechanism, although it feels like that should be a reasonable approach. Yeah. And and basically, the other one is just that it that's been like a very recent proposal. So I, personally would be fine with either of those 2. And there's this more principled solution, or maybe these, this original Max Resnick proposal. That's a bit simpler, I think. Given that with pierdas. We will have so many more blobs, and probably we will have quite a few of these moments where otherwise the fee will basically be be in kind of unfortunate, unfortunately unresponsive areas. So I would hope to at least chip one of the 2. They're both specs wise, super, super simple.

Maybe the the best given that we want to freeze pfi, like like Cfi today. What we could do is we could move both of those 2 to Cfi and have wait for a recommendation of which of the 2 to use over the next 2 weeks, or something. Yeah. Otherwise I'd personally be happy for us to to go with either.

Tim Beiko: Thank you. Yeah. Anyone have thoughts or comments on this. Yeah, Ben.

Ben Adams: I I do like the new proposal over the prior one. Because I think the prime one makes sense, because one way is like a crazy price. So you never launched a token at one way, because Uniswap wouldn't be able to do the math. But the the new proposal is less arbitrary. It's it's actually responding to the few markets. So it is. it feels better. It's got good vibes.

Tim Beiko: I guess. Yeah. One thing I would hope is that people like before we make this decision, we've actually like reviewed it fairly thoroughly. Both of these seem like relatively minor spec changes like only a few lines. If we feel like we need more time to think about it. Yeah, I would probably see if I either both or like one of them. But, like definitely take like reserve the rights to change whatever the the curve is or the the formula is to make sure it's correct. Assuming that, like the you know, the amount of work or the like complexity of implementation doesn't significantly change.

Anders Elowsson: Yeah. So it's I can mention one thing there, that is that it depends on how the are gonna implement. If they're gonna have a cap on. You know the the number of blobs you can sign send in a transaction, or if there's not gonna be a cap and depending on if there's a cap or not, you can have 2 different settings for this. So that's something we would adapt with. Whatever the the final option is.

Tim Beiko: Okay? Yeah. Does anyone? Yeah, does anyone feel like we should not? Cfi 7, 9, 1, 8. It seems like there's relatively broad support for that. I'm not sure. About 7, 7, 6, 2, but yeah, 7, 9, 1, 8 seems probably supported. And again we'd have. We'll have to like review the curve and potentially tweak it, but probably go in that direction. Okay, so that's Cfi 7, 9, 1, 8. Does anyone want to push for 7, 7, 6, 2 being Cfi as well. Then. it's yeah. Yeah. Worst case. At the last minute we could swap them out if we realize that it was a much better design.

Dankrad Feist: I'm I prefer. Cfi. 7, 7, 6, 2, I mean, I'm not. I wasn't really aware of 7, 9, 1 8. But I am, I don't like the argument. Oh, no, we need to do something super neutral, blah blah, or something. We should just do the right thing, and to me at least 7, 7, 6, 2 feels more like the right thing than something else. I mean, I'll have a deeper look at that. But I.

Tim Beiko: Yeah.

Dankrad Feist: Think min base fee is what we really want. What is the natural economic thing to do? And yeah, that's my opinion.

Tim Beiko: Yeah, I guess there's no. There's no world where we ship the 2 of these like they're mutually exclusive. So I think it's effectively free to Cfi both if we like. If we think there's a chance we might do 7, 7, 6, 2, we should just Cfi as well, and then we'll we'll choose one of the 2 that we actually implement. But yeah, anyone disagree with that.

Anders Elowsson: One thing I'd like to understand. If the base fee force say a lot. You know, the the execution basically falls a lot, because the. That's what I don't understand. Why, why we would like to have a high higher floor on the blob, basically than than the execution. Basically, if, if, for example, if for some reason the execution basically falls a lot.

Dankrad Feist: Yeah, I mean, I think it's a fair argument to simply say, we want to flow on both. I would also be pro having a higher execution policy.

Tim Beiko: One comment from the chat, is like, yeah, this assumes both of these are relatively trivial to implement. anyone have concerns about that like, it seems to me like they're both fairly small changes, and relatively equal in size. But yeah. is that, does anyone feel like that's not the case. Okay? Okay? If not, then like, yeah, let's see if I both of them. And yes, we should have a deeper discussions about each of each of them. I don't know if we want to have a breakout call or if there's a is there a channel in the R&D discord. Actually, where we can move this conversation to do you have like a free market channel or something?

We do not. okay. So I after this call, I'll figure out somewhere where we can continue this discussion forward. But I think for now Cfi and the 2 of them makes sense. Heydrien, let's do, Adrian, and then Barnabas will get to your question. Hadrian. yeah. Do you want to present your IP.

Hadrien Croubois: Yeah. So thank you for giving me this opportunity. I'd like to speak about 7, 8, 1 9 unlike the other one that was discussed. It's not about fixing incentives or or improving the blockchain behavior, but more about like, Oh, yeah, let me think.

Trent Van Epps: Hey! Adrian.

Hadrien Croubois: In regards, yeah.

Trent Van Epps: You're in a you're in a very echoey room, so maybe get closer to your mic.

Hadrien Croubois: Yeah.

Trent Van Epps: Go to a room with less echo, and then people will hear you better.

Hadrien Croubois: Okay, I'm I'm outside right now. Is that better?

Trent Van Epps: Yes, very much.

Hadrien Croubois: Okay. I'm sorry I'm at the maternity. My baby was just born this morning.

Trent Van Epps: Congrats.

Hadrien Croubois: So so yeah. So, as I was saying, maybe you haven't heard me. Eip 1729. It's really about the developer experience and improving how contracts are built. It's not about fixing incentive like gloves or things like that. So I don't think there is any big urgency in shipping that so the idea of this vip is that 7, 7 0, 2 created this new object. The delegation for Ua, which I believe is extremely powerful, and the idea of this IP is to have smart contract benefit from it. and the idea is that I would like more contract to be able to create these objects that have, in my opinion, external properties. These properties are that they're very small. They are just the size of a 7 7 0, 2 delegation

the redirect call very efficiently like a proxy would do, but they can be upgradable by just changing the code like 7,702 allows for Eos without having to rely on like the target implementation being in storage and required unless load to be updated. Another benefit from having this implemented is that explorers like it, or scan, and so on, wouldn't have to handle the many, many versions of the byte code that exist for both proxy and Clones, and it would just look like 7,702 delegation that are clearly to understand and to and to analyze. So the reason I'm proposing it right now is that I believe that this feature is really great for the long term development of more contracts in particular, like using the clone pattern. That is way more efficient in terms of storage for for the blockchain, and and make that more widely available.

And with the change to Eos it's unclear to me. What's the right moment to propose something like that? Basically, my fear would be that with a Max Us. Shipping soon we would be in a situation where new features like this one would take a very, very long time to get into like a version 2 or us, or something like that. So I'd like people to to consider it, and to and to give feedback about this proposal. But I understand that for Fussaka it may not be the right schedule.

Tim Beiko: Thank you. Anyone have comments or, yeah thoughts about this.

Marius van der Wijden: I don't really understand the Pr. The Ap. I kind of get the gist of it. But I don't think it should be done in Fusaka. To be honest, it's a it's as I. It's the way I see it. It's kind of a nice change. but I don't think this is like we have already so much included today. Again, that I think we should. We should do this in in the fog afterwards.

Tim Beiko: Anyone else have. But okay, so won't be moving this to Cfi today, I believe. Thank you, Adrian, and hopefully, you can get back to the maternity ward. Yeah. Yeah. And like, yes, we can add this to Eos in A in a different port. okay. So Barnabas had a comment about the deadline for ssifying things for Fusaka. I think. Yes, the the way I I would approach it is what we want as a bar for Sfi is what we're willing to include in the next devnet. We probably shouldn't be including things until what we have on the devnet or what we have already. Sfi is stable. In this case it means we have peered us and eof

we should be focusing on those getting a def net that runs both of them. And then, once we have that, then I think we can, we should make a call about okay. How far do you know? How far do we think we are from the fork? And what can we realistically include there? And without causing much delays? I think a lot of the things we've Cfid are relatively simple changes. And so. you know, potentially, we want to add a couple of them to say, like Devnet, one of Fusaka that has eof peer dos running smoothly, and then we had a few things. but that would kind of be the approach I would take to do this rather than like a specific deadline. If our goal is to ship pure Das as soon as possible, then we should have our engineering focused on that. If the 1st thing we've prioritized alongside with pure das is eof, then we should make sure that that works. So this is well tested. And when that's the case, and we feel like there's some extra bandwidth we make a call about what we bring in.

I don't know if we want to like. Set some sort of more stringent date. My fear is, if we do this, then we just end up breaking it, or it ends up being kind of a a useless state. and that the thing that kind of bottlenecks us as we're working on the fork is like implementation stability on the devnet. So yeah, that would be my approach. I don't know if anyone has opinions or thoughts on this. Okay? And so, as of now, the stuff we have Sfi in in Fusaka. Sorry is Peerdas, and this list of Eof eips from Devnet 0 and devnet one for eof that should be teams priorities. Then for the Cfi section we have this. Rip 7, 2, 1, 2, which we'll have to change due to this this bug that Carl mentioned.

we have another set of Eofeps. The MoD Xp gas increase. The transaction cap limit. S078-25-7907 the other limits around the or sorry the metering of the contract code size and then increasing the contract code limit. And we'll have to do the initial the in its code addition. we have these 2 eips with regards to the Blob fee market, 7, 9, 18 and 7, 7, 6, 2, that we both want to consider, and then the other thing that we kind of mentioned but don't quite have an eip for is this idea around the gas limit? and we sort of landed on. Maybe we should have just an informational eip about this that we can also include so I do think we should draft this. And even though our sort of

formal deadline was today like that feels like an important conversation to have So on the el side. I guess. The people feel like there's anything important or critical that's missing from this list.

Ben Adams: How.

Tim Beiko: Yes.

Ben Adams: 1 1 thing that's come up, but there isn't an aip for it is. Do we want to limit the number of blobs per transaction. So the blob per block. Obviously, that's decided. But do we want a single transaction to be able to use all the blocks like if if we're up to 52 blobs. Do you wanna do on a 7 MB transaction?

Tim Beiko: Mary says, yes.

Ben Adams: And then question is, do we want it in 2 second.

Tim Beiko: So.

Marius van der Wijden: If we're planning to increase the blobs again in Fusaka. I think we should have this.

Tim Beiko: So do we need an eip for this.

Lightclient (Matt Garnett): Why not just do this in the pure dot? Cip.

Tim Beiko: Yeah.

Marius van der Wijden: Yeah, that's kind of what we've been debating. So we will probably do this in the Peter Cip.

Tim Beiko: Yeah, I think I mean, if we need another eip. we can just have it. But I I think if it's just a part of pure das. It makes sense to just include it in that spec.

Marius van der Wijden: Yeah, it. It just felt kind of a bit off to decide this within the.

Tim Beiko: Yeah.

Marius van der Wijden: Within the Peters group and not inform everyone else about it. So if that's okay.

Tim Beiko: I guess, yeah.

Marius van der Wijden: Informed about it now, so.

Tim Beiko: Does anyone? Yeah, don't think we should have a limit.

Alex Stokes: Yeah, I and the protocol cause we've discussed this before. If I'm following, maybe I misunderstood. But just capping the number of blobs per blob transaction. We've gone back and forth on this so like, it could just be like an input restriction. For example.

Ben Adams: Yeah. But then I could build a block offline. Put a letter Ethernet through. Yeah, I don't know if it makes any difference.

Alex Stokes: Yeah, I mean, if most people want it, I'm not gonna block it.

Ahmad Bitar: I think the reason it makes more sense is because helps with mempool. So maybe having it only in mempool makes sense. If you modify the software and do up large transaction with a lot of blobs. Then it's fine. It's on you. But the important part is that the mempool will not have to suffer with these transactions that have a lot of blobs. But if there is another reason that restricting the blobs in a single transaction makes sense. Then, yeah, that wouldn't be valid anymore.

Tim Beiko: Great. Yeah, Barnabas Onsgar. And there's are your comments about this specifically.

Barnabas Busa: Yeah. So my comment would be that I would propose not to pump the blob limit in Fussaka and do it in a blob. Only update that way. We can test one lesson, 1 1 less thing, basically. And it's gonna be a bit quicker for us to ship it. And then we can focus on block updates.

Tim Beiko: On on that point. Yeah. Sorry. So I missed this. But in the Cl call last week we had Cfi, the Bpo fork at eip it was just a draft. Pr, and so I I miss it did get merged. So yeah, we we can still decide to to activate it that way? Yeah, I'm yeah. Onsgar on. Theirs is just about the same topic.

Anders Elowsson: Yeah.

Ansgar Dietrichs: I mean, I would. I just wanted to say that in general we should always be more okay with doing things that can be later on revised and so given that this restriction can always be lifted later on. I, personally don't think we need it. I think the Mempool would be the simpler place to do that. But given that, there seems to be relatively broad support, I would say, instead of bike shedding, we should just like have it in Fusaka, and then revisit this decision like for Glam, Saddam, or something.

Anders Elowsson: Yeah, I just wanted to pitch that. Maybe you could have this cap also vary. If you scale a lot, then a low cap may seem very small all of a sudden, so you could adopt the cap with the target.

Tim Beiko: Okay? So I guess yeah, just to not take up the rest of the call for for the implementation details here. It seems like there's broad support for a cap. We're fine doing this as part of the pure cip for now, if we were to change it in the future, then we probably want to split different eip it. Assuming this is in in protocol cap, and not a mental one. But I think we can define the like specifics of the cap on the peer desk breakouts. Does that seem reasonable to people? Okay, so we won't add a new eip for this. But we may expect a change with regards to capping the blog count in transactions to be added to the pure cip

and then, yeah. So to your earlier comment, Barnabas. You said we should see if I did. Blob parameter forks. We have done that. And yeah, my bad. I I missed the draft pr anything else. People feel strongly about us. Cfi in today. Lynn.

Lin Oshitani: Yeah. In last Cl call we talked about Eip 7, 9, 1, 7, which is deterministic proposing, look ahead. And, oh, is this.

Tim Beiko: I was gonna say, yeah, if- if for that vip. So I yeah, I should have been clear. But I think for that vip, I would make a call on next week's consensus. There, call and.

Lin Oshitani: Okay.

Tim Beiko: Yeah. So today, I I think if we can finalize the El IP today, that'd be ideal. But then I know that there's this one. And there's, I think, a couple of other ones. We need to finalize on the Cl call next week.

Lin Oshitani: Okay, okay, got it. Thanks.

Alex Stokes: Yeah, maybe just a quick comment. Here, yeah, let's talk about this next week and then homework for sale. Devs would just be to look at the cip, and you know, to the extent you can do due diligence around complexity. That would be super helpful for the conversation next week.

Tim Beiko: Okay. And Charles.

Charles Cooper: Hi, I am drafted a eip to change memory pricing from quadratic to, I guess some per page. Eip 79, 23. I didn't get it out the door soon enough for the cutoff 2 weeks ago. But if it's I'd like for it to be considered, at least for Fusaka, but at least kick off the discussion about it. So yeah.

Tim Beiko: Yeah. So for oh, you mean for Fusaka or for Amsterdam.

Charles Cooper: Right, if not for Fusaka. Then the next hard fork.

Tim Beiko: Yeah. So I think, yeah, because no one has had time to review it. And we're already past the deadline. I I don't think we should chat about it on the call today. If people feel like it's urgent to include it in Fusaka, we can bring it up, but then, otherwise I would default to just having this in the Amsterdam conversation. Does that seem reasonable?

Charles Cooper: Yeah. On a related note. I am wondering if there is ever any time to have like a meta discussion about how eips get proposed, because for people who aren't.

Tim Beiko: Yes.

Charles Cooper: Process. It's like There's like a 2 to 4 week window at seemingly random times where we can propose things, and it's very easy to miss the window.

Tim Beiko: Yeah, I agree. And I I wanted to chat about this. Today. I'm not sure we'll have the time, but if not, then I think on on next the next call we should get into this and I think part of the reason for for Fusaka specifically why this window was smaller, and and it's probably fine to keep it small, is Fusaka was effectively Petra 2, and the overall, like agreements across grand teams was, we want to have something that's small in scope, and that ships quickly, and we kind of overloaded the 1st fork too much that we had to split it into 2 but I think for Glamsterdam, we definitely need to make this much clearer. And then there's a point around which conversations we have want to have on the call versus like Async, and how to coordinate that

But yeah, I wanna make sure we can at least move forward with the Fusaka scope today before getting into how we plan the next work done.

Ben Adams: Sorry to go back to an early issue, and I know you accepted the Pr. But the sorry the change in the peer desk proposal. But the reason for also having a Max cap on transaction blobs per transactions is because there is a cap on blobs, and it makes them harder to pack. So if you if you did a 40, if everybody did 48 blob transactions and it was a 52 cap, then you can only fit one of those in, whereas if they're broken up, then you can more efficiently pack the transactions in. So you and you'd you'd end up with the lower amount of blobs if we didn't have a number.

Tim Beiko: Okay? yeah, can we discuss this on the pure breakout or Async, just so can move forward with proseca here. And okay, thanks. Okay. Last, call on like client teams, strong opinions for Cfi. I think we've gone through most of them. If there's nothing else, then what I would like to like explicitly go over is the El proposals that we effectively won't be doing this work just so that we can provide clarity to people. So of the Pfi list. the El ones that we're not gonna be doing include 7, 6, 6, which is Evm, define the identity. Precompile 7, 6, 6, 8, removing the bloom filters. 7, 6, 8, 8. The SSD for compatible. Sorry. This one's a Cl. One. We can make that call next week. 7, 7, 3, 2 scl

Then 7, 7, 8, 3 is not a is not a core eip, but I don't think So I don't think we see if I did. So. yeah, we wouldn't be doing that at least in a in a coordinated way. 7, 7, 9, 1 gas to East Opcode. Not doing that. 7, 7, 9, 3. They precompile to get the index of transactions within blocks. 7, 8 0. 5. Fossil. 7, 8, 19 to create delegate OP. Code that Hadrian presented. 7, 8, 2, 3, the upper bounds for MoD. Exp. 7, 8, 4, 3 at the current slot number 7, 8, 9, emitting logs on revert, 7, 8, 9, 8, and coupling the execution payload from the beacon block. 7, 9 0, 3 removing the init code size limit.

7, 9, 1 7. We'll discuss next week, 7, 9, 18, we Cfi and then 7, 19. We're not doing either. So I will. Dfi, basically all the ones that are el that are El, that are not Cfi, and then we'll do the same thing next week for the Cl. Side. and it.

Danno Ferrin: Marius brought up in chat that we thought we did both of them on exp, and I had thought we had done that too, because both 2 clients.

Tim Beiko: So no. So we didn't. Yeah. So we didn't. So 7, 8, 2, 3, we did not. Cfi yet. Do we want to do that?

Danno Ferrin: Yeah, basically, with another mind, we're in favor of it. And Epsilon is also in favor of it, because it solves a whole lot of problems.

Tim Beiko: Okay. And this is just adding your bound.

Danno Ferrin: Yes, talking it out at 4,096.

Tim Beiko: Yeah.

Danno Ferrin: Bytes, which is sufficient for any Rsa signature.

Tim Beiko: Okay, does anyone disagree with Cfa? I think that one. Okay. So then that would be the last that we Cfid, all the other ones I mentioned that are el specific, we would we would decline for this fork, and then on the Cl call. Next week we will go through the similar process and get us to our final list of Cfid eips Anything else on Fusaka scoping. Okay? then. Yeah, we have 10 min left. I shared this proposal last week on the chat around, reconfiguring all core devs. In short, the idea is that we are now working on different forks in parallel, and we kind of mix

2 concerns like implementation details of the current fork with planning of the next fork. And clearly, as we discussed like we could do a better job of coordinating on the planning side, both in terms of figuring out what's the most important thing in the fork. Why is that important? Who does it affects? And how important is that? And also. like, yeah, having more focus on the implementation of current fork. So the proposal would be to basically split awkward dev such that the existing testing calls that happen every Monday that Terry and Mario been running would become the effectively. Acdt was my name awkward as testing where we discuss the current fork so effectively the Petra portion of today's call. And then

awkward devs acde and Acdc would be only focused on looking at the next fork. And what this means is we would have more time on these calls to discuss, like at a high level, what should be the most important thing to do in a fork. So, for example, for Glamsterdam we 1st start with like, Okay, what is what should be like this headliner for the fork? What should the fork be about? And ideally get to hear from a broader set of the community as part of this. So we could bring in, you know, representatives from you know, app development compiler teams and whatnot to try and figure out, okay, what is the most important thing to ship for ethereum? And then,

once we agree on that. What's like the right eip for it. And then, once we agree on that, what are the other things we can include alongside kind of like we did today. There's a lot of implementation details to figure out. But I think the 1st step is agreeing to doing this or not, and in practice. What this would look like, I think, is that once Petra goes, live. Then this call would just focus on Amsterdam, and all of the Fusaka conversation would happen in the testing call. and the one, I guess the one caveat there is that this assumes the scope stays fixed. But I think if we are, you know, if we're working on Fusaka, and we realize that we need to add an eip removing the IP or whatever it would still make sense to bring it up on this call. Just a sanity check. But yeah, that. Given a forks like a fixed fork scope. We would just move forward.

like, yeah, with with that. And so basically, like, yeah, to the Cfi comment, my point would be like anything that's Sfi kind of moves to the testing call. But then moving stuff from Cfi to Sfi is probably still something we want to do here. yeah. And I, yeah, to pull this other comment. It's like it'll be impossible to avoid. I think that's probably true. Like I I don't think it should be like a fully, you know. Like. if we need to ship Fusaka to ship to Amsterdam, so we shouldn't just like naively, fully ignore it. If there is something that we can accelerate by spending a few minutes on the calls talking about it. That's good. But the main purpose of this call should be, you know, Glamsterdam going forward. And then

this means, if you're working on Fusaka, the expectation is, we have everyone on the testing call there to resolve the issues. And so like. If there is something that's so urgent that we can't wake up. We can't wait a week to make a decision. We should obviously bring it up on the Cl or El call, but my expectation is like 90 to 95% or more of the things would just be handled there. but yeah, for this, you wanna share more.

Potuz: Just something, and you said it. But I just wanted to be explicit. Is that, there's no going to be any decisions making outside of this call of what actually goes into the port like if there's discussions about the things that were Cfi and that are apparently ready to be included. That's this is a decision that is not going to be made on the testing calls.

Tim Beiko: Correct. So like, yeah, the testing call effectively works with, like the set of Sfid Ips. And look at some point like, you know, there might be some weird boundaries like, for example, this blob transaction cap we discussed, and people can use their judgments on those. But you know, say, we start working on Fusaka. We're not gonna add Epbs to Fusaka on the testing call, like, if we wanted to do something like that, or even, you know, add, like the pre compile, or whatever. Even if it's a minor eip, we would still make this call here. But then, once that's set, and we know what we're working on like the implementation coordination moves to the testing call.

Reddick.

Radek: Yeah. So just thinking that talking about future forks is something that we haven't been doing that much. So this is my understanding of to talk more about it. So it's adding more things to, you know, to Acde, Acdc or basically to our agenda. And so if we push both Icde and Ecdc topics about the current fork to one testing call. It may be that we won't be able to fit everything into 90 min, so I see we will see how it plays out. But I'm just, you know, worried a little bit. That one testing call for everything might be not sufficient.

Tim Beiko: So the testing call is every week. And right now it's like an hour a week, most of the time. We don't use the entire hour. So, and we spent, I don't know. like sometime on extra today, but.

Marius van der Wijden: But.

Tim Beiko: Not a ton. So I I think.

Marius van der Wijden: We can start with.

Tim Beiko: That and see how it goes. Yeah.

Marius van der Wijden: Okay.

Radek: It's every week sorry. Yeah, if it's every week. Then I think it's fine.

Marius van der Wijden: But we're also only not using the whole hour, because there's only like 30 people attending. Probably when we make this official. And there's like 80 people attending. Then we might take me.

Tim Beiko: Yeah, yeah, and look like, maybe we can play with the structure and whatnot. And you know, maybe this call ends up being an hour, because we have less to discuss, and the other call is 90 min or whatever like I, I think we should be flexible. But my sense is like, yeah, I would not start with more than one call a week. And one note, actually, like, yeah, we haven't been like streaming and recording the testing calls now, and we will start doing that as part of this. So yeah, how'd it go.

Ansgar Dietrichs: Yeah. And I just wanted to very briefly give a shout out to also this new. These new research calls that that. And I kind of recently launched. We had the 1st one just the other day where we talked a bit about local building, and we will have a second one on May 7, th and I think those can actually fill nicely. Fill this gap of like, start talking about these like somewhat further out topics. not to replace a conversation about this. Of course, Ok. Will still kind of like talk about them once we are very close to making decisions about them, but I think it can give a bit of an advanced space for at least some of these higher level topics, so that it maybe takes a bit away. A little bit of the pressure from from having to

to have this this more vision side conversation, as well.

Tim Beiko: Yeah, I definitely agree with this, like, my rough mental model, is like the research call should think in years and like, what are the things on the horizon for ethereum. And where should we be spending more or less of our efforts? Awkward devs on the Cl. And El. Side should focus on like months, like, what do we want in the next work? And why is this important? And then the the testing call should focus on weeks, like, how do we get the specific Pr implemented? And then, yeah, to Lucas's comment on attendance, like, I think teams should have people at all like at all these calls, but it doesn't have to be the same. People like there are people who

maybe don't want to spend the year talking about what's gonna go in the next fork and would rather talk about how we're implementing the thing in this fork and vice versa. So yeah, if you want to be part of every single conversation. Then. Yes, you will attend more calls, but I think teams can also assign different people for different parts of the process. I'm Trent, you had a comment.

Trent Van Epps: Yeah, this is just about Petra pages. So I can go at the end. If people have final comments about.

Tim Beiko: Yeah, so I guess yeah, just to wrap this conversation up. It seems like everyone is in favor. I haven't heard any like major objections. So I think we should start this like next month. Once Petra goes goes live, and we effectively move this over to to like a Glamsterdam planning, there'll be a bunch of minor issues to figure out. But I'll assume that if I haven't heard any objections by like the Cl. Call next week. everyone has reviewed the proposal and is happy with it. And you know, module figuring out some details. We're moving ahead. Yeah, okay, Trent.

Trent Van Epps: Some of you may have already gotten messages about this, but just wanted to broadcast it again. In years past we've done these sort of compilations of core contributor perspectives. We did it for the launch of the beacon chain. We did it for the merge, and we did it again last year for Denkun, and we'd like to do it again for Petra. tentatively titled Petra pages the way it works. We hope it will be a complement to the team perspectives that everybody has released on what went well with Petra and what we could improve. So if you were materially involved in core development over the last year or so specifically related to Petra. Please do reach out to myself or Nixo. We're working on coordinating this. The deadline is April 28, th hopefully, that's enough time for people to submit. It's not a very long you can choose how much depth you put into your responses. But

yeah, looking back on Petra things we could improve specifically. how the process could have been handled better. But also things like any contributions that you or your team are particularly proud of somebody that you want to give a shout out to and recognize their contributions on your team or otherwise. and something like you know, particularly nasty bugs. This is a way for you to surface things that are unique to your perspective. That may not filter up to like the high level team summary. So again reach out to myself or Nixo, if your team lead hasn't already sent you the form and submit it. By April 28.th Thanks.

Tim Beiko: Thank you. Trent. Yeah. I think this is, yeah. A great note to end on. So thanks everyone. We'll talk to you all next week. And yeah, let's get back to the ship. Have a good one.

Alex Stokes: Thank you.

Carl Beekhuizen: Thanks, all.

Marius van der Wijden: Take care!

Ansgar Dietrichs: Bye, everyone.

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