All Core Devs - Testing #94

Transcript

Toni Wahrstätter: Hello, Justin.

Justin Traglia: Hey, Toni. Good morning.

Toni Wahrstätter: G.M. Jochen.

Jochem Brouwer: Can you, can you EM?

Toni Wahrstätter: Yes, but you're quiet.

Justin Traglia: I was gonna say…

Jochem Brouwer: Thank you.

Justin Traglia: Good morning, Mario.

Mario Vega: Good morning.

Toni Wahrstätter: Don't you?

Justin Traglia: M. Meetings, Mario.

Mario Vega: The last week was interesting at 6 AM.

Justin Traglia: Oh, yeah.

Mario Vega: Oh, A.M. is not so bad.

Justin Traglia: Also, it looks like…

Mario Vega: brilliant.

Justin Traglia: quite a few, discussions, like, for both, EL and CL. Are you gonna lead the EL breakout afterwards?

Mario Vega: Yeah, I can do it.

Justin Traglia: I guess, or Toni, whatever. I don't know who normally does it.

Mario Vega: I can give it a try, yep.

Justin Traglia: Cool, thank you.

Justin Florentine: Good morning, testers!

Justin Traglia: Good morning. Just one more minute, and then we'll get started.

All right, good morning, everyone. Welcome to ACDT. 94. Stefan, are you here to get us… or sorry, to give us updates on Amsterdam devnet 8?

Stefan Starflinger: Yeah, sure. Can you hear me?

Justin Traglia: Yep, we can hear you just fine.

Stefan Starflinger: Perfect. So, Glamsterdam devnet 8 has been, doing pretty well. We've just had a few minor issues, a few orphan blocks. We've forwarded quite a few builders and validators as well. This is a public, testnet. We encourage people to join. In, and try to, do a little bit of havoc, not too much. So people can still use it, that would be great. In general, I think we have a few builder's photos joined, with Nice, PK. I might have joined as well. I think Toni also joined, and he was also successful. With, doing a little bit of testing. I recently found an issue with E72 as well, but I think you've added as an extra agenda point.

To the agenda. But in general, it would be good if clients could move to their trunk branches. I think most clients have done so. There are still a few times, left, at Nimbus EL and Rest, as far as I can see. And Grandine on the CL side, they have to move the trunk branches, which is still a bit of a blocker for the non-finity test networks that we're going to launch soon. And regarding devnet, I think Kerry has been preparing that. Maybe you would like to, give an update on that?

Parithosh Jayanthi: Yeah, so DevNet9's the non-finality network. I'm doing a small smoke test right now with, main or trunk branches from every client. If you haven't responded to my message on the Steel Discord server, please do, and let me know if it's okay to use that branch or not. Once the smoke test works, I'll spin up the roughly 1,000 nodes we're spinning up for the network, and then, we'll probably have, blobs at, like, 10 hours into the network or something. I'll set Genesis such that it starts tomorrow morning around European time.

Justin Traglia: Wow, that's very soon. Great. Do we know if any builders, like, block builders, are, testing on devnet 8 right now? Like, direct builders, maybe?

Parithosh Jayanthi: Not that I know of, I haven't been tracking that necessarily.

Justin Traglia: Okay. I'll follow up with that later. Okay, any other updates, Stefan, or maybe from clients regarding devnet 8?

Stefan Starflinger: Not too much from me.

Justin Traglia: Okay, moving on. Toni, you, suggested having a mainnet shadow fork for testing Snap 2. Would you like to discuss that?

Toni Wahrstätter: Yeah, this came up in a discussion with Gary, and Karim, that it would be nice if we had, like, a network with more history, such that we can test Snap2, and we were thinking the best would be to do a mainnet shadow fork.

Parithosh Jayanthi: Yeah, so there was, let's say Sepolia Shadow Fork was the first one that's planned. Would that be fine to first start the test with that, and then move to Mainnet ShadowFork after? This was a similar requests we got from the repricing folks as well. They wanted to test all of their repricings, but We're only now getting trunk branches, so we didn't want to immediately spend money on a mainnet shadow fork, and Sepolia shadow fork is something we'd do anyway.

Toni Wahrstätter: How many weeks is the Sepolia Shadow Fork still out?

Parithosh Jayanthi: If the non-finality network is good right now, I'd say we wait for… we agree on the testnet date, wait for client releases, and then batch it with that.

Toni Wahrstätter: 2 meters is fine, I'm wondering… If Karim or Gary have different opinions, or anyone else from the client teams. But, from my side, that sounds good.

Karim Taam: Just one question, do we have Shadow Reorg? Is this Shadow Fork, or… It's mostly without reorg, because not a lot of clients are building blocks. Because for SNAP2, we also need to have some reorg to test Block access list healing. So, I…

Parithosh Jayanthi: We can… we can trigger reorgs quite easily. So we have a GetNetherind fork that we maintain, and that has a built-in bug that you can trigger. So we send a transaction, we break the network, and then it doesn't break the network. It just means that that node will build on a different chain, and then whenever we want to heal it again, we… we heal it. And we can deploy this… Or on as many nodes as you want, so you can make the branch as large as you want.

Karim Taam: Okay.

Toni Wahrstätter: Yeah, and for deeper reox, we should use Hive. Like, if you're thinking about reorgs that go as deep as past the first pivot block, then I think we should use Hive for that.

