AllCoreDevs - Execution #236

|2026-05-07| Agenda: #2033| canonical JSON

Transcript

nixo:Good morning or afternoon. This is All Core Devs, number 236. It's May 7th.

nixo:Today we're going to talk about the… a little bit about the progress that came out of the Svalbard interop. There is a blog.ethereum.org blog post on that if you want to catch up.

nixo:We'll go over some…

nixo:other changes that, came out of the progress, or that are being proposed that came out of the progress, that happened in Svalbard, and then we'll go over some proposals for

nixo:I go to non-headliner proposals, AA update, and, an engine API schema fix.

nixo:Do we want to start with, Barnabas? You want to give an update on the Svalbard progress and some devnet updates?

Barnabas:Sure. Can you guys hear me well?

nixo:Yep.

Barnabas:Yeah, so we started out, with answering devnet 0, on the second day of in the interop. We basically included, all the, bal-devnet-5 changes and, ePBS.

Barnabas:And then we basically, went onwards, from there.

Barnabas:We quickly had some issues, and then we launched,

Barnabas:Glamsterdam didn't won, just a day or two later, and

Barnabas:In devnet 2, that was two days after that, we also added a new EIP on the CL side,

Barnabas:I'm just gonna put all the links here.

Barnabas:With the notes,

Barnabas:So the new EIP was the, EIP 8061, which is increasing the exit and consolidation churn limits.

Barnabas:We also discussed to, possibly DFI 8080, on the sales side, so…

Barnabas:we haven't made an explicit decision during the interrupt, but maybe this is something we can discuss next week on the ACDC.

Barnabas:Regarding any other CR changes, we decided not to push forward during the interop week on the forward-compatible, consensus data structures on the, 7688, and we decided not to move forward with AD45 during the interopweek,

Barnabas:Which is the slash valid, exclude slash validators from proposing.

Barnabas:Regarding the ER side, there has been a bunch of progress, especially,

Barnabas:8037. There has been lots of back and forth, and hopefully we can now, have a finalized pack, with finalized numbers, but I will, probably pass the mic to someone that is more familiar with, the 8037 changes.

Barnabas:We have, currently, Docker Access, Ball.net 6 up and running, with the old, Lighthouse and Lodestar images.

Barnabas:That has been quite stable, and we have glamsterdam-devnet-3, which is basically the same spec as glamsterdam-devnet-2.

Barnabas:But we can actually keep an eye on it now. This morning, I have started the P2P bids, using Builder, and it seems like, Lighthouse was unable to stay at the head, and

Barnabas:They seem to have some issues thinking, At this point.

Barnabas:That's the latest on Glamsterdam demonstrate.

nixo:Great, thanks. Stefan, do you want to, talk about ball dubnets?

nixo:Prior restoring, small person.

Stefan Starflinger:Yeah, sure. So, just a quick recap, we,

Stefan Starflinger:did some accounting change for 8037 that we went back on during Svalbard, and so we moved quickly from Baldefinite 4, up to Baldefinite 6. And Baldefinite 6 is going pretty well at the moment, but there are still some issues that were found.

Stefan Starflinger:And I linked most of them in the agenda, so I will share a link here.

Stefan Starflinger:If someone wants to look in more detail.

Stefan Starflinger:And then, the idea is now to move to BioDefNet 7, with a new testing release, and that addresses most of the fixes.

Stefan Starflinger:That were found, and, to also include the, optimizations for the benchmarks, so that we have one stable, performant,

Stefan Starflinger:execution side branch. It's still called ball definite, but it includes all the EL changes, which is a little bit confusing. But then, this should be the final, ball definite, so EL side only.

Stefan Starflinger:a branch, before we only continue with Gamstrom devnets, branches,

Stefan Starflinger:And there is one ask that,

Stefan Starflinger:Ben made, and I just summarized it here a little bit, is maybe we should have a debug get block receipts, because the gas accounting is becoming more complicated with different variables, especially the split between regular and state gas.

Stefan Starflinger:It would be very good for debugging to understand how much

Stefan Starflinger:state and how much regular gas was used. This doesn't necessarily need to surface to the user, but it would be good to have something like this as a debug endpoint, and I just kind of,

Stefan Starflinger:created a recommendation of how it could look like. Maybe later, if clients want to speak on it or have some more specific suggestions, that would be great.

Felix (Geth):Sorry, could it also just be added to the receipt? Sorry, sorry, sorry.

Felix (Geth):Nick, can we somehow surface it? We could also just surface it in the block, no.

Ben Adams:I mean, we could… we could do, but then,

Ben Adams:It's a… it's a lot more field.

Ben Adams:But I think it might be helpful for users to work out where they spend all that.

Stefan Starflinger:I don't know, I think we should take this async somewhere to discuss it. I'm not sure where exactly the best place for it is yet, but I think it's something that we do need.

nixo:Okay, great. Stefan, can I just assume that you'll put that in the, EL?

nixo:EL channel and, R&D, where people can go to discuss it.

Stefan Starflinger:Yes.

nixo:Any other updates on devnets, Salbard, or, like, 8037?

nixo:Maria.

Maria Silva:Yeah, so I just wanted to clarify something quickly. So, we are…

Maria Silva:working on Vol devnet 7 for next week, but at this point, we still have some clients working on some optimizations, and those should still be merged to Vol devnet 3.

Maria Silva:So, we are working on bal-devnet-7, with the fixes from 8037, and that should then, at some point next week, become our EL stable branch, but until then, for the clients that are

Maria Silva:working on the optimization still from last week, please merge them to bal-devnet-3 so we can see the results on Benchmarker.

Maria Silva:Sorry, I think I'm… I may have missed some of the numbers there, but essentially, it's, like, merge optimizations to bal-devnet-3 until we have

Maria Silva:all devnet 7 stable.

nixo:Great. Thanks.

nixo:Alright, any devnets Svalbard 8037?

nixo:Otherwise, we'll move on.

nixo:Okay, so in that vein, just, like, some, process.

nixo:We had talked about, an SFI definition change, at…

nixo:Svalbard, at one of the sessions, I had brought this up on a call, about a month ago to look through this SFI definition.

nixo:I have made the final changes, reflected… that reflected that discussion. If there are no,

nixo:Objections, I'll move to get that, merged in the next…

nixo:day or two. And then, based on that definition, I think that, DancerAtops had a list of EIPs, that could be, moved from CFI to SFI, that would

nixo:help both ecosystem participants know that these are the EIPs that are most likely to go in, they're being worked on, they're quite stable, there's, like, a set of four criteria in that SFI definition.

nixo:And he did a draft proposal, or a draft PR to, move those to SFI in 773, so if there are any…

nixo:Objections to that, please comment on that, PR.

nixo:Otherwise we'll get that, we'll get that merged by the end of this week.

nixo:Tony?

Toni Wahrstätter:Yeah, regarding… regarding the process, I mean, I brought it up in the…

Toni Wahrstätter:swipeout session, the only thing we should, think about is, how do we then decide what to put on devnets and whatnot.

Toni Wahrstätter:Because this is one of the criterias in that, in those four points, and we don't really have a process for that right now.

nixo:Yes, I actually, I think that, you may have missed earlier this year, we did actually make a prioritization list for,

nixo:for the CFIs that are in Glamsterdam. We didn't, like, put it anywhere, we just discussed it on a call once, and I think 8037 was number one on that list.

Toni Wahrstätter:I'm sure

Toni Wahrstätter:It's on forecast, right? I mean, I know that… I know the priorization… okay, but there was a priorization with the tiers on fork… on forecast.

Toni Wahrstätter:And… We didn't really, go…

Toni Wahrstätter:with the… with the order we had on forecast, we were randomly, like, chosen EIPs that we put on the devnet. For example, 8047 was, like, the second

Toni Wahrstätter:lowest prioritized, EIP by clients, but we still agreed it's, like, important. So I think we… we should either not overcomplicate things and just

Toni Wahrstätter:Keep the freedom there, and put things on a definite that we think, when we think it's the right time.

Toni Wahrstätter:Yeah.

Toni Wahrstätter:I don't think we should directly go by the prior list.

nixo:So the, the prioritization list, it was, is not on forecast,

nixo:I will link it somewhere, but we can… I think we're not gonna have to CFI or, like, prioritize a CFI list again until we get to the final, list for Hegota, so we can…

nixo:discuss if this is still, like, a controversial, move, but I think it does help the testing teams decide what goes in, and I…

nixo:the criteria listed there was that the… basically the facilitators work with the testing team, to create that prioritization list, propose it on oral core devs, make any changes the clients, think are more appropriate, and then that's quite a flexible list. So that's just reflecting what the clients

nixo:think, the ordering should be what's,

nixo:Based on what can't… what can go in, what's,

nixo:able to, be implemented, what's important to implement, not just what's easiest, not just what's more… most desired.

nixo:And then, put that in the… in the meta. And I think the idea is that's flexible. That's not, like, a… a rule set if things change.

nixo:later on, then we can move things up and down that prioritization list, but it just helps the testing teams figure out what should go in. And I think that we can bring that at ACD if anybody thinks that an EIP is misplaced on that list.

nixo:Pooja?

Pooja Ranjan:While we are addressing the PR11475, which talks about the specific condition, I would like to request to kindly look into the PR11006, which actually talks about

Pooja Ranjan:an important part of this Proposal 7723. So, basically, there is a difference between EIP stage… status and EIP stages, so I… I believe that it has not been correctly documented in the proposal, and the

Pooja Ranjan:PR suggests that we should actually update statuses with stages wherever applicable, wherever it is related to network upgrade, not the EIP standardization process. So, just wanted to bring it to attention.

nixo:Okay, great. That is in the chat, if you have any, preferences on

nixo:that wording, please go comment on that, on that PR.

nixo:If… no objections, then we'll move to, SFI those EIPs.

nixo:most of those are in… I think all of them are in devnets. There was a comment that 8037 is not…

nixo:But the argument for that was a… the amount of work that has been done during Glamsterdam, and the fact that it is.

Marius Van Der Wijden (M):Mmm.

nixo:Excellent.

Marius Van Der Wijden (M):He meant 8038.

nixo:Oh.

Marius Van Der Wijden (M):88 is not under DEFNet, and it shouldn't be SFI at this point, but 8037 is.

nixo:Okay, yeah, 8037, 8038 is not on that list.

Ben Adams:Yeah, I… off by 100.

nixo:Okay.

nixo:Okay, we'll move on, to 80-70 changes. Camille, are you here?

Kamil Salakhiev:Yep, I'm here.

Kamil Salakhiev:Yeah, just want to quickly highlight, yeah, changes to 8070. Yeah, we've had a good progress in Svalbard, discussing sparse blog posts.

Kamil Salakhiev:Yeah, so we merged already the changes required in Engine API, basically introducing Git blocks before, and some updates for Fortress Updated.

Kamil Salakhiev:calls, yeah, so the last piece remaining is,

Kamil Salakhiev:yeah, make some final changes to 8070 EIP to kind of narrow down, the…

Kamil Salakhiev:behavior for the builder, and, yeah, also just highlight these engine API changes. So please take a look,

Kamil Salakhiev:Yes, I believe Geth's team is actively working already, on the AIP, and, Nethermine and Besso, yeah, also.

Kamil Salakhiev:Kinda, either working or considering to start working on that soon, so…

