All Core Devs - Execution #228

Transcript

Ansgar Dietrichs: Hello, hello everyone. Can you hear me well?

Justin Florentine: Good morning, Ethereum, we can hear ya!

Ansgar Dietrichs: Well, good morning, Justin, to you, too. Yeah, let's wait, like, one more minute, but I've gotten the request to maybe, in the future, start kind of sharper on time. So… yeah, maybe for today we wait just a little longer again, but then possibly starting on next ACDE, we might… Get going quicker. Okay, I think we can go live.

Josh Davis: You are alive.

Ansgar Dietrichs: Perfect. Hello, everyone. Welcome to AllCoreDevs Call 228. I'll put the link to the agenda in the chat. Basically for today, two main topics. One is the, DevNets, Glamsterdam DevNets, specifically DevNet2Scope, and then some clarifications to related EIPs. And then afterwards, hopefully, we, we'll be able to finish the, Glamsterdam PFI decisions today. To get started, for DevNet 2, specifically, so there was a preliminary decision made on DevNet2's scope on ACDT this Monday, but then my understanding is there was some conversation afterwards about whether maybe that scope was too broad, Whether that… whether it would make sense to revisit that. So, do we… do we have anyone with context on this decision and the current status of the thinking there on the call that could give a summary?

Stefan Starflinger: Yeah, I could give a quick summary. In general, it seems that we need to change something in the CL for this change, and that's why there was some, kind of discussion if we should even include it, because having changes in the EL and the CL, so the goal was just to have changes in the EL, might be a little bit, too much, so there was some discussion about that. It would be great to hear quickly from clients how they feel about it, but from my perspective, it seems it would be nice to include it. It's only, I think, a small change set. And I think it shouldn't be such a big blocker. But from Lodestar right now, we don't have anyone, I think, that can speak about that. I think we will… from the Lodestar side, we can make a discussion on Monday when someone will be back from holiday. That's pretty much the context.

Ansgar Dietrichs: Sounds good. And just to clarify, this is about the slot numb code specifically, is this right?

Stefan Starflinger: Yeah, EIP7843.

Ansgar Dietrichs: Sounds good. Yeah, I do think, I mean, in principle, I'm not… I'm not sure how the EL clients feel about this in general. It seems to me like it would be nice if we could kind of agree on the scope of DevNet2. Kind of today, not just next week. Of course, unless… so, so, so, do we have client teams with an opinion, A, on, like, do we want to make, this decision today, and then… Whether they would want to… Yeah, remove the slot number up code from Devon 2.

Carl Beekhuizen: Admin. You're unmuted.

Ansgar Dietrichs: Was there someone from the big group? In the camera that wants to say something, or was this accidental?

Carl Beekhuizen: No, sorry, we're just technologically illiterate. Mostly me.

Ansgar Dietrichs: In a voice.

Stefan Starflinger: I mean, otherwise, we can also just decide on Monday if, There's no one wants to talk now about it.

Ansgar Dietrichs: Yeah, I mean, in principle, like, I was trying to monetize with timeboxes anyway, if there's no urgency on this discussion, which I thought there might be, but now that no one's speaking up, it seems like maybe there's no urgency, then I would propose we just… make, kind of, like, the final DevW2 scoping decisions on ACDT next Monday. But of course, it's good to pilot this today, so people are aware that's when that will happen. Is that okay with everyone? I'll just wait for any protest? Okay, but then we do… then let's just not today touch the scoping discussion itself, but we do have a few EIP clarification requests, or otherwise kind of just topics around the EIPs that came up, four in total.

I'll just go through them one by one. So the first one was… on the EIP-7778, lock us accounting without refunds, there is… A request for clarifications… On cumulative gas used, gas used for paying, gas used for block limit. I think the comment… Was by Andrew, on the issue. Is Andrew, are you on the call, or Tony, do you have… Context on this?

Andrew Ashikhmin: Yeah, I'm on the call. Basically, as I wrote on Discord, At least, So, is it 7778 or 80-22?

Ansgar Dietrichs: Mayor 7778.

Andrew Ashikhmin: Yeah, okay, so… Yeah, at least in Erigon… The assumption that the cumulative gas used in receipts actually corresponds to block gas limit counting is in so many places that it will be very difficult to change it. So I suggest to keep that, that assumption. Otherwise, yeah, it will be a massive change, and very bug-prone. So that's a change that I proposed to the spec, and there is also a clarification needed Because it underspecies the overplay between, 77-78 and, 76, 23, but I think, yeah, maybe Tony can comment on that.

Ansgar Dietrichs: Tony?

Toni Wahrstätter: That's a good point. I actually, I actually had a PR Today, so this is something we clarified today in the execution specs. And… just to… to ask you, Andrew, you were saying you want the… The block gas accounting should include the transaction costs before the refunds, after the refunds, sorry. So you want the receipts to include The gas used after the refunds, am I correct here?

Andrew Ashikhmin: No, no, no, so… The, it should be, like… Okay, so in 7778, you have this, this, Gas used for block accounting, right? Number 2, which… which does not contain refunds, right? So, I want cumulative gas used in receipts to be consistent with, with block gas accounting, not user gas costs.

Toni Wahrstätter: Okay, yeah, this is… this is exactly what we clarified in the last PR, so it should be fine now.

Andrew Ashikhmin: Please, take a look and let me know.

Toni Wahrstätter: Because previously it said the receipts should include the gas used the gas used after the refunds, but the receipts only include the cumulative gas used. So the question is. What do we want to add to the cumulative gaseous? Should we add the gaseous pre-refund or after refund? And…

Andrew Ashikhmin: Do we need to use it to edit?

Toni Wahrstätter: So it makes sense to, add the… gas used, Pre-refund in order such that we can use the cumulative gas used to enforce the block gas limit.

Andrew Ashikhmin: Yeah, I don't know, I don't know whether we need to add the gas used before refund, maybe it's useful, but I guess if there is no big ask for it, we can just skip it. But I don't know.

Ansgar Dietrichs: Okay, is this something that, then, beyond this, we can take offline, or would we have to make a decision here further today?

Toni Wahrstätter: No, I think we can take it async. Let's have a chat under the PR I posted. I think that's the best place where we can discuss that further.

Ansgar Dietrichs: Sounds good. Then, I'll move to the next EIP. That is, EIP 8024, so the swap and dupe and exchange opcodes. There was also an… a comment by Andrew, about, clarification, basically what happens if the code ends, right, right before an, immediate operand. And then there was also separately from… drag on a proposal to potentially simplify the EIP, so, Yeah, Andrew, do you want to give a comment on a clarification on your question first?

Andrew Ashikhmin: Yes, so the, this EIP was, underspecified. I looked at the implementation in GAS, and there it treated that case when, when, The immediate operand was on the code's end as an error. And it's not what push 1 does, so my suggestion is to do it consistently with push 1. I treat the value of the operand as 0. I mean, I don't care much. I just have a slight preference for com… for consistency, but in any case, it should be specified in the EIP. I think there is a PR to the EIP to… Treat the operand value as zero in such case.

Ansgar Dietrichs: Okay, do we have anyone on the call? I see one raised hand. Is this… is this about this topic, or… EIP question?

Francisco Giordano: Yeah, about this. So just, I want to give some context. So first on the… on the zero padding, yeah, this is the PR. I'm already changing it to be, like, push, which makes sense. And on Dragon's question, the… there… the EIP currently… So, in order to, to work with, jump dest analysis. The EIP is currently designed in a way that the immediate has to avoid using the jump test opcode as a part of its immediate, or the push opcodes as a part of its immediate. And because this leaves a gap in the range available for the immediate. There needs to be an encoding and decoding step, which… is relatively simple, but also relatively complex, and so Dragon's, suggestion is to instead use, another approach which, adds, like, a… is encoded in a way that you go, like.