Parithosh Jayanthi: Yeah, that's way nicer a location for deep re-out testing.

Stefan Starflinger: Also, which plans are ready for Step 2 testing already?

Karim Taam: On Besu, we have a first version we want to test, it's not, I will say maybe not production already, but it's, it's ready to… to run on some Shadowfk or something like that.

Justin Traglia: Are there any clients that are not ready? Sounds like everyone's ready then. Tony is asking if Hive is Glamsterdam ready? Is it?

Stefan Starflinger: I got an.

Mario Vega: I'm so rich.

Stefan Starflinger: Yeah, that it was updated.

Justin Traglia: Okay. Alright, so Toni, does this sound fine to you? I mean, doing the… Shadow Fork and Sepolia, I guess, mid to end September.

Toni Wahrstätter: Yeah, to me, that's fine. Of course, Client should tell me, but yeah. Sounds good to me.

Justin Traglia: Okay. Yeah, clients, if you're not ready, please just reach out. We can plan accordingly. Alright, for the next agenda item, there are two, relatively minor things for FOCIL. That are worth bringing up. Both from Barnabas, but he's out of office now, so I'll speak for him. He's proposing that we raise the, maxed signed inclusion list size from 8 kilobytes to 41 kilobytes. Previously, Sorry, that number, the 8 kilobytes number. Did the math using a single transaction, but you could, in theory, have many transactions in the inclusion list, which add padding and increase the size. So if we… if we assume a min transaction size of 1 byte, the limit would be 41 kilobytes. I know that's probably unrealistic, but…

It's a good baseline. Toni?

Toni Wahrstätter: Yeah, I would… I would personally keep it at 8KB. I'm not sure if the maximum transaction size of a single transaction even matters here, because when we talk about, like, call data, everything is… Statically available, and for things like the bul doesn't contribute to the size of a transaction within the inclusion list. So, to me, 8KB seems fine. Also, we have to think the larger we make that, like, the more we have to propagate in the worst case scenario, which is when an inclusion list member equivocates, because then you have to propagate the equivocation and the inclusion list itself, so everything doubles. And right now, we're at 256 kilobytes, which is nice.

Justin Traglia: To clarify, this doesn't change the maximum size of the trans… transaction. Sorry, the inclusion list, that's still 8 kilobytes. But this is the, like, P2P message size. Jihoon.

Jihoon Song: Yeah, I was just… wanted to… At that point, this is about P2P object sites. So before Progressive SSZ, we were just using 10MB, which was used for payload, but with Progressive SSZ, We had to set some limit, and we set it to, what, 8,348. And as Justin said, this was when there is just one transaction, but it's actually a list of transactions, which is dynamic. So, if we assume that the minimum transaction size is 1 byte, we get 41,000… 112 bytes as an upper bound. So, I think… The discussion point regarding this resent is whether we are good with this number, or… Have a better one.

Justin Traglia: Sorry, thank you, Jihoon. Toni or anyone else, like, what is the actual minimum transaction size right now?

Toni Wahrstätter: I don't know, I think right now it's, like, a bit above 100 bytes, but with frame Transaction, it gets much smaller because the signature is out there. I'm wondering why are we even doing this so accurately? Because, for example, for other things on the SL, we just have, like. hand-wavy limits, like the 10MB limit, and so on. This doesn't need to be so, so accurate.

Jihoon Song: That's 10 megabytes is just for payload. Others also have very precise limit, because we can now calculate it.

Justin Traglia: Yep. I mean, it's still pretty hand-wavy, in my opinion, like, 41 kilobytes. It won't actually be that large. like, I can't do the math in my head right now, but… Yeah, and maybe, like, 12 megabytes, or sorry, 12 kilobytes would be the actual maximum. Anyway, I guess just, look at the PR and, see what you think. I don't… I'm not sure if we can make a decision on that right here, Jihoon.

Jihoon Song: There's another discussion point. The second thing is… Adding a new gossip rule that checks whether any transaction is empty. So… We can bike share on the upper bound number, and then we can also discuss whether we want to add this new gossip rule. We can take this offline, we can just discussing the PR. But yeah, these two are what we need to decide on regarding this topic.

Justin Traglia: Okay, yeah, let's discuss that point more in the SL breakout, maybe at the end. Is that fine?

Jihoon Song: Yeah, sounds good to me.

Justin Traglia: Okay. And then semi… moving on to the next agenda item, semi-related, Barnabas is proposing a minor change to the Engine API Get inclusion list endpoint. It just… Essentially, we're just checking that it does not… we're ensuring that it does not return Into Transaction… transactions. I guess it sounds fine to me. I would like to update the language a bit, though. But, those working on the EL. Please review. Thank you. Alright, tamaghna, are you here to discuss, the REST SSZ Engine API. And why you want to merge that PR.

Tamaghna Choudhuri: Yes, so the basic idea is, in the last call, we decided that the shape of the spec that is there is pretty much, let's say, what we want as the first version, so now the ask would be for every client team to have a view of that PR, and then, put in your review so that we can get it merged, because, like, after… yeah, thank you, I was adding that to the So, the idea is basically, once we have, the reviews and we add that, we'd be following up with a few small PRs, one of which would be the, would be transitioning to progressives, one of them would be adding, let's say, the injured witness, and,

