Ansgar Dietrichs:Perfect. Hello, everyone. Welcome to AllCoreDevs Call 228.
Transcript
Ansgar Dietrichs:I'll put the link to the agenda in the chat.
Ansgar Dietrichs: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,
Ansgar Dietrichs:we'll be able to finish the, Glamsterdam PFI decisions today.
Ansgar Dietrichs: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,
Ansgar Dietrichs:Whether that… whether it would make sense to revisit that.
Ansgar Dietrichs: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
Stefan Starflinger: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,
Stefan Starflinger: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.
Stefan Starflinger:And I think it shouldn't be such a big blocker.
Stefan Starflinger: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:Kind of today, not just next week.
Ansgar Dietrichs: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…
Ansgar Dietrichs:Whether they would want to… Yeah, remove the slot number up code from Devon 2.
Carl Beekhuizen:Admin.
Carl Beekhuizen:You're unmuted.
Ansgar Dietrichs:Was there someone from the big group?
Ansgar Dietrichs: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,
Stefan Starflinger: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,
Ansgar Dietrichs: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…
Ansgar Dietrichs: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.
Ansgar Dietrichs:Is that okay with everyone? I'll just wait for any protest?
Ansgar Dietrichs: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.
Ansgar Dietrichs:I'll just go through them one by one. So the first one was…
Ansgar Dietrichs:on the EIP-7778, lock us accounting without refunds, there is… A request for clarifications…
Ansgar Dietrichs:On cumulative gas used, gas used for paying, gas used for block limit.
Ansgar Dietrichs:I think the comment…
Ansgar Dietrichs:Was by Andrew, on the issue. Is Andrew, are you on the call, or Tony, do you have…
Ansgar Dietrichs:Context on this?
Andrew Ashikhmin:Yeah, I'm on the call.
Andrew Ashikhmin:Basically, as I wrote on Discord, At least,
Andrew Ashikhmin:So, is it 7778 or 80-22?
Ansgar Dietrichs:Mayor 7778.
Andrew Ashikhmin:Yeah, okay, so… Yeah, at least in Erigon…
Andrew Ashikhmin: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.
Andrew Ashikhmin:So I suggest to keep that, that assumption.
Andrew Ashikhmin:Otherwise, yeah, it will be a massive change, and very bug-prone.
Andrew Ashikhmin:So that's a change that I proposed to the spec, and there is also a clarification needed
Andrew Ashikhmin:Because it underspecies the overplay between, 77-78 and,
Andrew Ashikhmin: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
Toni Wahrstätter:Today, so this is something we clarified today in the execution specs.
Toni Wahrstätter:And… just to… to ask you, Andrew, you were saying you want the…
Toni Wahrstätter:The block gas accounting should include the transaction costs before the refunds, after the refunds, sorry. So you want the receipts to include
Toni Wahrstätter:The gas used after the refunds, am I correct here?
Andrew Ashikhmin:No, no, no, so… The, it should be, like…
Andrew Ashikhmin:Okay, so in 7778, you have this, this,
Andrew Ashikhmin:Gas used for block accounting, right? Number 2, which… which does not contain refunds, right?
Andrew Ashikhmin: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
Toni Wahrstätter:the gas used after the refunds, but the receipts only include the cumulative gas used. So the question is.
Toni Wahrstätter:What do we want to add to the cumulative gaseous? Should we add the gaseous pre-refund or after refund?
Toni Wahrstätter:And…
Andrew Ashikhmin:Do we need to use it to edit?
Toni Wahrstätter:So it makes sense to, add the… gas used,
Toni Wahrstätter: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.
Andrew Ashikhmin: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.
Ansgar Dietrichs:There was also an…
Ansgar Dietrichs:a comment by Andrew, about, clarification, basically what happens if the code ends, right, right before an,
Ansgar Dietrichs:immediate operand. And then there was also separately from…
Ansgar Dietrichs:drag on a proposal to potentially simplify the EIP, so,
Ansgar Dietrichs: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,
Andrew Ashikhmin:The immediate operand was on the code's end as an error.
Andrew Ashikhmin: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.
Andrew Ashikhmin:I mean, I don't care much. I just have a slight preference for com…
Andrew Ashikhmin:for consistency, but in any case, it should be specified in the EIP. I think there is a PR to the EIP to…
Andrew Ashikhmin: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…
Ansgar Dietrichs:EIP question?
frangio: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.
frangio:And on Dragon's question, the… there… the EIP currently…
frangio:So, in order to, to work with, jump dest analysis.
frangio:The EIP is currently designed in a way that the immediate has to avoid using
frangio: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.
frangio:There needs to be an encoding and decoding step, which…
frangio: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.
frangio: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.
frangio: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
frangio:feel here is, the best choice. I will just say, I think the trade-off is
frangio: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.
frangio: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.
Dragan Rakita: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.
Dragan Rakita: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.
Ansgar Dietrichs:So…
Dragan Rakita:I would like… I would like to hear others just commenting on that now, or as async.
Dragan Rakita: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 (Besu):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.
Daniel Lehrner (Besu):So, I mean, this decoding logic is a bit…
Daniel Lehrner (Besu):unusual, but I don't think it's that complex.
Daniel Lehrner (Besu):But if we have to change it, I don't think there's any issue from our side.
Daniel Lehrner (Besu):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.
Ansgar Dietrichs:Anyone else?
Ansgar Dietrichs:Otherwise, maybe question for,
Ansgar Dietrichs: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?
Ansgar Dietrichs:Asynchronously? Is this the Discord? Is this the Ether Magicians? Like, where would be the best place?
Ansgar Dietrichs:Yeah, Ben, maybe before?
Ben Adams:So, one of them changes jump desk analysis, and the other doesn't, is that correct?
frangio:No, none of them do.
Dragan Rakita:Depends how you do jump test analysis.
Dragan Rakita:Depends if you're basically asking, if you're searching job destination, or you're searching the immediate.
Dragan Rakita:I didn't get, thoughts a little bit different.
Ansgar Dietrichs:Yeah.
Ansgar Dietrichs:So then, I guess, back to the question of where the best forum is for the decision?
frangio: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?
frangio: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.
Ansgar Dietrichs:Somewhere where the comment can easily be found.
Ansgar Dietrichs: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…
Ansgar Dietrichs: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
Ansgar Dietrichs:by Spencer, on… on the agenda. Are you on the call, or does anyone else have context on that, Pierre?
spencer-tb:Hey, yeah, I, yeah, just wanted to give that PR some more love,
spencer-tb:I think, it feels like everyone's in agreement, but I think some more eyes just to…
spencer-tb:Determine if we're happy with the log address and the first topic value.
spencer-tb:And then also, if he wants to include… The payment logs.
spencer-tb:On top of these transfer logs.
spencer-tb:And more of a, can we get this motion to respect sooner rather than later?
spencer-tb:clarification.
Ansgar Dietrichs:Sounds good.
spencer-tb:Definitely, I guess I'd also like to ask if we're going to finalize the scope for DevNet 2 next Monday.
spencer-tb:We're DevNet 2 scheduled on Wednesday, should we push?
spencer-tb: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-tb:It just feels…
Ansgar Dietrichs:And so what's.
spencer-tb:So, a general question, if we should push Devin at 2 forward, if we're going to finalize this group next Monday.
spencer-tb: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 (Besu):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.
Daniel Lehrner (Besu):Because we cannot properly test everything.
spencer-tb:Yeah, and I guess before we have the test out, we kind of need to finalize the specs.
Daniel Lehrner (Besu):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.
Stefan Starflinger:And we can do the benchmarking there, would be my suggestion, and then develop all the new EIPs on top of DevNet 2.
Stefan Starflinger: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.
Ansgar Dietrichs:So, is that a good place to leave it at for now?
Ansgar Dietrichs:And then come back on ACDT on Monday?
spencer-tb: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.
Ansgar Dietrichs:And then, presumably on Monday, by Monday, this would be… finalized.
Ansgar Dietrichs: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?
Ansgar Dietrichs:Okay, then let's move on.
Ansgar Dietrichs: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
Ansgar Dietrichs:website earlier today? Is it currently working? Perfect, okay. Thank you, thank you very much, Josh.
Ansgar Dietrichs:M…
Ansgar Dietrichs: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…
Ansgar Dietrichs:Decision is EIP 8037.
Ansgar Dietrichs:So you can see it there on the state growth section, so specifically, that's basically the…
Ansgar Dietrichs: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
Ansgar Dietrichs:For this, Marius, are you on the call?
Ansgar Dietrichs: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.
Marius van der Wijden:Yes, 1837…
Trent:You're very quiet, if you can move any closer.
Trent: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.
Marius van der Wijden:Basically, 1837, the state creation gas cost increase. It has multiple different, goals.
Marius van der Wijden:makes state growth,
Marius van der Wijden:Dependent on the gas limit, so that whenever we increase the gas limit, we also increase the cost for creating new state.
Marius van der Wijden:And this is very important, because if we, like, 10x the gas limit…
Marius van der Wijden: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
Marius van der Wijden:Increase to be kind of constant, and we want a target of
Marius van der Wijden:Roughly 100GB per year, and this can be, changed.
Marius van der Wijden: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
Marius van der Wijden:Like, creating one byte of state is very different across the different operations that we have.
Marius van der Wijden:So, the block gas limit.
Marius van der Wijden:What we want to do is make the state growth dependent on the block gas limit,
Marius van der Wijden:And in the last line, you see a formula for this.
Marius van der Wijden:And basically, small changes in the gas limit are smoothed out.
Marius van der Wijden:Otherwise, every time we would increase the gas limit, this would require repricings.
Marius van der Wijden:What this means, though, is that the intrinsic gas is now dependent on the block gas limit.
Marius van der Wijden: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,
Marius van der Wijden:To see if these… if the transaction is still occludable.
Marius van der Wijden:But, there might be a different, like, we might, change this formula a bit.
Marius van der Wijden:To smooth out the gas limit changes even more. So, you would only need to recheck if the gas limit changes pretty drastically.
Marius van der Wijden:And in addition to this, we will also need to introduce multidimensional metering.
Marius van der Wijden:But this is not multidimensional.
Marius van der Wijden:gas. This is very different, but we would, need to measure the state growth and a different exist than compute.
Marius van der Wijden:And, so we can adjust them independently.
Marius van der Wijden: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…
Marius van der Wijden:megacity, transaction limit.
Marius van der Wijden:So let's… Go through the concrete implementation.
Marius van der Wijden:The gas… In this… in this new world is the minimum of the gas limit and 60 million.
Marius van der Wijden: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…
Marius van der Wijden:You first check the state gas budget, and only the normal gas later.
Marius van der Wijden:And then all of the normal operations will charge to gas.
Marius van der Wijden:As usual, and that means that, at maximum, a transaction will execute 16 megas of burst resources.
Marius van der Wijden:as much as it pays for state growth. And, this also means off-heat gas will just work normally.
Marius van der Wijden:Why is this important?
Marius van der Wijden:The burst resources need to still be unaffected, so we can have the 16 megas gas limit.
Marius van der Wijden:Not for the execution.
Marius van der Wijden:So, result of this is all state operations will be split into
Marius van der Wijden:gas costs and state gas costs. So, for example, the S-store operation now charges 2,100, the cold S-load cost to gas.
Marius van der Wijden:And this cost, which is dependent on the gas limit, to storage gas.
Marius van der Wijden:So…
Marius van der Wijden: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.
Marius van der Wijden:And,
Marius van der Wijden:We allow to limit execution to $16 million, and unlocking higher state growth by making state growth itself more expensive.
Marius van der Wijden:And the changes are pretty limited to the EVM. I've implemented this yesterday and today in roughly 4 hours combined.
Marius van der Wijden:The… the… The heavy lifting, Or, like… people's,
Marius van der Wijden:There will be changes to the way we test, so testing is a bit affected, and block
Marius van der Wijden:Creation, block building is a bit affected.
Marius van der Wijden:But, all of those changes are…
Marius van der Wijden:Quite small for… compared to the gain that we can have with this.
Marius van der Wijden:In, in, in, in, in the amount of,
Marius van der Wijden:And the amount of compute, increase that we can do while keeping the state basically on a separate axis.
Marius van der Wijden:Yes, that's it.
Marius van der Wijden:Questions?
Andrew Ashikhmin:None.
Andrew Ashikhmin: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.
Andrew Ashikhmin: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.
Andrew Ashikhmin: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.
Andrew Ashikhmin: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…
Maria Silva: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?
Andrew Ashikhmin: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
Maria Silva: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
Maria Silva:That's different.
Andrew Ashikhmin:But maybe we should introduce, like, an independent fee.
Maria Silva:Right, but so…
Maria Silva: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.
Maria Silva: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.
Maria Silva: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.
Maria Silva: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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?
Ansgar Dietrichs: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…
Marius van der Wijden:against this change when I… when I started?
Marius van der Wijden:And,
Marius van der Wijden: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.
Ansgar Dietrichs:You had your hand raised?
Ansgar Dietrichs:On off?
Ansgar Dietrichs:Okay, right. I do think it's not ideal, of course, this kind of the specific
Ansgar Dietrichs:proposed, shape is coming on the call, where we ideally would already want to make the decision.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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 (Geth):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…
Felix (Geth):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
Felix (Geth):Something that is actually possible.
Felix (Geth):And so, yeah, I would say… I could get behind this.
Ansgar Dietrichs:We have anyone from… Nethermind on the call?
Ansgar Dietrichs:Dennis?
Ansgar Dietrichs:A view on this?
marek:So, from my side, I really like, gas metering proposed by Maria.
Ansgar Dietrichs:Do you prefer…
Ansgar Dietrichs: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?
Ansgar Dietrichs:Maris just presented.
marek:Smaller version.
Ansgar Dietrichs:I see. Okay. From the baseu side, I think we just…
Ansgar Dietrichs:At an attempt at a hand raised?
Justin Florentine (Besu):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…
Justin Florentine (Besu):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 (Besu):I think that means we are unprepared to contribute to the decision today.
Carl Beekhuizen:Maybe, yeah, I mean, I think,
Carl Beekhuizen:to make, kind of, the decision clearer, I would, like, just propose what the, yeah.
Carl Beekhuizen: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.
Carl Beekhuizen: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,
Carl Beekhuizen: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.
Carl Beekhuizen: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.
Carl Beekhuizen: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…
Carl Beekhuizen: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,
Carl Beekhuizen: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…
Carl Beekhuizen:Multidimensional in something, eventually.
Carl Beekhuizen: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
Ansgar Dietrichs:So basically, like, for people who are maybe not super deep into this topic, so…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs:Switch more towards contract deployments.
Ansgar Dietrichs: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.
Ansgar Dietrichs:Maria?
Maria Silva:Yeah, I just would like to add, like, this thing of doing, like, a proper solution
Maria Silva: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
Maria Silva:What we have right now is, like, the minimum
Maria Silva: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
Maria Silva: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?
Maria Silva: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…
Ansgar Dietrichs:see for today that we could decide is the EIP as proposed by Marius.
Ansgar Dietrichs:or a static repricing, as proposed by Vitalik, with the understanding that basically, yeah, we are somewhat
Ansgar Dietrichs: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.
Ansgar Dietrichs:Again, would be nice to make a decision today,
Ansgar Dietrichs:Yeah, after listening to these different proposed solutions, do we have more client team opinions? Ben?
Ben Adams:Yeah, for some more consideration time.
Ben Adams: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?
Ansgar Dietrichs: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.
Ben Adams: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:We had 3 last… Can we maybe, yeah, share the document again? If we scroll down, to EIP7793, that's the conditional transactions one.
Ansgar Dietrichs:That was the one where we, basically, we left it off.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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…
Ansgar Dietrichs:if, say, someone from either of those two clients, or someone else with opinions on the CRP would want to make a case for…
Ansgar Dietrichs:Adding, 7793 to the box scope, then now would be the time to speak up.
Marc:Yeah, so the motivation for this EIP really is to
Marc:Provide better support for encrypted mempools.
Marc:And provide a way for users to send their transactions, with, like, a very strong guarantee that they won't be front-run.
Marc:And kind of the way it's designed is to kind of support, like,
Marc:This kind of happening more at the application level, so sort of a minimal change to the protocol that will allow
Marc:Sort of the application layer to do most of the work.
Marc:Yeah, that's the sort of main motivation.
Marc:So, I think that, I was discussing with Marius, because he had some concerns about the, the sort of block-building aspect of it.
Marc:And whether it kind of complicated that, so I responded to that.
Marc:And essentially, because it's only, targeted towards,
Marc: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,
Marc:Only certain, kind of, clients that,
Marc:you know, want to provide support for it.
Marc:But yeah, I'm not sure if…
Marc: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…
Marius van der Wijden:We'll just not be able to include them.
Marius van der Wijden:And, like, unsophisticated builders, or… Yeah.
Marius van der Wijden:I'm sorry, I… up… Upped my microphone.
Marc: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.
Marc: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.
Marc: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.
Marc:And attempt to place them at the top of block.
Marc:Before you kind of sequence the rest of the block.
Ansgar Dietrichs:Fabian?
Fabio Di Fabio:Yep, so… I'm,
Fabio Di Fabio:following this discussion, and I want to say that I understand that most of the staff for the
Fabio Di Fabio:Encrypted mempool is, out of protocol, but…
Fabio Di Fabio:Apart from the new conditional transaction type and the… transaction index, opcode.
Fabio Di Fabio:I'm more concerned about the transaction index of code.
Fabio Di Fabio:As a way to have… maybe a quick way to start implementing encrypted transaction mempool.
Fabio Di Fabio:And because I don't know if this, opcode We'll be always…
Fabio Di Fabio:be used also in future. Maybe it could be something that will be deprecated, and we know how difficulties tend to
Fabio Di Fabio: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.
Fabio Di Fabio:What about changing the…
Fabio Di Fabio:Block import validation rule to make sure that a conditional transaction is included in the right place.
Fabio Di Fabio:So instead of, adding the opcode, Working on the… Block validation rules.
Fabio Di Fabio:Have you thought about that?
Marc:Yep, so that's the way that the EIP does work.
Marc:So basically, it's kind of two parts, so there's…
Marc: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.
Marc:And the op code is actually for… more for a different purpose.
Marc:So, if you're actually one of the users who sent your transaction that's been included on-chain.
Marc:It's gonna be part of, like, in most cases, part of a bundle.
Marc: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.
Marc:You can't necessarily trust them.
Marc: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
Ansgar Dietrichs: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
Ansgar Dietrichs:On Breath's side, and we have Marek from Nethermind.
Ansgar Dietrichs: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.
Ansgar Dietrichs:just physically… just move on with the DFI decision.
Ansgar Dietrichs:and reconsider this for Edgestar.
Ansgar Dietrichs:Does that seem reasonable?
Ansgar Dietrichs:width.
Ansgar Dietrichs:for people.
Ansgar Dietrichs:Well, yeah, if any of the clients that I mentioned basically feel like they don't…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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…
Ansgar Dietrichs:I… yeah, then we'll deify it now.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:And then the last one to talk about before we can, loop back to the beginning is…
Ansgar Dietrichs:EIP8051, that is the precompile for MLDSA signature verification. So this was…
Ansgar Dietrichs:part of a broader, post-quantum kind of, like, bundle of changes. The other ones we have DFI'd, this one specifically.
Ansgar Dietrichs: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,
Ansgar Dietrichs:on this EIP and some of the related ones, I'm not sure if you are on the call today.
Renaud-ZKNOX:Yes, I am.
Ansgar Dietrichs:Perfect. Would you want to briefly summarize your comments on this?
Renaud-ZKNOX: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.
Renaud-ZKNOX:Deliptium actually seems to be the choice of Web 2, because it's already included in some implementation in Chromium.
Renaud-ZKNOX: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.
Renaud-ZKNOX:So we think… yeah, and there is no,
Renaud-ZKNOX:backward compatibility issue with this one, so we think that While Falcon
Renaud-ZKNOX: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.
Renaud-ZKNOX:Okay, what's the commands here?
Renaud-ZKNOX:da-da-da.
Renaud-ZKNOX: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.
Renaud-ZKNOX:verification.
Renaud-ZKNOX:So the… the constraints with, Pascantom signature, are as bandwidth.
Renaud-ZKNOX:Meaning that, size of signatures and public keys are far far larger.
Renaud-ZKNOX:So there are several, several efforts. Consensus, Consensus team is working.
Renaud-ZKNOX:Aggregation of signatures, what they… what they will use is,
Renaud-ZKNOX:Most probably hash-based, hash-based aggregation.
Renaud-ZKNOX:I'm not sure that having a stateful candidates would be good for a consensus layer, so here.
Renaud-ZKNOX:Here, I don't know if we need only one pre-compiled, or…
Renaud-ZKNOX: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…
Renaud-ZKNOX:Mainly is, is already, available for consensus, so maybe in the future, we could, devise,
Renaud-ZKNOX:What is optimal for consensus, and separate what is optimal from consensus and for execution layer.
Renaud-ZKNOX:However, having the aggregation mechanism, I guess we could…
Renaud-ZKNOX:Yeah, I mean, for the choice, yeah, I see what Maurice is writing.
Renaud-ZKNOX:I think that… I'm not sure that Ethereum should be the one.
Renaud-ZKNOX:redoing all the process that the NIST has taken for more than 8 years now.
Renaud-ZKNOX:So, mainly, I don't know how many cryptographers we have in the Ethereum ecosystem, but basically the NIST and ISAR
Renaud-ZKNOX:Are counting, hundreds of cryptographers that has been working for 10 years, so…
Renaud-ZKNOX: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.
Renaud-ZKNOX:And another thing is that, the consensus, will be fast to move, because,
Renaud-ZKNOX:As soon as the concern fork will be pushed, all nodes will switch at once.
Renaud-ZKNOX:But,
Renaud-ZKNOX: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.
Renaud-ZKNOX:So I think we… We need to…
Renaud-ZKNOX:To begin, the, the pedagogy, and,
Renaud-ZKNOX: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,
Carl Beekhuizen:If we had to choose something now, I think this would make a lot of sense.
Carl Beekhuizen: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.
Carl Beekhuizen:Also, I think with all the repricings going on, now and in HDAR, I think, like, the trade-offs between compute and
Carl Beekhuizen: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.
Carl Beekhuizen:Certainly for now.
Ansgar Dietrichs:Dano?
Danno Ferrin - Tectonic.xyz: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.
Danno Ferrin - Tectonic.xyz: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.
Danno Ferrin - Tectonic.xyz: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,
Danno Ferrin - Tectonic.xyz:for RSA and ECDSA signatures.
Danno Ferrin - Tectonic.xyz: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.
Danno Ferrin - Tectonic.xyz: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?
Ben Adams:Where we can say, alright, this is the process that we'll add.
Ben Adams:post-quantum signatures, maybe there's a… I don't know if there's a transaction type involved as well.
Ben Adams:So that we can… We can add them without them just being sort of randomly compiled.
Ben Adams:But in a more coordinated way.
Ansgar Dietrichs:Felix?
Felix (Geth):So, regarding the transaction type, just as a quick comment, so…
Felix (Geth):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.
Felix (Geth):So that's kind of how I see this. I think… I think sooner or later, we're gonna have to add
Felix (Geth):Some, post-quantum signature scheme into the… into the protocol as a pre-compile.
Felix (Geth):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 (Geth):So,
Felix (Geth):I am never really against adding specific crypto precompiles, I have to say, because the process of adding them basically is always the same.
Felix (Geth):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
Felix (Geth):Agreed upon by the… community of cryptographers, but I think in this case.
Felix (Geth):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…
Felix (Geth):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
Felix (Geth):Is always the same.
Felix (Geth):So I'm not inherently against it. It's also one of the extension points in Ethereum that is…
Felix (Geth):kind of the most isolated in some ways, because it's just a function exposed to the EVM.
Felix (Geth):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.
Felix (Geth):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
Antonio Sanso: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
Antonio Sanso:A lot well known is that
Antonio Sanso:So DSA, so Delitium has been standardized by NIST, and, it's… the signature is bigger than Falcon.
Antonio Sanso: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…
Antonio Sanso:Delidium has already been standardized.
Antonio Sanso: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…
Antonio Sanso: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 (Geth):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…
Antonio Sanso: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…
Antonio Sanso: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.
Antonio Sanso: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,
Ansgar Dietrichs: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…
Ansgar Dietrichs: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.
Ansgar Dietrichs:So… That's maybe what's leaning? Do we…
Ansgar Dietrichs: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?
Ansgar Dietrichs:Okay, I think if… if it's… if all the clients basically are…
Ansgar Dietrichs: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…
Ansgar Dietrichs:I think that the default decision here is DFI for Glamsterdam.
Ansgar Dietrichs: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.
Ansgar Dietrichs:We can look into this async, but… but yeah, it's…
Ansgar Dietrichs:I would say DFI is the last opportunity for any… Objections to the DFI decision?
Ansgar Dietrichs:Okay, then we, for Amsterdam DFI, the… Be yippee.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs:Has there been any progress on this?
Ansgar Dietrichs:Okay.
Ansgar Dietrichs:Then,
Ansgar Dietrichs:I would say, then, this kind of… is it auto-DFI? Is there any, any, any objections to, to DFI-ing this?
Ansgar Dietrichs:Okay, then 7971 is DFID for Clemsonam.
Ansgar Dietrichs:The next one up, would be, EIP8032.
Ansgar Dietrichs:which is the size-based storage gas pricing. So the idea was to basically
Ansgar Dietrichs: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.
Ansgar Dietrichs:At the cost of a small, kind of, state-treat transition. Do we, like…
Ansgar Dietrichs:Do we have anyone with… opinions on… on this EIP?
Ansgar Dietrichs:Carlos?
CPerezz:Yeah, so very quickly, we… we basically benchmarked initially this, by running worst-case attacks to Zen.
CPerezz: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.
CPerezz:On the other side, I'm also trying to investigate whether depth, plays into it, and basically which percentage each of them,
CPerezz: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.
Ansgar Dietrichs: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:Which would be net… Thank you, man.
Ansgar Dietrichs:Maybe you can speak to this.
Guillaume:So, yeah, those two EIPs, like the binary trees, transition, and this thing have nothing in common. However.
Guillaume: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…
Ansgar Dietrichs: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
Ansgar Dietrichs:SDOS, kind of according to the worst-case performance of the heaviest contracts.
Ansgar Dietrichs:Which, of course, it's not ideal. It will make everything a bit more expensive for users.
Ansgar Dietrichs:And then, yeah, the reason for not doing it would be the complexity, so that's the trade-off here.
Guillaume: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.
Guillaume: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,
Guillaume:It helps to demonstrate the transition, so we will implement it anyway. In fact, the implementation exists.
Guillaume: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…
Ansgar Dietrichs:Okay. Then, indeed.
Ansgar Dietrichs:we will DFI this, or, yeah, with Strait, I think. I mean, DFI is maybe the cleaner way, but either way, same outcome.
Ansgar Dietrichs:And, yeah.
Ansgar Dietrichs:move on to the next EIP, EIP7907.
Ansgar Dietrichs: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.
Ansgar Dietrichs:In this fork, the last… the currently only remaining PFI at EIP is 7907, which would do it, based on a…
Ansgar Dietrichs: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
Ansgar Dietrichs: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…
Ansgar Dietrichs:constant…
Ansgar Dietrichs: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.
CPerezz:Boom.
CPerezz: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.
CPerezz: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.
CPerezz: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.
CPerezz: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.
CPerezz: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.
CPerezz: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,
CPerezz:in its research, I think the easiest way to go will basically be,
CPerezz: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.
CPerezz:disabled.
CPerezz:There's only two more things I want to mention here. The first one is, notice that
CPerezz: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,
CPerezz:bytecode deployment from EIP8037, and therefore, we're allowed to deploy this,
CPerezz: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…
Ansgar Dietrichs:approaches here, or three decisions we could make. Decision one, of course, would be to do nothing about contract code. Decision two would be
Ansgar Dietrichs: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,
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs:Do we have comments on which of those three options would be preferred? Ben?
Ben Adams:So I… For the simple bump.
Ben Adams:But to the level of 32, we can revisit because they also changed the… Account storage.
Ben Adams:And then we can revisit what we want to do after that.
Ansgar Dietrichs:maria?
Maria Silva:I… I just wanted to, so, to…
Maria Silva: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
Maria Silva: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.
Maria Silva:What this means is that if we want to go, let's say, from 24 to 64, this means that
Maria Silva:We would have to price…
Maria Silva: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
Maria Silva: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
Maria Silva:The throughput on these operations for Huge majority of users.
Maria Silva:linearly worse,
Maria Silva:just because we have the possibility of increasing the contract side. So, to me, this is a huge…
Maria Silva:drawback for a fork that is all about scalability. So, essentially, we are repricing
Maria Silva:Called accessing operations in a worst case.
Maria Silva: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,
Maria Silva: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.
Dragan Rakita:It seems like my spate.
Dragan Rakita:That's just… Maybe you should probably do it.
Ansgar Dietrichs:Guillaume?
Guillaume: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,
Guillaume:To be too low for what you get, or it's going to be too high for a…
Guillaume:for the… for the… builder.
Guillaume:The thing is, as long as you don't have something like 2926, which tries to precisely pay exactly for what you pay for.
Guillaume:You're going to have this, this imbalance, so…
Guillaume: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.
Guillaume:Either you decide you want to… to, like, the contract code size to… sorry, the access
Guillaume: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.
Guillaume: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…
Guillaume:The transaction sender, or the… or the blog builder.
Guillaume:But yeah, in my view, this is already a choice we made.
Guillaume:So that's, there's no point in, selecting or, like, scheduling an EIP. That is going to create a temporary cost.
Guillaume: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…
Maria Silva: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.
Maria Silva: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…
Maria Silva:where I'm concerned is, like, increasing contract size too much will be hurting contract loading…
Maria Silva:For all the other users at the same level.
Maria Silva:And contract loading is fairly a common thing we do, so…
Maria Silva: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: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.
Carl Beekhuizen: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,
Carl Beekhuizen: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.
Carl Beekhuizen:Like, it exacerbates the situation in some ways now.
Carl Beekhuizen: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,
Ansgar Dietrichs: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…
Ansgar Dietrichs: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
Ansgar Dietrichs: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?
Ansgar Dietrichs: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.
Ben Adams:But if we look at the goal, the short-term goal is to improve developer's experience, and a small bump
Ben Adams:We'll give that to, like, 32.
Ben Adams:Whereas… In a longer-term vision, we want to be able to allow
Ben Adams:Larger contracts, and for that.
Ben Adams: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…
Ben Adams:Stopgap to buy some time, make every developer happy.
Ben Adams:And they're used to doing 24KB contracts, so it'll be a while before they start hitting 32.
Ben Adams:4K or the 4K.
Ansgar Dietrichs:Yeah, so then maybe I would just, like, because I really want to make this decision today,
Ansgar Dietrichs:my prop…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:CFI-ing Julio's EIP with the understanding that it would be bumped to 32 kilobytes specifically? Is this…
Ansgar Dietrichs:Does this have rough consensus?
Ansgar Dietrichs:Or…
Ansgar Dietrichs:Yeah. It's basically any client, any client representative, I see, for example, Maurice in chat, that might have some…
Ansgar Dietrichs:or weak opposition, at least? Like, so any clients that are opposed to this, to this option?
Ansgar Dietrichs: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,
Ansgar Dietrichs:In the interest of today, getting through the scoping.
Guillaume:GFI, which one?
Ansgar Dietrichs:see if I do… so this would be… let me confirm the number.
Guillaume:Julius Pierre. Julius…
Ansgar Dietrichs:Julius. This is correct, yes.
Guillaume:Okay, well…
Ansgar Dietrichs:7954, but… yes, exactly. 7954.
Ansgar Dietrichs:And then…
Ansgar Dietrichs: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?
Ansgar Dietrichs:Okay, then I would say we DFI7907, and we instead CFI as a business swap-in replacement, 7954,
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:And…
Ansgar Dietrichs: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.
Ansgar Dietrichs:Or Maris, maybe do you…
Ansgar Dietrichs: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…
Marius van der Wijden:the Julio route, we should go the Julio route, double the… the init code.
Marius van der Wijden:That's it, and… and we're… we're done with, like, this…
Marius van der Wijden: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.
Ansgar Dietrichs:Remove init code size limit, and we instead just go with the…
Ansgar Dietrichs: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.
Ansgar Dietrichs:Anyone that's opposed to that?
Ansgar Dietrichs:Okay, then we really only have the one delayed decision until Monday,
Ansgar Dietrichs:Which was… which one was that? That was the…
Ansgar Dietrichs: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…
Ansgar Dietrichs:for all intents and purposes, otherwise the grump scope is, at this point, final, at least to the CFI stage.
Ansgar Dietrichs: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
Ansgar Dietrichs:See most of you all on ACDT next week.
Justin Florentine (Besu):Thanks, y'all.
Marius van der Wijden:Thank you, bye-bye.
Danno Ferrin - Tectonic.xyz:Thanks, bye.
Danno Ferrin - Tectonic.xyz:Sorry, you…
Marius van der Wijden:God damn, let's…
Chat Logs
00:03:30
Ansgar Dietrichs:agenda: https://github.com/ethereum/pm/issues/1867
00:03:35
Justin Florentine (Besu):bens really got his prompt dialed in. very consistent style.
00:05:11
Barnabas:We gonna hear from Lodestar on monday to let us know if its easy to add.
00:05:17
Barnabas:Unless any other CL team is happy to step up
00:05:50
stokes:It’s just sending the slot across the engine API? I would expect its pretty straightforward
00:06:00
Dragan Rakita:Syncing with CL can be a overhead on release/versioning side, would remove it from scope, it is small EIP in general.
00:06:07
Barnabas:Replying to "It’s just sending th..."
it is a straightforward change but its a change none the less
00:06:45
nixo:“tech illiterate” that group lol
00:06:49
Marius van der Wijden:Slotnum is the only one that requires el/cl right?
00:06:59
Marius van der Wijden:Maybe we can pull this one out
00:07:06
Mario Vega:Replying to "Slotnum is the only ..."
Three remaining are EL only
00:07:10
Stefan Starflinger:https://github.com/ChainSafe/lodestar/pull/8747 this is the change required according to claude
00:07:13
stokes:Replying to "It’s just sending th..."
I am surprised the 4788 route is that expensive given how cheap gas is getting (towards the EIP in particular)
00:07:18
Marius van der Wijden:But also there is a question about rebasing the other eips on top a moving bal target
00:09:20
Toni Wahrstätter:https://github.com/ethereum/execution-specs/pull/1401#event-22068883264
00:11:45
Łukasz Rozmej:will this break any receipt users?
00:12:14
Marius van der Wijden:Sorry again in writing:
We want the receipt to contain the used gas not including the refunds?
00:12:19
frangio:https://ethereum-magicians.org/t/evm-immediates/25605#p-62704-option-22-no-changes-to-jumpdest-analysis-5
00:12:56
Ansgar Dietrichs:Replying to "Sorry again in writi..."
should we come back to this or can we clarify in chat / async?
00:13:07
Marius van der Wijden:Replying to "Sorry again in wri..."
async please
00:13:15
frangio:https://github.com/ethereum/EIPs/pull/11085
00:14:58
Toni Wahrstätter:Replying to "Sorry again in writi..."
For BALs, if we want to use the receipt to enforce the block gas limit, it would be handy to have the gas_used BEFORE refunds.
If we say receipt (with the cumulative gas used) is user facing (e.g. eth_getTransactionReceipt) we can do the gas_used AFTER refunds - however, then you cannot use the receipt for validating the block gas limit being obeyed (as you would need to know the refunds of txs for that)
00:15:57
Marius van der Wijden:Replying to "Sorry again in wri..."
We use the gas before refunds now, right? So I think its fine that the users don't have that
00:16:27
Radek | solidity:Personally like postfix push version. It would make possible to easily add new opcodes using immediate arguments.
00:17:22
Toni Wahrstätter:today we use gas after refund.
As 7778 is spec'ed today, we use max(
tx_gas_used_before_refund, calldata_floor_gas_cost
) for block gas accounting
00:17:33
Dragan Rakita:Do you prefer first or second format?
00:17:48
Toni Wahrstätter:Replying to "Sorry again in writi..."
@Andrew Ashikhmin this might also clarify your question regarding 7623 <> 7778
00:18:10
Radek | solidity:which one is first?
00:18:35
Justin Florentine (Besu):existing bitoacking
00:18:44
Justin Florentine (Besu):bitpacking, per the EIP
00:18:47
Dragan Rakita:First == EIP, second == SWAPN PUSH2 0x0000
00:19:12
Radek | solidity:second. postfix push 🙂
00:19:41
Radek | solidity:so basically PUSHX tells you immediate size
00:19:51
Radek | solidity:for future
00:19:52
frangio:Replying to "First == EIP, seco..."
it would be PUSH1 strictly IMO
00:20:17
spencer-tb:https://github.com/ethereum/EIPs/pull/9003
00:20:30
Justin Florentine (Besu):why not introduce IMDN instead of overloading PUSHN ?
00:21:06
frangio:Replying to "why not introduce ..."
not possible, it changes jumpdest analysis and is not backward compatible
00:21:14
Parithosh Jayanthi:Should we time box and discuss the rest async?
00:21:30
danceratopz:About defining the devnet-2 scope. Will scope a devnet on Monday that we aim to launch on Wednesday? Or when is devnet-2 launch?
Scoping the devnet today would help prioritize testing efforts (and a test fixture release).
00:21:56
frangio:Replying to "why not introduce ..."
but if we go with PUSH-postifx option, we could have a convention where the PUSH* opcodes are rendered as IMDN* in assembly/disassembly
00:22:01
Radek | solidity:Replying to "why not introduce IM..."
PUSH is a hack but I would say the best we can have now w/o EOF 🙂
00:22:27
Barnabas:Replying to "About defining the d..."
I don’t think ACDE is the place for this.
00:22:38
Barnabas:Replying to "About defining the d..."
We still have many open questions about other EIPs whether they should be scheduled or not.
00:22:42
Dragan Rakita:Replying to "why not introduce IM..."
PUSH is a lot more structured way to use immediates.
00:23:00
Barnabas:Replying to "About defining the d..."
Maybe we can discuss these open questions in the end if we still have some time leftover but ideally ACDT should be the place to finalize scopes
00:23:05
vitalik:postfix push means that you can jump onto that (normally inoperative) push, right?
00:23:20
Radek | solidity:Replying to "why not introduce IM..."
Sorry. Have we decided? I missed this part of the call
00:23:29
Justin Florentine (Besu):Replying to "why not introduce IM..."
why does it break jumpdest analysis, because it's effectively a 3 byte opcode?
00:23:36
frangio:Replying to "postfix push means..."
no because there is no JUMPDEST that allows that jump
00:24:30
frangio:Replying to "why not introduce ..."
it's explained here: https://ethereum-magicians.org/t/evm-immediates/25605
00:24:31
vitalik:Replying to "postfix push means..."
aaaah right, I was thinking about generic pushdata
00:24:31
Radek | solidity:Replying to "why not introduce IM..."
I think it’s more about that it will require a change there.
00:25:56
Barnabas:whoever loaded that notes.ethereum.org page, DO NOT refresh, as hackmd site is down, so if you refresh we gonna lose the tracker 😄
00:26:10
Trent:Everyone increases their volume and then ansgar is going to crash in at full volume 😅
00:26:24
Ansgar Dietrichs:“measure state growth on a different axis than computation” - computation here includes normal i/o (read/write), so just the state creation is separate
00:26:36
vitalik:I would call SSTORE 312.5 gas per byte, info-theoretically an sstore adds ∼64 bytes (worst case) to state size
00:26:59
Ansgar Dietrichs:Replying to "Everyone increases t..."
I’ll make sure to whisper
00:27:03
Danno Ferrin - Tectonic.xyz:Multidimensional gas by another name. This uncouples storage limits from computation limits. 👍
00:27:05
Justin Florentine (Besu):Replying to "why not introduce IM..."
ahhhh it's the masking thank you.
00:27:28
CPerezz:Replying to "I would call SSTORE ..."
Yes. That was my mistake to not account keys also..
00:27:44
CPerezz:Replying to "I would call SSTORE ..."
Will update the site to reflect this
00:27:44
Anders Elowsson:We essentially do not want the expected relative increase in consumed state gas to encroach on the regular gas limit, since it would harm our general scaling efforts
00:28:36
Ansgar Dietrichs:Replying to "Multidimensional gas..."
yes but in a very lightweight variant, hopefully much simpler than full multidim gas
00:29:38
vitalik:this extra state gas reservoir is nice, as when we do full multidim it's a backwards compatible way to allow calls to still leave behind some resources in case the child fails (ie. gas observability use cases will still work)
00:29:51
Danno Ferrin - Tectonic.xyz:Replying to "Multidimensional gas..."
but we don’t get indepedently floating limits/costs, which also means we don’t get people cornering the market on storage becaus they can.
00:29:53
vitalik:we should charge 5000 (storg
00:30:06
vitalik:Replying to "we should charge 5..."
storage edit gas)
00:31:38
Maria Silva:Why is it hacky?
00:31:48
Ansgar Dietrichs:if we don’t put this into Glamsterdam, we will risk being at 1TB yearly state growth rate by the end of this year :-)
00:32:08
vitalik:the alternative is we change storage creation costs from
00:32:11
Łukasz Rozmej:Replying to "if we don’t put this..."
or we don't increase gas limit
00:32:22
vitalik:200 per byte 25000 per account 20000 per slot
00:32:31
Ansgar Dietrichs:Replying to "if we don’t put this..."
right, but then all of
ePBS
BALs
repricings
are useless
00:32:32
vitalik:to 300 100000 80000
00:32:39
Marius van der Wijden:Replying to "if we don’t put t..."
Both not great outcomes
00:32:52
marek:Replying to "if we don’t put this..."
of course, we should increase gas limit :)
00:32:56
vitalik:the main challenge with multidim in the evm is that you have to have a way to snake it through child calls
00:33:09
Marius van der Wijden:Replying to "the main challenge..."
Its actually not that bad
00:33:14
Łukasz Rozmej:Replying to "if we don’t put this..."
what is the main problem 16M tx gas limit?
00:33:29
CPerezz:Replying to "200 per byte 25000 p..."
Accounts are the highest priority IMO. Base already has an issue with state root recompilation due to the insane account trie they hold.
And this only gets worse
(Though avg. depth doesn’t. Which definitely mitigates)
00:33:31
Anders Elowsson:There is EIP-8075 that is less hacky, but it requires two additional header variables etc.
00:33:47
Marius van der Wijden:Replying to "the main challenge..."
Its much less worse than having to reprice every 6 months
00:33:51
Dragan Rakita:Replying to "if we don’t put this..."
If you increase gas price per new byte in bytecode you would not be able to deploy 24kb byte codes.
00:33:55
vitalik:Replying to "the main challenge..."
indeed, and this eip is basically doing a big portion of that work :D
00:34:06
CPerezz:Replying to "if we don’t put this..."
You can leave byte code aside. (I’ll justify later)
00:34:13
Anders Elowsson:Replying to "There is EIP-8075 th..."
The endgame multidimensional fee market requires us to handle gas introspection.
00:34:23
Toni Wahrstätter:Regarding EIP-7778, clarified the interaction with EIP-7623 in the EIP:
https://github.com/ethereum/EIPs/pull/11090
cc @Ben Adams @Andrew Ashikhmin @Marius van der Wijden
00:35:07
Marius van der Wijden:Also full fully-dimensional gas would require new transaction types etc.
00:35:53
danceratopz:Don't forget to shout, Marius.
00:35:55
CPerezz:Marius, you need to review your pulse audio config for the mic.
00:35:59
felipe:yell louder
00:36:09
Barnabas:micdao
00:36:13
Justin Florentine (Besu):nothing. i got nothing
00:36:26
Marius van der Wijden:This seems to me the best solution given the tradeoffs we have
00:37:07
Marius van der Wijden:Only speaking for myself atm
00:37:18
Dragan Rakita:Change looks like it is in good direction, would CFI
00:37:23
Marius van der Wijden:Well "speaking"
00:37:45
nixo:yelling quietly for yourself
00:38:12
danceratopz:Replying to "About defining the d..."
Ah hackmd is backup and it says end of january, i thought it said Wed 21st Jan :) Then it's fine to complete scoping in ACDT on Mon.
https://notes.ethereum.org/@ethpandaops/bal-devnet-2
00:40:18
Justin Florentine (Besu):that sounds like something i wouldn't be worried about ttrying to remove later
00:40:20
Ansgar Dietrichs:the main worry about the proposal by Vitalik is that we could in principle see very high state growth through contract code (because that would be 3x underpriced)
00:40:22
CPerezz:We need some handle on state growth until we decide how do we tackle it (expiry etc…)
And this seems the simplest solution that we can always “revert” or “update”
00:40:37
Danno Ferrin - Tectonic.xyz:(a) no change (b) much higher fixed cost (c) cost floating with gas limit.
No change is an existential risk to upping the gas limit further.
00:40:48
Anders Elowsson:This is an alternative that exists: https://eips.ethereum.org/EIPS/eip-8075
I like it but it adds 2 header variables etc
00:40:57
CPerezz:Replying to "the main worry about..."
Code has been free to deploy almost forever. Why is it an issue now when everybody deploys duplicated code?
00:41:14
Anders Elowsson:Replying to "This is an alternati..."
Apparently it is too complex as I have understood it
00:41:29
CPerezz:Replying to "This is an alternati..."
What are your takes on the tradeoffs?
00:42:03
Maria Silva:Replying to "the main worry about..."
The difference would be even large, so the potential for attack is much higher
00:42:12
Anders Elowsson:Replying to "This is an alternati..."
It adds 2 header variables. It allows us to target a specific state growth and guarantees fulls scaling. It requires implementing a 4844 mechanism for the state gas price
00:42:27
Marius van der Wijden:Replying to "This is an alterna..."
Also it breaks the gas opcode
00:42:45
Anders Elowsson:Replying to "This is an alternati..."
No
00:42:59
Anders Elowsson:Replying to "This is an alternati..."
@Marius van der Wijden What do you mean by this?
00:43:46
Justin Florentine (Besu):is there a link to the slides @Marius van der Wijden presented?
00:44:02
Łukasz Rozmej:So one thing to consider - by making state growth much pricier, while keeping 16M tx gas account limit, arn't we hindering usability, making individual transaction not being able to support some scenarios that are today supported?
00:44:09
Marius van der Wijden:https://docs.google.com/presentation/d/1zRVR-tziS0Z0IACiDlcOPOUmkPdaBvjE-b10yH35iOY/edit?usp=sharing
00:44:16
Marius van der Wijden:yes exactly, thats why we need the multidimensional metering
00:44:52
Maria Silva:No, because state creation costs do not count to the 16M limit
00:45:02
Barnabas:ACDT
00:45:07
Toni Wahrstätter:that's were the metering would help. We could allow large contract deployments (using more than 16.78M gas) while still keeping the 7825 tx gas limit
00:45:14
Ameziane Hamlat:ACDT would be great
00:46:57
Marius van der Wijden:I don't think we should do conditional transactions edit: in glamsterdam
00:49:05
Ansgar Dietrichs:oh of course NOW marius is loud… :-)
00:50:54
Łukasz Rozmej:Replying to "So one thing to cons..."
how that effects estimateGas?
00:52:43
Marius van der Wijden:Replying to "I don't think we s..."
Can we timebox this?
00:52:47
Felix (Geth):would it work with just the opcode?
00:55:02
Marius van der Wijden:While I like the idea, I think Glamsterdam already has a lot of more impactful EVM improvements
00:55:25
Luis Pinto | Besu:Besu has this implemented but would be ok to DFI since there’s no one shouting for it
00:55:33
Renaud-ZKNOX:PQ Signatures for Ethereum
ML-DSA (Dilithium): NIST standard, ZK-friendly, ~2.4 KB sigs, HW wallet impl done. Con: 40x larger than ECDSA.
FALCON: Smallest (~666 B), L2/EVM friendly (separable hash-to-domain). Needs ORAM for RAM limits, harder on constrained HW (working on it).
SPHINCS+: Hash-based only, huge sigs (8-49 KB). Justin Drake's team working on reduced stateful version. Cons: stateful, not web2 compatible.
TL;DR: ML-DSA = pragmatic choice for AA + HW wallets (~13M gas). FALCON = more complexity but cheaper (~6M gas). SPHINCS+ = large but worth separate precompile for Consensus Layer.
00:56:03
Anders Elowsson:This is a document on options that exist for EIP-8037:
https://notes.ethereum.org/@anderselowsson/3-paradigms-for-state-creation-repricing
As was mentioned already on the call, an important thing to remember is that the actual tracking of state creation is something that we will always have use for going forward.
00:57:08
vitalik:we really need to get better at treating all EVM feature additions as having a cost (on all future EVM impl developers ever) and not treat them as free :P
00:57:27
vitalik:Replying to "we really need to ..."
speaking generally
00:57:59
frangio:Replying to "we really need to ..."
we hardly treat them as free, there are a lot of evm features that were rejected for this fork
00:58:19
Justin Florentine (Besu):Replying to "we really need to ge..."
you can have feature points scaled to the protocol guild treasury 🙂
00:58:42
Marius van der Wijden:I personally think its too early to make a decision on which pq sig scheme we want to support. Don't want another blake, keccak, ecAdd, ecMul, ecPairing, ...
00:58:48
vitalik:Replying to "we really need to ..."
5x the state creation gas on new opcodes/precompiles
00:58:50
Carl Beekhuizen:Replying to "we really need to ge..."
@frangio mostly due to the one-time cost, not the ongoing maintenance
00:59:05
Dragan Rakita:Replying to "PQ Signatures for Et..."
This is good summary
00:59:10
Danno Ferrin - Tectonic.xyz:Replying to "I personally think i..."
There is no way on earth we support just one. We need to make many avaialble
00:59:42
Ansgar Dietrichs:Replying to "I personally think i..."
I agree though, I personally would rather see a coordinated fork with multiple integrated pq features, instead of having them trickle into the EVM one-by-one
00:59:58
Danno Ferrin - Tectonic.xyz:The buzzword is “Cryptographic Agility” that gives us bult in escape hatches if replacement crypto algorithms have their own security iseuss
01:00:27
Toni Wahrstätter:Replying to "So one thing to cons..."
I assume we could have estimateGas return {gas, stateGas}
01:01:29
Benedikt Wagner:Replying to "PQ Signatures for Et..."
Also note: NIST is delaying standardizing Falcon
01:01:37
Justin Florentine (Besu):a precompile feels like a pretty mild committment to me
01:01:50
Łukasz Rozmej:Replying to "So one thing to cons..."
ok my stance:
Keep state growth pricing as is
Do modest gas increases, where state growth increase is acceptable
Focus on repricing compute down where possible
01:02:18
Łukasz Rozmej:Replying to "So one thing to cons..."
you basically get same results without the complexity (and marketing number)
01:02:22
Dragan Rakita:Replying to "PQ Signatures for Et..."
Is the falcon the one that uses floats?
01:03:22
Ansgar Dietrichs:danno do you still have your hand up?
01:03:27
Benedikt Wagner:Replying to "PQ Signatures for Et..."
Yes, Falcon uses floats
01:03:49
Danno Ferrin - Tectonic.xyz:Replying to "danno do you still h..."
when did zoom get rid of auto-lower
01:03:53
Justin Florentine (Besu):Replying to "PQ Signatures for Et..."
internally or across the signature boundary?
01:04:03
CPerezz:Don’t the gas limit increases and compute repricings allow to skip precompiles? It would be A LOT better to have these things implemented in solidity in a contract and not affecting the protocol
01:04:37
Ansgar Dietrichs:Replying to "danno do you still h..."
yes the zoom behavior somehow got worse there
01:04:45
Dragan Rakita:Replying to "PQ Signatures for Et..."
It is internally, have read something that it was hard to audit bcs of it.
01:05:03
CPerezz:Replying to "Don’t the gas limit ..."
Ie. If we can make it to 100/150M gas limit and we have super cheap compute, what prevents us from just not going precompile and let people implement this as a solidity lib contract or similar?
01:05:10
iPhone:For pricing it, would we evaluate it against some zkEVMs too?
01:05:33
Dragan Rakita:tldr for me, to early for this kind of precompile
01:05:39
Marius van der Wijden:Replying to "Don’t the gas lim..."
I hope we get to a 300-700M gas limit soon™️
01:06:20
vitalik:Replying to "Don’t the gas lim..."
imo the right balance is simd
01:06:36
vitalik:Replying to "Don’t the gas lim..."
that lets you do the hard parts of all lattice stuff
01:06:52
Benedikt Wagner:Replying to "PQ Signatures for Et..."
@Justin Florentine (Besu) what does that mean? Signatures and keys should be objects that we never open and that are only consumed by the algorithms of the signature scheme
01:07:19
Renaud-ZKNOX:yep as ed25519 is better than k1
01:07:31
Renaud-ZKNOX:(r1 sorry)
01:07:37
Łukasz Rozmej:Replying to "So one thing to cons..."
Another approach is to increase tx cap - make it configurable parameter - BPO like and adjust it to gat limit
01:08:02
CPerezz:Replying to "Don’t the gas limit ..."
Do we have any numbers on perf/gas costs for these if implemented in solidity??
Maybe this gives light already on whether SIMD is a must or no (as SIMD would be really tricky to support in EVM considering all the variety of hosts that run it).
Also ZKEVM proving SIMD is a thing?
01:08:03
Benedikt Wagner:Agree with Antonio!
01:08:04
Justin Florentine (Besu):Replying to "PQ Signatures for Et..."
yes exactly. i.e. if falcon only uses floats internally, i don't really care.
01:08:05
Danno Ferrin - Tectonic.xyz:Replying to "PQ Signatures for Et..."
Floats are used for the signature generation and key generation. Verifying a signature is all integers. But the use of floats makes stuff like HD derivation a little squirly
01:08:06
Renaud-ZKNOX:But it must be investigated
01:08:22
Łukasz Rozmej:Replying to "So one thing to cons..."
@Marius van der Wijden WDYT?
01:08:29
Fab:I agree with Antonio. Also keep in mind that pre-quantum signatures have been tested for years, these sigs here are very new. Web2 solves the problem by deploying dual solutions where both a classical and a post-quantum resistant sigs must be used in pair. I am not sure this is an option here.
01:08:56
Renaud-ZKNOX:Well, we are relying on KZG, which is far newer than LWE and NTRU
01:09:11
Maria Silva:Replying to "So one thing to cons..."
“Focus on repricing compute down where possible” -> isn’t this much more work than 8037?
01:09:15
Fab:Indeed I've never been a fan of KZG, lol
01:09:18
vitalik:Replying to "Don’t the gas lim..."
the point of simd is not just to use literal simd features of cpus, it's do reduce the ratio of evm interpreter overhead to computation, so you get large speedups even from "naive" impls
01:09:21
Benedikt Wagner:Replying to "Well, we are relying..."
Valid point
01:09:22
Renaud-ZKNOX:but yes for sure Accounts will be hybrid
01:09:48
Maria Silva:Replying to "So one thing to cons..."
“Keep state growth pricing as is” -> if we do this, we won’t be able to use the gains from BALs and ePBS
01:09:49
Felix (Geth):Replying to "I agree with Anton..."
It's an option with account abstraction
01:10:06
Fab:Replying to "Well, we are relying..."
Indeed I've never been a fan of KZG, lol
01:10:43
Ben Adams:Replying to "So one thing to cons..."
Suggesting 300MGas before H*? 🤔
01:11:06
Maria Silva:Replying to "So one thing to cons..."
BTW, we are already at a growth rate of 100 GiB per year at 60M gas limit. I don’t think we can continue to increase the gas limit without making state growth more expensive
01:11:11
Łukasz Rozmej:Replying to "So one thing to cons..."
maybe more work, but less protocol complexity that stays forever, end result the same
01:11:21
Anders Elowsson:Replying to "So one thing to cons..."
@Łukasz Rozmej If you reprice compute down, state gas will still take up a larger proportion of the gas limit. It’s the same effect as increase the price of state gas essentially.
01:11:50
Łukasz Rozmej:Replying to "So one thing to cons..."
yes but 16M gas limit per tx is the problem
01:12:00
Łukasz Rozmej:Replying to "So one thing to cons..."
either we move it too, or we do this dancing around it
01:12:09
Łukasz Rozmej:Replying to "So one thing to cons..."
with big complexity increases
01:14:14
Maria Silva:Replying to "So one thing to cons..."
Also, we cannot make compute operations cheap enough go get the same gain as making state creation more expensive and increasing the block limit
01:14:32
Maria Silva:Replying to "So one thing to cons..."
So, we either make state more expensive or we limit scalability
01:14:36
Dragan Rakita:We are fine to DFI it
01:14:59
Łukasz Rozmej:Replying to "So one thing to cons..."
ok why not increase tx gas cap then and be done with it easily?
01:17:14
Maria Silva:Replying to "So one thing to cons..."
Because we lose on the parallelization gains from BALs. Now the worse case block will not be at 16M sized txs, but a higher limit
01:17:23
Maria Silva:Replying to "So one thing to cons..."
So, we loose scalability anyway
01:17:47
Marius van der Wijden:I think a simple bump is pretty dangerous
01:18:21
Marius van der Wijden:Replying to "I think a simple b..."
My preference is to (1) do nothing (2) go with 7907
01:18:50
Marius van der Wijden:Replying to "I think a simple b..."
(3) do code chunking
(4) do the simple bump
01:19:34
Ansgar Dietrichs:the two relevant EIPs:
https://eips.ethereum.org/EIPS/eip-7907
https://eips.ethereum.org/EIPS/eip-7954
01:20:00
Guillaume:Replying to "I think a simple bum..."
bump it's not dangerous as per Carlos data, also happy to do nothing
01:20:13
vitalik:Replying to "I think a simple b..."
what size of bump? what about 32k?
01:20:20
Ansgar Dietrichs:one main takeaway for me from this analysis:
mostly constant time for any code loads below 10KB
mostly linear time for additional code loads above 10KB
01:20:21
Luis Pinto | Besu:My thoughts on this one:
We should not just test with Geth but other clients before we make a decision regarding the right size to go with
We should test EXTCODECOPY instead as some clients might have some optimisations to cache the code size in the DB
01:20:26
Marius van der Wijden:Replying to "I think a simple b..."
That presumes a 60M gas limit
01:20:38
Guillaume:Replying to "I think a simple bum..."
32k looks safe
01:21:25
Guillaume:Replying to "I think a simple bum..."
I wouldn't go for 64kb personally
01:21:41
Marius van der Wijden:Replying to "I think a simple b..."
A 32k bump will mean either big contracts will be underpriced by 25% or smaller contracts will pay 25% more than they should be paying
01:22:25
Guillaume:that's going to be the case as long as you don't have something like 2926
01:22:43
CPerezz:There’s no reason for not going to 64kb
01:23:00
CPerezz:Again, Geth with enabled cache would perform infinitely better (and its the default case)
01:23:34
CPerezz:Replying to "I think a simple bum..."
The “it’s dangerous” claims aren’t backed by data at all.
I mean, why we make arguments that go directly against the data we took??
01:24:24
CPerezz:Replying to "I think a simple bum..."
If we want 500MGas, then ok. We need to be careful. But if we target 100-150M gas for H*, I don;’t think this is an issue
01:24:42
Marius van der Wijden:Replying to "I think a simple b..."
If we are trying to price the contract code more accurately, then this will be a problem
01:25:40
Ansgar Dietrichs:for context, the 60 MGas/s is the target on the compute side pre BAL speedup (expected ~3x).
But (large) contract loads don’t get a BAL speedup, so the performance target there would be more 180 MGas/s
01:25:45
CPerezz:Replying to "I think a simple bum..."
We will still be able to do it. And reduce the time it takes for users to get this feature
01:25:47
Marius van der Wijden:Replying to "I think a simple b..."
And yes, we might be able to go to 500MGas. BAL and EPBS alone would give us that
01:26:45
Ansgar Dietrichs:we will reprice contract loads anyway, so these performance considerations are not a blocker for a bump. e.g. going to 32 KB will just mean that all contract loads will have to be 33% more expensive than they would otherwise be
01:26:47
Marius van der Wijden:I'm a fan of 2926
01:27:10
Ansgar Dietrichs:Replying to "I'm a fan of 2926"
we will not revisit that decision today :-)
01:27:11
CPerezz:Replying to "we will reprice cont..."
Exactly! And with a simple bump we can always go for more complex repricings
01:27:14
CPerezz:Replying to "we will reprice cont..."
In the future
01:28:56
Toni Wahrstätter:Every small contract would be punished because we'd have to price it for the worst-case scenario. Agree with maria, this is a big hit
01:29:45
Marius van der Wijden:I think we want less refunds not more
01:29:55
Luis Pinto | Besu:Replying to "I'm a fan of 2926"
Also a fan of 2926 that fixes the problem at the root. Leaning towards small bump for now to 32KB with no other changes
01:30:52
Greg K | Lido:32KB is still not a big bump, 7907 suggested 48KB, right?
01:31:31
CPerezz:EXACTLY!
01:31:53
Ansgar Dietrichs:Replying to "32KB is still not a ..."
yes, but because 7907 can charge for it, the bump makes it free
01:31:59
Dragan Rakita:Any kind of contract size bump is desirable, simples bump to 32kb looks safe (supported with data) and it is conservative, EIP-7907 is even more conservative but it requires some changes.
32kb is 80/20 win
01:32:16
Felix (Geth):it's the inflation bump
01:32:22
Maria Silva:Without 7907, we would be doing something to help with dev experience, at the cost of scalability for everyone.
01:32:22
Carl Beekhuizen:To be clear, shipping 7954 means that every contract call will now be 32% more expensive
01:32:26
Justin Florentine (Besu):i think they go to 32 as soon as Solidity/Vyper update
01:32:28
CPerezz:Replying to "Any kind of contract..."
I think 48 is also safe. I can get the specific data if needed
01:32:41
Ben Adams:Cost increase isn't in the spec?
01:32:46
Carl Beekhuizen:We are making every user’s experience worse to help devs
01:32:50
Daniel Lehrner (Besu):We have 24kb limit since more than 9 years. I think it’s time to increase
01:32:52
Dragan Rakita:Replying to "Any kind of contract..."
Any kind of bump is a win!
01:32:54
Marius van der Wijden:Yes we are trading off ux for very few developers with cost for every user
01:33:20
CPerezz:Replying to "Without 7907, we wou..."
Why does this hurt scalability at all? This is a simple change backed by data vs. a more complex change that has no data collected on.
We can always reprice in the future this simple bump. But it’s much harder to come back from the complex metering
01:33:23
Marius van der Wijden:Not a hill I want to die on
01:33:32
nixo:https://eips.ethereum.org/EIPS/eip-7954
01:34:18
Carl Beekhuizen:I (Carl) think this a big mistake to be CFIing it
01:34:44
Maria Silva:Replying to "Without 7907, we wou..."
We need to always price contract calls on the worse case (we will be doing it in glamsterdam). This means that all contract calls are priced at the performance for the largest contract size
01:35:01
Josh Davis:**CFI**
7954
**DFI**
7793
5920
8051
7971
8032
7907
7903
**Delay**
8037 - delayed to ACDT (Jan 19)
01:35:22
Marius van der Wijden:Initcode to 64k
01:35:32
Marius van der Wijden:Replying to "Initcode to 64k"
DFI the uncapping
01:35:50
Maria Silva:Replying to "Without 7907, we wou..."
If that is 32kb instead of 24kn, then the price will be 33% more expensive, so we fit 33% less contract calls
01:36:21
Ben Adams:Replying to "Without 7907, we wou..."
technically there isn't any price increase in spec
01:36:45
Maria Silva:Replying to "Without 7907, we wou..."
This will be done in 8038
01:37:05
Carl Beekhuizen:Replying to "Without 7907, we wou..."
It has to be done, otherwise it’s a DOS vector
01:37:06
Maria Silva:Replying to "Without 7907, we wou..."
We will fix the price of all state access based on the formance of each operations after the glamsterdam fork
01:37:20
Maria Silva:Replying to "Without 7907, we wou..."
*performance
01:37:30
CPerezz:Replying to "Without 7907, we wou..."
It’s not a DOS vector..
01:37:35
CPerezz:Replying to "Without 7907, we wou..."
It’s insane to consider it a DOS