you put the swap-in opcode, and then you follow it by the push one opcode, and only then you put the immediate… but the push is not really an instruction, there is just part of the broader instruction encoding. All of this is explained in the Ethereum Magicians post that I shared on the chat. There are the two options there. And I don't think anybody has very strong opinions about what to choose, so we just have to make a choice, and so it would be good to know what others feel here is, the best choice. I will just say, I think the trade-off is Slightly or marginally more compute versus, being less efficient in terms of bytecode size, obviously, because one is a 2-byte encoding versus a 3-byte encoding.

But, to be frank, this is also an instruction that is not going to be extremely frequent, so it's, you can also argue that the bytecode size impact is not going to be so much.

Ansgar Dietrichs: And, yeah, try them.

Dragan Rakita: The only stance that we have strong… that we have strong stance is DCIP needs to be included. So, first or second version, it doesn't matter a lot. In my opinion, second version, having opcode, push to, and bytes is a lot more simple, and something that we could like to. But yeah, that's… this… this was not even my idea, this was, like, idea for, like, 2 years ago, and just bring… bringing it back.

Ansgar Dietrichs: I see. And, I would assume that the timing on this decision, like, that it's relatively urgent to decide this, given that this is potentially, or, like, for now, scheduled for DevNet 2, and I guess it would not be ideal if we implement it one way and then have to implement it a different way for DevNet 3 and forward. So…

Dragan Rakita: I would like… I would like to hear others just commenting on that now, or as async. It should be, like, simplest decision, but we need, like, input from other clients, not just threats.

Ansgar Dietrichs: That's good. Do we have any clients right now on the call that have a take on this? Yes? Can you?

Daniel Lehrner: Yeah, so I implemented it on the basis side, how it is specified in the EIP right now, and I mean, the logic is okay. So, I mean, this decoding logic is a bit… unusual, but I don't think it's that complex. But if we have to change it, I don't think there's any issue from our side. So, as long… as long as the EIP goes in, we are fine. So, we don't have any strong opinions, I would say.

Ansgar Dietrichs: Makes sense. Anyone else? Otherwise, maybe question for, Dragan and Francesco, where would the best place be for people to, like, come and comment to make that decision, say, in the next days? Asynchronously? Is this the Discord? Is this the Ether Magicians? Like, where would be the best place? Yeah, Ben, maybe before?

Ben Adams: So, one of them changes jump desk analysis, and the other doesn't, is that correct?

Francisco Giordano: No, none of them do.

Dragan Rakita: Depends how you do jump test analysis. Depends if you're basically asking, if you're searching job destination, or you're searching the immediate. I didn't get, thoughts a little bit different.

Ansgar Dietrichs: Yeah. So then, I guess, back to the question of where the best forum is for the decision?

Francisco Giordano: Wherever people want to leave their opinion, I'm monitoring Discord, but also the Ethereum Magicians forum from the EIP works.

Ansgar Dietrichs: And would it be reasonable to say that a decision, at least for, like, DevNet 2, would be made by Monday, Monday ACDT? Because I guess that would be nice for people implementing this?

Francisco Giordano: Yeah, I think that makes sense, and maybe if no decision is made, we just go with the current one.

Ansgar Dietrichs: Sounds good. So then, I guess, ask for our clients, do have a look, and if you have an opinion, or I guess even if you're fine with either, then just leave that as a comment. Somewhere where the comment can easily be found. Okay, thank you. Then, I'll move on again. We have quite a bit to get through. The next topic, was… the last EIP clarification was… EIP7708, so this is ETH transfers emitting a log. My understanding is that there is a pending PR and some open questions. I'm not sure if the questions are answered in the PR, or, like, they're specifically not yet answered in the PR, but there was a comment by Spencer, on… on the agenda. Are you on the call, or does anyone else have context on that, Pierre?

Spencer Taylor-Brown: Hey, yeah, I, yeah, just wanted to give that PR some more love, I think, it feels like everyone's in agreement, but I think some more eyes just to… Determine if we're happy with the log address and the first topic value. And then also, if he wants to include… The payment logs. On top of these transfer logs. And more of a, can we get this motion to respect sooner rather than later? clarification.

Ansgar Dietrichs: Sounds good.

Spencer Taylor-Brown: Definitely, I guess I'd also like to ask if we're going to finalize the scope for DevNet 2 next Monday. We're DevNet 2 scheduled on Wednesday, should we push? 7 at 2 forwards.

Ansgar Dietrichs: That's a reasonable question. Do we have… I'm not sure exactly who is in charge of demo coordination, like, do we have.

Stefan Starflinger: Sorry, I didn't catch that.

Spencer Taylor-Brown: It just feels…

Ansgar Dietrichs: And so what's.

Spencer Taylor-Brown: So, a general question, if we should push Devin at 2 forward, if we're going to finalize this group next Monday. Maybe, the 28th instead of the 21st? It gives us an extra…

Stefan Starflinger: Yeah, I think we can, see how far we are on Monday, and then decide on a date.

Daniel Lehrner: I think we don't even have the execution tests yet, no? I mean, before those aren't finished, we can't really start the definite. Because we cannot properly test everything.

Spencer Taylor-Brown: Yeah, and I guess before we have the test out, we kind of need to finalize the specs.

Daniel Lehrner: Yeah.

Stefan Starflinger: Yeah, I think what would be good is just to get everything ready for DevNet 2, as far as we can. I think I will leave DevNet 1 running a little bit longer, so that we can still target that, because the testing setup there is already ready. And we can do the benchmarking there, would be my suggestion, and then develop all the new EIPs on top of DevNet 2. And try to get everything ready there, and we should finalize everything on Monday, what exactly we're going to, that's not too.

Ansgar Dietrichs: Sounds good. So, is that a good place to leave it at for now? And then come back on ACDT on Monday?

Spencer Taylor-Brown: Yeah, that's good.

Ansgar Dietrichs: Awesome, sounds good. Then, you know, also same thing on, like, the EIP that's been… sorry, the PR that's been mentioned since 2008, the ETH transfers one, yeah, clients that might have an opinion, haven't looked yet, do have a look. And then, presumably on Monday, by Monday, this would be… finalized. Okay. Then, any last comments? Anyone that still wanted to bring anything up regarding the DevNets? Otherwise, we would move on to the Glamsterdam PFI decisions, the outstanding ones? Okay, then let's move on. we have, only a few EMPs left, I listed them all, with Nixu's help, and Nixu listed them all in the, agenda for the call, but we also still have this document, where they're categorized in different categories. I'm not sure there was some issue with the

website earlier today? Is it currently working? Perfect, okay. Thank you, thank you very much, Josh. M… Okay, so we… then we can, we can go through them. Specifically, one EIP that we've been postponing for a while now, that is ready now for… for a… Decision is EIP 8037. So you can see it there on the state growth section, so specifically, that's basically the… question of how, like, the choice of approach for the repricings of state growth, specifically. And, I think Marius had a brief presentation prepared for For this, Marius, are you on the call? Actually, then, we would have to switch screen sharing, actually.

Marius van der Wijden: Can you guys hear me alright?

Ansgar Dietrichs: A bit quiet, but we can hear you.

Marius van der Wijden: Okay, I tried to scream. Yes, 1837…

Trent Van Epps: You're very quiet, if you can move any closer. To the mic, or something.