Kamil Salakhiev:Yeah, as soon as it's implemented in more clients, yeah, we can schedule for the upcoming devnets.

Kamil Salakhiev:Yeah, so please take a look. Thanks.

nixo:Great, thanks.

nixo:Tony, do you want to talk about clarifying the min-rec depth, without rethinking?

Toni Wahrstätter:Yeah, this was one of the points we discussed, at Interrupt 2.

Toni Wahrstätter:Basically, how far do we want EL clients to reorg back in case of a deep reorg without triggering resync?

Toni Wahrstätter:And I think some clients, like GEF, are prepared to re-og back quite, quite, quite many blocks.

Toni Wahrstätter:Whereas other clients can only react back, like, a few epochs.

Toni Wahrstätter:And it would be great if we can align on the number there.

Toni Wahrstätter:And there have been multiple numbers proposed, for example, the 128 blocks, which was the minimum there. Then there was the week subjectivity period, so about 15 to 16 days.

Toni Wahrstätter:I think Jasek also proposed

Toni Wahrstätter:To have it more like 38 days, which is…

Toni Wahrstätter:Which is, with the inactivity leak kicking in, the amount of time we need to restore finality when 70% of the network are offline.

Toni Wahrstätter:So, we don't need to resolve that today in the call, but it would be great if people can look into this agenda item, and we can resolve

Toni Wahrstätter:This, and have yields align on that number.

nixo:Is there a deadline by which, we sort of need to have that sorted?

Toni Wahrstätter:So, in theory, we should have sorted it today, I would say, because, Reox could have many times, and I think many clients would today just trigger, sync.

Toni Wahrstätter:I think GEF is basically ready, because Marius was at some point saying GEF can react back, like, 90K blocks or something. That would be roughly the week's objectivity period. I would just ask other clients to, look into this.

Toni Wahrstätter:And then figure out, like, what to best do in order to not fall back into SnapSync.

Toni Wahrstätter:I know that sometimes it might take a while to restore the old state by going through the state divs and apply them.

Toni Wahrstätter:But this might be better than just returning an error to the CO. So better we miss a few blocks than we fall back into SnapSync.

nixo:Karim?

nixo:Kareem, did you…

Karim T. (matkt):Huh, yeah.

nixo:Raise your hand. Yeah, okay.

Karim T. (matkt):No, I said we have a pair in Bezo for that, but as I said, it would be nice to really have a…

Karim T. (matkt):a test with a shadow fork, even if it's not something we will run a long time, just to see the behavior of the different clients in a real,

Karim T. (matkt):real environment, with a good test close to the reality. Because, yeah, we have a PR today, but it's difficult. We can't do a big rollback, but we need also to check after the rollback, to roll forward with the new head and see how…

Karim T. (matkt):Or the client will,

Karim T. (matkt):work correctly with the CL, etc, so I think it would be nice to have a test.

Karim T. (matkt):To verify that we are working correctly in this case.

Karim T. (matkt):And maybe it will help to define the right amount of block.

Karim T. (matkt):Like that, if we have a test, we can try different, reorg size and decide what is the best.

nixo:Potus… I'm gonna call him POTUS before Felix, because POTUS couldn't raise his hand before.

Potuz:Oh, yeah, I just want to make a quick comment on the issue of reorging back. I think…

Potuz:So this is a problem that happens on EPBS, that we might send an FCU to a previous chain on the EL side.

Potuz:But…

Potuz:I think you guys should read this post that I posted on the chat. I think we should avoid completely, and we should even probably forbid an FCU to, without payload attributes to roll back. That means these reorg's bags are only relevant to building the next block.

Potuz:they're not relevant for the user that is following the chain, and it's not really relevant for the CL client to send an FCU without payload attributes to go back in the chain. So I think this shouldn't really affect users. We should never try to roll back the chain, live.

Potuz:on… yeah, so on regular sync. This should be only used by the proposer of the next block to trigger block production. So only builders and proposers should use this rollback, and not… no one else.

Marius Van Der Wijden (M):But…

Marius Van Der Wijden (M):photos, that means we would need to have this reorg within the proposing window, within the 12 seconds, right? And this is not possible.

Potuz:Yes, so… so what will happen is that the proposer will find out at the, later in the slot that, his head has just rolled back.

Potuz:And it will only roll back by one block. Actually, it needs to… it can roll back, and in the event of an attack, of a majority attack, it can roll back up to the justified checkpoint, and not more than that.

Potuz:But if there's no one that has a majority of the stake that is malicious, we can only roll back one block.

Potuz:And it's only for the proposer to say, you need to build me a block reorgan the last payload.

Mikhail Kalinin:I have a question, Potos. You were saying a bit different stuff before, when we were discussing this change.

Mikhail Kalinin:So… What is the finish?

Potuz:that I said differently.

Mikhail Kalinin:Oh, I mean, like, that, now you're saying that, basically we don't need to do, to do, revert on the same, I mean, like, reorgan on the same chain, deeply back, even if we are syncing, right? Well…

Potuz:Duh.

Mikhail Kalinin:Yeah, but before… but before that, you were kind of, like, saying that, we have to… we need to… we need this revert, up to a finalized checkpoint. I'm just wondering if anything has changed in that time.

Potuz:Nothing. The spec is the spec. So, formally, we can have a reorg, nothing is finalized, no payload is finalized.

Potuz:until… It's actually finalized, so we can… in theory, you can always reorder back all payloads.

Potuz:In practice, the proposer is the only one that should trigger this, and the proposer

Potuz:In practice, and even in theory, for the proposer, can only reorg back up to justified, because no proposer would reorg its own justified checkpoint.

Potuz:So that's one thing. And the… the other thing is that it's… if you're not under… the only way of reorging more than one block is if there's a malicious majority.

nixo:Felix?

Marius Van Der Wijden (M):Are you still… are you still talking about reorgs within the canonical chain, or are you talking.

Potuz:Yeah, yeah, it's only within the canonical chain, but the post that I want you guys to read is that the important thing about this is it's that the user should never see this.

Potuz:So, but a user that is following the chain?

Potuz:see a reor back on the EL. Only the proposer should see such a reor back.

Marius Van Der Wijden (M):Yes.

Felix (Geth):Talking a little bit about something else, yeah.

Marius Van Der Wijden (M):Yeah, we're talking about, any reorg, not in the canonical chain.

Potuz:Yeah, that's a different story. That should be up to finalize, in theory.

Felix (Geth):Yeah, so we are… what I wanted to just give a quick overview, maybe this topic can also be settled later. So there is an EIP proposed, I'm not sure, I think, Tony, you proposed it, that basically clarifies the expected reorg

Felix (Geth):window.

Felix (Geth):that clients have to support, and I think that is a good direction to go in, because in the past, we have just completely left it up to the client. And this has led to the situation where there are some clients that cannot reorg very far, and others that can reorg very far. So in Get, we always had this,

Felix (Geth):opinion that we have to be able to support very long reorgs in case the chain will actually hit this. However, it is important to consider that a very long reorg in the chain would also have a significant user disruption.

Felix (Geth):Like, regardless, if this happens, the chain is gonna be under heavy attack.

Felix (Geth):Still, it is good to clarify it, because in case of such an attack, we have to be able to recover quickly, and the only way to do that is if the clients don't fall into the snap sync. Because in the case of a sinking chain.

Felix (Geth):over a chain being attacked, the snap sync efficiency will also degrade. So we have seen this in the past with testnet incidents, where even getting clients to sync is the main issue. So what we would ask is that clients

Felix (Geth):extend their reorg window, and this EIP doesn't. However, just as a quick comment also about how GET handles this.

Felix (Geth):it's not actually required for clients to have the state, like, all the way back. That would make them an archive node, and that's not really the goal of requiring this. And it's also not said that reorging back the chain like many blocks has to be a particularly fast operation.

Felix (Geth):We… it doesn't have to be instant. It's just…

Felix (Geth):that it has to be supported at all. So I think one thing is we could… we should really start, to create some tests that exercises this.

Felix (Geth):and also see how the clients behave, just so that they have this theoretical capability. And then we can just see where it goes from there, like, what we can all agree on. But this, like.

Felix (Geth):38 days period or something sounds pretty reasonable to me, because if there's a natural limit in the beacon chain for how far back it could theoretically reorg at all, we could just use that limit, and that should be fine.

nixo:Marius, is your hand still up?

nixo:Okay, POTUS.

Potuz:Just from the engineering perspective, I'm a little bit confused. Wouldn't… wouldn't this in the happy case be a no change? Like, you… if you're finalizing, then it should be fine, you should be able to reorg the last 64 blocks, or whatever.

Potuz:And if you're… if we are not finalizing only in that situation, you trigger being a… sort of like an archive node since that point.

Felix (Geth):It's not about being archived node, this is just about the client being able to walk the chain back to an earlier state. In GET, this is achieved by storing reverse diffs of the state up to a certain depth, and we need those reverse diffs just to be able to walk the chain back in the theoretical case. It's not fast to do this.

Potuz:Yeah, no, I understand, but my point is that you don't even need to store anything if you're finalizing. You never need to reor back if you're finalizing.

Felix (Geth):Yeah, this is kind of true. We could, in theory, truncate also these reverse tips to the finalization point. That's correct.

Felix (Geth):So if we are certain that, like, there will never ever be a situation where we have to reset back to a point before finalized, then yes. In theory, you can delete everything before the finalized. But you have to be prepared in the client for a situation where finalization is not working.

nixo:Great. Do we want to…

nixo:take this off saying, er,

nixo:offline and, discuss it maybe in that EIP PR?

Felix (Geth):It would be good to get more statements from clients. I mean, the execution clients are all here, so… and you guys should all know, like, what are the limits of the org.

Felix (Geth):So, just to hear it from people, what's the situation, what do you think about it?

Felix (Geth):It's not a… not a slow… you can just have a quick run of thickness.

Łukasz Rozmej:So we are… we are working on supporting, reorg up to finalization barrier to make it dynamic, and that's our goal, and it will be then arbitrarily long, as… as… as…

Łukasz Rozmej:Where the finalization barrier is.

Karim T. (matkt):In Bizzle, we have something similar to GET. We have the trilog with the prior version of each account and slot and the new value, so we just have to apply this trilog to rollback, and we already have a printing mechanism that is not removing trilog.

Karim T. (matkt):Before finalization, so as soon as we have a finalization, we can start running the whole try log.

Karim T. (matkt):But before that, we are keeping this dry log. We just have to…

Karim T. (matkt):To modify the logic, to not have a…

Karim T. (matkt):out of memory, if you have a deep preyorg, and we have a PR for that.

Karim T. (matkt):But, thanks to that, we should not have any really limitation.

Karim T. (matkt):Oh.

Karim T. (matkt):can choose a big number, it will not be a problem, I think. But we need two tests, I think it just… if you have a test, we'll be… we'll be more confident.

Andrew Ashikhmin:In Erigon, the default is that we can only unwind to 512 blocks, so we probably need to make some changes to support extremely long reorgs.

nixo:Do we have anyone from rest?

nixo:Go ahead, Corinne.

Karim T. (matkt):I just wanted to say something. In Bezoo, in order to manage the deep reorog, what we are doing is to do this rollback by batch, so we are applying an amount of shredog, we are persisting this state, and