on… on a few, let's say, open APIP and open API migration, but, like, that comes later, so we'd like… we'd like all of you to have a look and, review it and… maybe… then we can get it merged soon. So, that's all. Also, like, if you have any reviews, please put it up, then we can, work on them and get it merged ASAP.

Justin Traglia: Great, thank you, Tamaghna. And, could you… sorry, remind me, what is your suggestion to merge it into the main branch, or into a new branch, just for SSE?

Tamaghna Choudhuri: Yeah, so my suggestion, personal suggestion, is to merge it into, let's say, an SSZ branch, and then, basically, we'd be having all of the different subsequent PRs into the SSZ branch, and one single PR from the SSZ branch to the master branch. So, that's my suggestion, but, like. I'm open for even more chicken and master, if that's what everyone prefers.

Justin Traglia: Okay. Any comments on this from clients?

Łukasz Rozmej: So, I left a few comments, but I would also like to merge it and proceed with it relatively soon. Nevermind, it's more or less, ready for testing.

Justin Traglia: Okay. Is there… is there anyone here from, the engine… or sorry, the execution APIs. repository. I don't know who the maintainers of that are, maybe Felix or Marius? I don't she know? Yeah, we do need Marius to move the status from draft to ready. Is Marios on this call? Okay, I guess not. Oh, okay. He's on vacation. I'll reach out to whoever the maintainers of this repo is, or are. And try to get that handled.

Okay. Right. That was the last agenda item for the, like, core, EL and CL. part of this call is there anything else we would like to discuss before moving into the breakouts?

Maria Silva: I do… I do have a question that I think is relevant for both EL and CL. So in the EL breakouts, we'll be discussing some potential updates to EIP-EIP-8037. And one of them, actually two of them will require a change in spec. So, my question is, like, would be… the, The general appetite for this, and what would be the impact in terms of fork timings?

Parithosh Jayanthi: How critical is the change, or what's the proposed change look like? And would it change any, would it change any user actions that people do?

Maria Silva: So, I… I can… maybe… I'm not sure if it makes sense to give, like, a big summary, but the TLDR is… one of the changes would mostly impact self-destruct users. And, the other change is… Something that, that, Pawel, figured out, and is, an issue with how we are refilling, refilling the state gas back, And it could lead to, essentially. I mean, it's an issue that appears mostly on edge cases, but, it's not the… let's say the correct implementation that we would… we were planning on doing when we were first designing, and it's a bug that kind of was introduced.

It doesn't necessarily… like, it's not necessarily a security bug, per se, but it's something that leads to a weird metering. behavior.

Parithosh Jayanthi: would this be, then, something we can just deploy onto the announced public testnet, or would it need, like, a new one? Would we have to relaunch it?

Maria Silva: Yeah, I'm not sure, that's why I'm bringing this up, so I really wanted to understand what are the consequences, in terms of timings, And, Spencer, I think you looked into it, right? You're still looking into…

Spencer Taylor-Brown: Yeah, so it would be a spec change, right? So… Right. In both cases, like, we'd have to review the tests, and… maybe… I mean, for the self-destruct one, personally, this is mostly a personal thing, but, like, I… I think what leads to overcharging With the… the weird, femoral… Self-destructs. scenarios, right? And I… Right. I personally feel like that's okay, but the other one, I'm still looking at. Deadline is in a day, okay. M… Yeah, to be honest, the other change I'd like to look at in more detail, and then also see, like, the… How many tests it breaks, for example.

Maria Silva: But I know it would be a consensus change to the point that, you could make a block that essentially would have a different state. Essentially, it's like it's… It's not something that is just in the internals of the metering, and then the end. result of the transaction would be the same. It's like, it can change the execution of the transaction, and so it's something you can essentially break a network with.

Parithosh Jayanthi: Yeah, that also means if we deploy the change, then when a block tries… when a node tries to sync up to the network, it might not be able to, because the past block, it won't be able to re-execute, right?

Maria Silva: I… I'm not sure, I guess it would depend on the previous blocks, but in general, yes. So it's like, this would come up in edge cases, it's not like every block would change, but yeah.

Parithosh Jayanthi: Maybe a question then to clients. Is this something we would then need to… that you guys would be comfortable just shipping directly to Sepolia, or do we have to start the… entire process again. Like, would we need to do a public testnet again, then a new non-finality network, Sepolia shadow fork, and so on? Because I think that would basically define if it changes, being able to do Sepolia at the end of September, or we basically shift by a month, and then we do Sepolia at the end of October, but that means we won't be able to do… we likely wouldn't be able to do December as the main network.

Maria Silva: Yeah, I do understand maybe clients want to look into this change, but I mean, this is a big thing, right? Like, it could mean we are delaying for a month, so I think it's important that everyone is looking into this, and we make an informed decision here.

Lightclient (Matt Garnett): Have we ever made a change between a DevNet and… a testnet without… seeing it on the devnet?

Parithosh Jayanthi: I mean, we can do it on a smaller scale one, like, we can do a Sepolia shadow fork with this change. I guess it just depends on the block, if… we're able to just directly apply it on devnet 8, like the publicly announced DevNet. There's a chance that we apply it and nothing breaks, and everything's fine, in which case, yeah, this is okay. But there's a version where everything breaks, and then we should realistically relaunch that network. And that's the timeline in which we probably add some delay.

Justin Traglia: I'm pretty sure we have had consensus-breaking changes, like, in the testnet phase in the past, just for, like, bug fixes that we identified. We didn't, like, redo a DevNet for those. But