Marius van der Wijden: I'm as close to the mic as I can be. I'll just try to scream. Basically, 1837, the state creation gas cost increase. It has multiple different, goals. makes state growth, Dependent on the gas limit, so that whenever we increase the gas limit, we also increase the cost for creating new state. And this is very important, because if we, like, 10x the gas limit… We also want to 10X how… we don't want to 10x the amount of state that we are… that can be created in this… in this gas limit. We want the state Increase to be kind of constant, and we want a target of Roughly 100GB per year, and this can be, changed. for this to happen, we need to measure state growth on a different axis than normal computation, and another thing that this EIP wants to do is wants to harmonize state creation across all operations. As you can see here, it is very different

Like, creating one byte of state is very different across the different operations that we have. So, the block gas limit. What we want to do is make the state growth dependent on the block gas limit, And in the last line, you see a formula for this. And basically, small changes in the gas limit are smoothed out. Otherwise, every time we would increase the gas limit, this would require repricings. What this means, though, is that the intrinsic gas is now dependent on the block gas limit. This means the transaction pools will need to, change slightly, so every time this cost per byte changes, we have… we would have to recheck the intrinsic gas, To see if these… if the transaction is still occludable.

But, there might be a different, like, we might, change this formula a bit. To smooth out the gas limit changes even more. So, you would only need to recheck if the gas limit changes pretty drastically. And in addition to this, we will also need to introduce multidimensional metering. But this is not multidimensional. gas. This is very different, but we would, need to measure the state growth and a different exist than compute. And, so we can adjust them independently. If we didn't do this, if we wanted to curb the state growth, that would, have the result that big contracts would be impossible to, to be created in the 60… megacity, transaction limit. So let's… Go through the concrete implementation.

The gas… In this… in this new world is the minimum of the gas limit and 60 million. gas. The gas limit can be much bigger than 60 million gas. Every… everything that is bigger than the 60 million gas is added to the state gas budget. And now, if you create state… You first check the state gas budget, and only the normal gas later. And then all of the normal operations will charge to gas. As usual, and that means that, at maximum, a transaction will execute 16 megas of burst resources. as much as it pays for state growth. And, this also means off-heat gas will just work normally. Why is this important? The burst resources need to still be unaffected, so we can have the 16 megas gas limit.

Not for the execution. So, result of this is all state operations will be split into gas costs and state gas costs. So, for example, the S-store operation now charges 2,100, the cold S-load cost to gas. And this cost, which is dependent on the gas limit, to storage gas. So… Why do we need this? We need this, otherwise we cannot increase the gas limit, because every time we would increase the gas limit, we would need to reprise all of the storage operations. Measuring the state growth separately allows us to adjust the limits. And, We allow to limit execution to $16 million, and unlocking higher state growth by making state growth itself more expensive. And the changes are pretty limited to the EVM. I've implemented this yesterday and today in roughly 4 hours combined.

The… the… The heavy lifting, Or, like… people's, There will be changes to the way we test, so testing is a bit affected, and block Creation, block building is a bit affected. But, all of those changes are… Quite small for… compared to the gain that we can have with this. In, in, in, in, in the amount of, And the amount of compute, increase that we can do while keeping the state basically on a separate axis. Yes, that's it. Questions?

Andrew Ashikhmin: None. Well, so, my initial impression is that it's hacky, and we should go for proper multidimensional gas. And, like, if we try to squeeze it in, into Glamsterdam, we'll repeat the same mistake as we did with Pectra. like, it's… we were too greedy, and we had to split the hard fork in two. So, to me, like, a proper version of this, without the… all the hacks. like, proper version of introducing a new dimension to the gas. It sounds like a good headliner for the next hard fork, but yeah, I just, again, I'm just seeing, like, this is the same Pectra story repeating again. I, like, we implemented it in 4 hours. I think it's optimistic and heroic, and there will be implications that are far-fetched.

Maria Silva: I'm sorry, Andrew, can you explain a bit more why you think this is hacky? Because this seems to be to be… Very compatible with, like… The full multidimensional metering, where you just meter every resource independently.

Andrew Ashikhmin: Then maybe we should then do it. We already have blob gas, right? So why don't we have… why don't we do it properly, and have state gas and so on? Rather than, like, pretend that it's not introducing a new dimension, but, like, kind of is introducing and is not, that just sounds to me a bit, strange and inconsistent.

Maria Silva: I would say the only difference here is that BlockCas has its own fee, and we are not yet doing the independent fees, right? Like, the state.

Andrew Ashikhmin: Yeah.

Maria Silva: creation gas is still charged on the main fee, but we are introducing an internal counter that is metering state creation costs independently. So I don't see how That's different.

Andrew Ashikhmin: But maybe we should introduce, like, an independent fee.

Maria Silva: Right, but so… that is a bigger change than just doing metering. So it's… you need metering to do the pricing, right, to update the fees, so you would have to do metering anyway. But just doing metering is simpler and already gives us big benefits. But if you wanted to do, for instance, multidimensional pricing in H-star. We still could do it and use the stuff we are implementing now in multidimensional metering. So they are completely compatible, it's just we don't need to do them all in the same step. And just doing metering already gives us huge cadence in scalability.

Andrew Ashikhmin: Okay, maybe. Just, okay, my initial impression is just we are trying, like, for tactical reasons, we are trying to… we are introducing unnecessary complexity to the protocol instead of a more, kind of elegant and comprehensive solution. But again, it's my first impression. I might be wrong.

Ansgar Dietrichs: Yeah, one… maybe from my… one comment from my side is just that I think it's important to keep in mind… I, in principle, agree with some of these worries about Glamsterdam scope. The problem is just that really the vast majority of Glamsterdam EIPs that we have, including both headliners, are focused on enabling a higher gas limit, and I think we are on track to actually being able to achieve quite a bit of a gas limit increase. I'm very excited about that. But all of this is basically blocked if we do not have any adjustment to limiting state growth. I think my understanding is currently, as of, like, today, we're basically at a roughly 100GB state growth rate.

annualized, and that is without any increases. We might even be able to get a little bit of a further gas increase before Amsterdam, so basically we would arrive at Amsterdam and then be blocked from actually making use of any of the changes we ship, if we don't have anything to address the, the state growth concerns. So while I, yeah, I think the concerns are very valid, but I do think, yeah, we need to discuss, like, if we do not want to go with this proposed change, what else are we doing about state growth? to actually be able to use all of the other changes that are coming with Glamsterdam.

Marius van der Wijden: So, I… I was also kind of… against this change when I… when I started? And, implementation, I kind of realized that this is really not such a big deal, and it seems to me to be, like, the optimal solution, given the trade-offs that we have.

Ansgar Dietrichs: them down. You had your hand raised? On off? Okay, right. I do think it's not ideal, of course, this kind of the specific proposed, shape is coming on the call, where we ideally would already want to make the decision. At the same time, I would also be very sad if we leave today's call while still not having finalized at least the CFI decisions. how do clients overall feel about this? Do we feel ready? Do we feel in… that we have the information to make this decision now? Where… what are people leaning towards? Maybe I can just call on I mean, I'm not sure, Marius, how much you've coordinated with the rest of GATH. Are you… how much… are you speaking for the GATT team versus just your own personal opinion? Do we have anyone else from the GATH team on the call that could comment as well?

Felix Lange: Yeah, I can give a quick comment. So, I do think that the direction laid out is, like, a good one. I vastly prefer this solution to actual multidimensional gas, because I always felt that the… True multi-dimensional gas accounting has a lot of challenges that we were never really able to resolve in theory, so this seems to be Something that is actually possible. And so, yeah, I would say… I could get behind this.

Ansgar Dietrichs: We have anyone from… Nethermind on the call? Dennis? A view on this?

marek: So, from my side, I really like, gas metering proposed by Maria.