Karim T. (matkt):restart applying a batch of trial, etc. Like that, we can, remove the issue of out-of-memory if we have a really, big, big reorg.

emma (reth):From the Reth side, we couldn't handle the one month at the moment. We'd need to make some changes.

nixo:Are those blocking changes?

emma (reth):Mmm… I think it would just be a bit of work for us.

emma (reth):So, it depends.

emma (reth):On, like, when you need it.

emma (reth):But yeah, it would be super slow for us, like, Felix is saying from Gath.

Toni Wahrstätter:Yeah, so can we do, my feeling is that clients are all more or less, ready for that until Glamsterdam, so I think as of Glamsterdam, we can assume that EL clients will be able to react back the

Toni Wahrstätter:38 days, which is the number that Yasek proposed, which is the inactivity leak, with 70% of the nodes being offline, and then restoring finality.

Toni Wahrstätter:Then I would update the EIP. Currently, it has the weak subjectivity period in it, and I would update it to the

Toni Wahrstätter:I think it was roughly 38 days,

Toni Wahrstätter:That we would then have to, react back at the maximum.

nixo:Is there any other client besides Reth who doesn't feel like, this is… Currently doable?

Andrew Ashikhmin:Well, it's probably doable, but as I said, for Erigon, we have to make some changes and to do the testing, so right now, probably doesn't work out of the box.

Andrew Ashikhmin:It's, everything is doable, but…

Andrew Ashikhmin:we… it seems that we have a lot of things, required for Glamstaden. We try to do it, of course, but, you know.

Andrew Ashikhmin:Like, let's not repeat our mistakes with Pectra when we had to split it into two works.

Toni Wahrstätter:Yeah, I agree, this doesn't even need a hard fork, in my opinion. Like, this is something we should just agree that we want to move towards to, but this is nothing that can break a consensus here, so we don't necessarily need to do it with Glamsterdam.

Toni Wahrstätter:But yeah, we can just say, okay, we agree that we want to get there as fast as possible, and if we have it at Glamstadom, great, and if we don't, then sometime after Glamstadum.

emma (reth):Yeah, I think that's reasonable.

emma (reth):From roughside.

nixo:You're welcome.

jochem-brouwer:Yeah, I wanted to quickly ask, because I saw that in Hive, this is possible to test, but since this is, like, a very deep reorg, is this directly supported? Because I would like to…

jochem-brouwer:help testing this, and also, because this is mainly about the performance, but this is also part of, like, a benchmark or whatever, but I think this is, like, very handy to… to see what the impact is on these kind of attacks.

nixo:Otis…

Potuz:Am I correct that the danger here is that if I receive such a block, and everyone that becomes, I send new payload, I get an accepted, because they verified the block hash.

Potuz:and then for some reason, it becomes my head, then every client that cannot actually execute that reorg becomes optimistic. So, in principle, we could just immediately stall the chain.

Potuz:If every CL says, this is the head, and we're all optimistic, is that the case?

Mikhail Kalinin:It depends on what status the EL will return in the response to that reorg.

Potuz:But I haven't triggered the reorg yet. I just sent new payload, and it's a… it's based on a very, very old guy. So I assume that the EL does not execute it, it just tells me syncing, or accepted whatever was the original one. And then I… then I can actually just send an FCU to it.

Potuz:If the Yale has not finished executing, it will tell me syncing, I will just change my head to that, and then suddenly we're all dead because we're optimistic, all of us.

Potuz:That's my reading of what you guys are telling me happens.

Potuz:I mean, in…

Potuz:I don't care that it's too slow. It could take, like, 6 hours, but as long as the block is actually executed, we can just… we don't lose slightness.

Marius Van Der Wijden (M):Yeah, like, for gas, it is being executed, it just takes a long time.

Marius Van Der Wijden (M):And we can only do 90,000 blocks instead of 120,000 blocks.

Marius Van Der Wijden (M):So, we… like, for us, it's just a parameter change, but other clients don't have that capability yet, at all.

Mikhail Kalinin:But if… so you have to execute a block, but before that, you have to… to obtain the state, right?

Mikhail Kalinin:Which is kind of, like, 100,000 blocks ago.

Mikhail Kalinin:I mean, like, it diverges from the state that you have

Mikhail Kalinin:100,000 blocks ago, so you have to apply reverse diffs, and then execute a block. Is that correct?

Marius Van Der Wijden (M):Yes, exactly.

Mikhail Kalinin:So, and I saw in the chat that it will take about 6 hours, right?

Marius Van Der Wijden (M):I think… So, like, we have to also test that.

Mikhail Kalinin:All right, and yeah, see, so in which status will be responded in the engine API in this case?

Mikhail Kalinin:If it's gonna be, like, sinking, then…

Mikhail Kalinin:And then it becomes the head. What Podit is saying, then, all CL nodes that

Mikhail Kalinin:Got into this situation, we'll be optimistic.

Marius Van Der Wijden (M):If I understand Sino correctly, we don't return anything, we just… We just do the reorg.

Marius Van Der Wijden (M):And then at some point, we return.

Marius Van Der Wijden (M):Accept at all.

Marius Van Der Wijden (M):Pilot.

Potuz:But I think on new payload, you should return immediately, without executing.

Marius Van Der Wijden (M):Yeah, yeah, on new… no, no, this is on blockch just updated. This is only if you really force us to do… to execute this block.

Marius Van Der Wijden (M):A new payload, we just can just ignore it.

Marius Van Der Wijden (M):This, this can only happen in the case

Marius Van Der Wijden (M):Where the CL node says, this is our current block.

Marius Van Der Wijden (M):And that can only happen if there's… Either non-finality going on.

Marius Van Der Wijden (M):Or a majority is malicious.

Potuz:then can I suggest that we agree on, if we are in such a situation, we decide that all clients should either return syncing, or all clients should execute and not return anything, so not to have a split there? If everyone returns syncing, then we all become optimistic, and then we wait until someone can actually execute it.

Potuz:And if everyone doesn't return anything, then the reorg is not even performed.

Potuz:Because we can't… we do not, change head until the EL tells us. We actually time out, and we would consider that block as not imported.

nixo:Okay.

nixo:Do we have any other open questions around this? Because I feel like we maybe aren't going to get to the number.

nixo:the option that we want to choose today, but we have agreed that testing is needed, and it sounds like Joachim and Mario can work on testing.

nixo:Okay.

Toni Wahrstätter:Apart from that, it would be great if… I mean, Yasek already looked into that. I looked into the number today a bit too, but if we can…

Toni Wahrstätter:That might work async, if we get more confirmation that, those 38 days might actually be the right number there.

nixo:Great.

Toni Wahrstätter:I will update the EIP, right after the call, and then I can drop it into the CL.

Toni Wahrstätter:Cheat.

nixo:Perfect.

nixo:Okay, we're gonna move on to 8254.

nixo:This…

nixo:I think was a Barnabas and Marius topic. Do you guys… or do either of you guys want to talk about it?

Barnabas:Yeah, so the main concern, came from the initiative to raise the gas limit in Grand Sterdam to 200 million, gas.

Barnabas:Which will basically allow us to exceed the 8,192, deposits in a single slot transaction, which will basically make all the CLs fail.

Barnabas:there's a few ways to, get around this. One of them is, get rid of the limit. The other one is to, enforce the limit on the ES side, and,

Barnabas:Yeah, we could just also increase the limit, or decrease the limit.

Barnabas:This is basically what we should discuss.

nixo:So, to be clear, this would be a new EIP in Glamsterdam, in order to… enable…

Barnabas:Yeah.

nixo:Okay.

Marius Van Der Wijden (M):Yeah, so, the A2 platform, the one that Barnabas is proposing, basically says that we have to count every, deposit, and if,

Marius Van Der Wijden (M):above.

Felix (Geth):In Liechtenberg.

Marius Van Der Wijden (M):Huh?

nixo:Go ahead, Marius, I think that was an accident.

Marius Van Der Wijden (M):Oh, okay. We have to… we have to count every deposit, and, and then, at every… after every transaction, we have… we have to check whether… whether,

Marius Van Der Wijden (M):Whether this transaction can still fit in, or if it can't, and then we have to move it out, and then… so yeah, it…

Marius Van Der Wijden (M):Makes block building quite a bit harder. For block verification, we can choose to either…

Marius Van Der Wijden (M):Verify the limit after every transaction, so we can verify the limit after the end of the block.

Marius Van Der Wijden (M):Verifying it after every transaction has the advantage that we can arrow out earlier. Verifying it at the end of the block means we will, in the worst case, spend more time

Marius Van Der Wijden (M):But it's much easier to implement. Yep.

Marius Van Der Wijden (M):I… I'm not a big fan.

Marius Van Der Wijden (M):I had the idea of just…

Marius Van Der Wijden (M):Just, deleting every deposit that goes over a certain number.

Marius Van Der Wijden (M):And just, yeah. But that is, griefable.

Marius Van Der Wijden (M):Another idea, and it has…

Marius Van Der Wijden (M):gained some laughs in the chat, but it's actually a serious idea, would be to switch out the deposit contract

Marius Van Der Wijden (M):With a different deposit contract that, that codes a limit per block.

Marius Van Der Wijden (M):And, Then we would actually limit it

Marius Van Der Wijden (M):Where it makes sense, because right now the idea is to limit it

Marius Van Der Wijden (M):in that… in the single part that… where it doesn't make sense, and that is the EL, it would make sense to either limit it on the deposit contract, or to limit it in the CL. Yeah.

Barnabas:How would you propose to limit it on this scale?

Felix (Geth):I can give a comment, sorry, for earlier audio issue. So,

Felix (Geth):for… we can either reject the block on the CL by just validating that there are

Felix (Geth):not more than X.

Felix (Geth):Number of requests?

Felix (Geth):However, this is a bit awkward because it creates a new invalidity condition for the block on the CL side only, so it's kind of like, basically, we would have to modify the fork choice to say that this block will never be…

Felix (Geth):You know, in the… in the active fork.

Felix (Geth):So this is possible.

Felix (Geth):Or, I was also wondering what it would take to raise the limit on CL site.

Ben Adams:We'd also need to change, not the validation rules, but the building rules, so that It doesn't…

Ben Adams:The CLs then reject the block, moves to another EL, which overstuffs the deposits, which then gets rejected, which moves to another EL, which then overstuffs the deposits.

Ben Adams:Otherwise, we'd halt by just doing the same thing again and again.

nixo:Tony?

Toni Wahrstätter:Yeah, I agree that this makes block building a little bit more complicated, because

Toni Wahrstätter:you would basically introduce a new, cycle problem, where one transaction could basically consume, for example, all 512 deposits, and then you can't really append more transactions into the block. So we basically, in addition to the gas limit, we would have another,

Toni Wahrstätter:very arbitrary limit that you can't even statically see, like we do for block transactions, for example, that we have the same problem, but we can at least statically see it from looking at the transaction, which is not the case here.

Toni Wahrstätter:But yeah, it feels like Banabas EIP is the simplest thing to do by just, capping it, and…

Toni Wahrstätter:EL clients would just abort block building, or not append any more transactions if we hit it. Just for context, this almost never happened in the past, so I think we had two blocks

Toni Wahrstätter:That actually went over the 512. So this is really an edge case we're talking about here.

Toni Wahrstätter:So I would prefer a very simple solution here.

nixo:Mars?