Parithosh Jayanthi: Maybe a good path forward is the only blocker this immediate week is the non-finality network. one thing we could do is just focus a lot more on just ePBS-based testing, like CL-based testing. I'll leave the EL side relatively alone. Which sucks, of course, but at least we'd gather a lot of information about the CL side. And maybe we can make a decision on ACDC this week. I know it's off-band and not really the location to make this decision, but it would save us a bunch of time.

Potuz: I find it hard… I mean, we can test some things of ePBS, but I think, many of the things that we want to test will involve anyways spamming on the EL and executing very large blocks, so… most of the ePBS-specific CL behavior that we want to test on hardnets, involve, anyways, blocks that are either very large on the EL, or blocks that are taking a long time to execute, so I think we're gonna be anyways, requiring to spam on the EL side, and… It's gonna end up being a test on the EL anyways, so we're gonna have to…

Parithosh Jayanthi: Yeah, but only kind of marginally, right? Because the non-finality network is a clean state. It just doesn't have much state. So you can spam, but you just won't create that many worst-case scenarios.

Potuz: Then… but then… then I think it's… it's… it's… yeah, I don't know if it's a good idea to start with a… with a small state on the EL. I mean, we… we can test… non-finality on the EL, and then we're just going to grow with the EL state, but I suspect that things will actually get worse if we have a big state on the EL.

Parithosh Jayanthi: Of course.

Potuz: I mean, the problems that we have of split views on the CL are going to appear because of the timing of blocks on the EL side. So I think… We need to test this under a heavy state on the EL.

Parithosh Jayanthi: Yeah, but again, it has to be a different network, because, I don't think we have a budget for a thousand mainnet shadow fork-style nodes for multiple days. That's probably multiple engineers' salary for the year. So yeah, I understand the constraint, but we will have to split this up, and mainnet shadow fork will have to be on a smaller number of nodes.

Justin Traglia: Maria?

Maria Silva: what… I was just going to repeat what Perry said, that the plan is to test that in the main network, so having, like, a full EL state and doing more heavy EL state tests. So that was the original plan.

Potuz: So, as far as I can see, I don't see any problem in having two different tests. We can test, like, non-finality with only a few nodes and a large EL state. Anyways, we'll be testing, like, the out-of-order and long executions and these kind of things. It should be fine.

Parithosh Jayanthi: Wait, is that an argument for not doing a large-scale non-financial.

Potuz: No, no, no, it's… it's fine. It's, we can do the large, non-scale… the large… with a large CL, one lots of nodes with small EL state. I think it's still going to be more important than the other one, but it's good to have this one.

Parithosh Jayanthi: Yeah, okay, that sounds good. Then Maria, would you be okay with, just allocating some time on, ACDC at the beginning, and we can discuss this, so that everyone has some time to review stuff?

Maria Silva: Sounds good. So, now on the EL breakout, we'll go through this change as well and discuss it a bit, and then I can go to ACDC and, give an update.

Parithosh Jayanthi: Yeah, and it would be awesome if EL Devs can actually show up, at least for the beginning, or… Give your opinion in writing, or some… somehow communicate it.

Justin Traglia: Yep, sounds good. Anything else we'd like to discuss before jumping into breakouts? Or is this it? Alright, thank you, everyone. I'm going to head to the SL Breakout, which I have just shared a link for. By EL people.

Mario Vega: Hey, I'll help, coordinate this one. So yeah, let's just get started. So the first issue is by Toni. I'm gonna share the link. Yeah, exactly. Thank you, Toni. Would you like to give it a go?

Toni Wahrstätter: Yeah, this is more as a heads up for clients. Most have noticed already, I made a PR to execution APIs. One case where the ball was undecodable was yet unspecified, and now it's specified. I think, Geth and Reth had the right response already. I'm not so sure, because I also saw Reth open the PR based on it, and the other clients are on it, as far as I can tell, so just as a heads up.

Mario Vega: Great, and I… I think I reviewed your PR4 ELs, right? Is that correct?

Toni Wahrstätter: Yes, it's merged already. I saw some other clients have merged it already, too, and for the others, I think they're on their way there.

Mario Vega: Any comments from clients? Alright, let's move to the bigger topic. Let me share again the link on the chat. So there are 3 issues that we should discuss. So, I think… To be honest, I'm not very familiar with the last one, I think it's the meatiest one. But yeah, let's start with the self-destruct account one first. Let me share that too in the, in the chat. Alright, so who has the most context for this one, for the self-distruct? Is that you, Spencer, or is it someone else? Or Maria, you'd like to be able to go?

Maria Silva: Yeah, maybe I can…

Paweł Bylica: So, I can also, like, go over there if you want.

Maria Silva: Yeah, sure.

Paweł Bylica: So… So basically, this is a use case that is actually used on the mainnet, where we have a create and sort of distract sandwich, so it creates some kind of ephemeral contract that can execute, and it's removed in the end of transaction. And it doesn't work very well with a current EIP-8037 spec, because User will be charged for creating a contract, including its code. And will not get the refund in the end. And the fix is to actually give it the refund. So this is basically, like, saving one use case, and… Yeah, I don't want to really give opinion if this is a useful use case or not. But some data shows it's… it's been utilized.