Ansgar Dietrichs: Do you prefer… talking about the full gas metering that, I think we decided to, for now, GFI for Glamsterdam, or are you talking about this, like, smaller version? Maris just presented.

marek: Smaller version.

Ansgar Dietrichs: I see. Okay. From the baseu side, I think we just… At an attempt at a hand raised?

Justin Florentine: Yeah, I think, we might need a little bit of time. I think we're a little torn between the difference between the multidimensional… a full-blown multidimensional approach and metering, only because… You know, when things go in, they don't come out, right? So we need to think about that.

Ansgar Dietrichs: And does that specifically mean, that you'd prefer to not make the decision today?

Justin Florentine: I think that means we are unprepared to contribute to the decision today.

Carl Beekhuizen: Maybe, yeah, I mean, I think, to make, kind of, the decision clearer, I would, like, just propose what the, yeah. what possible, alternative is, and it would be, basically a bare-bones EIP that increases the, gas, like, the state creation costs. Probably for contracts, the number I had was from $200,000 going to $300, for new storage slots from 20,000 to, 80,000, and for creating new accounts from, 25,000 to $100,000. And, the, idea is basically that, like, this would go in, and, this would be, either sufficient or somewhat, or a little bit uncomfortable for the next year, but then, So I think, like, if you want maximum simplicity for Glanster Dam, like, as you crank that goal up to infinity, like, you basically approach having to do this.

But, the long-term picture of this is, like, I think importance to think about, right? Which is that, like, keeping code mostly out of the increases, which is necessary to allow deployments within 16 million, is, something that, like. we'd eventually have to fix, and in general, the… it feels like the way that things are growing is that, like, the ratio between ex… how much we can scale execution and how much we can scale states dies, it would… it will, in the long-term future, possibly be a factor of 10, or even a factor of, like, 30 different from, what it was at the beginning. And so, like, basically, yeah, gas costs, would, have to change quite a bit, and and so, like, a gas policy increase ultimately would likely kick the can down the road, and so, realistically, yeah, it would basically mean, you know, like, either…

Multidimensional in something, eventually. Or it would mean that we, yeah, like, create a completely different facility for creating big contracts and, like, basically deprecate and break the existing functionality eventually, right? So, I think, like, that's the, like, basically the alternative path to, like, doing something like this now.

Ansgar Dietrichs: Right. And just to basically make that So basically, like, for people who are maybe not super deep into this topic, so… Yeah, the idea could be we basically, like, completely remove the multidimensional metering aspect of it, and then we either have a fixed repricing or a repricing that is still relative to the gas limit, but no kind of no separate tracking of the state creation gas and all these things. The main, kind of, like. Downside there is that if we still want to allow for maximum size contract deployments within a 16 million transaction, we basically have a very sharp limit on how much we can increase the price for state… for contract deployments, and so it would mean that we end up in a world where contract deployments are basically, say, four times cheaper than all other ways of creating, state.

Which means if someone wants to, they can basically just, or if, say, for example, there's… yeah, there's some reason why average use case patterns on Ethereum Switch more towards contract deployments. state growth could be at a very high rate, for a couple months at least, until we get to a more proper solution in H-star. If we're willing to take that trade-off, that would be a simpler option. Maria?

Maria Silva: Yeah, I just would like to add, like, this thing of doing, like, a proper solution on HTAR, I just want to clarify that, actually, it wouldn't be a very different proposal from what we have right now. I think What we have right now is, like, the minimum change in the EVM that would allow us to meet their state growth independently from the other resources, which I think it's something we'll want to do at some point in the future, but this step, even if you do more stuff on top of it, this small step will have to do it anyways. So the question is, like, do we have scope for doing it now? Or do we push it forward? Knowing that doing it now, it actually brings a lot of benefits in terms of scalability and making sure that contract deployments don't get too cheap in relation to all the other state creation operations.

Ansgar Dietrichs: Sounds good. So the three options that I… see for today that we could decide is the EIP as proposed by Marius. or a static repricing, as proposed by Vitalik, with the understanding that basically, yeah, we are somewhat you know, have this risk of somewhat higher state growth for a while because of contracts, or a variant of what Vitalik proposed, but basically still with this relative pricing to the gas limit. So, just kind of, just taking out the metering. Again, would be nice to make a decision today, Yeah, after listening to these different proposed solutions, do we have more client team opinions? Ben?

Ben Adams: Yeah, for some more consideration time. This just presented today, and… So it's the… New alternative?

Ansgar Dietrichs: If we wanted to have more consideration time, the next ACDE would be in 2 weeks. Is there any way for us to make a decision on a faster timeline on this? How much, like, what is a reasonable amount of time for clients to look into this?

Ben Adams: ACBT? I mean, I don't… I don't think it needs 2 weeks to think about. I like my nostal.

Ansgar Dietrichs: what… so what… what… what clients, would that be, enough time? That's basically two days from now? I mean, two working days? Is this… does that work for clients? Then… then I do think… because, yeah, I think I'd be much more comfortable delaying for Monday than delaying for 2 weeks. But yeah, then, I think, I mean, I see quite a few thumbs up on ACDT in chat, so then, yeah, let's, let's, postpone to that. Maybe we can have, like, a summary document of the available, options out to help guide that. Okay, good. Then, let's move on. Quite a few more EIPs to discuss, and hopefully this is the only one that we are postponing. We had 3 last… Can we maybe, yeah, share the document again? If we scroll down, to EIP7793, that's the conditional transactions one.

That was the one where we, basically, we left it off. last call. We basically didn't go, like, there was 3 last EIPs that we didn't get to, so I would want to start with those before we revisit the other, the other ones. So 7793 conditional transactions. The main reason why, this is… right now, basically, everything is marked as DFI candidate by default, just because, yeah, we kind of have a pretty big scope. There wasn't really much engagement by clients so far on calls when we were discussing it. However, we had two clients, specifically NetherMind and Besu, who ranked this as A, and so that's why I wanted to at least get back to this one more time, so…

if, say, someone from either of those two clients, or someone else with opinions on the CRP would want to make a case for… Adding, 7793 to the box scope, then now would be the time to speak up.

Marc Harvey-Hill: Yeah, so the motivation for this EIP really is to Provide better support for encrypted mempools. And provide a way for users to send their transactions, with, like, a very strong guarantee that they won't be front-run. And kind of the way it's designed is to kind of support, like, This kind of happening more at the application level, so sort of a minimal change to the protocol that will allow Sort of the application layer to do most of the work. Yeah, that's the sort of main motivation. So, I think that, I was discussing with Marius, because he had some concerns about the, the sort of block-building aspect of it. And whether it kind of complicated that, so I responded to that.

And essentially, because it's only, targeted towards, these, kind of, it's out of protocol, and only specific validators have to opt into it. It would kind of contain, potentially, the block building changes to, Only certain, kind of, clients that, you know, want to provide support for it. But yeah, I'm not sure if… I'm not sure if the guest team were convinced by that, but yeah.

Ansgar Dietrichs: Maris?

Marius van der Wijden: Yeah, I'm not… I'm not super convinced by that, because that basically means we have some transactions that only some people, or some clients, or some, like, sophisticated builders can… can build, and others… We'll just not be able to include them. And, like, unsophisticated builders, or… Yeah. I'm sorry, I… up… Upped my microphone.

Marc Harvey-Hill: Yeah, so to kind of address that, so what I'm kind of saying here is that mostly, okay, so you would have, like, this sort of, as I say, it would be out of protocol, and certain, you know, proposals have opted into it, and they're running, like, a custom block builder. building plugin, and then, you know, that would kind of handle that. But for those who aren't opted in, you could kind of have some kind of very basic support, so it's not like you're kind of limited to not, support these transactions at all. But, you could just kind of have some very kind of basic heuristic, where you're just going to kind of see what conditional transactions are in the mempool.