Marius Van Der Wijden (M):Yeah, quick question. Pluto seems to be…

Marius Van Der Wijden (M):worried about builder deposits. I have no idea how they work, and whether they will run into the same problem, so it would be…

Marius Van Der Wijden (M):Are they also deposited via the deposit contract?

Barnabas:Yes.

Marius Van Der Wijden (M):Included.

Potuz:So, from the perspective of DL, they're just the same, they're normal deposits, so for block building, I guess it's… you're not gonna recognize this.

Potuz:But the problem is that on the CL, we might actually need to do a signature verification immediately on the block as we are importing it, which is not something that we do for normal deposits, for validators.

Potuz:So this… in that sense, what, what Tony said, which is fright, we only had, like, one of few blocks with this many deposits, like, 512 would be more than fine.

Potuz:My fear is that, A, for builder deposits, we do not know if we can actually survive 512 deposits, as we did for validators.

Potuz:Because for those validators, we didn't need to immediately verify signatures. We put them in a queue, and then later on, we… on a churn, we verified those signatures. For builders, we would like to do this on demand immediately.

Potuz:which I'm not sure we can handle. And second, we do expect, at the fork boundary to get a lot of deposits for builders.

Potuz:So, I would not discount this problem of builder deposits. So, if there is a word in which we can cap this, the building time on the EL, that would be great.

nixo:Okay, great. Do we wanna do… is there any opposition to PFI-ing that to 7773?

nixo:And then, it sounds like they're… Sorry?

Peter Miller:Yeah, can I just clarify? It would seem to me that if you do this, there's a denial-of-service attack, where people have… you send a transaction that spends loads of gas.

Peter Miller:And then, after spending that gas.

Peter Miller:Turns out to not be inclusible, because it makes a ridiculous number of deposits.

Toni Wahrstätter:So I'm like…

Peter Miller:I'm quite wary of doing this. I'm like, can we not, like, find a way… basically, I…

Peter Miller:Because currently, we have a rule that you can tell, cheaply and statically, whether a transaction is includeable. And once you pass that check, you can include the transaction in the block.

Peter Miller:I'm very skeptical that it would be a good idea to act… to add a condition for block validity that violates that principle.

Peter Miller:So we should… it… the transaction should fail in some way, and still be includeable, if it busts this cap.

Peter Miller:Just getting to the end of a transaction and go, oh, sorry, you couldn't include that.

Peter Miller:doesn't, like, align with the basic principles that the EL goes through.

nixo:Tommy?

Toni Wahrstätter:Yeah, what Peter is saying is true. So basically, this is exactly the problem that… and what Marius was proposing would fix it, basically switch out the deposit contract, because then we would essentially have the transaction revert in case

Toni Wahrstätter:the maximum deposit number is reached. Otherwise, EL clients would have to find a way, for example, just abort block production at some point if they

Toni Wahrstätter:Keep trying to append transactions to the payload, and the block turns invalid because the maximum deposit is reached.

nixo:Felix.

Felix (Geth):I just want to give the quick note that,

Felix (Geth):we already have such a condition in the form of the maximum block size. So even currently, the builder has to be aware of… No, actually, yeah, so the builder has to be aware of, like.

Felix (Geth):How big is the block that it's currently building?

Felix (Geth):But it's a bit… it's, like, kind of goes in this direction also, but it… so we do have to verify that condition while… while building.

nixo:Okay, just to sort of time box this, do I understand that this is, like, the biggest blocker right now towards, 200 million gas?

nixo:For Glamsterdam?

Barnabas:Yeah, we could… we could safely do 190.

Barnabas:But, as soon as we go over 193, we are gonna have issues.

nixo:Marius, if, your, your alternative, direction, would that be a different EIP, or would that be 8254?

nixo:Oh, boy.

nixo:just to age by far.

Marius Van Der Wijden (M):So… the problem… well, it seems like even 190 is too much, because CLs cannot handle more than 512.

Marius Van Der Wijden (M):-Oh.

Marius Van Der Wijden (M):More than a couple of builder, builder, signatures.

Marius Van Der Wijden (M):So, I don't know.

nixo:Can we, propose 8294 to Glamsterdam and have this open as a… as a way to address this one last blocker, and have people…

nixo:Discussed this async about how to fix this one last blocker to 200 million.

nixo:Felix?

Felix (Geth):The way I should have lowered my…

nixo:Okay. Okay, I will,

nixo:Barnabas, if you want to PFI 8254 to 7773, and we'll have it in the PFI, not CFI, just to indicate that there are open questions that need to be addressed.

nixo:Because we would definitely like to get that floor of $200 million.

nixo:If possible.

nixo:Right.

nixo:Let's move on to, pavel has two items, related to self-destruct, one Glamstream related, and I think one, general.

nixo:Pavel, do you want to take the mic?

Paweł Bylica:Yes, hello?

Paweł Bylica:So I'll start with, EIP8246, which proposes to

Paweł Bylica:Remove the burn feature of self-destruct.

Paweł Bylica:So…

Paweł Bylica:not going into, like, very, very much into details, the service track has, like, multiple things it does at the end, but,

Paweł Bylica:It can also burn if, if… If you target,

Paweł Bylica:the EF transfer to yourself, and

Paweł Bylica:And the main motivation why we would like to remove that is the other AP, AP7708, which emits logs for transfers and also emits logs for burn events.

Paweł Bylica:So, kind of contrary to the CIP, I propose that instead of emitting logs for the burn events, we actually get rid of burn events from EVM.

Paweł Bylica:And that's, like, the main motivation of this EIP.

Paweł Bylica:How this is done is basically we… We try to,

Paweł Bylica:persist the balance of the account. So, distraction might not be, like, complete in the end. We can… we might be left with the,

Paweł Bylica:With the accounts that… Will be empty, but will have, some balance left.

Paweł Bylica:So yeah, so that's basically, like, rough overview.

Paweł Bylica:of the CAP, and… Proposing this, rightfully triggered the question if we can completely remove, self-destruct.

Paweł Bylica:And I think… Should be clarified what the complete removal means.

Paweł Bylica:It's not like the service tracking structure will stop working, it will…

Paweł Bylica:Still do some stuff, but in the limited factor.

Paweł Bylica:So, I think the agreement is that,

Paweł Bylica:it will behave as, sometimes called, send all instructions, so we'll still send EF to the targeted address.

Paweł Bylica:And will terminate the execution of a call at this point, as it does currently.

Paweł Bylica:And thus has been proposed previously, and we kind of… head to…

Paweł Bylica:Went back to some defensive positions, and we removed Self-destruct partly.

Paweł Bylica:But still, in the case, an account is created in the same transaction, ServeDestruct kind of behaves as historically it was designed.

Paweł Bylica:Okay, so, so yeah, that's basically…

Paweł Bylica:Like, intro to this part, and

Paweł Bylica:I collected some data about self-distract usage, in the current mainnet.

Paweł Bylica:And I can give some details, but basically this is available already.

Paweł Bylica:So I can send the link to the AP, the first one mentioned, and the…

Paweł Bylica:And my, like, brief report about self-destruct usage.

Paweł Bylica:And if there are no questions so far, I can go over, like, basic,

Paweł Bylica:like, some overview of the data I collected.

Paweł Bylica:Okay, so there's no questions so far, so,

Paweł Bylica:So I… I collected all the self-destruct events since, for the last 5 million blocks.

Paweł Bylica:And,

Paweł Bylica:And the, this, like, yeah, the block 20 million happened right after Cancun, so this was the point where we modified some of these tracks already.

Paweł Bylica:So we have the… all the events that happened in these 5 million blocks.

Paweł Bylica:And the usage of the… I mean, the usage of the service track actually, increases, although the… the deprecation notice that we… we kind of notified users of, previously.

Paweł Bylica:So absolute values go up,

Paweł Bylica:If we compare that with the gas limit, I can say, roughly, it stays on the same level, so we might want to attribute the increase of usage to the gas limit increase.

Paweł Bylica:Although we can also identify, like, more unique users,

Paweł Bylica:Coming for this pattern, so that's one thing.

Paweł Bylica:In general, there was, like, five, well, this was half a million events that happened, within these 5 million blocks.

Paweł Bylica:And if we consider, like,

Paweł Bylica:the context where self-destruct is completely removed,

Paweł Bylica:That would, that would cause creation of additional foi… 400,000 accounts.

Paweł Bylica:Some of them would have… Would have some…

Paweł Bylica:code, and the code is actually very small. It's, our,

Paweł Bylica:combines into around 3 megabytes of additional code. So the number of accounts are quite big, I would say. The number of codes is, like, tiny.

Paweł Bylica:And why people use it, I'm not currently sure. I tried to classify this, I mean, categorize the usage, and I have some idea how to do it, but well, there's not so much time to do so, so far.

Paweł Bylica:And finally,

Paweł Bylica:So, so the, so the gas, gas schedule, so the users already pay for the creation of their account, and they don't get any refund, coming from the service track.

Paweł Bylica:So, like, there's not… from our perspective, like, the kind of protocol devs is not really issue.

Paweł Bylica:So, even if the account will remain in the state, someone paid for them.

Paweł Bylica:And within this event of self-destruct, like, majority of this would work as it is right now. So basically, the only difference would be that there were some Duster counts remaining after transactions, but the workflow will not be broken.

Paweł Bylica:So only 12% of this, usage would be broken, and this only happens with… if any of these schemes reuse the same address, because the next time you want to create account on the address, and

Paweł Bylica:It wasn't, and if it's not properly self-destructed, it means the creation will fail.

Paweł Bylica:this is 12% of all of these, events, but still, I think this is the part we'll need to, like, dig into.

Paweł Bylica:And, yeah, so basically, that's the overview. My personal comment is that

Paweł Bylica:from the usage patterns, I kind of find some, like, elegance into this that they actually clear after themselves.

Paweł Bylica:Because many of these… many of these, usage is basically, like.

Paweł Bylica:create… just create, like, a top-level account, do some scripting, and then serve this track. There are definitely other ways to do so, but yeah, this is kind of, like…

Paweł Bylica:At least, it doesn't cause unnecessary state decrease in this in this region, I mean…

Paweł Bylica:Yeah, so that's… that's it. And, I think that's… that's all for… from me for now.

nixo:Peter?

Peter Miller:Yeah, firstly,

Peter Miller:Thank you, that's, incredibly helpful, and I really appreciate that you've gone to the effort of producing this data that we can look at.

Peter Miller:I basically agree with you about the whole wasted account. We currently…

Peter Miller:charge people for creating accounts that get self-destructed in the same transaction, and then we don't refund them that if the account gets self-destructed. We don't care if such accounts end up in the state because they've paid for them.

Peter Miller:I find the fact that you've located 60,000 transactions.

Peter Miller:In two years, that would fail.

Peter Miller:If we removed self-destruct.

Peter Miller:makes me skeptical that we'd be persuaded to do it. Like, I think I agree, everyone agrees that if we could just get rid of self-destruct, we would absolutely like to do this. But the only reason we kept self-destruct is because users told us that it would break stuff.

Peter Miller:If we didn't… if we removed it entirely, and that this was basically the only use case.

Peter Miller:And we've historically observed a very extreme policy on changing things that might break current users.

Peter Miller:And there are a lot of candidates for things that we would remove.

Peter Miller:If we were happy to, like, break the occasional user.