Some words about implementation think it's not very complicated, but it's also not trivial. It's basically… In the place where we are doing… Self-destruct and linking the end of transaction that is already required by Some EIPs, including, 8246? The one that removed burn, event. We can place it there, but in the end, it's a combination of some simple conditions, and So that's, I would consider it simple, but not trivial to implement. Yeah, so that's basically… They were basically that. And the EIP change… proposes to… to add it back, I mean, to actually extend the spec. To include this case, and give you the state class.

In the end of transaction for the contract you didn't create.

Mario Vega: Mario?

Maria Silva: I… I just wanted to add two things here. So, first off, this is not something we discovered yesterday, like, this was… A decision we made in April. And… The thought process was twofold. So, first was, simplicity in the protocol and testing. So this was one of the… one of the big reasons, because initially we had these, like, we were giving the refunds on these. Ephemeral deployments, let's say. And, the reasons why we dropped it was first for simplicity and testing, because after We started implementing these, we realized, Give some edge cases that were… more complicated. And the second one was, sort of these… idea that we would like to eventually deprecate self-destruct, right? So we don't want to move in a direction where we are making these use cases, like, incentivizing people to continue to use self-destruct, which I think is what's happening here. So.

The people that are pushing more strongly for the… for the refund to go back are people that are deploying new contracts that want to use that mechanism. And so I think if we are giving the mechanism, then we are essentially Saying that we are giving the incentives for these people to continue to use it, and this will go against the initial thought of this change. And so this is just to say, I think this change is very different from the other, where Pawel identified an actual thing that we wanted to do it in a way, and it was not implemented in that way. So yeah, I… yeah, in my opinion, I feel like we shouldn't do it, but yeah, at the end of the day, I think

CoreDevs need to… give their opinion, and if you all feel strongly that we should do it, then let's do it. But, but yeah, so I just wanted to… to give this caveat.

Mario Vega: Maria, are you expecting a resolution today, or should we follow the procedure of waiting until ACDC to give everyone enough time to make considerations and decide?

Maria Silva: I mean, if we can decide today, I think that would be better. If client teams are not ready to make a decision, then we need to… wait until ACDC, but yeah, ideally, I would like us to make a decision here, if possible.

Mario Vega: Okay, let's hear from the EL clients for now. Does everybody feel like we understand the issue? I want to… I would like a response from each… One person in the team. Do you understand the decision? Can we take the decision today, or do we want to defer until Thursday for ACDC? Let's hear from Get. Is anyone from Get here?

gary: Yeah, I can't speak for gas. So, I think I can understand the issue, and I also agree with Maria that I think we will, like, fully deprecate the self-destruct in the Hegota, probably, and The complexity is probably not what's why, especially, like, especially we are… Fast approaching the… the hair fall. And, If we really want to include this change, and I need a bit more time to evaluate the complexity for the implementation, it's my opinion. I would prefer to not do it, but if someone really has some strong opinion, I can also spend some time to… To dig into the implementation.

Mario Vega: Nice, thank you. From Nethermind, do we have… do we have an opinion? This time, so the third Thursday, right? Alright, let's go with Besu. Besu, do you have an opinion on this?

Justin Florentine: I don't think that we do. Karim or Fabio, feel free to contradict me, but I think that we need some time to consider this.

Mario Vega: Alright, we're leaning towards the fairing. Erijon, is anyone from getting Erigon here that can chime in?

Milen Filatov: I haven't really had time to look at this, to be honest, but, I mean, I… I would probably defer to Pavel. Cause he's more familiar with this.

Mario Vega: Thank you. Anyone from Reth who wants to chime in?

Dragan Rakita: Just to be clear, this is about getting refund, getting state refund, because the created contract got self-destructed.

Maria Silva: So… This is getting a refund when you create and self-destruct in a single transaction, in the same transaction. Right now, the account is still getting deleted from state, but we removed the… the refund in 837.

Dragan Rakita: Rethund, is it a general refund, or…

Maria Silva: No, no, no, it's the refill.

Dragan Rakita: Yeah, it's okay.

Maria Silva: It was… sorry, it would be a state refill, yeah.

Dragan Rakita: In my opinion, it's too late to change this. I feel this, like, minor thing. I do feel that's going to be… Painful for some things. I would not change for Glamsterdam. I would re-evaluate… basically re-evaluate it for the Higata or some other… Some other mechanisms that basically allows creation of the temporary accounts.

Mario Vega: Alright, thank you, Joan. Pawel, sorry, I skipped you.

Paweł Bylica: No, no problem. So yeah, I have… I have one argument, that I would like to share. So, this pattern that is… that we kind of disable, I think, Because I was thinking so much about it recently, it's actually, like, compatible with the intent of state gas. So basically, users found a way To do some work in a transaction without actually increasing the state. And I think that's what the EIP-8047, one of… one of many, tries to incentivize. And we're kind of in the same process, we disable some of the partners that we actually would like to see on the mainnet. Because there's a way to make a transaction without actually increasing the state. So, I think, you should consider that, although…

In the end, I don't really have strong opinions about About this specific change.

Maria Silva: Can I… can I just add something quickly? Sorry, Guru, before you go.

Paweł Bylica: Yeah, sure, sure.