And attempt to place them at the top of block. Before you kind of sequence the rest of the block.

Ansgar Dietrichs: Fabian?

Fabio Di Fabio: Yep, so… I'm, following this discussion, and I want to say that I understand that most of the staff for the Encrypted mempool is, out of protocol, but… Apart from the new conditional transaction type and the… transaction index, opcode. I'm more concerned about the transaction index of code. As a way to have… maybe a quick way to start implementing encrypted transaction mempool. And because I don't know if this, opcode We'll be always… be used also in future. Maybe it could be something that will be deprecated, and we know how difficulties tend to

to deprecate and remove, maybe, opcodes that are now more used. So, what about… I don't know if you have thought about, instead of adding this opcode. What about changing the… Block import validation rule to make sure that a conditional transaction is included in the right place. So instead of, adding the opcode, Working on the… Block validation rules. Have you thought about that?

Marc Harvey-Hill: Yep, so that's the way that the EIP does work. So basically, it's kind of two parts, so there's… the conditional transaction, like, the new transaction type, right? And then this is integrated into the block validation rules, so if you created a block and included this transaction in the wrong place, it would invalidate the block. And the op code is actually for… more for a different purpose. So, if you're actually one of the users who sent your transaction that's been included on-chain. It's gonna be part of, like, in most cases, part of a bundle. And so what you want is a way to actually check in the smart… in your, like, smart account what the TX index is, because you don't necessarily trust whoever actually posted the transaction, like, the bundler.

You can't necessarily trust them. So you kind of need a way to also check on-chain, that was included where it was expected to be.

Ansgar Dietrichs: Yeah, just to cut in here for timebox reasons, Maris has mentioned it for now, I see Maris had the comment that he would prefer to basically have this not in Amsterdam, but maybe consider it for H. Stein. I see in the kind of emoji reaction supporting this, Dragon from On Breath's side, and we have Marek from Nethermind. And also, yeah, so that, to me, implies that we might just be relatively far away from, kind of, broad client support for this in Amsterdam, in which case we should just, for now. just physically… just move on with the DFI decision. and reconsider this for Edgestar. Does that seem reasonable? width. for people. Well, yeah, if any of the clients that I mentioned basically feel like they don't…

they're not correctly represented as opposing inclusion in Amsterdam, then ideally, now would be a good time to correct that. Otherwise, I think we have more basis for CFI, and then we have to DFI now. Okay, then I would say, I mean, it does seem like a very interesting proposal, and I do think it probably has good chances in H-star, but I think then the decision is clear, and that we just don't have enough client support for this, for Glumpster dump, so then we would… I… yeah, then we'll deify it now. Okay, then, we move on to the second EIP out of that section, which is the, or the second one out of the ones that were left, which is the payoff code, EIP5920.

there, basically, the reason why this is marked, again, as DFI is just that, by default, anything here is DFI, but also that no single client had ranked this better than B, and we had, basically, client rankings B, B, B, C. So, seemed pretty far from client consensus on including it. Has anything changed since then? Are any clients super excited about this now? Otherwise, I think it's a clear default DFI. Okay, then I think for this one, we don't have to have too much discussion. Then the pay-up code is also deified for now, for Amsterdam. And then the last one to talk about before we can, loop back to the beginning is… EIP8051, that is the precompile for MLDSA signature verification. So this was…

part of a broader, post-quantum kind of, like, bundle of changes. The other ones we have DFI'd, this one specifically. we have not yet, we have not yet made a decision on, and there was, from a while ago already on, on an, ACD agenda from December 15th, there was a comment by, Renaud on, on this EIP and some of the related ones, I'm not sure if you are on the call today.

Renaud Dubois: Yes, I am.

Ansgar Dietrichs: Perfect. Would you want to briefly summarize your comments on this?

Renaud Dubois: Yeah, so, we have been talking a lot about post-quantum transition, yet we have, some… some proposals, so there is… there are two separated, Falcon proposals. There is Delithium. Deliptium actually seems to be the choice of Web 2, because it's already included in some implementation in Chromium. And so on. The difficulty to implement this one is lower than the hosters. There are several implementations, that could be directly integrated into clients. So we think… yeah, and there is no, backward compatibility issue with this one, so we think that While Falcon as some advantage, and mainly we began with implementing those in smart contracts, and the gas cost was far lower, but it's because it's not included in a node. If we compare MLDSA efficiency with Falcon.

Okay, what's the commands here? da-da-da. Yep. Is that comment, related to, including, signature verification precompile? So, basically, if we look at the cycle, numbers of post-contomb, verification, it's, for Falcon, it's even, smaller than an ECDSA. verification. So the… the constraints with, Pascantom signature, are as bandwidth. Meaning that, size of signatures and public keys are far far larger. So there are several, several efforts. Consensus, Consensus team is working. Aggregation of signatures, what they… what they will use is, Most probably hash-based, hash-based aggregation. I'm not sure that having a stateful candidates would be good for a consensus layer, so here.

Here, I don't know if we need only one pre-compiled, or… If we look at what, what we have for elliptic curves, for instance, we have, we have Air1, we have K1, we have BLS, BLS… Mainly is, is already, available for consensus, so maybe in the future, we could, devise, What is optimal for consensus, and separate what is optimal from consensus and for execution layer. However, having the aggregation mechanism, I guess we could… Yeah, I mean, for the choice, yeah, I see what Maurice is writing. I think that… I'm not sure that Ethereum should be the one. redoing all the process that the NIST has taken for more than 8 years now. So, mainly, I don't know how many cryptographers we have in the Ethereum ecosystem, but basically the NIST and ISAR

Are counting, hundreds of cryptographers that has been working for 10 years, so… I'm not sure that if we have to redo all the process on our side, even if some tweaking and tuning to Ethereum might be necessary. And another thing is that, the consensus, will be fast to move, because, As soon as the concern fork will be pushed, all nodes will switch at once. But, moving users from accounts will take years, if we look at what happened with Account Abstraction, for instance. It has been available for 3 years now, and it's mainly no wallet implemented. So I think we… We need to… To begin, the, the pedagogy, and, work on this, because once the solution is available…

Ansgar Dietrichs: You know, just to cut in, just because of… for timeboxing, just because we only have 30 minutes left in the call, I think the argument is clear for now. I'd rather, for now, just go on a round of feedback from… from other people on this point, and then we can get back to you afterwards. Thank you. There's a big group there, I'm not sure who of you all want to say something.

Carl Beekhuizen: Yeah, I just wanna push back against this, like, I think it's, If we had to choose something now, I think this would make a lot of sense. But I think, yeah, just given the unknowns of what the industry is gonna adopt, and, like, and put into hardware and that kind of thing, I think it's… making a decision now is, like, like, is a good chance we end up with something that's not quite as popular. Also, I think with all the repricings going on, now and in HDAR, I think, like, the trade-offs between compute and storage and cold data costs are changing quite dramatically, and that might have a big impact on what is viable or makes sense in terms of the standards, so I think it might be good to hold off on this.

Certainly for now.

Ansgar Dietrichs: Dano?

Danno Ferrin: So, as far as the notion that we're picking a PQ algorithm now, the reality is we are not going to be able to pick just one. Each one has their own quirks and their own compromises that different users are going to want different values for. But from that set of what is going to probably be in the set, MLDSA is almost certainly going to be one of them, because it has NIFT support, that's FIPS 204. And that's what chips are coming out with to support the signature already. It's already the leading replacement in the Web2 world for the signatures, for, for RSA and ECDSA signatures. But I think another thing that we need to think about is downstream users, particularly in the smart contract world. If we give them no smart contract precompiled support for post-quantum signatures, they're not going to have time to adapt their ideas and their motions towards supporting post-quantum signatures in things like, you know, signed messages.