Peter Miller:So, I just don't see how it's viable to remove same-transaction self-destruct, given that there are 30,000 cases a year

Peter Miller:Of people actively relying on it, as in their contracts and transactions would break if they didn't use it.

Peter Miller:Which is my understanding from your statistics.

Paweł Bylica:Yeah, I can… I can… I wanted to raise my hand, but I…

Paweł Bylica:I lost where the button is, but anyway, yeah. So, like, I have two comments. One, all of this data is available if someone wants to do, like, further analysis or anything like that.

Paweł Bylica:Secondly, I think this… this situation is not so dramatic as it sounds.

Paweł Bylica:Is that my observation, although I'm… I don't feel as an expert on, like, usage analysis of… of… of contracts.

Paweł Bylica:So many of these usage are still kind of scripts.

Paweł Bylica:So, you kind of make a decision to send it, and the moment you create a transaction.

Paweł Bylica:And the other part of the usage

Paweł Bylica:is some kind of, like, operation, like, operator doing some stuff with a factory, but the… this operator kind of can be identified as an EOA. So.

Paweł Bylica:It's… it's actually also, like, kind of decides to use a contract that has this pattern in their,

Paweł Bylica:and the moment it sends a transaction, so I think there's a way to migrate that. It's not like a…

Paweł Bylica:Yeah, so… so I kind of find it this… this pattern… It's basically some, like, helper…

Paweł Bylica:scalper EVM bytecode, but I… I kind of feel there's a way to migrate existing users.

Paweł Bylica:how ex… how… yeah, how to notify them, how to identify them, it's kind of… yeah, I don't know, but

Paweł Bylica:yeah, if… if you dig… yeah, if you go deeper into data and, like, the usage patterns, I think we can identify some… some ways, but…

Paweł Bylica:Yeah, kind of agree also that, well, it would… we would need to at least

Paweł Bylica:Make sure we actually find all of the cases that we need to, handle.

nixo:Okay. Paul, can I… is it accurate to say that, 8246 is being proposed for Glamstrom to enable 7708, and then…

nixo:Removing self-destruct is a… is a longer-term,

nixo:goal that might be for Hegota, and maybe needs a little bit more analysis into other,

nixo:He's…

Paweł Bylica:Yeah, I think that's not accurate, because we also had discussion with the testing team, and

Paweł Bylica:I think if you want to completely remove self-destruct, and we…

Paweł Bylica:I think the moment of Glamsterdam is also a good one, because it simplifies other AIPs, to my understanding, but

Paweł Bylica:Maybe some… someone from the testing can comment on this.

Peter Miller:I think that the, evidence, having looked at the data for these two AIPs that you've produced, is that removing the self-destruct, burn is at the level where it's unlikely to create any real breakage, and

Peter Miller:it is somewhat annoying, so I would be quite supportive of that.

Peter Miller:like, removing self-destruct entirely, given that it has actual users who will experience at least some breakage, is going to require, like, long-term research, and definitely can't make it into Glamstam.

nixo:Mario?

Mario Vega:Yeah, I could comment quickly on the testing. Yeah, it definitely will be nice, but I feel like if UX is gonna break in some… at some, to some degree with this change.

Mario Vega:It's… it's…

Mario Vega:I mean, the nice part would be that, local access list and 837 would never have to interact with self-destruct. That's very nice, because we will remove a lot of cases where this is like a…

Mario Vega:a problem to testing, but we have already, like, test cases for that, so we're not really removing work from us. It's like, basically, we're just simplifying the change, which is good. But I feel like, I mean, yeah, I do agree with the point that it's maybe too short notice. So, for us, I feel I'm leaning towards the

Mario Vega:the burn… the burn removal. I think, I think it's a nice middle point.

nixo:it seems like there's con… there's, some support for that, based on the emoji reacts in the chat.

nixo:Powell, does that sound good? And if yes, do you want to, do a PR to…

nixo:CFI that in 82…

Paweł Bylica:Yeah, yeah.

nixo:Yes.

Paweł Bylica:Sure, you can do that.

nixo:Are… is there any, opposition to… to going straight to CFI for that, EIP, given that it,

nixo:It seems to have broad support.

nixo:Great.

nixo:If not, we'll move on to Hegota.

nixo:Okay, we have a couple proposals for Hegota and an AA update from my client. Do we want to start off…

nixo:With 7709.

nixo:From Ignacio.

ignacio:Yeah, sure, I have 3 slides, to present this, so it should be pretty quick.

ignacio:Give me a second… Can you see my… Screen.

nixo:Yep.

ignacio:Cool.

ignacio:Yeah, so I wanted to, propose 7709 for Hegota.

ignacio:And I said.

ignacio:TLDR of what this EIP is proposing today, and he'll know when… whenever he has to execute a block hash up call.

ignacio:It, resolves the result, by using, any memory cache of the last 256 block hashes.

ignacio:And that's, justified by the current price of BlockHash, which is 20 gas.

ignacio:And what the EIP is, proposing is that, at the protocol level, we decide to resolve, block hash values, via an S load.

ignacio:Against the system contract of EIP2935 that was activated in Prague.

ignacio:Because the system contract is storing the history of the more than 8,000, block hashes,

ignacio:So, since block hash in-window size is the last 256 values, this can be a result from the…

ignacio:The storage try of the system contract.

ignacio:So the reason why, I'm proposing this is that block hash not being resolved from this system contracts.

ignacio:Create some complications for creating the execution witness for stateless environments.

ignacio:So if you're trying to execute a block statelessly, and this block contains a block hash execution of code at any point in the transaction list, the stateless client should receive

ignacio:This value, and approve that this value is correct.

ignacio:So, since block hash is, a kind of stateful opcode that is not really being resolved from the tries.

ignacio:This creates some complications whenever this execution width is constructed in a stateful EL, because

ignacio:For other state-to-log opcodes, like slowed or balanced,

ignacio:the Yale State Tracker usually will be aware of this axis happening, so…

ignacio:Creating an MPT proof for that stateful access is pretty natural, but for plug hash, it's not really the case.

ignacio:And the execution witness construction needs, like, an exceptional path to really resolve this.

ignacio:Because it's not, like, formally estate access.

ignacio:So, that's basically the gist of the motivation for this.

ignacio:So it's basically making block hash not be, like, an exception compared to other opcodes that are stateful.

ignacio:the, kind of, main concern that this EIP can have is what is the UX impact, because

ignacio:making block hash be resolved via an S-load to a system contract basically means that we have to reprice it to… to…

ignacio:To be aligned with what is happening.

ignacio:So that means that, we will be moving to the current 20 gas, price to an S-load cost, so it might be cold or warm,

ignacio:Depending if the… if the block hash is, repeated or not.

ignacio:So that's a decent amount of price change. Like, in the worst case, it would be around, like a…

ignacio:A lot of… a lot of change for users. And actually, if EIP8038,

ignacio:happens, this will be even more than today. The final numbers of DCIPs are not really yet decided, but probably we will expect a big change, so…

ignacio:Yeah, this might… might make things worse.

ignacio:So, I'm planning to run a replay analysis of historic blocks to really understand which is the UX impact.

ignacio:Probably I will try to wait until AT38.

ignacio:has some final-ish numbers, and we can try to understand which is the UX impact.

ignacio:I wrote some, deeper… analysis around DCIP, some implications.

ignacio:So here's the link if anyone is, interested,

ignacio:I also write the specs and tests in the execution specs repo.

ignacio:So yeah, I will share the slides, the link to the slides in the chat, so anyone can look at them.

ignacio:And, yep, that's mainly it.

nixo:Felix?

Felix (Geth):Yeah, sorry, I just have a quick question. So, is it… you are giving the main motivation for this change that, the stateless client would have to be aware of the hash, but is it not reasonable to expect that the stateless client should be aware of the last 256 block hashes in the history? I feel like this is a very obvious

Felix (Geth):I mean, most status clients will be aware of it. You would really, really, really have to have a client that is, like, completely unaware of the chain in order to not have this.

ignacio:Right, so the idea here is that the stateless client doesn't really have to…

ignacio:doesn't really need, like, memory about the previous blocks that were executed, so I want, like, the execution witness to be self-contained.

ignacio:Regarding… What is needed to execute the block?

ignacio:Because if not, you need an execution witness plus some kind of memory of the last Blogs that happen.

Felix (Geth):Yes, I understand this. I was just wondering, like, what kind of client would that be? Because most, like I said, most clients that are participating in the chain at all, even very, very lightweight ones, would have knowledge of the chain. I'm just, like, really wondering, like, it's… I feel like a very narrow case for a client. I mean, there's more like a…

Felix (Geth):philosophical change, I guess, that you're trying to…

ignacio:Yeah, I think this is mainly about just making the execution witness just have all the information that is needed for executing the block statelessly.

ignacio:It's just basically that, and not having assumptions about,

ignacio:These stateless clients having knowledge about what happened.

ignacio:Like, previously. So it's like a pure function, circus client.

nixo:Oh.

Paweł Bylica:Yeah, so I think this is not, like, super fancy change, but it makes the witness very much consistent and self-contained.

Paweł Bylica:Like, for example, you can pin this… this element in the storage to the block hash root, block state hash root, right?

Paweł Bylica:Otherwise, you would need to have, like, the hash chain of blocks to prove that the values are correct.

Paweł Bylica:And for that, you would need to block headers to actually hash them, and so on. So…

Paweł Bylica:Yeah, there's nothing we cannot do right now, but it just makes it nicer.

Paweł Bylica:And then, like, the witness is only about status, nothing like external elements there.

nixo:Peter, and then I'm gonna time Alex this so we have enough time for the last 3 items on the agenda.

Peter Miller:Yeah, that makes sense. I was just quickly going to say this is a very small change, but the benefits really are quite substantial. If we get rid of this, we're pretty much going to be in a position where you can validate a block with only the current block and its body, the parent header, and the state.

Peter Miller:And currently, you require

Peter Miller:the last 512 headers, and there's no good reason for this. Now we have this contract, so this is a very sensible change.

nixo:Great. Let's move on to, EIP8253. Jokam, do you wanna… Take the mic.

jochem-brouwer:Yes, yes, yes, let me also share my screen.

jochem-brouwer:Okay, I also have some slides. Can you see my screen?

nixo:Yep.

jochem-brouwer:Okay, cool. So this is about… I was beaten this one, so let's… let's go. This is about ERP 8253, remove EIP used back in accounts, and the context of this is also about ERP7610 on ERP by Gary and Martin.

jochem-brouwer:which is… which I've PFI'd for a glance at them. It is still in PFI, because this is somewhat, I would not say controversial, but okay, let's get… let's get into those points in a later slide. So, if we go back in time, at, well, nine and a half years ago.

jochem-brouwer:at change start, we could create contracts which did not start with non-0, but that was actually… sorry, that did not start with nonce 1, but the contract creation was then always 0. And, this leads to a specific kind of account, which was only possible to create before Spurious Dragon.

jochem-brouwer:This is an account where the code is empty, you have zero nons, but the storage is non-empty, and this leads to problems when you check for contact collisions.

jochem-brouwer:Because EIP784, which defines how you check for contact collisions, that says, okay, you should check the months and the code, and that should be zero, and it should be empty, so it does not check for the empty storage.

jochem-brouwer:And this is what was introduced by 7610, because this is not specified in the protocol yet. But this condition is theoretically possible.