Maria Silva: I do agree that this is something we want to see on mainnet, so if we don't… like, if you have a use case that doesn't create state, you shouldn't have to create it, but at the same time, the question here is, do we want to do it through self-destruct? or not. And in my opinion, we don't want to do it through self-destruct, we want to introduce, like, a new type of Temporary state that is designed for that. And that is something we can do in Egoto. or in the future. I, I, I just fear that… Do… like, maintaining these… Like, giving these refill will essentially further incentivize new use cases that come and do it, through self-destruct. And so, once we… after, if we want to introduce a new type of temporary state, they won't want to move, because they already have a nice thing that is implemented and is working, so they will fight again.

Paweł Bylica: Okay, I agree, yeah. I agree that this is not ideal way of doing this, but we also have really bad track of the living EVM features. And the ephemeral contracts have been discussed for, like, 5 years. And now you've promised, like, to pro- like, to create proper solution in Next fork, which, in my opinion, is uncertain. Because there always will be something more important to include in Hegota, and… It's really, like… Yeah, I wouldn't really, like, sign up for the promise that we'll deliver some improvement. Because we promise improvement, As a way of retract other features, and we usually don't deliver them. But yeah, I'm… I think the proper solution is also a solution. I'm just not… I'm not… I… I… I'm not convinced that…

We actually will do it in the next fork.

Mario Vega: Guru?

Guruprasad Kamath: Yeah, so, I just wanted to add a bit of context here. So, if the… I think we kind of need to distinguish between if we do this… if we do this, why are we doing this? So, if the argument is, we are doing this to save this particular use case, that's one thing. But if the argument is, we are doing this because if the user is not creating state, he should not be paying for it. I guess that is also happening in other cases where we don't refill, like, for example, a user today can, or not today, but in the spec for 2780, for example, the user has an author… sets an authorization and then clears it within the same…

transaction on a new account, the refill doesn't happen. So there is that asymmetry already elsewhere in the protocol, so that, I don't think, is a… would be a good argument for this. Like, the only reason why we would be doing this is if we want to save this specific use case. So, just wanted to add that as context.

Mario Vega: Alright, yeah, Luz, go first.

Luis Pinto: Yeah, I would also like to make the argument that we seem to be conflating the decision to remove self-destruct with the decision of fixing this in the right way, so if a user is not creating state, shouldn't be paying for it. And, we seem… I think the decision to remove self-distract should be had… should be done at a later stage, or in its separate forum. And yeah, I wouldn't like to see this kind of conflating, or, like, leaving self-district in the broken state even if it's an edge case, just to… just keeping in mind it's going to be removed later. But yeah, that's my personal opinion.

Mario Vega: Alright, I don't think we've heard from ethrex. Do we have someone from ethrex who wants to chime in?

Iván | ethrex: Hello. Yes, I agree with Dragon and Gary. I think it's not worth solving this right now.

Mario Vega: Alright, it seems like we have… mixed opinions, basically half and half are leaning towards no-go, and others are leaning towards the fair. how do people think of, giving people that want to include this change until Thursday to make a decision? Or do we feel like… do we still feel like we have to decide today? Yeah, dragan, go for it.

Dragan Rakita: I'm just thinking, I don't think it's… I think the change is more bigger than we thought. What happens if we give back the refund at the point of self-destruct? Then somebody else sends the balance. And then we decided that we… if the account has balance, that we… that that account is going to stay. So there is that edge case that we need to think about. End of Transaction… okay, that makes more sense, yeah. Thanks, Maria.

Paweł Bylica: Yeah, that's why it's in the end, but there's also some other tricks there. For example, you need to know if the account was there when the create was going in. So there's a way to, like, look it up in the pre-state, but it's not triv… that's why I said it's not trivial. Because sometimes Create actually charges you for creating an account, but sometimes it doesn't, and the condition happens in some other time. Then you need to kind of recover this condition in the end of transaction.

Dragan Rakita: Yeah, you need to have original state, original account balance.

Paweł Bylica: Yeah, so my idea was to just look up, is the account in the, like, the original or whatever, but I… I don't have the implementation yet, so… I cannot guarantee this is… Thank you. Like, easily doable, yes.

Dragan Rakita: It really depends on implementation. For us, it would be easier, but I don't know if everybody can do that. Basically, access the original state at the end of the transaction, when they decide if account's going to stay or not.

Paweł Bylica: Yeah. There are some… there are some edge case in the edge case, yes.

Mario Vega: Yeah, Gary, go for it.

gary: I actually have a question for Pawel. So, in the EIP, it says, for the, Created a slot, it will not be refunded. Just in case, like, the account was created in the single transaction, and it has a few slots created within the… initialization. If the contract is gone, why we will not refund the cost for the storage slot?

Paweł Bylica: I think… tourism is… there was never… it was never actually… refunded in any EVM revision. It's all even when the self-destruct had refund. some… some revisions before. We never actually Gave back the… the storage cleaned. Secondly, it seems really complicated to actually compute that. You would need to traverse the… whatever your internal representation of the intermediate state is. I didn't want to touch it. And seems… this is not… from the user perspective, this is… this is, like, you can work around. Because if you create ephemeral contracts. with the intention to execute it only within a transaction, you can always use t-store instead of storage.

And so, like, proper usage of this pattern doesn't require storage at all. So definitely, from my opinion, it's not worth to actually include this in the calculation.

gary: Yeah, so, theoretically, even we go with this approach, the entire picture can still be not idle, because you can… you will still overcharge the slot for some reasons.