and smart… and account abstraction. So waiting until we get everything perfect is really going to put all our downstream users at a disadvantage.

Ansgar Dietrichs: Ben?

Ben Adams: If we're gonna have to support multiple, potentially, would it be better to have some kind of framework? Where we can say, alright, this is the process that we'll add. post-quantum signatures, maybe there's a… I don't know if there's a transaction type involved as well. So that we can… We can add them without them just being sort of randomly compiled. But in a more coordinated way.

Ansgar Dietrichs: Felix?

Felix Lange: So, regarding the transaction type, just as a quick comment, so… Having it as a precompile kind of factors in with the whole account abstraction effort, where you would be able to use this precompile inside of a smart account to verify the transaction origin, so just basically adding this precompile in now fits in kind of good with the account abstraction roadmap of being able to support, post-quantum signatures later. So that's kind of how I see this. I think… I think sooner or later, we're gonna have to add Some, post-quantum signature scheme into the… into the protocol as a pre-compile. And so, yeah, we might as well add this one, but adding it as a precompile, I think, is the correct approach.

Ansgar Dietrichs: And to clarify, Felix, I think the guest team had put this at sea, but that, to me, sounds like you're now more open to having this as part of Amsterdam, or how to interpret this?

Felix Lange: So, I am never really against adding specific crypto precompiles, I have to say, because the process of adding them basically is always the same. It requires extensive testing, it requires diversity in the implementation libraries, and it requires that the cryptographic standard itself, which is being added as a print compile, is reasonably Agreed upon by the… community of cryptographers, but I think in this case. I haven't evaluated if there are good libraries for this algorithm, but I think there are some. And so, mostly it's gonna come down to how it holds up in fast testing and so on, and what is the danger of splitting the network due to a… bug in the underlying implementation of this precompile. So that's… I cannot answer this exhaustively right now. I just know that, in general, adding precompiles like this

Is always the same. So I'm not inherently against it. It's also one of the extension points in Ethereum that is… kind of the most isolated in some ways, because it's just a function exposed to the EVM. So it's also very easy to decide late in the process that, yeah, we don't end up activating this because we found the bug, or we feel not confident about it. Whereas if we make a huge change to, for example, the fee market, and then we decide later to not do this change, we have to undo a lot of complexity, whereas with adding a precompile, we can always, in the last minute, pull it. Because there's an issue in testing, or we feel the confidence doesn't hold up, or so.

Ansgar Dietrichs: And, Antonio?

Antonio Sanso: Right, just, like, adding a quick thing here, I've been working with Renault a lot in the last year on this, just, like, adding something that has been… has not been covered here. I'm all for, like, having, post-quantum into a precompile. There's a little problem until now, there's a bit of confusion what is standardized or what not, and one thing that happened in the last summer that is not A lot well known is that So DSA, so Delitium has been standardized by NIST, and, it's… the signature is bigger than Falcon. And this, this is bad. But what happened last summer at Crypto 2025, the best paper award has actually a lithium with the smaller signature size. What's the problem here? That…

Delidium has already been standardized. And, so we are now in a situation where Falcon has a smaller key, and not yet standardized, and, and it's complicated to… the signature is complicated. Delithium has bigger signatures, but… standardized, but at Crypto 2025, actually, there is a new paper that makes the lithium signature smaller, but it's already been standardized, so it's like paradox on paradox, just adding this, sorry.

Felix Lange: So basically what I'm hearing is your feedback is… it's a bit too early, because we don't really… the space of signature algorithms hasn't solidified to the point where we can clearly say which one is the best one, or which one should be added.

Antonio Sanso: At the very least, I will wait yet another release, so at the very least, I will not put anything in Glamsterdam, and maybe have a really scoped this properly for H-star, where we have a bit of more months to understand the status quo, because again, like, this, this Delithium, this delithium paper on Crypto 2025, they brought… the signature almost at the same size than Falcon, for example, was totally unexpected, at least to me. And… but the problem now that this has been already standardized, so I will wait at least H-star to, like, and focus… I actually agree with what was written in the chat, that maybe we should have AIM1… one of our, fork only on this, and… because this is going to be a bit of effort. Maybe having more than one, but really having one fork on post-transaction signature focus.

We can… I don't know how we want to call it.

Ansgar Dietrichs: Okay, right, I think it would be really important if we could make a decision today, it felt a little 50-50. It seemed like everyone was open to it, but also a bit hesitant. I think now, Antonio, you're specifically recommending to… wait at least one more fork? Is this, like, do people in principle, like, I think, again, given the grams and fork scope, like, any 50-50, I think we would eventually resolve with a DFI, because we already have a big fork scope. So… That's maybe what's leaning? Do we… Do we currently have any clients that would prefer this in Glamsterdam over delaying the decision to H-star, basically? Let's ask it this way. Any client representatives that would specifically want this in Gramsterdam?

Okay, I think if… if it's… if all the clients basically are… kind of unsure about whether or not this should be in Glamsterdam, and no one… no one really has a strong preference for Amsterdam, and there are some concerns, then I… I think that the default decision here is DFI for Glamsterdam. And maybe we can, like, in the run-up to the H-star decisions, consider having some ACD break out specifically about post-quantum signatures and EVM changes. We can look into this async, but… but yeah, it's… I would say DFI is the last opportunity for any… Objections to the DFI decision? Okay, then we, for Amsterdam DFI, the… Be yippee. Okay, then, let's see, we are already starting to be a bit short on time, but, also not that many EIPs left. Now that the only primary section we should still try to get through is decisions from… or EIPs from last ACDE that we basically had to delay, or postpone to today.

The first one in that group, so we now scroll back up, basically, on the page, would be, the T-Store one, so EIP7971, hard limits for transient storage. that one, basically, in general, had some… like, overall, there was some interest in shipping that. At the same time, there were unresolved account obstruction concerns, and specifically, there was the ask to give two more weeks of time for people to potentially address those kind of abstraction concerns. Have those been addressed? Is there anyone with context on this that could speak up? Again, default otherwise, with… if there was no status change, this would be a DFI. Has there been any progress on this?

Okay. Then, I would say, then, this kind of… is it auto-DFI? Is there any, any, any objections to, to DFI-ing this? Okay, then 7971 is DFID for Clemsonam. The next one up, would be, EIP8032. which is the size-based storage gas pricing. So the idea was to basically Make it so, state… state rights, could basically be priced, according to the… to the total kind of size of the… of the storage tree. At the cost of a small, kind of, state-treat transition. Do we, like… Do we have anyone with… opinions on… on this EIP? Carlos?

CPerezz: Yeah, so very quickly, we… we basically benchmarked initially this, by running worst-case attacks to Zen. But now we have basically bloated a new contract, a new ERC20 contract to 30GB to actually make sure that indeed is the size of the contract storage what actually causes, this, let's say, more performance issues. On the other side, I'm also trying to investigate whether depth, plays into it, and basically which percentage each of them, like, takes, from the overall execution time. So I would say, at least from my side and in my opinion, we don't have enough data to actually, make this or put this into Glamsterdam, until we are not able to run, some experiments on BloodNet.

Ansgar Dietrichs: My understanding is also that there's now a renewed interest in working towards a general, kind of, state tree transition for Ethereum, basically the successor to the Verkel saga. But obviously not for Glamsterdam, but for later hard fork. So, of course, the temptation would be to then, like, potentially, like, not make earlier transitions of the state tree.

Guillaume Ballet: Which would be net… Thank you, man.

Ansgar Dietrichs: Maybe you can speak to this.