jochem-brouwer:As previous vegan, we introduced EIP161, this is the state clearing EIP, and this bumps the standard conflict norms to 1 to mark these accounts.

jochem-brouwer:224 of these accounts existed at Spurious Dragon, and 28 accounts of them exist today, which I will call the fossil accounts.

jochem-brouwer:The ones which were removed, so the difference of these 2 on the 24 and the 28, these, it's actually no balance, and these are then empty by the definition of EIP161, and these were then deleted from the state already.

jochem-brouwer:So, about ERP67610, the argument against is that the address collision cannot happen in practice, because this would… well, you need to do some… well, it's a theoretical attack. And there's also, like, this extra runtime code, because you have an empty storage foot check on creation, which might need an extra disk lookup.

jochem-brouwer:regarding on the database layout, or you can check against a hard-coded list of existing accounts, which GEF has currently moved to. It's this,

jochem-brouwer:VR.

jochem-brouwer:to Gav, which is already merged, so there's now not the storage with Jack anymore, but the list check. And this list, I've checked it, I've also checked this against the list which I got at this ERP, and it's the same list, so that's good.

jochem-brouwer:Okay, so about this ERP… It's this pull request, which I will share here in the chat.

jochem-brouwer:Because it's this one… okay, yes.

jochem-brouwer:It's this… VR, which I don't seen the chat.

jochem-brouwer:Okay, so at the fork block, what we do is we bump the launch of all the accounts which have zero launch, no code.

jochem-brouwer:And non-empty storage, so there is at least one key with a non-zero value which exists in the storage fee of this account. And the balance is non-zero because of this argument which I just made, because all the empty accounts have been cleared by this ERP7523.

jochem-brouwer:The nonce is bumped before running the system contracts, so, yeah, also before any transactions. The non-spump is reflected in the book access list.

jochem-brouwer:There are the 28 non-perms, and this converts the previous dragon accounts, the fossil accounts, to accounts which can also be created now, because this is… has no code.

jochem-brouwer:But they write the stories in the init code, and per ERP161, the non-stage created account is at least 1. So why should we do this?

jochem-brouwer:This makes ERP7610 obsolete, because the ERP7684 collision check is not sufficient, because it is not possible to pay these accounts anymore, where we have, like, this weird situation where we have storage, but we also have zero nodes.

jochem-brouwer:Which was his point.

jochem-brouwer:It removes the pre-spirious dragon type of accounts from state, which is not possible to create anymore. It removes specific code at clients to handle these accounts. It removes also this type of accounts from state, so you can maybe do some kind of nice database layout optimizations.

jochem-brouwer:And it removes this, well, this special handling of these accounts, also in the testing suite, and the best point I want to raise is this simplifies the protocol, and it makes us all happy.

jochem-brouwer:Okay, that's lost my… points.

nixo:Great, thank you very much. Peter, I know you have a comment to make, but, we have two more things to get through. Light client, just real quick, do you feel like 5 minutes is enough to… or 4 minutes is enough to give an AA update, or do you want to kick it to the next one? Because if you want to kick it to the next one, we can…

nixo:do some questions on Yochum's presentation.

lightclient:I can go very quickly.

nixo:Okay. Real quick, though, Joachim, if anybody wants to discuss this, where's the right place to go?

jochem-brouwer:That's to execution depth at R&D.

jochem-brouwer:Okay.

jochem-brouwer:Yep.

nixo:Thank you.

nixo:Matt, the mic is yours.

lightclient:Thanks.

lightclient:Yeah, so I got a chance to talk to a lot of you guys in Small Bar last week. We had one major session where we discussed some high-level AA goals and constraints. This was kind of separate of

lightclient:How do we achieve these things? And I was more focused on, like, what exactly are we trying to achieve?

lightclient:posted the HackMD with the result of that session in the chat.

lightclient:And from there, had a lot of other conversations with people.

lightclient:More focused on the frame transaction proposal.

lightclient:And we are still working on figuring out what the right spec is that can make everybody happy.

lightclient:One specific spec item we spent a lot of time talking about was the 2D nonces, and we ended up deciding that we would just

lightclient:Proposed the 2D nonce.

lightclient:mechanism for frame transactions, this separate EIP.

lightclient:For now, and see…

lightclient:if, you know, what the feasibility of actually including this together with the frame transaction, in a GoTo would be.

lightclient:But yeah, I'm happy to answer any questions here offline.

lightclient:But otherwise, we'll just keep working on the spec for the next week or so, and then hopefully get to implementing some prototypes.

nixo:Thanks for the update.

nixo:Mercy, do you… you wanted to go over your engine API V2 scheme effects?

nixo:Mercy here.

Mercy Boma Naps-Nkari:No, I just wanted to bring it up so that, Codex can make a decision on it and also approve the PR. And also on this one,

Mercy Boma Naps-Nkari:We'll be removing this so that people are aware of this. This plan for PR788.

Mercy Boma Naps-Nkari:Thank you.

nixo:Thank you. That is all of the items on the agenda. Thank you guys for coming.

nixo:See you in two weeks.

lightclient:Thanks.

jochem-brouwer:Bye-bye. Thank you.

Mikhail Kalinin:Bye.

Toni Wahrstätter:Bye bye.

Chat Logs

Josh Davis:https://blog.ethereum.org/2026/05/02/soldogn-interop-recap

Barnabas:https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-0

Barnabas:https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-1

Barnabas:https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-2

Potuz:Replying to "g(svalbard)m" nah man are you still there!?!$#$

Barnabas:Replying to "g(svalbard)m" someone gotta skii all the slopes

Stefan Starflinger:https://github.com/ethereum/pm/issues/2033#issuecomment-4397074196

Mikhail Kalinin:Replying to "g(svalbard)m" And keep providing 24/7 uptime

lightclient:What if we create a gas trace format?

lightclient:Or extend the existing trace format?

spencer:Replying to "What if we create ..." Yeah we need to align on state gas in the traces

jochem-brouwer:Is it an idea for testing to leverage the BALs here to isolate txs for debugging here? At most 16.7 regular gas used

Marius Van Der Wijden (M):I would prefer to make it oblivious to the user

Ben Adams:Don't mind where it goes; but is very hard atm to tell either from receipts or trace where the gas goes on a client

Marius Van Der Wijden (M):Whats the tldr?

danceratopz:https://github.com/ethereum/EIPs/pull/11399 which proposes to update the SFI'd EIPS in Glamsterdam to: ### EIPs Scheduled for Inclusion * [EIP-7708](./eip-7708.md): ETH transfers emit a log * [EIP-7732](./eip-7732.md): Enshrined Proposer-Builder Separation * [EIP-7778](./eip-7778.md): Block Gas Accounting without Refunds * [EIP-7843](./eip-7843.md): SLOTNUM opcode * [EIP-7928](./eip-7928.md): Block-Level Access Lists * [EIP-7954](./eip-7954.md): Increase Maximum Contract Size * [EIP-7976](./eip-7976.md): Increase Calldata Floor Cost * [EIP-7981](./eip-7981.md): Increase Access List Cost * [EIP-8024](./eip-8024.md): Backward compatible SWAPN, DUPN, EXCHANGE * [EIP-8037](./eip-8037.md): State Creation Gas Cost Increase

Ben Adams:Replying to "https://github.com/e..." 8037 isn't in devnet yet?

Potuz:Replying to "https://github.com/e..." wdym? I thought this was included in every devnet after BAL5 with all the latest changes.

Toni Wahrstätter:https://forkcast.org/priority

Ben Adams:Replying to "https://github.com/e..." D'oh; was thinking of the other one

Marius Van Der Wijden (M):Replying to "https://github.com/e..." 8038

felix (eest):Replying to "https://github.com..." classic off-by-one

Ansgar Dietrichs:Replying to "https://forkcast.org..." I would consider this more as pathfinding towards introducing a prioritization list. so for Hegota we would start relying on it more (but as nixo is saying, only as a default ordering, not binding)

Toni Wahrstätter:Replying to "https://forkcast.org..." but who decides prios then if not ACD?

marc | wolovim:Just deployed a forkcast change to make the client prios, STEEL complexity assessment, devnet status easier to find. Not meant to be prescriptive, just helpful data. Feedback welcome: https://forkcast.org/upgrade/glamsterdam/candidates

Pooja Ranjan:https://github.com/ethereum/EIPs/pull/11006/changes/3fd84bb5a82b5f41d79cb4b3f5cde592bee609bf

Stefan Starflinger:Replying to "https://github.com/e..." single character change :D

jochem-brouwer:Ok this removes my confusion as well thanks Marius

Kamil Salakhiev:https://github.com/ethereum/EIPs/pull/11444

Potuz:I'd love it if EL devs could take a look at this, regarding those "reorgs back", I believe there's a lot of confusion on this topic: https://www.potuz.net/posts/gloas-honest-reorgs/

Łukasz Rozmej:We are working to support arbitraly long reorgs with targeting finalization block

Mikhail Kalinin:Do you want this number to be in the spec?

Karim T. (matkt):It will be nice to have some tests to verify the client behavior with different reorg

Francesco:Imho if the number is as low as 128, we need to completely rethink what we are doing with consensus, because there’s no point in trying to worry about all kinds of crazy edge cases of days without finality if then at the end of day it’s not possible to reorg past 128

Karim T. (matkt):We have a PR in Besu

Potuz:@nixo my stupid client on Arch doesn't let me raise my hand, would like to comment on this topic briefly

Mario Vega:Replying to "https://forkcast.org..." we’ve been doing ACD-T proposals for devnet inclusions: testing teams (devops+steel) suggest EIPs then core devs should raise if they disagree either because a proposed EIP is not important, or a more important EIP is missing, we put EIPs in the agenda prior so everyone has time to digest and raise opinions

Mikhail Kalinin:It can be a Hive test, right?

Parithosh Jayanthi:Replying to "It can be a Hive tes..." Hive chain isn’t that deep unfortunately

Felix (Geth):Yes would be good as hive test!

Mikhail Kalinin:Replying to "It can be a Hive tes..." Oh, that’s an interesting limitation

Potuz:ahh it was full screen

spencer:Replying to "https://forkcast.o..." Once we have a CFI list I'd love to have a flexible devnet-N plan (timeline). STEEL<>pandas should propose this during ACDT, and I feel it should be correlated to EIP complexity. The lesson this fork is that more complex EIPs should be in a devnet earlier

Tomás Arjovsky | Lambda | Ethrex:Should we modify the “safe” in the api to be “justified” per-protocol? I think everyone is doing it, but there’s nothing on EL side that guarantees it. All we have on our side is finalization.

Karim T. (matkt):Replying to "It can be a Hive tes..." I think we need also p2p part because we can receive a new block in a new chain but we don’t have all the blocks of this new chain . So we need a backward sync

Tomás Arjovsky | Lambda | Ethrex:“user” here you mean the node operator, right?

Csaba:The goal of Jacek was different here. It is about sync.

Potuz:Replying to "“user” here you mean..." yes

Toni Wahrstätter:This is the PR: https://github.com/ethereum/EIPs/pull/11601

Tomás Arjovsky | Lambda | Ethrex:Yes, plus if everyone starts snap sync that is an issue as the amount of providers left be small plus the network would be heavily overloaded, whereas deep-reorgs should be mostly self-supported, right?