Paweł Bylica: Yes, yes, and that's why I fully agree with Guru that said, like, there are other cases in the CAP when Then we don't give refunds for some other reasons. I think, yeah, these are compromises, but… I personally don't disagree with them.

Mario Vega: Alright, thank you, Pawel. It feels like the only person pushing towards, going on… going ahead with this change is… Is Pawel, if I understand correctly, does anybody else feel compelled to give this one a go? I feel that because of complexity, we need to make a decision today. Otherwise, if we defer, it's gonna be even worse. So, does anybody feel like, from other client teams, does anybody feel like we should give this a go?

Milen Filatov: I… I feel like… is this the first opcode that we are sort of deprecating in DVM? Because just, like, a note as a lesson for next time that I kind of feel like we… Didn't really do a good job with the way we've deprecated this op code. And if we need to deprecate some of codes in the future again, like, I think there's better ways to do it. Usually, it feels like we're doing it in reverse. And, next time we should first actually introduce the alternative, and make the one that we want to deprecate A lot more expensive, so that people have time to transition. Because, yeah, like, what we're doing now is basically in reverse of how we should be doing it.

Mario Vega: Alright, so, I think this is the EIP that deprecated in Shanghai. Okay. Let me, let me… yeah.

Milen Filatov: Yeah, but it's still used on mainnet, so… It's not been kind of deprecated in a way that… Addresses all use cases.

Paweł Bylica: Yeah, I mean, I don't want… I don't know how much you want to discuss it right now, but I think… That's kind of the conclusion, it's also mine. That we did duplicate it, but we were not tracking what's going on on real usage. And I think people just find it useful for some cases, and they don't care about the deprecation. Oh. Yeah, if there is alternative, that would be an easier path. Yeah, so basically, there's something that works, and… And they… they will use it, but maybe there's not other way to… to use Ethereum otherwise for the idea of app or project, and so they can either option to use deprecated feature, or just move to somewhere else, or, like, close the business, whatever, right? So we don't really know.

But, I think… deprecation warning in EIP, or even Solidity. Seems doesn't… Prevent increased usage.

Mario Vega: Alright, let's get back to the decision. I still don't hear from other people that we should push with this forward, and make the refund. Does anybody else want to have… want to… make the case for this. I feel like it's only Erigon that wants to go through it. The others are, want to make the… don't want to delay Amsterdam, because this is a complex change. Does anybody else feel like, we should… Implement this. Alright. It seems like there's no support for this, so I think we are going ahead with not implementing this one, for now. Alright, we still have 3 to go. Yeah, let's quickly go to the last one, I feel like that's the most contentious one.

I'm sorry, that's the one that requires spec change.

Maria Silva: Yeah, so I, I'll see…

Mario Vega: Go for it, Mary.

Maria Silva: from… from the two that are missing, one of them is just a clarification in the EIP, so from my understanding, it's like the spec is correct and doesn't need to change anything. The second one is where a spec change would be required. So I don't know, Pavel, do you want to give some context there?

Mario Vega: Yeah, just for context, let's just go to the one that requires spec change, because we have to.

Paweł Bylica: Okay, yeah, I… I think we can swap over the first one. It's basically what Maria said. So this is… this is a series that touches the same part of the spec. But, one is kind of spec bug fix, because the implementation is different than the spec says, and… And I think we followed the implementation, and that's reason that it makes sense this way, so it basically updates the IP to the reference implementation. That's at least my intention, as it was. And second, kind of builds on top of this, And… and tries to bring… the claim that EIP promised. In… in some introduction, but it was not fully delivered, and it's related to… Oh… this, like, this LE-4 queue that's… refills…

The state goes back to the… the pool it took it from. And it works, but only in the frame context, and it doesn't work across the frames. So the update is to actually make it work across the frames. Yeah, and to my understanding, the implementation impact is small. It's basically in the same place where you do some… after the frame After the child frame closed, Computation, you just need to make it slightly different. Yeah, so that's basically this one.

Maria Silva: Yes, and so… and this would… you would observe differences in behavior here in the cases where you have no reservoir, and so you have to keep a counting of how much was taken from the gas left. And then you enter a frame. You… you have some amount of gas that was taken from gas left, and then you exit, you enter a new frame, and then you need to… refill back, in that point. And in that point, the issue is that you don't have information about the frame number 1 that had some… Thing that was spilled into, and you don't have that information, so it makes you add stuff to the reservoir instead of gas left.

Yeah, so this is the situation. For most… I would expect, like, a lot of transactions wouldn't see any change, but I don't know if this would break definite Aid or not, So, I guess this is the… The key question is, like. how much would these… fixing this would delay the fork? Yeah, so I don't know what is the best way for us to kind of answer this as soon as possible.

Mario Vega: I think… I think we need context on the complexity for this. Do we have, someone from the specs? Spencer, have you seen this, PR? Do you have a sense of complexity?

Spencer Taylor-Brown: Yeah, I think, spec and existing test changes are fine, but extra test cases is probably the only… added complexity, but then I'm not really sure what the… Yeah, I still need to look into it deeper. And I… I think, in the chat, Luis, I think it's… is it that PR, or is it the other one? 12256, or 12265. I think it's 5-6.

Maria Silva: That requires… so the one that requires a spec change is the one that ends with 65. Just to make it clear, it's the one, yeah. That Mario shared now.