Guillaume Ballet: So, yeah, those two EIPs, like the binary trees, transition, and this thing have nothing in common. However. If you are, if as a client developer you are worried that the binary transition is too complex, this is a much simpler version of it, and it gives you a great opportunity to test that transition.

Ansgar Dietrichs: Right. Do we have client, team takes on… On this. And of course, just to clarify for people, right, like, the upside, like, the reason for why this would be nice to do is, of course, that otherwise we have to price all SDOS, kind of according to the worst-case performance of the heaviest contracts. Which, of course, it's not ideal. It will make everything a bit more expensive for users. And then, yeah, the reason for not doing it would be the complexity, so that's the trade-off here.

Guillaume Ballet: Okay, in the interest of time, and also because Carlos would like to talk about 7907, this CIP is created for, to help, actually, Reth and another client. If REST is happy to DFI it, well, you know, I'm not gonna try to help them against their, their will. So, it helps with, It helps to demonstrate the transition, so we will implement it anyway. In fact, the implementation exists. But, yeah, I'm not gonna fight to help people that don't want to be helped, so I am withdrawing this EIP for Glamsterdam.

Dragan Rakita: I'm not exactly sure what the help was, but thank you for helping.

Ansgar Dietrichs: Okay, is this… like, a final decision deal? Because, I mean, I can check if other clients… Okay. Then, indeed. we will DFI this, or, yeah, with Strait, I think. I mean, DFI is maybe the cleaner way, but either way, same outcome. And, yeah. move on to the next EIP, EIP7907. meter contract code size and increase limit. So, just for context there, yeah, before we go into the analysis that Carlos has done, there is… there was initially several different, proposals for how to potentially allow for larger maximum contract sizes. In this fork, the last… the currently only remaining PFI at EIP is 7907, which would do it, based on a… change to the, to the state, basic account structure by adding, a size value, but only to newly deployed contracts. But we also, on last call, discussed that, theoretically, we could instead replace this with the even simpler EIP by Julio from a while ago, about… that there would basically just

do a constant bump to the maximum allowed contract size, and my understanding is that Dallas Hue did an analysis, and I think it was actually primarily about this… this alternative proposal by the… the Julio EIP that would… that would just be a… constant… bump of the maximum contract size, and how much of a bump there we could do, and what the implications would be. Do you want to briefly share your screen and go through that analysis?

CPerezz: Yeah, sure. I sent a request to actually share the screen.

Ansgar Dietrichs: I think now you should be able to.

CPerezz: Omoe… So… This one is… Yeah. Boom. Okay, can you say, can you see the…

Ansgar Dietrichs: Yes, we can see the screen.

CPerezz: Okay. Okay, perfect. So, yeah, to go very quickly, basically, what I did was I took Geth, I completely disabled all the cache, specifically the code one, and from there, what I did is I deployed 18,000 contracts. All of them have different bytecode, because they use others in the init code. And besides that, they all have different ranges of sizes that go from 0.5 kilobytes to 64. And basically, the TLDR is we are hitting for 64 kilobytes, on average, 1 second of execution time, which includes, of course, reading. So, that's certainly valuable at 60 million gas. especially because Geth, as I said, has a completely disabled cache, which… that is a scenario that will never, ever happen. And on top of that, this is the worst possible case that we could execute, so that's a block full of transactions with minimal overhead to do as many Xcode-sized calls to call contracts as possible.

And the data that I would, like to highlight here is that basically Code Read, scales sublinearly with, bytecode size. So basically, as you can see. From the time it takes us to read 0.5 kilobytes to 64 kilobytes, we have an increase of 8.5x, but we have actually gone from 0.5 kilobytes to 64, which means we have a 128x increase in code size. And of course, if you basically check the overall thing, the more we screw towards bigger contracts, the much more time it takes over just reading the code itself than actually doing any other thing whatsoever. So yeah, after all of this, analysis, which you can check in, in its research, I think the easiest way to go will basically be,

just accept, having the proposal from Julio, and for the question, what if we go to 100 million gas? Well, with the data we have, the projected times for 100 million gas with this attack will be, 1 second, execution time for 32 kilobyte contracts, and 1.5 seconds for 64 kilobyte contracts. And that's, again, with the cache from GethDescent. disabled. There's only two more things I want to mention here. The first one is, notice that most of the… most of the contracts deployed, nowadays are, copies. So basically, when we actually deployed code, we very rarely see new additions into the database, and that basically comes to say that I think it's not an issue if we just remove,

bytecode deployment from EIP8037, and therefore, we're allowed to deploy this, bigger contracts, let's say, at least up to 64 kilobytes, without hitting any transaction gas limit cap issues or anything like that, at least because it's the simplest solution, and because we can, at this point, accept it. But yeah, that's more or less the conclusions. Anyways, you are free to interpret the data as you wish and come up with yours.

Ansgar Dietrichs: Thank you very much. So, basically, I think there's three… approaches here, or three decisions we could make. Decision one, of course, would be to do nothing about contract code. Decision two would be to, implement the simpler, Julio EIP, so 7954, I put the links in the chat, with, a bump, and we could decide which bump, so, 32 kilobytes or 64 kilobytes, For example, or option 3 would be to go with the EIP that is actually PFI'd right now, which is 7907, which, just to remind people, right, like, that specifically, instead charges proportional to the size of the contract, so it doesn't have any performance considerations, but it comes at the cost of Also a state change, nothing that needs to be applied retractively with the transition, but basically any new accounts would now have an extra field, which is the code size.

Do we have comments on which of those three options would be preferred? Ben?

Ben Adams: So I… For the simple bump. But to the level of 32, we can revisit because they also changed the… Account storage. And then we can revisit what we want to do after that.

Ansgar Dietrichs: maria?

Maria Silva: I… I just wanted to, so, to… say something, like, about the analysis from Carlos. So, an interesting thing here is that you can see that, until the 10 kilobyte contract size, the performance is mostly linear, so it doesn't increase, significantly with the code size. But then when we go from 10 to 24, 24 to 32, and 32 to 64, we actually see a pretty linear increase. What this means is that if we want to go, let's say, from 24 to 64, this means that We would have to price… the operation at the worst case scenario, which would be the 64. And so, essentially, every time we are loading code, even if it's smaller contracts, to see

a performance which is much, much better, we would have to price it at the worst-case scenario, so at the 64 kilobytes. So, essentially, we would make The throughput on these operations for Huge majority of users. linearly worse, just because we have the possibility of increasing the contract side. So, to me, this is a huge… drawback for a fork that is all about scalability. So, essentially, we are repricing Called accessing operations in a worst case. and hurting the scalability on those… on those operations. So, I don't… I don't think this is something that I would be happy with, So, I… I do have a huge preference for spending the time and actually implementing 7907 so that we can keep the cost of these operations in line with their, actually, costs to execute.

Ansgar Dietrichs: Try that?

Dragan Rakita: Upping the size to more conservative, 32 kilobytes. It seems like my spate. That's just… Maybe you should probably do it.

Ansgar Dietrichs: Guillaume?

Guillaume Ballet: Yeah, just a quick response to Maria's statement. For sure, it's true that if you have a single cost for any contract size, someone's going to be fleeced. Either your cost is going to be, To be too low for what you get, or it's going to be too high for a… for the… for the… builder. The thing is, as long as you don't have something like 2926, which tries to precisely pay exactly for what you pay for. You're going to have this, this imbalance, so… even 7907 has this problem. Why is it given a price for something, you, you know, until 24 kilobytes, it's, it's the standard price, and then it gets bigger. It's kind of the same approach, I mean.