Toni Wahrstätter:Right now it uses WSP (~15-16 days) but I'm happy changing it to the 38 days (restoring finality with 70% of the network offline).

Potuz:We should agree that returning before finalized **requires** social intervention anyway

Marius Van Der Wijden (M):Also what if we finalize something weird

Karim T. (matkt):We have a pruning mechanism in Besu and we not remove trielog before finalization

Tomás Arjovsky | Lambda | Ethrex:IMO if you have to revert to pre-finalization you might as well resync, that is a stop-everything situation

Dustin:Replying to "Also what if we fi..." social recovery or etc

Dustin:Replying to "Also what if we fi..." the technical mechanism has broken

Potuz:exactly, we need to agree socially in that case anyway

Marius Van Der Wijden (M):Replying to "Also what if we fina..." Yes, but for that we need the state anyway

Francesco:Imo if we don’t want to support reorgs past X blocks, then we should explicitly have soft-finality past X blocks, where the CL also refuses to reorg that deep and we accept that we could lose liveness/require manual intervention if such a situation ever happened. The in between state where some clients do support deep reorgs and some do not is not helpful, we are probably not going to be robust to such situations in practice if it’s not something we test for, but we still pay the cost of trying (in the consensus design, and in client work)

Marius Van Der Wijden (M):Replying to "Also what if we fina..." The 90k was chosen because it allows for social recovery

Potuz:Replying to "Imo if we don’t want..." forbidding such reorgs in the CL may be quite complicated

Potuz:Replying to "Imo if we don’t want..." can look into it, but it sounds like hacking forkchoice to start from below the justified checkpoint perhaps

Mikhail Kalinin:I think we will leave Engine API as is with that abstract ‘Too deep reorg’ error where the limitation is supposed to be implementation specific. And figure out the ability of EL clients to reorg separately

Marius Van Der Wijden (M):Replying to "I think we will leav..." But thats for reorgs in the canonical chain

Marius Van Der Wijden (M):Replying to "I think we will leav..." Not for normal reorgs

Felix (Geth):Geth reorg is also pretty slow. We should really optimize it more

Francesco:Replying to "Imo if we don’t want..." Yeah I meant something like this, not so much forbidding a reorg but more marking a block as always canonical like we do for justified (tbd exactly)

Karim T. (matkt):Replying to "I think we will leav..." For the moment we return SYNCING in besu in this case

Potuz:Replying to "Geth reorg is also p..." what is slow? I would have expected that executing the payload is slow, so on newPayload and not on FCU

Mikhail Kalinin:Replying to "I think we will leav..." It’s for all types of reorgs

Potuz:Replying to "Geth reorg is also p..." well, perhaps on newPAyload you don't execute in this case

jochem-brouwer:I would like to assist on the testing part of this, so we can also optimize/test reorgs and also make this somewhat part of benchmarks to get an idea of the performance of nodes in this network attack situation

Potuz:Replying to "Geth reorg is also p..." but I think the execution is the slow part right?

sina:Replying to "Geth reorg is also p..." Applying all the state diffs in reverse

Marius Van Der Wijden (M):Replying to "Geth reorg is also p..." We apply the reverse diffs on the db directly

Marius Van Der Wijden (M):Replying to "Geth reorg is also p..." Lol as sina said

Potuz:Replying to "Geth reorg is also p..." yeah but if this is slow then you don't reorg

Potuz:Replying to "Geth reorg is also p..." cause you trigger the node to be optimistic

Marius Van Der Wijden (M):Replying to "Geth reorg is also p..." Its like 6 hours slow

Tomás Arjovsky | Lambda | Ethrex:Can we better clarify what “this” as in “this is doable” is? Are we talking about deep-reorgs in general or reorgs deeper than finality?

Karim T. (matkt):Without any tests difficult to say . We should see the result of client before we decide

sina:Replying to "Geth reorg is also p..." We should return syncing in this case. Currently we block until reorg is finished

Mario Vega:Replying to "I would like to assi..." what framework do you have in mind to write this test?

Potuz:Replying to "Geth reorg is also p..." thanks yeah that confirms the above

Potuz:Replying to "Geth reorg is also p..." then nodes that can't just become optimistic

Potuz:Replying to "Geth reorg is also p..." for a whil;e

Potuz:Replying to "Geth reorg is also p..." but it doesn't kill the chain

Mario Vega:Replying to "I would like to assi..." We can give it a try and I can assist whether is eels or hive

Parithosh Jayanthi:At that point wouldn’t most people just resync their node?

Mikhail Kalinin:So on the fcU SYNCING is returned and node becomes optimistic in this case

Karim T. (matkt):FCU there is timeout for RPC calls ? Return syncing and do reorg in background seems to be better

Tomás Arjovsky | Lambda | Ethrex:For NewPayload we just return “accepted” if we don’t execute it, e.g. would require deep reorg

Tomás Arjovsky | Lambda | Ethrex:syncing would be “oh I’m actually doing work to get there"

Potuz:Replying to "So on the fcU SYNCIN..." yeah this seems to me the sanest option here

Potuz:Replying to "So on the fcU SYNCIN..." instead of not returning anything

Mikhail Kalinin:And if you get ACCEPTED and then reorg to it, and get SYNCING in the fcU response then you become optimistic right?

Potuz:Replying to "So on the fcU SYNCIN..." because at least this lets the chain stall until execution finishes

jochem-brouwer:Antwoord verzenden naar "I would like to as..." I feel hive as this is a test, if we do eels only we assume that we have local rollback, and we want the network to be available to see what the network does. In case all clients except one rollback to sync we want to see the impact of this (esp. on the network)

jochem-brouwer:Antwoord verzenden naar "I would like to as..." (then the one node which does the local rollback is essentially the snap sync seeder)

Marius Van Der Wijden (M):Or we fork the deposit contract

Potuz:only builder deposits are a problem right?

Barnabas:Replying to "only builder deposit..." no, all deposits

jochem-brouwer:Antwoord verzenden naar "I would like to as..." For EELS this is also doable for the local rollback but the fixture file will be funny to fill if we want to do 113056 blocks rollback (flashbacks to 8192 blocks for blockhash contract lol)

Barnabas:top up / new validator anything

Mikhail Kalinin:I am in the support of this EIP as it removes the dependency between MAX_DEPOSIT_REQUESTS_PER_PAYLOAD on the CL side and gas limit on the EL side

Potuz:Replying to "only builder deposit..." all deposits are not a big issue for us cause we don't verify the sig immediately

Parithosh Jayanthi:Replying to "only builder deposit..." Even 1 ETH top ups can cause issues

Toni Wahrstätter:That's how it looks in EELS (tldr super simple) https://github.com/ethereum/execution-specs/pull/2818 Block builder is more problematic

Potuz:Replying to "only builder deposit..." only the SSZ issue is the problem

Potuz:Replying to "only builder deposit..." but builder deposits are actually a problem

jochem-brouwer:Antwoord verzenden naar "I would like to as..." And this should also use blockchain-engine-x format I think as this is not a "normal" blockchain test

Barnabas:Replying to "only builder deposit..." thats another problem

Potuz:Replying to "only builder deposit..." yeah the SSZ limit we can simply just limit the number of deposits. But the DOS on builder deposits I think it's a real danger

Justin Traglia:We could look into a queue in the CL

Mikhail Kalinin:And have CL execution requests to keep arbitrary number of deposits up to a gas limit?

Justin Traglia:Replying to "We could look into a..." And we would raise/remove the SSZ limit.

jochem-brouwer:Antwoord verzenden naar "I would like to as..." (ill doc this chat and move it to discord for async discussion)

Potuz:@Felix (Geth) I do not think raising the limit on the CL side is an issue for normal deposits, the problem is builder deposits as far as I can see, we should lower that limit in fact

Justin Traglia:Replying to "And have CL executio..." Yes, that’s right.

Felix (Geth):Damn that's so annoying, changing building rule

Justin Traglia:Replying to "And have CL executio..." I don’t love the idea of having another queue, but it’s sounding like the best solution to me right now.

Barnabas:Replying to "@Felix (Geth) I do n..." yeah I’d reduce the max from 8192 to 512

Potuz:Replying to "@Felix (Geth) I do n..." probably less :) need to bench this for builder deposits

Barnabas:Replying to "@Felix (Geth) I do n..." we have had slots with over 600 deposits alraedy

Barnabas:slots with >251 deposits Slot Deposits 13509034 335 13210333 692 13210332 400 12357246 328 12258228 648 12151075 383 12151074 400 12148580 470

Marius Van Der Wijden (M):Lets switch out the contract

Justin Traglia:Replying to "And have CL executio..." But yeah, simpler the better. Idk. Limiting to 512 on both layers would indeed be the simple fix.

Paweł Bylica:Deposits go into a queue in CL anyway, right?

Mikhail Kalinin:8,192 deposits per block is 1.5MB of data

Barnabas:Replying to "Deposits go into a q..." there is no queue

Mikhail Kalinin:Replying to "Deposits go into a q..." There is no queue for builder deposits. We might want to have one

Parithosh Jayanthi:This should be easy to test no? Just fill up a block with 200M gas + 512 builder deposits to stress the machine

terence:can we spam devnet3 with lots of builder deposits per block?

Barnabas:Replying to "This should be easy ..." its more than the current ssz limit

terence:Replying to "can we spam devnet3 ..." I can profile the impact

Marius Van Der Wijden (M):Replying to "can we spam devnet3 ..." No, don't break the network, create a new nft

Barnabas:Replying to "can we spam devnet3 ..." if we do 8193 deposits or more we gonna break

terence:Replying to "can we spam devnet3 ..." I mean even 512

Barnabas:Replying to "can we spam devnet3 ..." every CL breaks

terence:Replying to "can we spam devnet3 ..." (That seems like the concern)

Barnabas:Replying to "can we spam devnet3 ..." @terence we are able to handle about 1500 deposits with gloas

terence:Replying to "can we spam devnet3 ..." Builder deposits?

Barnabas:Replying to "can we spam devnet3 ..." around 2000 its really struggling (at least on my local kt)

Barnabas:Replying to "can we spam devnet3 ..." I’ve tested top up deposits, but don’t see how it would be diff than builder deposits

Barnabas:Replying to "can we spam devnet3 ..." can also try 500/1000/2000 builder deposits

Potuz:Replying to "can we spam devnet3 ..." I think we aren't even batching signature verification in this case

Francesco:+1, don’t think we should throw away that property (cheaply check includability) so easily

Tomás Arjovsky | Lambda | Ethrex:If we want to limit the amount of deposits should we not do this in the contract itself?

Paweł Bylica:This is basically soft-fork situation proposed for the DAO fixup.

pk910:Replying to "can we spam devnet3 ..." getting to that point of exceedign the deposit limit already costs 8192 ETH.. driving a gas waste attack on this sounds extremely expensive

terence:Replying to "can we spam devnet3 ..." Ya but it seems to me builder deposits are more stressing than normal deposits so we should just test it like 512 and see what happens

Ansgar Dietrichs:but size can be verified statically

Barnabas:I think proposing a change to the deposit contract would have huge implications

Toni Wahrstätter:We have it with blobs too but there it's nicely statical

Potuz:Replying to "@Felix (Geth) I do n..." not builder deposits

terence:Replying to "can we spam devnet3 ..." I don’t care about normal deposits. Only builder deposits

