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.
Transcript
Tim Beiko: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.
Tim Beiko:And then finally, at the end, I had this proposal around reconfiguring all core devs. So we can discuss that.
Tim Beiko:And yeah, I guess. Before we go into the 7 7 0, 2 receipts, proposal,
Tim Beiko: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?
Tim Beiko:I'm ben.
Ben Adams:If 69 doesn't actually need to happen on a hard work, does it?
Felix: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: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.
Ben Adams:but I mean it, doesn't it? It's not. It doesn't alter the timeline of the circuit. It's not like a
Ben Adams: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
Tim Beiko:Is that still reasonable.
Tim Beiko:No major concerns or issues round up.
Tim Beiko:Okay?
Tim Beiko: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.
Tim Beiko:Oh, thank you. Yeah, Lucas, do you wanna give some context on this.
Lucas:Actually, this was written by my colleague Nicholas.
Lucas:But it's a pretty small change for context.
Lucas:we just want to add the
Lucas:results of the authorization into the transaction receipt.
Lucas:So for context, right now to identify whether the authorization has passed.
Lucas:we have to do if get code
Lucas:to check. So we thought it'd be a better developer experience if we can add this
Lucas:success or failure in the authorization.
Lucas:Oh, success or failure of this authorization in the transaction receipt.
Felix:Sorry to just speak up, but I think it's not possible this way, because then we would have to actually store this
Felix:right.
Tim Beiko:What do you mean by store this.
Felix: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.
Felix:And
Felix: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
Felix: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
Felix:Rpc. Api change. I feel like this requires some actual
Felix:changes in the client to make it work.
Felix: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: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
Felix:it's kind of it. I guess there is another check in there somehow, like it cannot be.
Felix: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
Felix:wrong, then well, we're not going to have
Felix: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.
Felix: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
Tim Beiko:parse the response. I guess. Yeah, I'd be curious
Tim Beiko:when in the doc. It says, you know, you need to parse the response. But is it just
Tim Beiko: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
Lucas:the implementation details. So
Lucas:yeah, we thought it would be a minor change to improve like the developer experience. But if the risk is too high, I guess.
Lucas: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?
Tim Beiko:yeah, like is from my, it's like you're doing one extra Rpc call and then matching the data
Tim Beiko: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
nic:getting the result through a transaction receipt. There are additional steps just to accommodate this spectral workflow.
nic: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.
nic: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
Tim Beiko: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,
Tim Beiko: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.
Tim Beiko:yeah, Felix.
Felix: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.
Felix: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
Felix: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
Felix: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.
Roman: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.
Tim Beiko: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
Tim Beiko:a similar design to that.
Roman:Yeah, but because, as far as I understand, like you, you only care about like authorization succeeding
Roman:in the moment when you're submitting it.
Felix: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.
Felix:it is probably going to be okay.
Tim Beiko:Okay? So I guess yeah, we should not
Tim Beiko:change to specs now. It seems like there's workarounds.
Tim Beiko: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
Tim Beiko: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?
Tim Beiko:yeah. The best way to to efficiently query this data.
Lucas:Alright. Thank you very much.
Tim Beiko:Yeah, thank you.
Tim Beiko:Okay, anything else on Petra that people wanted to discuss.
Tim Beiko: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.
Tim Beiko:Okay. So next up Fusaka.
Tim Beiko: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
Tim Beiko:the El side of things finalized. On this call.
Tim Beiko:And 1st before we get into like the specific team preferences. I realize we
Tim Beiko: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
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:yeah, I guess. 1st of all, does this seem reasonable to people? To anyone have like an objection with
Tim Beiko:the process like this at a high level, or is it unclear in any way?
Tim Beiko:Okay? Let's go then.
Tim Beiko:so given this. Yeah. All of the El teams shared their preferences.
Tim Beiko:on the last call the last El call we'd already we'd already Cfid. Or sorry we'd already
Tim Beiko:specified one other.
Tim Beiko:Okay, sorry, my bad on the last call we Cfid one other eip for the MoD Xp gas through pricing.
Tim Beiko: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
Tim Beiko:in terms of like the the things client teams kind of signaled that they would like.
Tim Beiko:we I don't think there was anything else that was effectively supported by teams unit unanimously. The
Tim Beiko:let me look through the list with like the other broadly supported ones were
Tim Beiko:so I guess the yeah. The other ones around
Tim Beiko:addressing MoD. MoD. Xp. Where
Tim Beiko: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.
Tim Beiko:yeah, as as like broadly supported.
Tim Beiko:And then, yeah, maybe
Tim Beiko: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
Tim Beiko:what they'd like to see included, or like Cfid beyond this. That's probably a good, a good step.
Tim Beiko:Yeah, Ben.
Ben Adams:Since it was brought up at the the start of the call and support. If 69
Ben Adams:But I'm
Ben Adams:from 2 points of view. It's, you know, helpful, but also from the point of view it it's not
Ben Adams:contingent on the Fork timeline, so it'd be nice to get into the fork, but it'd be good to market as a
Ben Adams: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.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:do client teams generally want to try and get this like when we say Petro means in the next week
Tim Beiko: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.
Andrew Ashikhmin:Probably we won't be making a a release in the pector timeframe. We'll have a release, maybe a month or 2 later.
Andrew Ashikhmin:but also about it 69. It's it's nice if if 69 specifies the available block range
Andrew Ashikhmin: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.
Tim Beiko:okay, so we won't have all the teams with 8, 69 before Petra. But
Tim Beiko:teams are actually spending. Yeah, spending time on this.
Tim Beiko:and yeah, it because it doesn't require a hard fork. It's kind of
Tim Beiko:awkward or to include it. But I
Tim Beiko: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: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:I feel like this.
Felix: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.
Tim Beiko: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
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:there is like, yeah. One
Tim Beiko:one interesting question in the chat around raising the gas limit, which is another thing that's been discussed.
Tim Beiko:it's kind of a weird topic, because there's no
Tim Beiko: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.
Tim Beiko:so is that something that we should somehow also incorporate in this and like,
Tim Beiko:yeah, I I don't know if we should have just like some placeholder Eip that says.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:this feel different than saying, we want to reach a hundred 1 million gas. And that's like our priority.
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:yeah.
Andrew Ashikhmin:Yes, so
Andrew Ashikhmin:I I like to be honest. I think that we should do it post Fussaka, but but
Andrew Ashikhmin: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.
Tim Beiko: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
Dankrad Feist: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
Dankrad Feist:not.
Dankrad Feist: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
Dankrad Feist:we ignore this part. So I think, like.
Dankrad Feist:yeah, on a relatively short timeline, getting all the hurdles out of the way that technically limit us to below 100 million
Dankrad Feist:seems very high value.
Dankrad Feist:Also, in terms of our signaling to the community that we are actually taking this seriously. And this is not just like
Dankrad Feist:everything slides back after there was a big
Dankrad Feist: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.
Tim Beiko: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.
Tim Beiko:yeah.
Tim Beiko: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
Ansgar Dietrichs: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
Ansgar Dietrichs:development bandwidth will be consumed by performance increases. And so that just means that the overall shipping bandwidth of new features is going down.
Ansgar Dietrichs: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.
Ben Adams:60 million. We don't want a single transaction that uses the entire block.
Ben Adams:It's bad for paralyzation. Further optimization. And we? We also don't know.
Ben Adams: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
Tim Beiko:like. Why should it be 30, and not 10, or 15, or.
Tim Beiko:You know.
Ben Adams:Low, low lower would be better. But I think the idea was
Ben Adams: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?
Tim Beiko:Yeah. Like client. You have a comment about the count. Abstraction.
lightclient: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
lightclient: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:Well, you pay more gas for storage reads.
lightclient: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.
Dankrad Feist:So I think, like.
Dankrad Feist:it is just essential to do this, and we'll have to like people will have to pack them into smaller
Dankrad Feist:transactions.
Ben Adams:Also it means if if it's a 30 million, if it's a entire block transaction
Ben Adams:that would imply that it's a single bundler that is dominating, you know, pushing out everybody, everybody else.
lightclient: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
Tim Beiko:that's a concern, even with a 30 million?
Tim Beiko: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
Tim Beiko:should. We
Tim Beiko: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: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,
Tim Beiko:I don't know how the it seems like they sue.
Marius:I'm strongly in favor of sifying this and of doing this because I think it's just
Marius:It also becomes a thing of fairness at some point. If if these
Marius: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.
Marius:So I would rather have them
Marius:send 2 or 3 transactions. And then the likelihood that someone can
Marius: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.
Tim Beiko:Yeah, decide if and how we want to implement it at a later date, but it seems like there's some
Tim Beiko:support for it. And then, if to the extent we actually want to raise the gas limit. It can be helpful.
Tim Beiko:yeah. So I would. Cfi, this one.
Tim Beiko:And Carl, yeah, you have a comment. About 7, 2, 1, 2.
Carl Beekhuizen:Yeah. So curl of butts recently found that
Carl Beekhuizen:back for 7, 2, 1, 2. That's the r, 1 free compile. Add a bug edit.
Carl Beekhuizen:and so we will need a new
Carl Beekhuizen:rip. Slash eip if you want to ship this which is basically the same thing to put the same address. But with this.
Carl Beekhuizen: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
Carl Beekhuizen: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
Carl Beekhuizen:for their sake.
Carl Beekhuizen:Those yeah.
Tim Beiko:That seems.
Tim Beiko:Yeah. I mean, I think, yeah, we should treat this as though it was
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:okay, I guess. Aside from the transaction limit cap, are there other vips? Some clients felt strongly about
Tim Beiko:stiffying today? That yeah, we should add to this list.
Tim Beiko:And I posted the full list of what's been proposed in the chat.
Tim Beiko:okay? And if okay,
Tim Beiko: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
Tim Beiko:do Onsgar, and then the 2 IP champions after. But
Tim Beiko:yeah, like clients increasing the code size which one is this
Tim Beiko:or the contracts up.
Marius:7, 9 0 3 sorry! 7, 9, 0 7.
Tim Beiko:7, 9, 0, 7.
Marius:We? We are kind of against 7, 9, 0, 3, because it removes the entire limit, and we are for 7, 9 0, 7,
Marius:which increases the the code size limit.
Marius:but also adds, adds additional cost, and it's not unbounded.
Tim Beiko:Yeah. Charles.
Charles C:Yeah, I'm the author of both of these vips. I think that.
Charles C:Well, I was given the feedback that it could have a limit. A little bit later.
Charles C:I think it would be okay to add it as like
Charles C:one x or 2 x the limit in the runtime code size limit.
Charles C:I don't really see a need for it, because
Charles C:the Init code limit is already basically, the Init code
Charles C:doesn't incur a read from State.
Charles C:and it's already paid for by memory expansion. But
Charles C:if people are more comfortable with the limit, I'm happy to add that in.
Marius:The problem is that you can just create really, really big contracts, a really, really big init code and then execute certain attacks
Marius:because of that.
Marius:So that's why. Why the.
Charles C:That's.
Marius:Jump Destin notices.
Charles C:It's already metered.
Charles C:So it's like paid basically per word.
Marius:It would still.
Charles C: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: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
Guillaume:to figure out if that is true.
Charles C:Yes, the benchmarks are published, and there's a link to them in the youth magicians discussions today.
Tim Beiko:And I guess
Tim Beiko:yeah. So, Charles, if assuming the client teams prefer 7, 9 0, 7, and you're an author on this one where you?
Tim Beiko:Were you happy with
Tim Beiko: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 C:I think they both need to go in, because without an innate code size increase, you can't practically
Charles C:deploy larger contracts.
Tim Beiko:I see
Tim Beiko:any other client. Teams have opinions on this one or.
Guillaume:I'm not another client team, but I do have an opinion. When we redid we did the redesign
Guillaume: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
Guillaume:for the code size.
Danno Ferrin | Ipsilon:Then we up to 3 in a design session. A few months ago I brought this issue up.
Guillaume:Going in.
Danno Ferrin | Ipsilon: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: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
Guillaume:It's still going to be limited. So I would prefer not doing this, not having an unlimited code size, simply because
Guillaume: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
Guillaume:for for Eap 4,760.
Charles C:I see what app.
Charles C:All right. Go ahead.
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon: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 C:Yeah, init code. Never. Actually.
Charles C: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.
Charles C:But it's not actually physically stored in the State.
Charles C:So like Dana was saying, like the
Charles C:limit on the Runtime code is like what you really need.
Marius: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:We're we're not clear on on the bonds yet. Yes.
Tim Beiko:Which so 7, 9 0. 7 in.
Tim Beiko:Proposes an increase to the bound right.
Charles C: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 C:Right and 7, 9 0, 3 uncaps in that code.
Tim Beiko:But I guess, yeah, the question is, would people
Tim Beiko:prefer? Would people be okay with a larger but capped edit code size?
lightclient:That's probably my preference.
Tim Beiko:Do any other client teams have opinions on this?
Tim Beiko:Okay. So then, I guess, would that mean
Tim Beiko:Cfi 7, 9, 0, 7. And then.
Tim Beiko:either modifying 7, 9 0, 3. To have a proposed limit, or just adding a init code limit to the 7 9 0, 7
Tim Beiko:Vip. I don't know if people have a preference for for that.
Marius: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
Marius:in a code limit as we have right now, which is twice the size of the of the Max Contract limit.
Marius:which I think is reasonable.
Tim Beiko:Does anyone have concerns or objections about this.
Danno Ferrin | Ipsilon:Not necessarily concern or objection, but I wanna make sure people know that there's going to be an extra charge
Danno Ferrin | Ipsilon: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?
Ben Adams:I think I think it came up to increase contract size.
Marius: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
Marius:to something bigger.
Ben Adams:Okay.
lightclient: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
lightclient: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
lightclient: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.
lightclient: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.
Tim Beiko: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.
Tim Beiko:Any other eips client teams feel strongly should be cfi'd So
Tim Beiko:we have 7, 8, 2, 5, 7, 9, 0, 7.
Tim Beiko: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 (OpenZeppelin):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?
Tim Beiko: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
Tim Beiko:and is Anders on the call. I probably saw him in chat
Tim Beiko:is on theirs.
Anders Elowsson:Oh, yeah, hello, yeah. Yeah. Hey, okay, yeah.
Anders Elowsson: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.
Anders Elowsson: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.
Anders Elowsson: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.
Tim Beiko: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,
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Tim Beiko:Yeah, Ben.
Ben Adams:I I do like the new proposal over the prior one. Because
Ben Adams: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.
Ben Adams:But the the new proposal is less arbitrary. It's it's actually responding to the few markets. So it is.
Ben Adams:it feels better.
Ben Adams:It's got good vibes.
Tim Beiko:I guess. Yeah. One thing I would hope is that people
Tim Beiko:like before we make this decision, we've actually
Tim Beiko:like reviewed it fairly thoroughly.
Tim Beiko: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.
Tim Beiko:Yeah, I would probably see if I
Tim Beiko:either both or like one of them. But, like definitely take like
Tim Beiko: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
Tim Beiko: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?
Tim Beiko:Yeah, does anyone feel like we should not? Cfi 7, 9, 1, 8.
Tim Beiko:It seems like there's relatively broad support for that. I'm not sure. About 7, 7, 6, 2,
Tim Beiko:but yeah, 7, 9, 1, 8 seems
Tim Beiko:probably supported. And again we'd have. We'll have to like review the curve and potentially tweak it, but
Tim Beiko:probably go in that direction.
Tim Beiko:Okay, so that's Cfi 7, 9, 1, 8. Does anyone want to push for 7, 7, 6, 2 being Cfi as well. Then.
Tim Beiko:it's yeah.
Tim Beiko: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,
Dankrad Feist:I mean, I'm not. I wasn't really aware of 7, 9, 1 8. But I am, I
Dankrad Feist: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?
Dankrad Feist: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
Tim Beiko: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
Tim Beiko: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.
Anders Elowsson: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
Dankrad Feist:flow on both. I would also be pro having a higher execution policy.
Tim Beiko:One comment from the chat,
Tim Beiko:is like, yeah, this assumes both of these are relatively trivial to implement.
Tim Beiko:anyone have concerns about that like, it seems to me like they're both fairly small changes, and relatively equal in size. But yeah.
Tim Beiko:is that, does anyone feel like that's not the case.
Tim Beiko:Okay?
Tim Beiko: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
Tim Beiko:move this conversation to do you have like a free market channel or something?
Tim Beiko:We do not.
Tim Beiko: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.
Tim Beiko:Heydrien, let's do, Adrian, and then Barnabas will get to your question. Hadrian.
Tim Beiko:yeah. Do you want to present your IP.
Hadrien Croubois (OpenZeppelin):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:Hey! Adrian.
Hadrien Croubois (OpenZeppelin):In regards, yeah.
Trent:You're in a you're in a very echoey room, so maybe get closer to your mic.
Hadrien Croubois (OpenZeppelin):Yeah.
Trent:Go to a room with less echo, and then people will hear you better.
Hadrien Croubois (OpenZeppelin):Okay, I'm I'm outside right now. Is that better?
Trent:Yes, very much.
Hadrien Croubois (OpenZeppelin):Okay. I'm sorry I'm at the maternity. My baby was just born this morning.
Trent:Congrats.
Hadrien Croubois (OpenZeppelin):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
Hadrien Croubois (OpenZeppelin):so the idea of this vip
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):and the idea is that I would like more contract to be able to create these objects that have, in my opinion, external properties.
Hadrien Croubois (OpenZeppelin):These properties are that they're very small. They are just the size of a 7 7 0, 2 delegation
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):Another benefit from having this implemented is that
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):And with the change to Eos it's unclear to me. What's the right moment to propose something like that?
Hadrien Croubois (OpenZeppelin):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:I don't really understand the Pr. The Ap. I kind of get the gist of it.
Marius:But I don't think it should be done in Fusaka. To be honest, it's a it's
Marius:as I. It's the way I see it. It's kind of a nice change.
Marius:but I don't think this is like we have
Marius: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.
Tim Beiko:But
Tim Beiko:okay, so won't be moving this to Cfi today, I believe.
Tim Beiko:Thank you, Adrian, and hopefully, you can get back to the maternity ward.
Tim Beiko:Yeah.
Tim Beiko:Yeah. And like, yes, we can add this to Eos in A in a different port.
Tim Beiko:okay. So Barnabas had a comment about the deadline for ssifying things for Fusaka. I think.
Tim Beiko:Yes, the the way I I would approach it is
Tim Beiko: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
Tim Beiko: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?
Tim Beiko:I think a lot of the things we've Cfid are relatively simple changes. And so.
Tim Beiko: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.
Tim Beiko:but that would kind of be the approach I would take
Tim Beiko: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.
Tim Beiko:I don't know if we want to like. Set some sort of
Tim Beiko:more stringent date. My fear is, if we do this, then we just end up
Tim Beiko:breaking it, or it ends up being kind of a a useless state.
Tim Beiko:and that the thing that kind of bottlenecks us as we're working on the fork is
Tim Beiko:like implementation stability on the devnet. So
Tim Beiko:yeah, that would be my approach. I don't know if
Tim Beiko:anyone has opinions or thoughts on this.
Tim Beiko:Okay?
Tim Beiko:And so, as of now, the stuff we have Sfi in in
Tim Beiko:Fusaka. Sorry is Peerdas, and this list of Eof eips from Devnet 0 and devnet one for eof
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko: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?
Tim Beiko:and
Tim Beiko: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
Tim Beiko:formal deadline was today like that feels like an important conversation to have
Tim Beiko:So on the el side. I guess.
Tim Beiko:The people feel like there's
Tim Beiko: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
Ben Adams:the number of blobs per transaction.
Ben Adams: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
Ben Adams: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:If we're planning to increase the blobs again in Fusaka.
Marius:I think we should have this.
Tim Beiko:So do we need an eip for this.
lightclient:Why not just do this in the pure dot? Cip.
Tim Beiko:Yeah.
Marius: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.
Tim Beiko: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:Yeah, it. It just felt kind of a bit off to decide this within the.
Tim Beiko:Yeah.
Marius:Within the Peters group and not inform everyone else about it. So if that's okay.
Tim Beiko:I guess, yeah.
Marius:Informed about it now, so.
Tim Beiko:Does anyone? Yeah, don't think we should have a limit.
stokes:Yeah, I and the protocol cause we've discussed this before. If I'm following, maybe I misunderstood. But
stokes: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
Ben Adams:through.
Ben Adams:Yeah, I don't know if it makes any difference.
stokes:Yeah, I mean, if most people want it, I'm not gonna block it.
Ahmad Bitar | Nethermind:I think the reason it makes more sense is because
Ahmad Bitar | Nethermind:helps with mempool. So maybe having it only in mempool makes sense.
Ahmad Bitar | Nethermind:If you modify the software and do up
Ahmad Bitar | Nethermind: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
Ahmad Bitar | Nethermind:transactions that have a lot of blobs. But if there is another reason that restricting the blobs in a single transaction makes sense.
Ahmad Bitar | Nethermind: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
Barnabas Busa:I would propose not to pump the blob limit in Fussaka and do it in a blob. Only update that way. We can test
Barnabas Busa:one lesson, 1 1 less thing, basically. And it's gonna be a bit quicker for
Barnabas Busa: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
Tim Beiko:we can still decide to to activate it that way? Yeah, I'm
Tim Beiko:yeah. Onsgar on. Theirs is just about the same topic.
Anders Elowsson:Yeah.
Ansgar Dietrichs:I mean, I would.
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Tim Beiko: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
Tim Beiko:define the like specifics of the cap on the peer desk breakouts. Does that seem reasonable to people?
Tim Beiko: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
Tim Beiko: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
Tim Beiko:anything else. People feel strongly about us. Cfi in today.
Tim Beiko:Lynn.
Lin Oshitani | Nethermind:Yeah. In last Cl call we talked about Eip 7, 9, 1, 7, which is deterministic
Lin Oshitani | Nethermind:proposing, look ahead.
Lin Oshitani | Nethermind: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 | Nethermind: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 | Nethermind:Okay, okay, got it. Thanks.
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.
Tim Beiko:And Charles.
Charles C:Hi, I am
Charles C:drafted a eip to change memory pricing from quadratic to, I guess some per page. Eip 79, 23.
Charles C:I didn't get it out the door soon enough for the cutoff 2 weeks ago. But
Charles C:if it's
Charles C:I'd like for it to be considered, at least for Fusaka, but at least kick off the discussion about it.
Charles C:So yeah.
Tim Beiko:Yeah. So for oh, you mean for Fusaka or for Amsterdam.
Charles C: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
Tim Beiko:chat about it on the call today. If people feel like it's urgent
Tim Beiko:to include it in Fusaka, we can bring it up, but then, otherwise I would default to just having this in the Amsterdam conversation.
Tim Beiko:Does that seem reasonable?
Charles C:Yeah. On a related note. I am wondering if there is ever any time to have like a meta discussion about
Charles C:how eips get proposed, because for people who aren't.
Tim Beiko:Yes.
Charles C:Process. It's like
Charles C:There's like a
Charles C: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
Tim Beiko: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
Tim Beiko: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
Tim Beiko:Fusaka was
Tim Beiko: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
Tim Beiko: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
Tim Beiko: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
Ben Adams: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
Ben Adams:blob transactions and it was a 52
Ben Adams: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
Ben Adams:if we didn't have a number.
Tim Beiko:Okay?
Tim Beiko:yeah, can we discuss this on the pure breakout or Async, just so can move forward with proseca here.
Tim Beiko:And okay, thanks.
Tim Beiko:Okay. Last, call on like client teams, strong opinions for Cfi.
Tim Beiko:I think we've gone through most of them.
Tim Beiko:If there's nothing else, then what I would like to like explicitly go over is
Tim Beiko:the El proposals that we
Tim Beiko:effectively won't be doing this work just so that we can provide clarity to people. So of the Pfi list.
Tim Beiko: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
Tim Beiko:Then 7, 7, 8, 3 is not a
Tim Beiko:is not a core eip, but I don't think
Tim Beiko:So I don't think we see if I did. So.
Tim Beiko:yeah, we wouldn't be doing that at least
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:7, 8, 4, 3 at the current slot number 7, 8, 9, emitting logs on revert,
Tim Beiko:7, 8, 9, 8, and coupling the execution payload from the beacon block. 7, 9 0, 3 removing the init code size limit.
Tim Beiko:7, 9, 1 7. We'll discuss next week, 7, 9, 18, we Cfi and then 7, 19. We're not doing either.
Tim Beiko:So I will. Dfi, basically all the ones that are el
Tim Beiko:that are El, that are not Cfi, and then we'll do the same thing next week for the Cl. Side.
Tim Beiko:and it.
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon: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 | Ipsilon: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.
Tim Beiko:And this is just adding your bound.
Danno Ferrin | Ipsilon:Yes, talking it out at 4,096.
Tim Beiko:Yeah.
Danno Ferrin | Ipsilon:Bytes, which is sufficient for any Rsa signature.
Tim Beiko:Okay, does anyone disagree with Cfa? I think that one.
Tim Beiko:Okay.
Tim Beiko: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
Tim Beiko:Anything else on Fusaka scoping.
Tim Beiko:Okay?
Tim Beiko:then. Yeah, we have 10 min left. I shared this proposal last week on the chat around, reconfiguring all core devs.
Tim Beiko:In short, the idea is that we are now working on different forks in parallel, and we kind of mix
Tim Beiko: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.
Tim Beiko:like, yeah, having more focus on the implementation of current fork. So the proposal would be to
Tim Beiko: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
Tim Beiko: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
Tim Beiko: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
Tim Beiko: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,
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:and the one, I guess the one caveat there is that
Tim Beiko: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.
Tim Beiko:like, yeah, with with that. And so basically, like, yeah, to the Cfi comment, my point would be like
Tim Beiko: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.
Tim Beiko:yeah.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:you know, say, we start working on Fusaka.
Tim Beiko: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
Tim Beiko:like the implementation coordination moves to the testing call.
Tim Beiko:Reddick.
Radek:Yeah. So just thinking that
Radek: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.
Radek: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.
Tim Beiko:like sometime on extra today, but.
Marius:But.
Tim Beiko:Not a ton. So I I think.
Marius:We can start with.
Tim Beiko:That and see how it goes. Yeah.
Marius:Okay.
Radek:It's every week sorry. Yeah, if it's every week. Then I think it's fine.
Marius: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
Marius: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
Tim Beiko: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
Tim Beiko: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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?
Tim Beiko: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?
Tim Beiko:And then, yeah, to Lucas's comment on attendance, like, I think
Tim Beiko: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
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:I'm Trent, you had a comment.
Trent: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
Tim Beiko:to like a Glamsterdam planning, there'll be a bunch of minor issues to figure out. But
Tim Beiko:I'll assume that if I haven't heard any objections by like the Cl. Call next week.
Tim Beiko:everyone has reviewed the proposal and is happy with it. And you know, module figuring out some details. We're moving ahead.
Tim Beiko:Yeah, okay, Trent.
Trent: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.
Trent: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.
Trent: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
Trent:yeah, looking back on Petra things we could improve specifically.
Trent: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.
Trent: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
Trent:Thanks.
Tim Beiko:Thank you. Trent. Yeah.
Tim Beiko: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.
Tim Beiko:Have a good one.
stokes:Thank you.
Carl Beekhuizen:Thanks, all.
Marius:Take care!
Ansgar Dietrichs:Bye, everyone.
Chat Logs
00:03:05
Lucas:Transaction receipt change
PR:
https://github.com/ethereum/execution-apis/pull/640
Ethereum-magician:
https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code/19923/383
HackMD:
https://hackmd.io/@cU7QMf4cQE-bqaR_VenOTw/HyCKM3531e
00:04:01
Danno Ferrin | Ipsilon:Replying to "Transaction receipt ..."
Is this is RPC only, not impacting any on-chain executions?
00:04:04
Ben Adams:eth69 drops Bloom and includes block ranges for history https://eips.ethereum.org/EIPS/eip-7642
00:04:30
lightclient:ah right, it depends on the current nonce of the authorizer
00:07:17
Mario Vega:Wouldn’t querying the code of the account be better anyway? Because even if you store the success of a delegation on a particular tx, a subsequent tx could re-delegate
00:07:31
Ansgar Dietrichs:could this not be added to clients at a later time? does this require a hard fork?
00:08:08
Felix:Replying to "Wouldn’t querying..."
I think same. In the end you want to know if the account is delegated correctly, you can get that by matching on the response to getCode being 0xef01<address>
00:08:14
Anders Kristansen:Replying to "could this not be ad..."
Doesnt require a hardfork
00:09:15
Hadrien Croubois (OpenZeppelin):It feels like the workaround to this proposal, which is using getCode, also requires an archive node to get historical results. The delegation might have change since that Tx
00:10:43
frangio:another note here is that the delegation can be inspected in the EVM so the entrypoint of the transaction can do the confirmation that the delegation was set
00:11:53
Roman:that‘s also a good point
00:13:31
Trent:🚢
00:15:22
Marius:Lets gooo
00:15:58
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7607
00:17:12
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7823
00:17:14
lightclient:EIP-7907: Meter Contract Code Size And Increase Limit
00:17:25
Dankrad Feist:Should we CFI a target gas limit increase to 100m?
00:17:47
Tim Beiko:Replying to "Should we CFI a targ..."
I would like this 😄
00:18:15
Dankrad Feist:Replying to "Should we CFI a targ..."
is this an EIP? how do we fix this as a priority?
00:18:37
Barnabas Busa:eth69 should be done way before fusaka gets activated
00:18:41
Toni Wahrstätter:Replying to "Should we CFI a targ..."
Get it on a testnet asap, I'd say
00:18:46
Marius:Replying to "Should we CFI a ta..."
Geth nodes can't even handle 60m at the moment. Running oom
00:19:14
Marius:Yes
00:19:28
Dankrad Feist:Replying to "Should we CFI a targ..."
Yes. I'm saying let's try to ensure that we reserve capacity to get there
00:19:29
Marius:Lets get eth/69 in the next week
00:20:20
Toni Wahrstätter:Replying to "Should we CFI a targ..."
When will we be able to bump sepolia to 60m? What timelines are we talking?
00:20:20
Ben Adams:My main point is should eth/69 then be moved up in status?
00:20:32
Ben Adams:Rather than PFI
00:20:40
Marius:I don't think it needs to be in this list at all
00:22:04
Ansgar Dietrichs:so quick process question: what exactly are we freezing today? anything that’s not CFI after today will not be in the fork?
00:22:12
Gajinder Singh:Replying to "Should we CFI a targ..."
+1
00:22:32
Toni Wahrstätter:Replying to "so quick process que..."
I think so yeah. Today is deadline
00:22:59
Gajinder Singh:info EIP
00:23:14
Tim Beiko:Replying to "so quick process que..."
anything that’s not CFI after today will not be in the fork?
yes
00:23:15
Marius:Replying to "so quick process q..."
Should we just go through the PFI and reject them?
00:24:05
stokes:Replying to "so quick process que..."
Easier to just raise things we should CFI
00:24:14
Andrew Ashikhmin:https://eips.ethereum.org/EIPS/eip-7783
00:24:21
Gajinder Singh:or the hardware spec EIP can specify the target
00:24:47
Andrew Ashikhmin:Or https://eips.ethereum.org/EIPS/eip-7790
00:24:58
Ansgar Dietrichs:clearly we don’t need to freeze gas limit decision today, right?
00:25:00
Marius:Replying to "so quick process q..."
I think the best would be to quickly go through an reject all where two or more client teams are against
00:25:11
Ansgar Dietrichs:Replying to "clearly we don’t nee..."
so we should focus on the decisions we actually have to make today
00:25:35
Toni Wahrstätter:An info eip to communicate tested numbers to validators might be the right approach
00:25:36
Tim Beiko:Replying to "clearly we don’t nee..."
Sure, but this does affect the scope. If we CFI a bunch of EIPs and eat up all our bandwidth, that’s not great
00:25:49
Łukasz Rozmej:I thought we wanted to go to 60mln post Pectra and we will see then whats next
00:25:53
Ansgar Dietrichs:agree though, ideally we should aim for something like
Fusaka - 60M
EOY - 100M
00:25:59
Tim Beiko:Yeah, I think an info EIP that says “we’re trying to reach X gas and fill fix the bugs until there"
00:26:10
Kevaundray Wedderburn:Replying to "or the hardware spec..."
I’d prefer not to overload that EIP tbh
00:26:37
Gajinder Singh:Replying to "Yeah, I think an inf..."
yea that specifies the schedule of bumping it
00:26:48
Gajinder Singh:Replying to "or the hardware spec..."
makes sense
00:28:04
Andrew Ashikhmin:EIP-7825: Transaction Gas Limit Cap
00:28:07
Dankrad Feist:agree with transaction gas limit
00:28:13
lightclient:limiting the size of the tx per block is not good for AA through
00:28:20
Dankrad Feist:this also improves worst case parallelization
00:28:36
Ansgar Dietrichs:cap seems reasonable - also worth noting that we can always remove / modify the cap later. doesn’t lock us in permanently
00:28:42
Łukasz Rozmej:30 was before we went to 36
00:28:47
Mario Vega:Replying to "Should we CFI a targ..."
We currently hard-code 30 million in many of our tests, but we could make this value parametrizable in our test-generating framework to make our tests adjust dynamically to these continuous gas increments to mainnet. Created issue here: https://github.com/ethereum/execution-spec-tests/issues/1434
00:29:09
Toni Wahrstätter:Replying to "limiting the size of..."
but would that be that bad going to 30m. Are there many 30m AA transactions today? If it's only saving 21k then I don't see a big problem
00:29:26
Ansgar Dietrichs:even then, 30M is just not restrictive
00:29:34
Sophia Gold:Likely 60m gas limit by the time Fusaka is on mainnet
00:29:40
Ansgar Dietrichs:we can always lift that once we are at gigagas on mainnet :-)
00:29:42
Danno Ferrin | Ipsilon:Replying to "limiting the size of..."
4337-style AA with a bundled entrypoint, but native AA will have no problem
00:30:12
Danno Ferrin | Ipsilon:Replying to "limiting the size of..."
4337 style bundling is a barrier to parallelization.
00:30:20
Ameziane Hamlat:I have already seen 30 mags transactions on Ethereum mainnet. The closer we do transaction gas limit, the better it is.
00:31:17
Ansgar Dietrichs:can we just CFI the cap and then have the discussion async for whether to move it to SFI? clearly there is a lot of support
00:31:43
Parithosh Jayanthi:Also CFI doesn’t mean we have to ship it (SFI it)
00:32:03
Andrew Ashikhmin:Erigon is in favour of EIP-7825
00:32:16
Sophia Gold:We want to continuously pump the gas so the longer we wait the more likley this breaks things
00:32:26
Carl Beekhuizen:Re: RIP-7212, we’ll need a new RIP/EIP due to a bug in the 7217 spec: https://github.com/ethereum/RIPs/pull/62/files
I’d like to talk about this briefly re: its CFI status
00:34:05
Marius:I would like this as an EIP anyway
00:34:39
Tim Beiko:This is the list of PFI’d EIPs
00:35:01
Ansgar Dietrichs:I would argue for CFI-ing EIP-7762, the blob basefee floor.
to reiterate, this floor is still in the “practically free” range, so this is not about fee revenue, just efficiency.
It’s a 4-line spec change, and with peerdas the blob supply will increase enough to otherwise make the fee market quite annoying
00:35:15
lightclient:increase contract size
00:35:35
Ansgar Dietrichs:Replying to "I would argue for CF..."
happy to let client teams go first :-)
00:36:07
Mario Vega:Replying to "Re: RIP-7212, we’ll ..."
We could have found this through testing, I would encourage RIP implementers to use EEST (execution-spec-tests) to write the tests, core protocol also benefits from this because if the RIP makes into mainnet, then we already have tests
00:36:11
Anders Elowsson:I would like to argue for EIP-7918 instead of EIP-7762. It is a neutral change to fix the fee market
00:36:18
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7907
00:37:16
Ansgar Dietrichs:Replying to "I would argue for CF..."
to note: Anders had an alternative EIP proposal for this recently that is more sophisticated, but I worry it might be too short notice to CFI today.
00:37:47
Anders Elowsson:Replying to "I would argue for CF..."
I would argue it is just as simple, and also more neutral
00:37:49
Tim Beiko:Replying to "I would argue for CF..."
Ok, then I think we should do @Hadrien Croubois (OpenZeppelin), then @Anders Elowsson and you 😄
00:38:10
Anders Elowsson:Replying to "I would like to argu..."
https://ethereum-magicians.org/t/eip-7918-blob-base-fee-bounded-by-execution-cost/23271
00:38:17
Marius:He's busy celebrating his birthday
00:38:37
Łukasz Rozmej:btw if clients persisted jumpdest analysis bitmap it wouldn't be a problem?
00:39:41
Tim Beiko:No one else had mentioned 7903/7907 as a preference and ~everyone wants to keep the scope small, so I’d lean again CFIing it.
00:39:58
lightclient:are any clients against increasing code size in principle? details can be totally agreed on for SFI
00:40:07
Marius:Replying to "btw if clients per..."
yes it is, because you are doing it in initcode and you can change initcode
00:40:09
Ansgar Dietrichs:why don’t we just charge proportional to code size in EOF?
00:40:10
Kevaundray Wedderburn:7903 seems problematic for zkEVMs if you can have arbitrary contract sizes
00:40:15
lightclient:this is one of the most requested EVM improvements
00:40:19
Ansgar Dietrichs:Replying to "why don’t we just ch..."
that way we can remove any hard limit
00:40:26
lightclient:Replying to "7903 seems problemat..."
it isn’t going to be arbitrary
00:40:35
Alex (axic):Here’s an encoding of jumpdest analysis as done part of the verkle work: https://github.com/ipsilon/eof/blob/main/spec/eofv0_verkle.md#jumpdest-section-encoding
00:41:10
lightclient:Replying to "why don’t we just ch..."
still need an efficient look up for code size, EOF doesn’t grant this by default AFAIK
00:41:33
Ansgar Dietrichs:sounds reasonable to charge for size and so effectively bound by tx gas limit, instead of having arbitrary code size limit
00:41:55
Ansgar Dietrichs:Replying to "why don’t we just ch..."
ah, I remember. what’s the plan for this @Danno Ferrin | Ipsilon ?
00:41:59
lightclient:it’s easier to reason about if there is an explicit bound separate of tx
00:42:13
Gary Schulte:Replying to "7903 seems problemat..."
functional code size limit will be one of those unintended consequences of an otherwise innocuous change (block gas limit)
00:42:34
Marius:same here
00:42:47
Daniel Lehrner (Besu):Seems reasonable
00:43:07
Ansgar Dietrichs:Replying to "why don’t we just ch..."
and it’s probably impractical to pass the gas limit into the code load, and abort that load once it is too large?
00:43:20
Danno Ferrin | Ipsilon:Have 7907 update the initcode limit
00:44:35
Danno Ferrin | Ipsilon:24k limit was larger than the gas limit at the time.
00:44:36
Ansgar Dietrichs:any issues with forward compatibility here? we could still completely remove the limit in the future, right?
00:44:46
Marius:Replying to "any issues with fo..."
yes
00:45:39
Danno Ferrin | Ipsilon:There’s a code size field in the verkle account proposal.
00:45:48
FLCL:may be superficial idea: can code be encoded so length is always dividable by 32 or 1024, so you can store bigger x32/x1024 length
00:46:48
Charles C:i'd like to discuss EIP-7923 -- just got merged today (so maybe it's too late for fusaka) but i'd like to get some discussion going around it anyway
00:47:18
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7918
00:48:14
Marius:Replying to "i'd like to discus..."
This and EOF will be very annoying to test together imo. Not against this proposal, but I don'think we should do it in osaka
00:48:27
Hadrien Croubois (OpenZeppelin):@Tim Beiko got to somewhere where I can speak :)
00:48:47
Francesco:My summary: it's also a one line change in the spec, it increases the blob base fee until the blob portion of the cost matches the base execution cost
00:49:10
Ahmad Bitar | Nethermind:I think this is a needed addition alongside PeerDAS
00:49:20
Potuz:I like this idea
00:49:55
Tim Beiko:This is the original EIP by Max that Ansgar referenced: https://eips.ethereum.org/EIPS/eip-7762
00:50:34
Marius:We have a constant floor for min-tip in geth, since there is some cost to distributing, verifying, mining the transactions. So I am not opposed to some sort of minimum floor price
00:52:19
Ansgar Dietrichs:the only caution with the newer proposal is that it is so recent that it didn’t have full review yet. so I would still want to keep the old proposal as fallback
00:52:22
stokes:Does CFI give us time to investigate further?
00:52:28
Charles C:Replying to "why don’t we just..."
i originally proposed eip-7907 as having no limit. but it was pointed out that there are limits in the p2p network that we don't want to break (like devp2p has a soft limit of 512kb per packet or somethin
00:52:34
Ahmad Bitar | Nethermind:CFIing 7918 makes sense
00:53:19
Ansgar Dietrichs:Replying to "the only caution wit..."
so I think the important part would be to decide today to introduce any version of this, and then go with Anders’ as the candidate version for now
00:53:20
Marius:CFI 7918 and modify it how we need it
00:53:23
Toni Wahrstätter:Get 7918 more reviewed and have 7762 as a backup
00:53:36
stokes:Replying to "CFI 7918 and modify ..."
Lets do it
00:53:59
Ansgar Dietrichs:happy to not CFI 7762, as long as we agree that it could still be swapped in for 7918 if there are issues
00:54:25
Danno Ferrin | Ipsilon:Replying to "why don’t we just ch..."
You can calculate the container size from the full header, but it wasn’t designed as a quick lookup. Storing in a side table or a revised account tuple (in verkle) I feel is the better path.
00:54:52
stokes:CFI both today, and commit to only shipping one?
00:54:59
stokes:(Pending further analysis of 7918)
00:55:22
Charles C:Replying to "i'd like to discus..."
what is annoying about it? just the matrix of gas changes?
00:55:24
Potuz:It wasn't said explicitly but I assume both of these don't cause any delays whatsoever, they are both trivial to implement right? it'd be nice to say it explicitly in the call
00:55:41
Tim Beiko:Replying to "It wasn't said expli..."
Anders said it for 7918 but I’ll ask one last time 😄
00:55:51
Ansgar Dietrichs:the call doesn’t seem like the right place for this research debate
00:55:52
Danno Ferrin | Ipsilon:Replying to "why don’t we just ch..."
But “charge proportional to code size” is in reference to calling a contract or deploying a contract?
00:55:58
Potuz:Replying to "It wasn't said expli..."
Oh I missed it, should chat less :)
00:56:54
Danno Ferrin | Ipsilon:Replying to "i'd like to discuss ..."
My preference is that this is part of the “gaspocalypse” where we do all the gas schedule changes. Weakly held.
00:56:59
Barnabas Busa:whats the deadline for SFI for fusaka?
00:57:26
nixo:Hadrien, your audio is terrible
00:57:28
Marius:Whats the number?
00:57:32
Pooja Ranjan:echo
00:57:36
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7819
00:57:37
Danno Ferrin | Ipsilon:Replying to "whats the deadline f..."
when we schedule testnet forks?
00:57:42
stokes:Replying to "whats the deadline f..."
yeah
00:57:43
Tim Beiko:Replying to "whats the deadline f..."
I think it should be far befroe
00:57:50
stokes:Replying to "whats the deadline f..."
I would suggest we only SFI very carefully
00:57:54
Gary Schulte:DEDICATION! congrats
00:57:55
terence:congrats!
00:57:55
Pooja Ranjan:Congratulations!!
00:57:57
Tim Beiko:congrats!!
00:57:58
Ahmad Bitar | Nethermind:Congrats!
00:58:01
Kolby ML:congrats!
00:58:01
Manu:Congrats!
00:58:02
stokes:Replying to "whats the deadline f..."
So it would be clear to everyone when something should move from CFI to SFI
00:58:05
James He:Congrats!
00:58:06
Barnabas Busa:Priorities 😂
00:58:06
terence:that’s some dedication
00:58:14
Potuz:Wow! that's really being committed to Ethereum!
00:58:19
stokes:Replying to "whats the deadline f..."
And it should be settled around halfway in the fusaka devnet series
00:58:22
ethDreamer (Mark):While making a proposal about “delivery experience” lol
00:58:33
Barnabas Busa:Replying to "whats the deadline f..."
Could we deadline SFI by end of this month?
00:58:36
Ansgar Dietrichs:I think the rule is that we owe him a celebratory EIP inclusion now
00:58:42
Barnabas Busa:Replying to "whats the deadline f..."
So we can have may for stable devnets already?
00:58:56
Marius:Replying to "I think the rule i..."
Yep, just not in Fusaka :P
00:59:04
Guillaume:Replying to "I think the rule is ..."
I also have an EIP to include and a baby if that helps
00:59:06
Barnabas Busa:Replying to "I think the rule is ..."
in pectra
00:59:09
Parithosh Jayanthi:Replying to "whats the deadline f..."
Doubt implementations would be done by then tbh
00:59:25
Barnabas Busa:Replying to "whats the deadline f..."
I’m not talking about implementations
00:59:38
Barnabas Busa:Replying to "whats the deadline f..."
I’m talking about having a strict list of things that we will or will not include
00:59:45
stokes:Replying to "whats the deadline f..."
Impl progress will inform what makes sense to SFI tho
01:00:08
stokes:Replying to "whats the deadline f..."
t having a strict list of things that we will or will not include
This is SFI
01:00:16
Barnabas Busa:Replying to "whats the deadline f..."
if its a small thing to implement then it shouldn’t be hard to do by end of the month
01:00:18
stokes:Replying to "whats the deadline f..."
And then we must be very careful moving things from CFI to SFI
01:00:26
Danno Ferrin | Ipsilon:I like it, but of course that may be because I’m a co-author.
01:00:27
Barnabas Busa:Replying to "whats the deadline f..."
if its a complicated thing to implement it shouldn’t be in fusaka
01:00:49
stokes:Replying to "whats the deadline f..."
Id rather everyone focus on peerdas/eof in stable devnet-0 before thinking about other EIPs
01:00:54
Guillaume:small fork
01:00:58
Parithosh Jayanthi:Replying to "whats the deadline f..."
More than complicated, its just bandwidth to work on another thing
01:00:59
Lin Oshitani | Nethermind:I'd like to discuss EIP-7917, we didn't reach a conclusion in the last CL call: https://eips.ethereum.org/EIPS/eip-7917
01:01:06
Parithosh Jayanthi:Replying to "whats the deadline f..."
If teams have time, they should work on eof/peerdas first
01:01:09
rodiazet | Ipsilon:Next one will be small….
01:01:20
Potuz:@Anders Elowsson when you imlpement this I'd set it differently though, set a new function `F` instead of `TX_BASE_COST`, that can be just the identity `F = TX_BASE_COST` but so that we can trivially update this in the spec to any higher function if this limit is too small, same as with Max's PR, it can trivially be adjusted in the future if the limits become trivial.
01:01:32
Mario Vega:Can be added to EOF later ?
01:01:43
Potuz:Replying to "small fork"
yeah WTF, I really want 7732
01:01:46
Charles C:Replying to "I think the rule i..."
am i understand that we can get EIPs included by having babies?
01:02:36
Piotr | Ipsilon:EIP-7819 sounds like it can be added to EOFv1 later (new opcode). No need to bump version
01:03:33
Potuz:+1 for Tim's point, this is starting to look again like Pectra v2, and then I'll want 7732 since all these additions will delay the fork anyway
01:03:56
stokes:Peerdas EOF
01:03:59
stokes:Focus on these
01:04:51
Parithosh Jayanthi:^ by then teams should have a handle of the other CFI-ed EIPs are manageable to implement quickly or not. If not, we really shouldn’t SFI anything beyond peerdas + eof
01:05:18
Toni Wahrstätter:Gas limit Info EIP like the hardware specs
01:05:22
ethDreamer (Mark):Did we already CFI BPO forks on the execution side?
https://eips.ethereum.org/EIPS/eip-7892
01:05:40
stokes:Replying to "Did we already CFI B..."
It was CFI’d last call
01:05:53
stokes:Replying to "Did we already CFI B..."
You could raise here
01:06:02
stokes:Replying to "Did we already CFI B..."
But I don’t think there are issues w/ that one
01:06:07
Marius:Blob per tx limit: yes
01:06:23
Tim Beiko:Replying to "Did we already CFI B..."
Oh it was! Sorry, didn’t see the draft PR!
01:06:25
Justin Traglia:I’d also like a limit
01:06:25
Marius:yes
01:06:27
stokes:Replying to "Blob per tx limit: y..."
Does it need to be in-protocol?
01:06:33
Ansgar Dietrichs:happy to have a limit, if so we should have it in fusaka though
01:06:40
Ansgar Dietrichs:Replying to "happy to have a limi..."
can always be removed later
01:06:51
Ansgar Dietrichs:Replying to "happy to have a limi..."
could be part of peerdas eip
01:06:57
stokes:Replying to "Did we already CFI B..."
https://github.com/ethereum/EIPs/pull/9603
01:07:07
Anders Elowsson:Is it possible to have a limit that adjusts with the target, I.e., max(8, target // 8) ?
01:07:08
Kevaundray Wedderburn:@Anders Elowsson Will your EIP need to changed if we add blobs per tx limit?
01:07:17
Potuz:yeah this was just an omission in PeerDAS
01:07:24
Carl Beekhuizen:in case we want to change the limit later, i think it’s cleaner to have a limit in its own EIP
01:07:30
Anders Elowsson:Replying to "@Anders Elowsson Wil..."
Yes, I mention this in a twitter thread today
01:07:33
ethDreamer (Mark):Replying to "I think the rule is ..."
Only if ACD gets to name it
01:07:47
Tim Beiko:Replying to "in case we want to c..."
Agreed
01:07:58
Potuz:Replying to "in case we want to c..."
Why so? we can simply change a parameter in the spec?
01:08:13
Tim Beiko:Replying to "in case we want to c..."
“Change a parameter in the spec” should require an EIP IMO
01:08:18
Toni Wahrstätter:This is the equivalent of what we just CFI'd with the tx gas limit max
01:08:18
Tim Beiko:Replying to "in case we want to c..."
The issuance is “a parameter in the spec"
01:08:20
Tim Beiko:Replying to "in case we want to c..."
😄
01:08:27
Francesco:I think it’s more critical to have it be a mempool restriction, but would also favour a general restriction to simplify packing
01:08:29
Anders Elowsson:Replying to "@Anders Elowsson Wil..."
https://x.com/weboftrees/status/1910313154392817971
01:08:49
Potuz:Replying to "in case we want to c..."
yeah changing in a subsequent fork will need an EIP, but not in this one cause can be (and should have been) part of PeerDAS
01:09:28
Potuz:That's not a blob only update then
01:10:04
stokes:Are we talking about the (target, max) limits or a per-txn blob limit?
01:10:43
Kevaundray Wedderburn:Replying to "Are we talking about..."
This is per transaction
01:10:59
FLCL:you can increase it and decrease, omit when it fully scalable
01:11:37
Carl Beekhuizen:Replying to "in case we want to c…"
if we do change the limit, we can have a nice clean EIP that says this supersedes (and deprecates) this other one. i also think it’s easier to reason about as it doesn’t look like we have PeerDAS except for this one constant which is now no longer true
01:11:50
Marius:Replying to "i'd like to discus..."
Charles said: i would disagree since it doesn't just change the relative pricing of the opcode, it fundamentally changes how memory is used (he got kicked off)
01:11:50
stokes:Replying to "Did we already CFI B..."
Left as draft bc we may add another CL EIP to CFI on next ACDC
01:13:45
lightclient:didn’t v post this idea before?
01:13:58
Potuz:It would be nice to have a presentation *before* we get to the Glamsterdam discussions
01:14:00
lightclient:so not like it’s completely new
01:15:37
Charles C:Replying to "didn’t v post thi..."
there's been a couple EIPs in the same vein
01:15:45
Ansgar Dietrichs:also to be clear, we should not have any strong pre-commitments about what should be in Glamsterdam. I know we have many people with strong opinions about what should be in there (me included), but it’s important that the understanding is that that is tbd
01:16:37
Marius:Etan not here?
01:16:38
Potuz:There isn't any strong precommitment to anything here, ask @Guillaume otherwise
01:16:50
Potuz:Danno could write a thesis about this
01:16:56
Marius:Replying to "Etan not here?"
Haven't heard ssz mentioned yet
01:17:22
Guillaume:yeah, promises are to be forgotten the next day
01:18:00
Ansgar Dietrichs:Replying to "There isn't any stro..."
well, peerDAS and EOF were kind of decided for Fusaka before the main Fusaka inclusion discussion
01:18:10
Ansgar Dietrichs:Replying to "There isn't any stro..."
(ofc we then decided to revisit that EOF decision)
01:18:18
Marius:I thought we did both modexp eips?
01:18:26
Potuz:Replying to "There isn't any stro..."
They were decided for Pectra
01:18:40
Ansgar Dietrichs:Replying to "There isn't any stro..."
well yes, but then grandfathered into Fusaka when we did that split
01:18:47
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7823
01:19:00
stokes:Replying to "Etan not here?"
There wasn’t much interest from last week’s ACDC
01:19:05
Ahmad Bitar | Nethermind:Agreed, we are in support of this
01:19:08
stokes:Replying to "Etan not here?"
Have next week to finalize CFI list
01:19:16
Marius:üIn support as well
01:19:39
Marius:Damn it can be so efficient! Well done Tim
01:19:56
Tim Beiko:https://ethereum-magicians.org/t/reconfiguring-allcoredevs/23370
01:20:20
Barnabas Busa:glamsterdam planning wen?
01:21:09
Guillaume:Replying to "glamsterdam planning..."
when you have shipped Pectra 😁
01:22:02
Danno Ferrin | Ipsilon:Replying to "glamsterdam planning..."
When we understand the path to 100M gas, then we will know our available capacity.
01:22:36
Parithosh Jayanthi:Any big contentious decisions would still be brought to ACDC/ACDE since more people attend them atm
01:22:37
Potuz:We should CFI less EIPs then
01:22:56
Potuz:It'll be impossible to avoid Fusaka's calls here
01:23:17
stokes:We can streamline better on the margin though
01:23:51
Kolby ML:Aren't Etan's SSZ EIP's mostly on the EL side?
01:23:52
Danno Ferrin | Ipsilon:Replying to "glamsterdam planning..."
My quick analysis is there will be some glamsterdam changes needed for gigagas, so that will drive some of glamsterdam.
01:24:42
Potuz:oh why not?
01:25:04
Marius:(if we find that an EIP is broken on the testing call, we will still discuss it in ACDE/ACDC)
01:25:06
Kolby ML:Replying to "Etan not here?"
So they are more applicable to ACDE
01:25:13
Parithosh Jayanthi:Imagine stuff like PRs that make a decision about a CFI/SFI-ed topic, its mostly the type of PRs people want to raise before merging
01:25:16
Tim Beiko:Replying to "(if we find that an ..."
Majorly broken yes 😄
01:26:05
Potuz:I like the idea, and I think it'll streamline better the forks
01:26:14
stokes:Replying to "Etan not here?"
AFAIK it is just adding minimal stable container functionality
01:26:17
Ben Adams:Are also breakouts for features
01:26:25
stokes:Replying to "Etan not here?"
There’s no push for the ssz-ification of the EL AFAIK
01:26:36
Potuz:I don't expect 80 people in that call, it'll be implementers mostly
01:26:49
Danno Ferrin | Ipsilon:My take: we need to pipeline ACD to ship faster, that’s what this plan starts doing. ACDT is what is shipping, ACD{E|C} is planing what may be shipping.
01:26:54
Marius:Replying to "Are also breakouts..."
Breakouts will continue until morale improves
01:26:55
Parithosh Jayanthi:Yes, like 30-50 people would need to attend ACDT, its probably noise for the rest
01:27:05
Tim Beiko:Replying to "Yes, like 30-50 peop..."
But how many would want 😄 ?
01:27:48
Trent:I can go right at the end
01:27:54
Łukasz Rozmej:We need to hire someone to attend all the calls :P
01:28:02
ethDreamer (Mark):<3
01:28:07
ethDreamer (Mark):Love that
01:28:09
lightclient:too many calls
01:28:22
Łukasz Rozmej:CallOverflowException ;)
01:28:25
stokes:Replying to "too many calls"
Have you heard about agents? ;)
01:28:26
Danno Ferrin | Ipsilon:Replying to "We need to hire some..."
Middle managers are created, not born.
01:28:41
Parithosh Jayanthi:Replying to "too many calls"
Skip acd, they have more time to bikeshed
01:28:43
Ansgar Dietrichs:Replying to "too many calls"
isn’t it the other way around? more specialized, not everyone having to attend everyhting
01:28:45
Parithosh Jayanthi:Replying to "too many calls"
Join the trenches call
01:29:24
Łukasz Rozmej:Replying to "too many calls"
AI drived core dev calls trained on team posiotions?
01:29:41
Phil Ngo:Replying to "too many calls"
ACD(T) = ACD Trenches?
01:29:51
Parithosh Jayanthi:Replying to "too many calls"
Yessir, non-canonical name 😛
01:29:54
Ivan Metrikin:Great initiative, Tim
01:30:41
Ansgar Dietrichs:“the deadline is April 28” - I still have a tab open for filling out the merge retrospective...
01:31:05
nixo:Replying to "“the deadline is Apr..."
will make sure to bug Ansgar specifically
01:31:15
Barnabas Busa:Replying to "“the deadline is Apr..."
good thing he didn’t mention which year april 28
01:31:25
Ansgar Dietrichs:Replying to "“the deadline is Apr..."
ah wait no that’s the “Dencun Diary”