Either you decide you want to… to, like, the contract code size to… sorry, the access cost for the contract size to… sorry, the access cost to reflect the contract size, in which case, that's $29.26, or you say, well, this is not a problem big enough to do that at this moment. And then you just bump the code size to a safe limit, knowing that some people will pay more than they have to. Either the… The transaction sender, or the… or the blog builder. But yeah, in my view, this is already a choice we made. So that's, there's no point in, selecting or, like, scheduling an EIP. That is going to create a temporary cost. that we'll… we'll have to maintain for the rest of, of the time, with, you know, and that we want to replace eventually, either in I-Star or, or a bit later.

Maria Silva: But so, but… That's the thing, right? Like, ideally, we would have the threshold at 10 kilobytes, or close to it, because before that, costs are fairly linear. But the issue is that at 24, the difference is still not horrendous. But then, the higher you go, the worse it gets in a linear fashion, right? And so that's… where I'm concerned is, like, increasing contract size too much will be hurting contract loading… For all the other users at the same level. And contract loading is fairly a common thing we do, so… I don't know, it seems, it seems like a huge hit in scalability. So yeah, I'll be a bit unhappy about that.

Guillaume Ballet: I mean, core development is about being unhappy, at least that's my experience.

Ansgar Dietrichs: From the group, again, there seems to be a comment.

Carl Beekhuizen: I think another thing here is that, like, we can also, for smaller contracts, implement some kind of refund mechanism, in the future. It's very… it's very hard to make stuff more expensive, like, price some of these other things correctly, but, like, having it where we charge the 24K limit and then, refund if it was less. I think it's a sensible mechanism that wouldn't break anything, and would allow us to get the correct pricing.

Ansgar Dietrichs: Are you proposing that we would basically modify the Julio EIP already to have such a refund, for smaller than, like, say, 32GB contracts, or would you say at a later fork this could be added?

Carl Beekhuizen: I would… I would say for a later fork, I don't think we should make the situation worse by implementing the naive bump, the Julio's EIP, because I think that's just gonna, like. Like, it exacerbates the situation in some ways now. But, like, I think another mechanism where we correctly price things is more reasonable. And then, like, if we further want to be able to scale the, like, if we want to further price things correctly for the contracts less than 24 kilobytes, I think we can do that in the future.

Ansgar Dietrichs: So, we are… yes. Just cutting you, cutting off, because, like, we are… we are, like, one or two minutes before the end of the call, Yeah, it feels a bit hard. It's not… like, it seems like people are leaning towards a bump to 32 kilobytes, it seems like… that's the option that I've heard the most so far. We have not talked much about the actual, like, the kind of the EIP that was originally proposed, the 7907, at all, so it seems like people are mostly apparently not a fan of that style of approach. I don't know, do you have any… maybe just to simplify the decision tree here, like, first, is there any client that actually prefers the 7907 mechanism, so basically the extra fields to new accounts that includes the size of the contract?

I mean, I guess I've… Carlos and Ben, you already had you on up, but I assume that was not on this point.

Ben Adams: Yeah, I mean, I'm happy… I'm happy with… I'm happy with, 7907. But if we look at the goal, the short-term goal is to improve developer's experience, and a small bump We'll give that to, like, 32. Whereas… In a longer-term vision, we want to be able to allow Larger contracts, and for that. maybe we think a little bit longer and do an improved mechanism. So therefore, the 32K bump is, you know, it's a… it's a… Stopgap to buy some time, make every developer happy. And they're used to doing 24KB contracts, so it'll be a while before they start hitting 32. 4K or the 4K.

Ansgar Dietrichs: Yeah, so then maybe I would just, like, because I really want to make this decision today, my prop… it's just in terms of, like, what I hear the most seems to be the bump to 32, that's something that came up repeatedly, and yes, there's the protest, and I personally also am a little worried about this, that, like, it will make all contract loads 32% more expensive. At the same time, contract loads are not a very dominating part of the current transaction costs, so maybe it's not so bad. And it's a very highly requested feature. So, do we generally have rough consensus around the bump to 32? So basically, like, DFI-ing 7907, and instead CFI-ing… it's not technically PFI'd, but I think we were all okay with swapping this one out. Basically.

CFI-ing Julio's EIP with the understanding that it would be bumped to 32 kilobytes specifically? Is this… Does this have rough consensus? Or… Yeah. It's basically any client, any client representative, I see, for example, Maurice in chat, that might have some… or weak opposition, at least? Like, so any clients that are opposed to this, to this option? Because otherwise, I would propose that we at least CFI it, and then we still, of course, in the DevNet stage, we can still, also we will have benchmarks and everything, and we can still decide whether we actually end up going ahead with it or not, but, In the interest of today, getting through the scoping.

Guillaume Ballet: GFI, which one?

Ansgar Dietrichs: see if I do… so this would be… let me confirm the number.

Guillaume Ballet: Julius Pierre. Julius…

Ansgar Dietrichs: Julius. This is correct, yes.

Guillaume Ballet: Okay, well…

Ansgar Dietrichs: 7954, but… yes, exactly. 7954. And then… just to have this be coupled with the last decision, because we have… we always waited for… so… but yeah, like, first, do we… how do we feel about this? Is this… I'll just… I… can we… so basically, can we CFI this? Is there anyone who… who is veto… who would veto now CFI… making this CFI decision? Okay, then I would say we DFI7907, and we instead CFI as a business swap-in replacement, 7954, And my understanding is that, looking at the AP right now, that it already, in the current form, proposes a bump from 24 to 32, so that is exactly the number that we also intended here. I would then propose that, just for practical reasons, this EIP7954 comes with also an adjustment to the maximum init code size from 848 to 64. We don't have time to get into this now.

And there's also this alternative EIP that we basically delay decision on. You can see it right under the one that's currently marked, 7903, remove init code size limit. I would propose that we basically just, on Monday, on ACDT, also very briefly revisit this. This should be a very quick decision, because it's just about the init code, and just basically see, whether A the Julio EIP on this point on the init code is reasonable, and then whether we still see a need for this additional EIP. And… I think that that's the most reasonable, so if everyone is okay with that, then I would basically also delegate that small decision to ACDT. Or Maris, maybe do you…

You're saying you'd already just now make the DFI decision on the full uncapping?

Marius van der Wijden: Yes, I think we should… we should DFI the full-on capping, we should just do… if we want to go the… the Julio route, we should go the Julio route, double the… the init code. That's it, and… and we're… we're done with, like, this… Like, yeah, walking around the decisions.

Ansgar Dietrichs: Okay, then… I mean, that's… I think that's kind of where we are… where this would be headed anyway, so then, yeah, maybe that's more reasonable. Okay, I was a bit hesitant because we're already 5 minutes over time, it's a bit late for a decision, but yes, then I would propose we DFI7907… sorry, not 7903. Remove init code size limit, and we instead just go with the… init code size adjustment from… that is part of, the Julio EIP, and yes, we can still see, of course, if we want to adjust that number. That's in… that's in there. Anyone that's opposed to that? Okay, then we really only have the one delayed decision until Monday, Which was… which one was that? That was the…

state growth, so… so we're basically delaying this… yes, exactly. We are delaying the, AT37 state growth decision for Monday, and other than that, the only EIPs that we'll have to talk about for Glamsterdam scope will be the ones without protocol changes, so… for all intents and purposes, otherwise the grump scope is, at this point, final, at least to the CFI stage. Awesome. This was a long path to get here, so I'm very, very happy we got it done, and thank you all very, very much, and See most of you all on ACDT next week.

Justin Florentine: Thanks, y'all.

Marius van der Wijden: Thank you, bye-bye.

Danno Ferrin: Thanks, bye. Sorry, you…

Marius van der Wijden: God damn, let's…

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