Justin Traglia:Replying to "I think proposing a ..." Definitely. I would be very against deploying a new deposit contract.

Francesco:Replying to "but size can be veri..." And validity rules actually force you to not even have the chance to go over the limit, you can’t include a tx that could over the gas limit even if it doesn’t actually do it in practice

Paweł Bylica:192.9 🥲

Marius Van Der Wijden (M):Yes

Ansgar Dietrichs:seems like this is complex enough to delay the decision to next call? or do we want to PFI the EIP as a stand-in for whatever mechanism we end up choosing?

Parithosh Jayanthi:I’d also be against a new deposit contract tbh. The second order effects for the ecosystem will be non-trivial and its not easy writing a contract that will be responsible for ~30%+ of all eth. At least not one we can write in a month.

Potuz:yeah I believe the UX of changing the deposit contract is just too complex

Potuz:money could be lost

Potuz:and therefore will be lost

Parithosh Jayanthi:Someone somewhere will make a mistake, money will be lost if we change it

jochem-brouwer:Is there a limit for execution requests eip 7685 which could handle this on el side also, or is there no limit? (deposits are in exec rqs)

Peter Miller:Could we make logs emitted by the deposit contract extra expensive? Add a special gas charge to `LOG` opcodes, but only in the deposit contract.

Marius Van Der Wijden (M):Replying to "Is there a limit for..." No

Marius Van Der Wijden (M):Replying to "Is there a limit for..." Also this would run into the same issue as metering it in the el

Ansgar Dietrichs:one note on block building DOS: the issue is less bad now that we have the per-tx limit than it used to be. at least it is no longer free to do so, at worst an attacker can force the creation of under full blocks (and here at the cost of locking up ETH). pre the per-tx gas limit one could create txs that were not includable under such a cap

Ansgar Dietrichs:Replying to "one note on block bu..." so I actually wouldn’t mind a simple cap so much here, at least for now

Ansgar Dietrichs:Replying to "Could we make logs e..." that would make depositing ETH quite expensive, seems not ideal

Potuz:I want to propose formally essentially what Felix said about the problem of deposits. A two part fix: - Modify `apply_parent_payload...` to assert that there are no more than x deposits. So no block that builds on full is valid. - Modify `on_execution_payload` to not insert into forkchoice on these payloads.

Potuz:This seems trivial to do on the CL and has no implications on the EL

Potuz:nor on UX

Potuz:and we just lower the limit, or can even have independent builder and normal validator limits

Toni Wahrstätter:Replying to "Could we make logs e..." yeah, we should. And we should charge deposits 192 * 64 gas in addition. (charging 64 gas per byte) - deposit requests add 192b to the block.

Tomás Arjovsky | Lambda | Ethrex:I agree that changing the deposit contract might not be feasible. Not clear on the alternative though. Is it mempool guards?

Paweł Bylica:https://eips.ethereum.org/EIPS/eip-8246

Paweł Bylica:https://ethereum-magicians.org/t/can-we-completely-remove-selfdestruct/28464

Toni Wahrstätter:Replying to "Could we make logs e..." doesn't solve the problem though

Ben Adams:Replying to "This seems trivial t..." Unless round robin to keep building those blocks by the EL since the txs are available to add?

Toni Wahrstätter:Replying to "Could we make logs e..." The max of 8192 is just way too much for CLs

Potuz:Replying to "This seems trivial t..." we count on builders to be smart

Potuz:Replying to "This seems trivial t..." they won't like their blocks to be missed

Ben Adams:Replying to "This seems trivial t..." Fair

Mikhail Kalinin:Replying to "This seems trivial t..." And then only local block building could become a problem but we don’t expect that many deposits in the mempool?

terence:Replying to "can we spam devnet3 ..." I’ve tested top up deposits, Ah, keep in mind for top up deposits, CL doesn’t even need to verify the signature

jochem-brouwer:Account creation will be more expensive due to eip-8037 so this pattern to create temp contracts is now more expensive (in terms of gas units)

Ben Adams:Replying to "This seems trivial t..." Can change local block building; just keeps it out of validation path

Barnabas:btw is anyone against removing self destruct, feels like everyone is on board lol

Ben Adams:Replying to "This seems trivial t..." As long as someone is building the right blocks

Luis Pinto | Besu:Is this for Glamsterdam? Should we give a bigger notice to users and do in Hegota?

jochem-brouwer:I love it, cleanup after usage

Barnabas:Replying to "Is this for Glamster..." pretty sure self destruct was already in ‘deprecated’ state

Barnabas:Replying to "Is this for Glamster..." so it should be fine to remove now

Mikhail Kalinin:Replying to "This seems trivial t..." Cl already limits it to 8,192. Do we want to reduce it?

Barnabas:Replying to "Is this for Glamster..." we been saying that its gonna be removed soon

jochem-brouwer:Antwoord verzenden naar "I love it, cleanup..." (lets remove it though, esp. burn part. we should keep the SENDALL)

Luis Pinto | Besu:Replying to "Is this for Glamster..." Yet they still use it 😄

Marius Van Der Wijden (M):Probably mev stuff, right?

Marius Van Der Wijden (M):Need to get the gas token guy back on acd

Barnabas:Maybe stupid question but why not just make selfdestruct crazy expensive, no refunds at all so we would discourage future use, then yeet it in hegota?

Luis Pinto | Besu:Replying to "Maybe stupid questio..." I don’t dislike this

Barnabas:Replying to "Maybe stupid questio..." This could help filter out actual use cases

Barnabas:Replying to "Maybe stupid questio..." double negative is a positive right?

Luis Pinto | Besu:That could act as a formal deprecation notice

Ansgar Dietrichs:A complete selfdestruct removal in Glamsterdam seems way too short notice, considering the backwards compatibility concerns

jochem-brouwer:Antwoord verzenden naar "Maybe stupid quest..." Want to add one feature of SELFDESTRUCT which we cannot do now: SELFDESTRUCT allows to send eth without invoking the code of the target account. If we want to yeet it then we should have an alternative for this, e.g. PAY EIP-5920

jochem-brouwer:I think we can do the burn removal yes

Potuz:Replying to "This seems trivial t..." we cannot handle these many deposits

Potuz:Replying to "This seems trivial t..." we need to bench, but I'd be very surprised if we can handle this many deposits for builders

Mikhail Kalinin:Replying to "This seems trivial t..." That’s a different story, we could queue them — that’s the alternative that can be discussed. But we cannot handle above 8,192 at all

Potuz:Replying to "This seems trivial t..." yes, I don't like the queue mechanism

Paweł Bylica:I can collect all BLOCKHASH usage, just give me the block range :)

kevaundray wedderburn:Without block hash you need all of the block headers

Peter Miller:Do you want me to send you a list of "things we would remove if no one was using them"?

terence:Replying to "This seems trivial t..." Batch verify helps a lot but the issue is easy to grief. If one of them fail then you have to fall back whether its linear fall back or divide and conquer. Code complexity is not great

Peter Miller:Replying to "I can collect all BL..." I think CALLCODE would probably be top of that list

Tomás Arjovsky | Lambda | Ethrex:I don’t think this is a DA problem, it’s to support MPT proofs for blockhash?

Peter Miller:Replying to "I can collect all BL..." Probably not used in the last decade, if ever

Ansgar Dietrichs:Reasonable to make it more principled, but the tradeoff would be that if we wait, we might have same-block or even multi-block slot warming / caching, so this would then be a much less disruptive change for blockhash users

ignacio:link of my slides https://docs.google.com/presentation/d/1raEGijf92cUBeCGeTzQusItvIVUAjRcLzzlXtgL9jcU/edit?usp=sharing

ignacio:Replying to "I can collect all BL..." Thanks Pawel. I've something already prepared to do this analysis but would be cool to also double check with you if you also have something that we can compare. Can ping you whenever I've something to compare to.

jochem-brouwer:https://github.com/ethereum/EIPs/pull/11605

Paweł Bylica:Replying to "I can collect all BLOCKHASH usage, just give me the block range :)" No problem. However, I'm running this with 100+blocks/s

Łukasz Rozmej:so irregular state transition?

raxhvl:I dont think we should modify state by side stepping the EVM

lightclient:https://hackmd.io/@matt/aa-goals

jochem-brouwer:Antwoord verzenden naar "so irregular state..." yes

jochem-brouwer:Antwoord verzenden naar "I dont think we sh..." I know this is controversial, but we now have these old accounts in state which needs handling. Lets move discusison here https://discord.com/channels/595666850260713488/688075293562503241/1501968541212082296

jochem-brouwer:Antwoord verzenden naar "so irregular state..." discussion here https://discord.com/channels/595666850260713488/688075293562503241/1501968541212082296

Mercy Boma Naps-Nkari:https://github.com/ethereum/execution-apis/pull/788

Summary

14 highlights · 6 decisions · 5 action itemsExperimental

fork status and schedule

Glamsterdam devnets 0-3 launched; glamsterdam-devnet-2 added EIP-806100:03:24
EIP-8080 (CL side) discussed for potential DFI at next ACDC00:05:33

testing progress

bal-devnet-6 stable with Lighthouse/Lodestar; glamsterdam-devnet-3 running00:07:09
bal-devnet-7 planned for next week with 8037 fixes00:07:47
Optimization merges needed to bal-devnet-3 until bal-devnet-7 stable00:10:36

eip proposals

SFI definition finalized; 10 EIPs proposed for SFI status00:12:42
EIP-8070 (sparse block posts) Engine API changes merged00:18:16
Min reorg depth discussion: targeting 38 days and asking clients to review/comment00:19:50
EIP-8254 PFI'd as a potential path to the 200M gas floor00:43:28
EIP-8246 (remove selfdestruct burn) has support; full removal needs more time01:00:47
EIP-7709 proposed for Hegota to make BLOCKHASH read from EIP-2935 storage01:12:59
EIP-8253 proposed for Hegota to clean up the remaining pre-Spurious-Dragon accounts01:21:19

technical discussions

Debug endpoint needed for state vs regular gas breakdown00:09:03
Deposit limit creates block building complexity; 512 max discussed00:46:30

Decisions

EIP-7708, EIP-7778, EIP-7843, EIP-7954, EIP-7976, EIP-7981, EIP-8024, EIP-8037 moved to SFI for Glamsterdam00:13:24
Target 200M gas floor for Glamsterdam (pending deposit limit fix)00:54:32
EIP-8254 moved to Proposed for Glamsterdam; open questions remain00:56:15
EIP-8246 moved to CFI for Glamsterdam; full SELFDESTRUCT removal can't fit Glamsterdam01:11:59
EIP-7709 moved to Proposed for Hegota01:12:59
EIP-8253 moved to Proposed for Hegota01:21:19

Action Items

Stefan Starflinger: Create debug gas endpoint spec in EL channel00:09:59
Toni Wahrstätter: Update the reorg-depth EIP around a 38-day target and gather client feedback00:31:23
Jochem Brouwer and Mario Vega: Create Hive tests for deep reorg scenarios00:35:04
Barnabas: PFI EIP-8254 to Glamsterdam meta (deposit limit discussion ongoing)00:55:18
Paweł Bylica: CFI EIP-8246 (remove selfdestruct burn) to Glamsterdam01:11:59

Targets

bal-devnet-7 launch - next week00:07:57