Mario Vega: Yeah, in the interest of time, I feel like we do not have enough context or information on this. I want to quickly go through the clients to see if anyone has an opinion on this, just to see if we can make a decision. I don't think we can, but let's see. Anyone from Geth? We're, just to clarify, we're talking about 12265, the last one that was posted on the… on the chat that requires a spec change.

gary: Yep. So, I think, semantically, the change is correct. So basically, we… whenever a child is, Like, child comes back to the parent, and if it's possible to… Have something referred to the… So, let me restart again. I think the change is mentally correct, but I need to evaluate the complexity and potentially need to discover some edge case for merging the child forming back to the parent footing. And I would… prefer to defer the decision to the ACDC.

Mario Vega: Alright, let's quickly jump to another mind. Do you have an opinion on this?

Łukasz Rozmej: Sorry, I don't, I would have to, talk with Ben, he's our EIP-8037 champion.

Mario Vega: Alright, Besu?

Luis Pinto: If I understood this correctly, what you're saying, Pawel, is that we should refill the gas that is being, cleared back to the parent where it was created, is that right?

Paweł Bylica: Yes, yes. So, we wanted this change to be consistent. And not to allow the situation when you… kind of launder. the regular gas into state gas, and you cannot. Yeah, so that's happened in, like, some previous versions of EIP. And we fixed that, but only locally, not… In the scope of transaction, that's kind of the overview, and that tries to fix this. fully, and… and… I think… With the fix, we can… We can guarantee this property, so… You never transmute regular gas in the state gas.

Luis Pinto: Yeah, it's a tricky one, might need to think about security considerations. But also, on the other flip side, on the other flip side, like, the color that the frame that frees the state should maybe be the beneficiary of that gas that was refilled. So I don't know… yeah, I would be interested in, like, security impacts, or, like, if you have a use case in mind that could break, By… with the current approach.

Paweł Bylica: Yeah, I think… I think the situation is that the child is beneficial anyway, to some level. And this is limited… By the… this is… the limit is the same, it's amount of state… amount of regular gas the child got from the parent. Well, who loses here is the parent, actually. Because… At the crossing from the child to the parent, this laundering will happen, and Yeah, and so the parent is the loser.

Luis Pinto: This is not new behavior. This is not new behavior, though, right? Because we don't refill anything at the moment. It's just with EIP-8037, we start refilling gas back. So, it's kind of the parent stays with the same behavior, is that the child now can have new benefits, I guess, no?

Paweł Bylica: Mmm… Yeah, I'm not sure. I'm not sure we can…

Maria Silva: don't…

Paweł Bylica: project that to existing EVM easily.

Maria Silva: maybe, if I can add, I don't think that's.

Paweł Bylica: Yes.

Maria Silva: what is happening here. So I think what is happening here, you are still receiving the refund in the same way. The only difference is that now you can have a child move gas between gas left to the reservoir. So, you still have that gas available, it's just in a more restricted counter, right? Because in the reservoir, you can only use it for state gas. And so, initially, this was the design, right? Like, we always give the refund to the reservoir. And these meant that you had these… behavior, where you could have things moving from a less restrictive place to a more restricted place. And I think with these Bug? In quotes, what we are saying is, like, we… we haven't solved this, right? Like, initially, we wanted to solve this, and we wanted to keep this invariant that

If you had some gas left, you should always be able to use it as gas left. But now it doesn't quite work that way, so depending on your execution, sometimes you get this behavior, and other times you don't, which is, I think, is not great.

Mario Vega: Okay, let's just finish the round. We only have… well, we don't have time left. Go for it, Reth. Do you have any opinions?

Dragan Rakita: No. I don't fully understand it. I will read it again. Before the call.

Mario Vega: Thank you. Anyone from ethrex?

Iván | ethrex: Yeah, I also need to review it, Are the next steps to discuss it on ACD or async?

Mario Vega: So, I think, Maria, if I understood correctly, you were going to open a comment on ACDC schedule to discuss this at the start, is that…

Maria Silva: Right, but I do think if we can have a discussion async until then, I think it will be important. Like, I want to avoid us just going to ACD and rehashing these, so… Ideally, what would happen is, I will put on the Discord, threads, to gather your opinions, and it would be great if you can do it, in the next day. Or two, so that we can make a decision, and then we go to ACD with the decision made. rather than just doing the discussion there again.

Mario Vega: Would that be…

Maria Silva: You okay?

Mario Vega: That sounds perfect, Maria, thank you so much. Also, just wanted to point out that we skipped one of the three EIP issues, just be sure to also put that in the EAT R&D, just in case people have opinions and can chime in on that one, too. But yeah, that sounds like a plan. We had one topic left, but I think we're way over time at the moment, so I would like to just wrap this up now. Any final comments from anyone? Is the plan clear? All right.

Maria Silva: Sorry, I'm not sure what Ragani's asking. What do you mean, can we get an example of usage similar to what we had in Svalbard?

Dragan Rakita: Sorry about that. It was mostly, like, example that we had, like, storage takes 5 gas. CPUs as fungus, and what happens after first call? What happens after second call.

Maria Silva: Got it. Yeah, I can do that.

Dragan Rakita: Thank you.

Mario Vega: All right, thank you so much, and sorry for going over time, but yeah, I think it was very fruitful. Thank you so much. Please follow the discussion on EL R&D, so we can have a clearer view on ACDC next Thursday. Thank you so much, everyone. Bye.

gary: Thank you.

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