AllCoreDevs - Execution #219

|2025-08-28| Agenda: #1687| canonical JSON

Transcript

Tim Beiko:Okay. Are we good, Akash?

Akash | ECH:Yeah, we are live.

Tim Beiko:Okay, awesome, thanks. Welcome, everyone, to ACDE number 219. I have a bunch of things on the agenda, as always today.

Tim Beiko:We'll chat about Fusaka, how the nuts are going, especially the non-finality testing we've done this week.

Tim Beiko:Then, there's some configuration PRs, for, yeah, that the PentOps wanted to review, and we can chat about what the next steps should be from here.

Tim Beiko:After that, I wanted to check in on, Holeshky, so we discussed shutting down the testnet.

Tim Beiko:at the end of September, so I want to make sure that this still works for everyone. We can chat a bit, about some EL gas limit bottlenecks, continuing the conversation for Monday, and then discuss

Tim Beiko:some, updates around Glamsterdams and how we should approach, EIP discussions for the fork.

Tim Beiko:But to kick us off this PandaOps, I want to give an update on, the current DevNets, where we're at, and how the testing has been going this week.

Barnabas:Sure.

Barnabas:Dentistry has been going through a non-frenalty period for a little bit longer than we anticipated. We wanted to do approximately 2 days first, and now we're hitting day 5.

Barnabas:We've been trying to recover the chain, and we have encountered a bunch of syncing issues that a different client had. There are lots of fixes coming in, and we've been rolling those out as they come.

Barnabas:We are approximately at 50% to 55% participation now. I have triggered a few exits from Nimbusia to try to gain back the final tea. Those are being processed slowly.

Barnabas:Nimbustia have been struggling to keep up with the non-frenalty period, and there has been quite some memory issues there. That's why, we decided to…

Barnabas:Kick some, ventilators off.

Barnabas:Regarding notes that are,

Barnabas:struggling to sync up. Lighthouse, seemed to be stuck syncing, made many different ELs, Lodestar seems to be stuck syncing as well. Brandon seems to have an issue, and a few technical nodes as well.

Barnabas:Most of the Prism nodes are, pine, and,

Barnabas:Most of the technicals are also fine, but a few of them seem to have some,

Barnabas:No more issues.

Barnabas:Regarding the EA, there also seems to be a few bugs reported by Eragon and Bezu.

Barnabas:That they are investigating.

Tim Beiko:Thank you.

Tim Beiko:Any of the client teams want to chime in or share more context?

Barnabas:there would be another update, so we did a non-finity test on NFT demo.9, which was basically, pre-FULU, with using all the latest, stable releases from each EL and CL, and we tried to replicate the same,

Barnabas:non-funately, we were offline for, I think, a day and a half, and we brought the notes back online, and the chain has recovered within,

Barnabas:I think 2 hours.

Tim Beiko:Nice.

Tim Beiko:Yeah, any client teams, or anyone else have…

Tim Beiko:context I want to share on the cognuts?

Barnabas:One of the main differences that could be,

Barnabas:I just want to make sure that this is set up. I used the… on the…

Barnabas:Photoko.net 3, the initial way, how we try to recover the chain is just,

Barnabas:removing the EL database and resync using the CL database, without checkpoint syncing, and hoping that all the CR clients would just reorg, back to the

Barnabas:Back to the inbound block.

Barnabas:And on NFT.NET9, we have actually wiped the database of the EL and the CL, and the recovery was very fast there.

Barnabas:And on NFT DevNet9, we seem to have, about 80% participation.

Barnabas:Yeah, I think we also had 80% participation before, and there seemed to be a few Ergon nodes,

Barnabas:I'll find her.

Parithosh Jayanthi:Yeah, the main reason we made the change for NFT DevNet 9 was that there was none left on the network to provide the invalid state, because we did the resync in kind of all at once. So there was just no one… no peers to get the invalid chain to then claim it was invalid.

Tim Beiko:Got it.

Tim Beiko:So in terms of next steps for the DevNets, obviously we want to fix, the issues that we found, and the CL teams are working on that.

Tim Beiko:Do we… do we think we want to have another DevNet after this?

Tim Beiko:I assume we at least want to get this, non-finalized DevNet back to finalizing, but yes.

Tim Beiko:After that, would we… would we move forward and, launch… launch DevNet 5? Do we want to do that in parallel? .

Barnabas:So, ideally, DevNet3 should recover to close to 100%, and then we would want to do another non-finity test, and see if we can actually recover within a reasonable period of time.

Barnabas:Just to make sure that we have actually ironed out all the bugs.

Barnabas:Launching DevNet 5 with known syncing issues,

Barnabas:Probably not worth it.

Tim Beiko:Yeah, that makes sense.

Tim Beiko:And do we think, most thinking issues should be, like, at least have tentative fixes this week?

Tim Beiko:Is that something we think we can, like, yeah, get live on the DevNets today or tomorrow and see it progress over the weekend, or do teams feel like they're going to need more time to address those?

Manu:I can speak for PRISAM, it should be okay for this week.

Tim Beiko:Okay, Lighthouse is saying goodbye mid-next week. Any other teams?

Parithosh Jayanthi:Maybe one thing also worth mentioning is, now that we have our… we have, like, a malicious getth image, as well as another manned image, that we can trigger this fork very easily, and cause non-finality and everything on DevNet 3.

Parithosh Jayanthi:We should be able to reproduce this as often as clients want, so if we have one client with a fix, we can already deploy it and already try out their fix, and we don't have to wait for all clients to be ready before we do.

Parithosh Jayanthi:Before we do another test. And same thing goes for, DevNet 5. We've sped up, we've sped up our Ansible stack significantly, so it should reduce the amount of time we take to spin up, like, larger networks now.

Tim Beiko:Awesome, thanks.

Tim Beiko:And yeah, so Lifehouse is saying they should probably have a fix by mid-next week. I'm curious how the other CL teams are looking, like,

Tim Beiko:So I guess this would mean we probably…

Tim Beiko:don't launch DevNet 5 until, like, at least a week from now, once we've had time to actually deploy these fixes and potentially see the network recover.

Tim Beiko:Is that relatively the timeline that

Tim Beiko:themes think makes sense, and also, can we handle the DevNet 3 being non-finalized for another week? And will that…

Tim Beiko:Compound problems somewhere or another.

Tim Beiko:Okay, so Taeku… Okay, so it seems like Tegu, Lodestar as well,

Tim Beiko:are gonna have fixes for next week, so, like, realistically, we're not gonna have all the CL fixes to get DevNet 3 finalizing by this week.

Tim Beiko:Yeah, the only concern I could see is if things get significantly worse on the DevNet, because it's not finalizing, for what will be, yeah, probably, like, 10 days by the time we have the fix,

Tim Beiko:then we may want to think about other ways of testing these… these fixes, or, like, yeah, whether or not it's worth, recovering DevNet 3 if it's… if it's, if it's fully degraded.

Tim Beiko:But we can discuss this further, I think, on the testing call Monday and, on Thursday, if,

Tim Beiko:Yeah, if we need. Barbara, let's say we can finalize the 3 today, how would that work? Would you just make all the, or, like, two-thirds of the steak PRISM?

Barnabas:So maybe, like, we have a bunch of nodes that are syncing, but the sync times are just so long, especially during non-finance period. Forward syncing takes a bunch of time. So, we can see that some nodes are still making progress, and the participation is growing.

Barnabas:So, hopefully by the end of today, we're gonna have a lot more nodes that are synced ahead, and we're gonna be able to reach 66%.

Barnabas:And I think that we could possibly get back to 100% participation by

Barnabas:End of day tomorrow, hopefully, or very close to 100%, with just, checkpoint syncing and, removing the databases and forcing them that way.

Barnabas:And ideally, yes, the thinking,

Barnabas:the thinking fixes should be tested again, and if everybody says that they can be done by next week, by mid-next week, then maybe we can trigger another non-finality, next week, and in the end of, next week, we can then, schedule DevNet 5, if everything goes smoothly on DevNet 3.

Tim Beiko:Yeah, that sounds like a plan.

Tim Beiko:Alex has a question asking, do we have any theories on why sync is slow?

stokes:Yeah, this might be a bit of a parallel thread to the present topic, but I am curious.

Tim Beiko:Okay, guess not. We can maybe discuss this when we, have had more time to look into it on Monday or next Thursday.

Tim Beiko:Anything else on the non-finality testing?

Tim Beiko:Otherwise, Barnabas, you had the four PRs that you flagged,

Tim Beiko:Yeah, to, to update the blob schedules on, a bunch of, the testnets. Yeah, do you want to give…

Tim Beiko:Reach out to those?

Barnabas:So, that, mainly Nethermind, is the one that have a big change in how the blob scheduling is handled.

Barnabas:And ideally, we want to merge all these in by end of day tomorrow, and this is required for us to be able to do shallow forks on OSCI, Sepolion, Mainnut, and UDI.

Tim Beiko:Anyone from Nethermine had a chance to look?

Tim Beiko:Can potentially give a quick… 1 or minus one?

Barnabas:Nevermind already approved it, but I would just like to have a few more approvals from different EL teams, because I know that some clients might rely on these files.

Barnabas:So I just want to make sure that they are aware of this change.

Tim Beiko:Okay, so yeah, people can have a look, and I think if in 24 hours you haven't heard any complaints, we can go ahead and merge them.

Barnabas:Sounds good.

Tim Beiko:Okay.

Tim Beiko:Bye.

Tim Beiko:Okay, next up, so Alex had posted an updated timeline for Fusaka,

Tim Beiko:obviously, you know, based on the current state of DevNets, this might be a bit delayed, but yeah, Alex, do you want to give a bit more context on that?

Tim Beiko:Curse, also…

stokes:Thursday, sometime.

Tim Beiko:type to review, yeah.

stokes:Yeah, I mean, I can walk through it,

stokes:So, essentially, just trying to track everything so that we can hit a pre-dev Connect launch date for Fusaka.

stokes:Basically, what we had discussed kind of before the past few days with the sinking issues, we would have, trunk branches together by the end of this week.

stokes:Demet 5 next week, do some analysis, use that to figure out how to set up Pulaski and Sepolia.

stokes:We'd do those forks mid-September, or we'd have releases mid-September, do the forks later in the month.

stokes:That would then set us up to do releases beginning of October for Hoodie and Mainnet.

stokes:do hoodie, do mainnet. You can look at the dates here, and yeah, I mean, the thing is,

stokes:this is all kind of on hold with the present issues with DevNet3, so yeah.

stokes:I think what we want to do is focus on DevNet 3,

stokes:If we get DevNet5 up next week, that'd be amazing, because then these dates don't change too much, and we can kind of stick to the schedule.

stokes:But, yeah, it's… Slightly premature, just given… given the current status, so…

stokes:I think we all know what we need to do to keep moving forward.

Tim Beiko:Yeah.

Tim Beiko:Thanks. Anyone else have comments on that?

Tim Beiko:this.

Manu:Yeah, so basically on Prism, we have…

Manu:Yes, almost everything in the developer branch.

Manu:Which is our untappable branch, but we continue to run the DevNet tree on the PRDAS branch, because it's quite simpler.

Manu:When you have a new bug detected, we just…

Manu:push the fix on the PureDust branch, which does not require any review, and when it works, we do a real code review when we push it in develop branch. So basically, develop branch and PureDAS branch differs only on the new bug fix seen in the DevNet. But, yes,

Manu:We have the backfield, which is not yet merged in develop.

Manu:But, so else is… Every… everything else is… is matching.

Tim Beiko:Nice fix.

Tim Beiko:Yeah, so there's a comment saying we don't have one month between the first release and the test sets, and

Tim Beiko:Yeah, so we would have… the plan is to have one month between the mainnet releases and mainnet forking, but then we would have shorter,

Tim Beiko:shorter timeframes for the testnet forks, and notably, Haleszhki would be kind of the shortest, because we also plan to deprecate it shortly after the fork.

lightclient:I mean, isn't that what we agreed, though? That we would have one month before the DevNet forks?

Tim Beiko:After a picture? You mean testnet?

lightclient:Or sorry, testnets. Yeah.

lightclient:Like, the complaint before was that we were making the Sepolia release, and then Sepolia happened, like, a week or two after, and same thing with Koleski.

lightclient:And we kind of told the…

lightclient:The application companies, that we would give them extra time.

Tim Beiko:I thought this was about maintenance?

lightclient:I mean, it meant that we always have one month.

Tim Beiko:Yeah.

lightclient:Like, the complaint last time was not about Mainnet, it was about Sepolia.

lightclient:I mean, I specifically remember Optimism being frustrated that they need to do a lot of work now, based on… they're waiting for the client releases to update their software, and then we fork the Sepoliad network one or two weeks after we make those releases.

Tim Beiko:Yeah.

Tim Beiko:And yeah, Frederick has this, linked it, and, like, yeah, this did say 30 days before the first test set.

Fredrik:Yeah, yeah, it sets in the process there that we should have

Fredrik:30 days between the first testnet and when the client's release is ready.

Tim Beiko:Okay, so I guess if we wanted to do that,

Tim Beiko:then yes, we would obviously have to modify, the schedule quite a bit.

Tim Beiko:It is something, yeah, we can do. We should probably get input from

Tim Beiko:all of these L2s specifically as well, because, they're also the main consumer of the blobs, so…

Tim Beiko:Yeah.

Tim Beiko:They may…

lightclient:It's just like, how many times can we ask them, you know? It's like, we just keep asking them until they don't respond, or they are tired of us asking. Because they kind of came, and they told us what they wanted, and we haven't even had a hard fork since they told us what they wanted.

stokes:I will point out one difference is Pectra had many things that, like, impacted them directly, and that they needed to, like, actually change, whereas Fusaka doesn't have things like this.

Barnabas:I mean, they have to… Calculate the proofs, so that is a… That's gonna fall on them.

stokes:roofs.

Barnabas:the blot proofs?

stokes:Doesn't the EO handle this when you submit the blobs?

lightclient:Do ELs handle this when people submit the blobs?

stokes:Yeah, like, if I give you a blob over RPC, then the ELs handle this stuff, right? So my point is just that

stokes:the things that we change at Fusaka are, like, fairly transparent to all the people we were just talking about, whereas with Pectra, that was not the case, so I could see how, you know, I think it makes sense for them to be like, okay, with something like Pectra, this makes sense. We need time to update, you know, our code.

stokes:Whereas, there's not that much here.

stokes:So there's less To have so much time.

lightclient:I just don't think that because we decide that there's less things for them to do, that we get to change what the agreement was before.

Tim Beiko:grab pullers…

potuz:Rollups typically base their main node on the… as a fork of Geth, or as a fork of whatever L1 client is. And this is the main reason why they required a lot of time between having a release and they themselves having a release that supports the same features of the fork.

potuz:I think this is the… one of the reasons why they requested this extra time, and this is going to be independent of what kind of features they want to ship or not.

Tim Beiko:Thanks, Oscar.

Ansgar Dietrichs:Yeah, I just wanted to say that, like, I think we have to make… be careful, though, to not make this mistake of, like.

Ansgar Dietrichs:weighing the cost imposed onto a few very visible, entities higher than, basically, the cost distributed more across, like, a larger set of people. I think there's costs both to a two-accelerated rollout, like.

Ansgar Dietrichs:we just are discussing right now, for L2s, mostly. And then there's, of course, also a cost, for example, if, say.

Ansgar Dietrichs:the outcome here would be, can we still ship the fork by the end of the year, or slip into next year? That's, like, an extra month of delay, that also delays

Ansgar Dietrichs:kind of, like, Lamsterdam and the follow-on work. I think the problem is just that the people affected there is a much more diffuse set, it's basically, like, everyone in Ethereum, but only a little bit. And it's hard to weigh, like, a few people, like, strongly affected, whereas, like, a lot of people a little bit affected, but I think it's important that we don't

Ansgar Dietrichs:Only focus on one side of that, of the picture.

lightclient:I mean, we made a very unambiguous agreement with Rollups and other participants at the time with Pectra that we were going to give them 30 days from a client release to a testnet.

lightclient:I don't understand why. This is about the third time for Fusaka we've had to come back and, like, re-agree with this.

Ansgar Dietrichs:Can you…

lightclient:And a week ago.

Ansgar Dietrichs:Maybe in the governance process where we did that? Like, the meta-EIP for that, that was on Universal.

lightclient:spreadsheet.

Ansgar Dietrichs:I think it was mostly…

Tim Beiko:Yeah, Frederick's…

lightclient:lifted it.

Tim Beiko:Doug, yeah.

Ansgar Dietrichs:Yeah, like, you talk, I understand, but… but, like, it was never, there was no…

lightclient:It's in a folder called Processes.

Ansgar Dietrichs:I understand, I understand, but what I'm saying is, like, this is a best-effort type of commitment, and, like, if there are costs, the circumstances arising, like, I don't think it's a guarantee, that's… I agree with you, like, we should try to stick to this as much as possible, but we should also try to, like, not let the Ethereum community down. Like, it's… there's a trade-off here.

lightclient:The Ethereum community wants all these systems to work, and they don't want all the applications and the Layer 2s to roll out half-baked updates. And they… L2s and apps asked for 30 days to give them the appropriate amount of time to securely upgrade their software.

Tim Beiko:I'm Zoop Podus.

potuz:I'm just stating the obvious here, but if we do have fixed 30 days for testnets, fixed 30 days at least for mainnet, and at least 30 days for DevNets, it's really not realistic to have a 6-month work cadence.

Tim Beiko:I don't think the definite thing is correct, but yes, like it… like, yes, if we have even 30 days for those two, and obviously they have to fork and go and, you know, go smoothly, that's probably 3 months you add to the process, between, like, putting out the first release and,

Tim Beiko:And, and having Mainnets go live. Death.

lightclient:This says… it does say 30 days before the first testnet, so, like, we can pipeline the testnets a bit. It doesn't have to be one month between each testnet.

Tim Beiko:Oh, yeah, yeah, for sure. And then… but then I think we also want at least a week between each of these testnets, and even that, you know, if there is an issue, a week is…

Tim Beiko:not… like, you know, it's doable to fix the issue within a week, but it's kind of a rushed timeline.

Tim Beiko:Yep.

Fredrik:I think we… we decided that it should be 14 days.

Fredrik:Apart from each upgrade.

lightclient:Alright. So, fastest possible is two and a half months? Or I guess the two 14 days add together.

Tim Beiko:Before mainland?

Fredrik:I think it's gone 37 days.

Fredrik:Don't matter if the process is followed by the book.

Parithosh Jayanthi:I think one of the differences between earlier folks is also we're requiring almost every client, if not all clients, to have all of their changes in their trunk branches before we start talking about testnet releases. I don't necessarily think this was always the case.

Parithosh Jayanthi:That's also another location where we're adding, like, a few weeks, which in the past we wouldn't have.

lightclient:Sorry, I don't know if I might follow that.

lightclient:You're saying we didn't require in… for a testnet release?

Parithosh Jayanthi:Exactly, for a test methodologies. In the past, it was very often that you'd get an RC release from a branch.

lightclient:Okay. I feel like for, at least for us, we've always… for a testnet release, we've made an actual GoEthereum release, and so at that point, the…

lightclient:New code is available for people to begin integrating with?

lightclient:I guess some other clients did that differently?

Tim Beiko:Okay, so I think… there's… I guess…

Tim Beiko:two paths forward. One is we kind of base

Tim Beiko:the, release schedule just on this process doc, and, you know, based on the previous discussion around DevNet 5, if we assume DevNet 5 goes well, we fix these finality bugs, we could set the dates for the first testnet, and kind of, you know, just schedule it out from there. I think if we want to have a shorter,

Tim Beiko:I think if we want to have a shorter schedule, then, like, yeah, maybe it's worth trying to get explicit feedback from, these L2s and other info providers again, potentially opening up a PR to Frederick's doc and trying to get,

Tim Beiko:Yeah, trying to get, like, some…

Tim Beiko:I guess, input from the community there.

Tim Beiko:realistically, we don't have to make this call today, like, we… we still have time, because we're still fixing DevNet 5, but I think over the next week, if,

Tim Beiko:If we… if we could actually get,

Tim Beiko:If we could actually get, like, some roll-ups to share their preferences, even though we've asked them in the past.

Tim Beiko:I think it's probably valuable, and they are kind of the main stakeholder, being, affected here.

Tim Beiko:Yeah.

stokes:Yeah, so I can make a version following the stock to the letter. I will also reach out to some roll-ups and try to understand if they care.

stokes:Let's see…

Tim Beiko:And I think if we can get, like.

stokes:into other parties beyond roll-ups?

potuz:Staking pools would be affected by the KCG proofs on the… on the sidecar, perhaps? I don't know.

stokes:Meh…

potuz:I don't know. Like, restaking tools, perhaps, I don't know.

stokes:Yeah, I'll reach out to some people.

Tim Beiko:Okay, yeah, I think if we do change it, we should just open a… we should, like, actually open a PR to this process doc and make it clear what the change is.

Tim Beiko:Yeah, and that's also, like, a concrete place we can send folks to, like, voice their… Preferences.

lightclient:I just think it's a really bad precedent to…

lightclient:keep letting decisions change. Like, we've talked about this in many different contexts. We even talked about this exact situation about a month ago, when we started putting out the timelines for Fusaka, because we had forgotten and then remembered about the agreement we made.

lightclient:And we said, okay, we really need to think about this, and, you know, we need to get the releases out mid-August as the only possible way to get a pre-DevConnect Lusaka. And now it seems like we just keep kind of changing what our agreement is to fit to this arbitrary deadline that we've imposed upon ourselves.

lightclient:And I just don't think that's fair for the people who are not full-time people part of this process, to have to again and again come and say what their preferences are.

Tim Beiko:I think that's true, but I also think that there is, like, a…

Tim Beiko:a big part of the community that does want Fusaka at the ship, and, you know, they don't come and

Tim Beiko:Say, like, oh, we want the fork to happen in, you know.

Tim Beiko:one week after the testnet release, or something like that. So… Yeah.

lightclient:I don't think we should choose timelines based on what the community necessarily wants. Like, the people who are shipping the software said they want 30 days to deliver high-quality software that the community is going to use. So…

lightclient:Until that… until we, like, revisit that decision with all of the people involved, there's really not that much point of arguing about it.

Tim Beiko:Yeah, okay, that makes sense, but I think we should at least…

Tim Beiko:Double-check with these, like, roll-ups and infra providers that

Tim Beiko:This is still their preference, because the same way we had forgotten about it until it came time to do the releases, it's not clear to me that they all have this expectation, and

Tim Beiko:Yeah, like, I think if this is what everyone wants, then great, we can stick with it, but we…

Tim Beiko:yeah, we should make sure that this is actually what they want, and I'm not 100% convinced that they…

Tim Beiko:they would still stand by this.

Tim Beiko:Yeah, so I don't think it's, like, a super high cost to check this in the next week or so.

Tim Beiko:And we can follow up with, like, yeah, who was involved in the original discussion.

Justin Florentine (Besu):But just to be clear, the decision is to stick to what we have already agreed upon, meaning the 30 days outlined in the document, right?

Justin Florentine (Besu):We assume that what we currently know is still true until we hear otherwise. Is that right?

Tim Beiko:Yeah, I mean, we can prep the schedule, like, we haven't chosen either way yet, but, like, yes, we should prep the schedule with what's in the document, and then in parallel, check with, like, the stakeholders that are affected.

Tim Beiko:If this is, like, still their preference, and…

Tim Beiko:If so, then we would stick there, but I think if we get other signals, we should also propose, like, some alternate schedule, and do that also by, like, changing the process doc to kind of reflect these updated preferences.

Tim Beiko:Okay, I think, yeah, we can follow this up async,

Tim Beiko:Anything else on the timelines people wanted to… Discuss.

Tim Beiko:Okay, related to this, so we did say we were gonna deprecate Poleski, after going live with this fork, and…

Tim Beiko:that would mean, you know, probably shut it down sometime, at the end of September.

Tim Beiko:We want to put an announcement up for this, but before doing so, just wanted to check in here if anyone has any reasons why they would need the testnets longer, or think that we should

Tim Beiko:yeah, somehow push that out. Otherwise, in the next week or so, we'll just put up an announcement saying that, Holeshky will just be shut down a couple weeks after, Fusaka goes live on it.

Tim Beiko:Okay, no one fighting to keep Holeshky longer. So yeah, expect a blog post in the next, week or so with, an update on that.

Tim Beiko:Anything else around Fusaka people wanted to discuss before we move on?

Tim Beiko:Okay, next up, so on Monday, we discussed, some of the gas limit work,

Tim Beiko:we were… we were, trying to see whether we could raise to $60 million before Fusaka would go live. Some of the EL clients were looking into, some performance bottlenecks, and… and trying to see what potential paths were to addressing those.

Tim Beiko:So I just wanted to check in and see if anyone had updates,

Tim Beiko:Yeah, on that work generally, in terms of just…

Tim Beiko:Yeah, potentially moving to 60 million before, before Fuseka. Or at least, yeah.

Tim Beiko:Getting somewhere there.

Luis Pinto | Besu:I can add a few words for Basu. So we were a bit hammered with,

Luis Pinto | Besu:the mods and division, and so we are looking at those, opcodes, and we have a working implementation for mods and DIF.

Luis Pinto | Besu:That we will most likely want to test in a few days.

Luis Pinto | Besu:Which is much more performant than the previous one.

Luis Pinto | Besu:So yeah, we're making progress on that.

Luis Pinto | Besu:On that front.

Tim Beiko:Awesome. Thanks for sharing.

Tim Beiko:Anyone else have updates on this?

Ben Adams:Question around signaling, because it does take a while between signaling and the gas going up.

Ben Adams:What would be the, I suppose, the process or the timeline? We…

Ben Adams:Do we wait until everything's happy and confirmed, or do we… Signal a bit sooner.

Ben Adams:Everything inside.

Tim Beiko:I think we should wait until no client has, like, major concerns, because going from 45 to 60

Tim Beiko:like, in terms of actual block updates, happens pretty quickly. I think… if we…

Tim Beiko:what helps also with the signaling and just the adoption is if it's actually included in a release. So, one thing that could be nice is if, you know, if we're confident in going to 60 before Fusaka goes live on Mainnet,

Tim Beiko:then, we could potentially just have the clients default to 60 in, say, the first testnet release, so that the first testnet release, you know, if people run that on mainnet, it defaults to 60 million gas,

Tim Beiko:So I think that's an option, but I wouldn't want to just… I don't know, if Besu is… if Besu still hasn't, tested, like, their improvements, I don't think we should, like, soft signal and kind of force Basu to catch up that way. Yeah.

Tim Beiko:Yeah, on to go?

Ansgar Dietrichs:Yeah, I think, maybe, concretely, I think it's good if our process basically, as you said, right, that, like, the threshold should be that every client has a release out that we are comfortable can handle, the kind of the new…

Ansgar Dietrichs:gas limit that we are signaling, but I think there's no need for us to wait for any specific adoption metric on that, on those new client releases, because I think…

Ansgar Dietrichs:If there ever were any hiccups, basically the important thing is that people can quickly upgrade to the version that can handle it. As Ben was saying, it will take some while for this to be rolled out anyway. In the meantime, people are upgrading, so I think, basically, like, that seems like to strike a good balance. Client releases out, but no specific threshold for adoption.

Tim Beiko:Oh yeah, yeah, exactly. And this is why I think if we can couple it to releases that more people are gonna be using anyways, then that's good. Like, at the very latest, if we say we want this before Fusaka.

Tim Beiko:all the Fusaka mainnet releases should default to 60 million, right? Like, but yeah, I think the testnet releases…

Tim Beiko:On the way there are just, like.

Tim Beiko:Yeah, also a good opportunity to put this as a default, and as long as every client team has a release that could handle this, then we're generally in a good spot.

Tim Beiko:And this, yeah, Terrence has a comment, like, this also includes CL releases, because the CL releases kind of set the values for, for boost, which is where most of the blocks get built.

Tim Beiko:Lewis has a question about Zen. Does anyone have more topics around, like, yeah, the specific bottlenecks around Zen?

Tim Beiko:And how that's blocking for $60 million.

Tim Beiko:Sorry, Ben, you were gonna say something?

Ben Adams:Yeah, just more related to the, ELs and CLs that…

Ben Adams:the ELs sort of determine whether they can handle it, but we have to wait for the CLs to

Ben Adams:Update there.

Ben Adams:defaults.

Ben Adams:I was just wondering if it'd be better to have a mechanism where the CL could query the EL, but the gas limit.

Ben Adams:They should be… Registering with us.

Tim Beiko:And to be clear, we don't… we don't need to wait, though, right? Like, operators can update themselves, it's just not the default, but… yeah. Terrence?

terence:No, I was gonna say it's possible to do that, but that's, like, an engine API change, and Engine API is typically, like,

terence:we only changed that during, like, the network upgrades, so for Fusaka, it's probably too late.

Tim Beiko:Yeah.

Tim Beiko:Yeah, we probably shouldn't be changing the engine API design this far late in the process, yeah. Felix?

Felix:Just as a quick comment, so I don't think that is technically true, that we can only change the engine API on a fork boundary, especially for this kind of thing, which would be a new feature anyways.

Felix:But also, I think it is totally possible, even now, with the existing RPC API, for the CL to query the EL and then adjust itself based on that.

Felix:Like, I don't think this is technically, like, an engine API change that requires a fork or an EIP, we can just kind of do this.

Tim Beiko:Yeah, I guess it requires, yeah, it requires the CLs changing how they pass that value through.

Tim Beiko:And yeah, Perry on the Zen comment said, that, it wasn't their focus yet, but they have a benchmarking, and they can gather data on any issues with that.

Tim Beiko:Any other updates or thoughts on the 60 million?

Tim Beiko:Okay.

Tim Beiko:Then I guess we can move on to Glamsterdam. So, first off, we had a, block access list breakout this week, the first, the first one.

Tim Beiko:Yeah, is there anything from there that people wanted to bring up or discuss?

Toni Wahrstaetter:Yeah, I can give, a quick summary.

Toni Wahrstaetter:Basically, the…

Toni Wahrstaetter:EAP7928. Breakout call is now happening every two weeks, so if you want to join, feel free to do so. Clients are quite busy at the moment in implementing the EAP.

Toni Wahrstaetter:Right now, every client team has started implementing, and I think, got the feeling that we're getting closer to a first step now.

Tim Beiko:Thanks, thanks.

Tim Beiko:Anything else on block exorcists?

Tim Beiko:Okay, then I had a couple things for just the rest of the EIPs, being proposed for Amsterdam. So first off, there's a lot of gas price or repricing EIPs that are being proposed, so, Maria and Ansgar put together a meta-EIP to try and keep track of them, but it's…

Tim Beiko:kind of a unique thing, to have, like, a nested nita EIP, so they had questions about, yeah.

Tim Beiko:how do people think we should, approach this? Anskar, yeah, you want to give some context on it?

Ansgar Dietrichs:Yeah, perfect. So basically, Maria and I, were talking with people, and in general, the need came up, or, like, the idea came up that it would be nice to have a document in general to basically collect.

Ansgar Dietrichs:And outline, kind of, all the peace and flight around repricing, because we also expect that that will still, kind of, quite actively, be a topic of iteration for the next few months, or next two months, at least, or something.

Ansgar Dietrichs:The… we were basically… we chose to do it as a meta-EIP, at least.

Ansgar Dietrichs:as of now, and then wanted to get a little bit of feedback on whether MetaEP is the right format, and whether people think that's useful. The idea specifically would be that the MetaEP does not have any specific role in the governance process, so include, like, being listed on the MetaEP would not directly correlate to

Ansgar Dietrichs:Inclusion decisions in…

Ansgar Dietrichs:glam stamp, we would, in the MetaAP, kind of basically just list the status of this is kind of where it's at in the governance process as well, just for convenience. But the MetaAP would be more like a document that then could be useful also, for example, in, like, early DevNets, and basically just, like, as some sort of specifying some sort of just, like, recommended set of EIPs.

Ansgar Dietrichs:we… after some talking with people, we think that Meta EIP might be the most useful kind of version of that kind of document, but we'd also be happy to kind of change it to just some other thing, I think.

Ansgar Dietrichs:Pari had the point that it would be nice to be version controlled, so we can just, like, target specific versions for definites or something like this, so…

Ansgar Dietrichs:Yeah, but basically just looking for feedback, and maybe one more point there, the reason why it's kind of Maria and I is that, at David and I used to kind of lead the research on this topic from the EF side, in the past. David is now moving to other topics.

Ansgar Dietrichs:And Maria is now taking over from him, so going forward, it will be kind of Maria from our side as the domain experts, and then kind of me in collaboration, so any kind of more research side topics you have around repricing, I think would be best discussed with Maria going forward.

Tim Beiko:Thanks, Eddie. Comments?

Tim Beiko:Okay.

Tim Beiko:Like, it's like, think we can give this a try?

Tim Beiko:And yeah, it is also… like, yeah, version control on the IPs is something we've…

Tim Beiko:Talked about in a bunch of contexts, and never really…

Tim Beiko:adopted, so this might actually be a good place, yeah, to justice.

Tim Beiko:Roman, are you asking about, in general, on the gas limit testing efforts, or,

Tim Beiko:Just for the CIP, like, which repricings we want to do.

Roman:Yeah, in general, but I'm asking this now, babe, because both are kind of intertwined.

Tim Beiko:Yeah, so we have this,

Tim Beiko:Yeah, so I guess we have these two Telegram channels that are, like, quite high activity, and then the Nethermine team has just been keeping, like, the high-level,

Tim Beiko:yeah, the high-level, bottlenecks, in this sparkdown that I shared.

Tim Beiko:I don't know that we have any kind of intermediate resolutions that you either have, like, the, you know, 10 bullet points skim, or the two groups with hundreds of messages.

Parithosh Jayanthi:Yeah, we do some summaries on ACDT, so I guess that might be the second best approach, but yeah, I mean, TLDR, the limits for 60 million gas are listed there.

Parithosh Jayanthi:Most of the work right now is on state bottlenecks, and we're focusing on sync-related state bottlenecks, and we have 2x mainnet state already to test with.

Tim Beiko:Okay, and yes, Maria shared. Actually, yeah, it might actually be a good idea to just share the… if we could link the Grafana dashboards. I don't know if these are actually public.

Parithosh Jayanthi:Yeah, so Docs has been a bit lacking, and we wanted to wait to finish rebasing the benchmarking tool on top of East, and I think Camille has…

Parithosh Jayanthi:basically achieved that over the last day, two days this week. So I would assume soon we would focus on documentation, we'll make sure all the links are in one place, and yeah, make it a bit easier, I guess.

Tim Beiko:Awesome, thanks.

Tim Beiko:And yeah, on the state side, Carlos, said… shared, the, BlockNet page with also… which also has a ton of, of, status updates.

Tim Beiko:Yeah, hopefully we can start to,

Tim Beiko:To align all these different resources, but, yeah.

Tim Beiko:For now, it's a bit of a mess.

Tim Beiko:Okay, so, yeah, back to repricing, so we can, keep the EIP, experiment with it, and, and, yeah, see how useful it is through the process.

Tim Beiko:The other thing, I want to discuss, so now that we have set the headliners for the fork, we should eventually review and at some point decide which EIPs to include.

Tim Beiko:we said that the deadline to propose the IPs for the fork would be when the Fusaka mainnet releases go live, which is still, you know, at least a month or a couple months away.

Tim Beiko:there's already 18 proposed EIPs, and I think there's a couple more that just haven't been merged in yet, so I can expect we'll get 20 or 30 of them.

Tim Beiko:I wanted to check in with teams about, like, how should we go about reviewing these? Not even, like, making decisions about them, but just, you know, when and how do we want to discuss or ask questions about them. Besu shared their preferences, and I think historically what we've done is kind of

Tim Beiko:have people semi-randomly show up on this call and pitch their EIPs and not be super systematic about it.

Tim Beiko:And it just gets harder as the number of EIPs scale. Like, if we have 30 EIPs and we give them each 10 minutes, that's 300 minutes of call time. So, yeah, curious how people think we can do this. Yeah, Justin?

Justin Florentine (Besu):Yeah, I just wanted to clarify real quick. I wanted to be very explicit that these are the EIPs that we listed that we would like to hear more about, so that might be a mechanic that we can leverage. You know, we're gonna get this list, like you said, it's gonna be 30 long, it might be the point where we have to schedule people and say, hey, you made it to, you know, you have this much interest from the core devs, please show up on X date and present this one, and we might

Justin Florentine (Besu):We might just have to actually, coordinate this.

Justin Florentine (Besu):I think that the important part of this is that the core devs reach out and say, hey, the following, you know, EIPs have questions that need to be answered, these are the questions, and proactively set an agenda for them to come in and discuss.

Tim Beiko:And, yeah, Tony, sorry, I didn't mean, like, a full-on presentation, but I think, like, yeah, each of them

Tim Beiko:itch that we actually want to consider probably takes some time on the call to discuss the trade-offs, and it's not clear that we… there's probably 70 IPs we don't even want to bring up on the call, because no one thinks they're, like, a serious candidate.

Tim Beiko:Yeah, so I…

Tim Beiko:I think it would be good to have some sort of, like, pre-filtering, and I think a requirement for this is, like, that teams actually have the time to look through the list, and I know that there's already a lot of things going on, and, like, we're asking people to focus on, like,

Tim Beiko:Yeah, on many things in parallel, so,

Tim Beiko:Like, if teams feel like they have the bandwidth to actually at least look through the list and, like, flag the, you know.

Tim Beiko:5-ish, or whatever most interesting ones they want to discuss, like base U. That seems pretty straightforward, like, you know, starting on the next call, we could…

Tim Beiko:we could try to have, like, yeah, more conversations about the ones Basie listed, or if there's ones other teams want to discuss, too.

Tim Beiko:But is that realistic? Like, do people think in the next week or two weeks they can even open the list of 20 IPs and figure out which 5 or 6 are most, most important?

Tim Beiko:And yes, obviously we have beat the magicians, like Greg says, so we can do this async. I think we… we should try to do as much of that as we can, but realistically.

Tim Beiko:Yeah, we do end up discussing a bunch on the call, and

Tim Beiko:Yeah, we can potentially improve the curation there.

Tim Beiko:if… I mean, if no one else have… have… has thoughts, then I think I'm happy to, reach out to the…

Tim Beiko:EIPs that BASU listed, or potentially, I don't give people a couple more days to share their preferences, and then for the next ACDE, we can have a set of them present.

Tim Beiko:There were a couple people who wanted to present today, and we have some time left, so if there's nothing else people want to discuss, we can also do that, and if folks don't want to sift through the presentations, you can obviously hop off a bit early, but…

Tim Beiko:Before we do that, Benny, Other thoughts on just how we approach this?

Tim Beiko:Okay, so…

Tim Beiko:yeah, let's do, let's see if client teams share more EIPs. I'll follow up with the one space you mentioned, and then, yeah, we can spend the rest of the call trying to go over the ones, I think there were five that people wanted to discuss.

Tim Beiko:First one being, EIP2926 by Guillaume.

Guillaume:Yep.

Guillaume:It's a short presentation, so you don't have to worry. I just need to find how I can share my screen, here we go.

Guillaume:Can you guys see it?

Tim Beiko:Yes?

potuz:Yes?

Guillaume:Wow, that was the fastest I ever…

Guillaume:was able to do it. Yeah, so EIP2926 is actually a very old EIP. It's starting to be a tradition at this point, but it's an EIP that was resurrected.

Guillaume:It's an EIP that dates from 2020, and introduced code, trunking in the MPT.

Guillaume:And the reason for this to be resurrected, was a discussion we had at the interop with, well, first that was a suggestion by Tomas, and then we talked about it with Ignacio and Jocham, and I think that's it.

Guillaume:To introduce code chunking, because coaching brings some advantages, immediately, and we don't have to wait for, binary trees, and… and or vertical trees, but in all likelihood, binary trees, to be implemented and tested, in mainnet.

Guillaume:So what does that… what does that do? Like I said, it's, miraculization in the MPT. What we changed from, from the initial EIP is that we bring in some of the learnings that we did, while working on vertical and binary trees. So we have 31 byte chunks with one byte of push data. We have…

Guillaume:EIP4762, or at least the code access part of it. This is still an open question, but I don't think it's gonna be a very complex one. The question is just how much,

Guillaume:how much do we pay for code chunk accesses? There's a very well thought out,

Guillaume:gas price for, for Verco that we could reuse. There seemed to be, some, thinking when, during the interrupt, we were considering 7903 or 7909, I don't remember the…

Guillaume:the number just now, that the code access should be much cheaper, so that's why it's still an open question, but I don't think it's a very complex one.

Guillaume:And, yes, it requires a transition, like an overlay… actually, not an overlay tree transition, but something a bit similar, something that is, that is, defined in EIP7612.

Guillaume:But because we're only changing, we're only trunking the code and inserting it in the tree, it will take less than one day, probably an hour, to be honest, but, yeah, it needs to be implemented and tested to know for sure.

Guillaume:Okay, I don't know why I can't go to the next slide. Yeah, so… the TLDR?

Guillaume:Nothing changes in the EOAs. You still have the nonce, the balance, the code hash, and the storage route.

Guillaume:But for contracts, you add two extra fields, the code size, so that you can just access X, like, you can serve X code size immediately. And then, the code root, which is another NPT, just like the storage tree, that is where chunks are just, added sequentially, except for the last, field, which is the last,

Guillaume:addressable.

Guillaume:integer, which gives you the version. And the version is probably going to be RLP, so if we encode it as, 0x, as 0 and not 0x80, we could, we could just not have the version until we start

Guillaume:Using different versions for accounts.

Guillaume:The transition…

Guillaume:This is just a quick explainer. You have an iterator, Ed, that goes over all the…

Guillaume:all the accounts in the state, so, like, the black squares are just the nons, the balance, everything. And then, the green squares are the code hash, so if the code hash is the non-empty hash, represented by the empty set symbol here.

Guillaume:Then there's a contract, and the contract is represented by a scroll, and so at every block, the iterator moves by n values.

Guillaume:and just sees if the contract is a, sorry, if the account is a contract, and if it's a contract, they will go get the code, chunk it, insert it, and add the extra fields.

Guillaume:This is much simpler than the overlay tree, because you can check if the conversion has happened for a given account, by the presence of this storage root, sorry, this code root,

Guillaume:field, but if you know that this is a… you can easily know whether an account is a contract or not. So, for example, here, if it doesn't have

Guillaume:If it has a non-empty hash, but doesn't have a code root and a code size, you know this hasn't been converted, so you can fall back to the old behavior.

Guillaume:Yeah, so just a quick summary, the difference with binary trees and vertical, well, it's… we are using the MPT, we're not using a unified tree, we're just, using, like, we're just doing the same thing as we do with the, with the storage, storage tree.

Guillaume:And, sorry, this is wrong, I meant, well, we could potentially get rid of the account version, so this is, my slide is wrong here.

Guillaume:Yeah, why do we need this now? Because it solves some, or at least it helps mitigate some attacks against the KVMs that we know of. And it's a simple fix for increasing the code size, because

Guillaume:If, you make the code, as large as you want, each chunk access will, will cost money, or cost gas, so, you can, you can disincentivize executing too much code this way. And, yeah, you get the code size field.

Guillaume:In the account, so you can serve that, without, without having to load the entire code and,

Guillaume:and computed size. And yeah, that's pretty much it. If there are questions, I'm happy to answer them.

Tim Beiko:Thanks.

Tim Beiko:I guess, yeah, I had a question around what the, you know, end-user benefits are, which, then sort the cheaper proving times for… or cheaper proving for certain worst cases and smaller proofs. Dragon is asking what the downsides of the CIP are.

Guillaume:I mean, I can't think of any, to be honest, except that the conversion might scare people off.

Guillaume:And, but it's, like I said, it's a much simpler one. The other downside is that it feels like this is settling down, like we could have the better model with a unified tree and everything, and people might say, well, look, this is good enough, let's stop there. So,

Guillaume:The, the other downsides… well, okay, actually, I should have, I should have, answered that better.

Guillaume:The other downside, of course, is that,

Guillaume:people… like, there will be an increase in gas costs, but I don't think you can, you can go around that.

Guillaume:And, that, if you need to pass proofs, you will find yourself with extra, extra chunks in your proofs, so some tooling will need to be updated, which is still an open question. I don't know who will be affected by this in the short term.

Tim Beiko:Thank you.

Tim Beiko:Any other questions? Otherwise, we can move on to the other EIPs?

Tim Beiko:Okay, Kevin's asking, could we benchmark the performance increase for ZK Proofers?

Guillaume:Sorry, I didn't quite get the question. Kev. I know it's Kev, but that was too fast for me to read. Could we benchmark the performance increase for ZK approvers? Yeah, we can. I mean, someone needs a proof of concept first. I don't really want to make the mistake of writing a ton of code for,

Guillaume:for something that's gonna end up in the garbage. But if, yeah, if it's, if it gets, included, I will gladly, re… you know, I would gladly take the code that already exists, adapt it, and, you could have that in, in a week, in less than a week.

Tim Beiko:Okay.

Tim Beiko:Thank you.

Tim Beiko:Okay, then, anything else on these?

Tim Beiko:Sorry, on this one, otherwise we can move on,

Tim Beiko:Mark had two EIPs that he wanted to bring you up, 7793 and 7843. Mark, are you on the call?

Marc:Yeah. Hello. Yeah, I don't have a presentation, but I just wanted to kind of give a quick pitch so that, maybe people can review async, or maybe I can kind of speak a bit more about it if there's interest.

Marc:So the first one is EIP7843, and this is the slot num op code. So this is, like, a very simple IP that just, returns a slot number on-chain, and the motivation for this is, kind of making it easier to change the slot length in future.

Marc:So currently, you can calculate the current slot by doing some, like, basic maths with a timestamp, but this would break if we change the timestamp in future. And there are other ways that you could potentially do it, like,

Marc:kind of proving against the beacon block route and stuff, but then these other ways are quite, kind of, gas expensive, so I think that in reality, people would likely fall back to the kind of seek way that would break.

Marc:So the way I see it, this EIP is, like, very simple, kind of low-hanging fruit, that will just kind of give us one less thing to worry about if we're gonna, change the slot length, you know, in maybe in a few hard forks' time.

Marc:So yeah, that's quite a small one. And then, so the other one is EIP7793, which is called, Conditional Transactions.

Marc:And the motivation behind this is improving support for encrypted mempools. So these are kind of like a cryptographic mechanism, if you don't know, that can give users protection against front-running. So to kind of

Marc:quickly most, like, explain how this would work. So, slot X, user submits an encrypted transaction. All of these, encrypted transactions, along with other users, they're all ordered.

Marc:And then in slot X plus 1, then the unencrypted transactions are put at the top of the block, and the order should match, the ordering that was kind of determined before.

Marc:And so the motivation here is, currently, there's not really a good way of actually enforcing this ordering, so we… we unencrypt it, we have the ordering, but there's not really a good way of actually, you know,

Marc:knowing for sure that these transactions actually were placed in the correct order. So what this EIP does is add a new transaction type called a conditional transaction, and essentially this just adds a field where you can specify the index of a transaction where you want it to land in the block.

Marc:So I can send my transaction and say, I want this to be at index 1, and it will only be valid, it will only execute if it's actually included at that point.

Marc:And so, between that, and also doing some kind of smart contract logic on-chain, then you can enforce the logic of the encrypted mempool. So the one other part of this EIP is there's the new transaction type, conditional transactions, and then there's one new opcode to go along with it, which allows you to actually

Marc:if this is a conditional transaction that's being executed, then you can check what the actual index is on-chain in order to enforce it. And so, as I say, this kind of allows encrypted mempools to actually have a lot stronger guarantees against front-running, and allows this logic to actually be enforced.

Marc:But yeah, that's what I wanted to talk about, but with this second one, if there's interest, then I can prepare something a little bit more in detail.

Tim Beiko:Yeah, Marius has a comment about the amount of work that the conditional transactions would add to the mempool. Do you have a sense for the

Tim Beiko:Yeah, implementation complexity there.

Marc:I mean, I'll have a think more about that, and kind of…

Marc:maybe just discuss with Maris, kind of what he thinks the problem with is there.

Tim Beiko:Substant.

Tim Beiko:Any other questions or comments?

Tim Beiko:Okay, then, last step, POTUS also had two EIPs, which I think are still, waiting to be merged. I'll put the PRs in the chat, but yeah, POTUS, do you want to…

potuz:Yeah, this is gonna be really fast, faster than Mark. Hopefully, I… I also won't have a presentation, and I just wanted to keep the ball running, to have the ball rolling. The…

potuz:the idea would be to try to separate a little bit more execution from consensus. Today, we have this mechanism to send requests from the execution layer to the consensus layer, and every time that we need to add a new request type.

potuz:because we just want to have some new feature being provided on the consensus layer, we need a hard fork that would involve both layers, the EL and the CL. We would need to have a new contract deployed on-chain, we'll need to, like, have a bunch of things, like the EL would need to do different things, and add a new list

potuz:In the payload, or in the payload envelope in the future?

potuz:When we actually… today, we have this consolidations contract that is already quite generic. The consolidations request, the EL sends us

potuz:a signature verified from the withdrawal credential of a public key for a validator, and then a second public key, which is 48 bytes that can be actually interpreted anyways on the CL.

potuz:So what this idea of DCIP is, is to just reuse that contract

potuz:to pass on the second public key from the same contract, to pass on the last 48 bytes, arbitrary data to the CL to interpret however the CL wants to.

potuz:This way, for example, we can just add a feature. I mean, this came from discussions into adding a feature to convert your validator into a builder after EPBS, and to overload already the consolidation request contract. There's tons of trade-offs.

potuz:I mean, the good one is that it allows the CL to do a hard work without ever involving the EL.

potuz:On the other hand, it would reuse a contract that is expected to be for something with a particular cadence, with a particular number of requests.

potuz:per block, and then we might add some new request type that might require many more, for example. There's issues about pricing, there's… there's a bunch of reasons why not to do this, and a bunch of reasons why

potuz:we should do this, and I just wanted to have the right people involved in the discussions.

Tim Beiko:Thanks. Felix?

Felix:Yeah, just as a quick note, so definitely I'm interested in this stuff. I was very interested also in the execution layer requests, and, I think from my end, yeah, it sounds pretty great to make it more generic. At the same time, the,

Felix:the mechanism is already very generic, so it's not a… we actually made sure that it's not a lot of work to add in the ELs, like new request types, and also I want to mention that the consolidation contract is not extensible in any way, and neither are any of the other system contracts that we use right now, so…

Felix:It will have to be a new contract anyways.

potuz:No, no, no, I want to reuse the same contract, actually. So, that's the whole point. Like, if you look at the second PR to actually use it for builder changes, it uses the exact same construct. And on the CL, we process them in the same place, in process consolidation requests.

potuz:It's just that we interpret the second 48 bytes in an arbitrary way.

Felix:Oh, well, I mean, as long as it's 48 bytes, it's totally fine. I mean, you guys can interpret it however you like, but definitely, like, if you ever want to store a different number of bytes, then it will have to be another contract. That's really my whole point.

potuz:Yeah, more than 48 bytes of data would be pretty bad.

potuz:For that contract.

Tim Beiko:Okay, anything else on, POTUS's VIPs?

Tim Beiko:Okay, thanks, Boris. I think this covers everything.

Tim Beiko:we… Had on the agenda. Anything else people wanted to discuss before we wrap up?

Tim Beiko:Okay, great. Well, we can wrap up here, Jen. Thanks, everyone, and we'll talk to you all soon.

Tim Beiko:Have a good… have a good day.

potuz:Bye-bye.

Marius van der Wijden:Thank you, bye.

stokes:Thanks.

Fredrik:Thanks, buddy.

Carson | STEEL:Thanks, bud.

Chat Logs

potuz:Go Prysm!

potuz::)

Manu:The 2 remaining prysm non synced nodes are now syncing. (Should be OK in a few hours)

Barnabas:https://dora.nft-devnet-9.ethpandaops.io

Barnabas:some erigon/besu teku nodes seem to struggle on nft-devnet-9

Barnabas:might worth investigating

stokes:Devnet-5!

stokes:I would suggest doing both in parallel

kingy_sigp:we have fixes for our syncing issues under review

kingy_sigp:lighthouse should be good by mid next week

Enrico Del Fante (tbenr):We are looking into a couple of things too. Still working on them. But should be fine next week

Phil Ngo:We’re working on some additional issues but we’ll prioritize syncing for next week

Barnabas:I think not enough CL devs here to comment?

Saulius Grigaitis | Grandine:Grandine will try to fix until mid next week

Barnabas:Ideally we can finalize devnet 3 today

stokes:Do we have any theories on why sync is slow?

Barnabas:columns go brrr

stokes:Replying to "columns go brrr" Right, is it in the network layer?

Mario Vega:Maybe we try to gather some info on syncing for next ACDT ?

stokes:Replying to "columns go brrr" Assuming there aren’t any compute issues

Parithosh Jayanthi:I’d be interested to see if its network rate limits being hit

Parithosh Jayanthi:Ie too many blobs to sync them fast enough

Tim Beiko:feat: update osaka style blob schedule eth-clients/holesky#129 feat: update osaka style blob schedule eth-clients/sepolia#110 feat: update osaka style blob schedule eth-clients/hoodi#19 feat: update osaka style blob schedule eth-clients/mainnet#10

Tim Beiko:https://github.com/ethereum/pm/issues/1687#issuecomment-3221657564

Tim Beiko:29 Aug: working fusaka trunk branches 3 Sep: fusaka-devnet-5 launch 10 Sep: fusaka-devnet-5 done -> use analysis to confirm (target, max) values here 15 Sep: Holesky/Sepolia releases; bug bounty begins 22 Sep: Holesky forks 29 Sep: Sepolia forks 1-3 Oct: Hoodi and mainnet releases 8 Oct: Hoodi fork 5 Nov: mainnet

kingy_sigp:Replying to "29 Aug: working fusa..." our unstable/trunk works but wont survive non-finality or chaos testing until our sync fixes are merged. As soon as we get those in we're ok with the other dates.

stokes:Replying to "29 Aug: working fusa..." Yep, makes sense

lightclient:Replying to "29 Aug: working fusa..." seems like we don’t have the 1 month between release and devnet fork? 2 weeks for sepolia, 1 week for hoodi?

stokes:Replying to "29 Aug: working fusa..." We only really said the 1 mo is for mainnet

Justin Florentine (Besu):and L2s

Fredrik:This is what was agreed on previously: https://github.com/ethereum/pm/blob/master/processes/protocol-upgrade.md

potuz:I remember something similar for Lido

Barnabas:we can do mainnet beginning of dec then.

Ansgar Dietrichs:it’s tradeoffs though, there are also many people frustrated when the fork is delayed

Barnabas:L2s are the main consumers of blobs tho

Ansgar Dietrichs:Replying to "it’s tradeoffs thoug..." as in, I think the cost to have the fork slip into 2026 would be very high imo, likely higher than any rollout process frustrations that might arise from a more compressed rollout

Parithosh Jayanthi:Yes Els handle this

kasey:Is that also true for L2 <> builder integration? re proof computation for blobs

Justin Florentine (Besu):cost != risk

Tim Beiko:Replying to "cost != risk" There is no real risk to L2s though

Tim Beiko:Replying to "cost != risk" It’s just that they want to support the fork on Day 1

potuz:FWIW, I think Matt is absolutely right

potuz:last time this was a big issue

potuz:and we did a mea culpa over this

Justin Florentine (Besu):Replying to "cost != risk" i think thats a pretty bold assertion, since they asked for 30 days

stokes:Replying to "last time this was a..." And I think this time is different 🙂

federicocarrone:processes processes

Ansgar Dietrichs:the Ethereum community wants Fusaka by EOY

nixo:it makes the upgrade process unpredictable for those building on top of it if we don’t stick to it

Fredrik:Personally I’m quite neutral about the timeline itself, but I feel it makes sense for us to have something that consumers can know about in advance and not need to check for each upgrade etc

nixo:Replying to "it makes the upgrade..." “best effort” isn’t sufficient

potuz:we never tested devnets less than 30 days

Barnabas:+1 potuz

Ansgar Dietrichs:in principle of course the rollout time should not affect fork cadence, because by the time we have testnet releases, client attention should be able to move on to the next fork, no matter how long the rollout process then takes

Christine Kim:Process also says, "If multiple upgrades are scheduled in advance, each testnet upgrade but must be at least 14 days apart."

Ansgar Dietrichs:Replying to "in principle of cour..." 6 months is very ambitious either way, I don’t think it’s currenty realistic

stokes:I do think getting fusaka this year is worth a few parties grumbling

Justin Florentine (Besu):I don't.

stokes:All the rollups I talk to would rather have more blobs, so I think they are fine w/ the tradeoff

Justin Florentine (Besu):whats the urgency for 1/1/2026 vs 1/15/2026?

potuz:Replying to "+1 potuz" are you agreeing with me again!??!@ I'm leaving

Ansgar Dietrichs:meta point, given that this proces doc is a unique type of doc, we should going forward clarify how “binding” / reliable it is for participants. I personally considered it more a “this is what we are aiming for”, but clearly others see it as more binding

lightclient:the rollups should use the blobs the have available 😂

Ansgar Dietrichs:very concerning (barnabas agreeing with you)

potuz:Preconfirmation teams pressured for the Proposer Lookahead feature, they may be affected perhaps as well

Justin Florentine (Besu):there is no point in building these processes if we can't be disciplined

Ansgar Dietrichs:Replying to "+1 potuz" we have a strict “no agreeing with potuz” rule, but people keep not sticking to the policy :-)

Barnabas:if the timelines in the docs are wrong, it needs to be changed.

potuz:Replying to "in principle of cour..." nah this is not the way it works though, we only really focus and open main feature branches with the right review process after the mainnet release is up in our main trunk branch

stokes:I think we need more info

lightclient:Replying to "in principle of cour..." lmao

Ansgar Dietrichs:process wise, we should treat the schedule from the doc as default, and require acd decision (like for any EIP inclusion) for override. maybe the doc should explicitly reflect that such an override is possible?

Enrico Del Fante (tbenr):If processes are there, we should stick to them. The more the ecosystem grows the less we can coordinate with everyone. So processes must e clear and respected.

Marius van der Wijden:Holesky shafted me at a hackathon, good riddance

Ben Adams:Holesky made me loose lots of sleep

Barnabas:Replying to "Holesky made me loos..." its cursed from the start

Enrico Del Fante (tbenr):Replying to "Holesky made me loos..." respect

Tim Beiko:https://github.com/NethermindEth/eth-perf-research/blob/main/README.md#60-mgas

Tim Beiko:This is the tracker for the current blockers

potuz:can we wait until I get a new NVME?

Luis Pinto | Besu:What was the story with the XEN contracts? Wasn’t that kind of blocking 60M?

Barnabas:Replying to "can we wait until I ..." I’m still rocking a SATA SSD

terence:just stating the obvious, EL client release is not enough, we would need CL client releases. 98% of the block is through mev-boost these days

Justin Florentine (Besu):THANKS

potuz:Replying to "can we wait until I ..." I suck and can't set up NFS correctly to send my geth ancient to my NAS yet

potuz:Replying to "can we wait until I ..." will try dealing with it this weekend

Barnabas:we are targeting trunk branches for all mev stack by end of this week too

Justin Florentine (Besu):idk, if my signal that i need to upgrade is a missed proposal I couldn't handle because we're at 60Mgas, i'm not happy 🤷

Ben Adams:Replying to "just stating the obv..." should we change something so CLs get the gaslimit data from ELs?

Ansgar Dietrichs:Replying to "idk, if my signal th..." that would require someone specifically attacking mainnet though, just with the intention to grief people that haven’t updated yet. and because their txs could still be included by up-to-date proposers, that is very costly

Parithosh Jayanthi:Re: Xen: we have a benchmarking suite for it, we’re focussed on 2x state sync related benchmarks for now. But we can gather Xen data asap.

Ansgar Dietrichs:Replying to "idk, if my signal th..." so I agree it would be bad ofc, but point is it is not realistic to happen

terence:ya, just use exchange capability

potuz:Replying to "just stating the obv..." please no

Ben Adams:Replying to "just stating the obv..." release faster ;)

kasey:Replying to "in principle of cour..." We can take turns - assign each client a “team” (0|1) and each team releases every other fork. Node operators just need to change clients every ~6 months.

Justin Florentine (Besu):Replying to "idk, if my signal th..." maybe, i'll think on it. allowing that doesn't feel like i'm developing for worst cases.

Raúl Kripalani:During the getBlobsV3 discussion we agreed that the Engine API can evolve independent of forks. That’s why we withdrew that proposal for Fusaka

terence:there's an eip7732 breakout tomorrow

Ansgar Dietrichs:Replying to "in principle of cour..." why only binary switching? let’s do one client per fork

Parithosh Jayanthi:Replying to "in principle of cour..." I do think if we’re serious about 6 month forks, we need bigger client teams and some of them need to change their processes. The current setup isn’t really conducive to it.

Tim Beiko:https://github.com/ethereum/EIPs/pull/10206

Will Corcoran:Replying to "there's an eip7732 b..." Agenda: https://github.com/ethereum/pm/issues/1696

terence:Replying to "During the getBlobsV..." Yeah that’s fair, I just wasn’t sure if client code supports this today. For ex, Prysm currently only treats engine API methods as hard fork changes, but that can be adjusted using exchange capability. We still have some work to do here

Barnabas:So glammy meta EIP gonna be renamed to Meta EIP Ultra?

Marius van der Wijden:Ansgar as the process expert :D

Pooja Ranjan:Version control will be good.

Roman:what’s the best place to get the status on the current state of gas limit testing efforts?

Tim Beiko:Replying to "what’s the best plac..." https://github.com/NethermindEth/eth-perf-research/blob/main/README.md#60-mgas

Parithosh Jayanthi:Replying to "what’s the best plac..." Gas-limit-testing group + state bloat group

Parithosh Jayanthi:Replying to "what’s the best plac..." You should be in both

Roman:Replying to "what’s the best plac..." yes, but there are so many messages

Roman:Replying to "what’s the best plac..." the gh page seems good too

Ansgar Dietrichs:also happy to take comments on the repricing meta EIP async, best would be in the EIP PR I think there is no urgency to sort this out, we could always switch to a different format at a later point

Marius van der Wijden:Replying to "what’s the best p..." https://grafana.observability.ethpandaops.io/d/feo4ronhsqv40d/opcodes-benchmarking?orgId=1&from=now-24h&to=now&timezone=browser&var-posgreSQL=benuragv7iuwwb&var-ClientName=$__all&var-TestTitle=$__all&refresh=auto

Marius van der Wijden:Replying to "what’s the best p..." Also this^

CPerezz:For updates in state bottlenecks project: https://cperezz.github.io/bloatnet-website/logbook.html This gets updated every day

Toni Wahrstaetter:Not every EIP needs a presentation, like 80% of them. We can discuss them all but presenting takes too much time.

Csaba:If the deadline seems too late, we could do a pre-registration deadline, with at least some details, so that we don’t have EIPs popping up the last day.

Dustin:As a process point, how does this interact with random last-minute, oh, let's wave that EIP in, EIPs which happened in Fusaka?

Ansgar Dietrichs:Replying to "in principle of cour..." my personal feeling is that with the current client situation, ideal outcome would be one fork every 8 months (so 3 forks every 2 years). still quite the stretch goal, but not unrealistic like 6 months

Dustin:At least 2 or 3 were just straightforwardly past stated deadlines

Ansgar Dietrichs:Replying to "in principle of cour..." (client situation as in resources, team sizes etc.)

potuz:Replying to "As a process point, ..." +!

potuz:Replying to "As a process point, ..." +2

Greg Colvin:The discussions threads on the Magicians is a good place to ask the EIP authors your questions.

marc|wolovim:Forkcast will introduce the tier ranking feature again for signal gathering. Open to other experiments/ideas.

Greg Colvin:Every EIP has a thread.

Parithosh Jayanthi:Replying to "in principle of cour..." IMO this is a discussion we should realistically have in person and everyone can sort their teams accordingly

Kevaundray Wedderburn:https://eips.ethereum.org/EIPS/eip-2926

Kevaundray Wedderburn:Replying to "https://eips.ethereu..." https://eips.ethereum.org/EIPS/eip-4762

Tim Beiko:What is the main benefit of this?

CPerezz:Replying to "What is the main ben..." Infinitely cheaper proving for certain worse-cases. Also much smaller proofs when code is needed (MPT proofs) IIUC

Ansgar Dietrichs:in terms of EIPs deadline rigidity, I think there are two cases: completely new EIP, on a topic not previously discussed EIP that was “pre announced”, i.e. comes out of a known workstream I think a completely new EIP addition past deadline should be a rare exception. It should be okay though for us to agree that we would be open to additional EIPs for specific topics (say e.g. state operation repricing) that are important to make the fork useful

Trent:Replying to "What is the main ben..." Larger contract sizes?

draganrakita:Replying to "What is the main ben..." What are downsides?

CPerezz:Replying to "What is the main ben..." @Trent Doesn’t matter. But ofc if they are bigger, the savings are bigger potentially

CPerezz:Replying to "What is the main ben..." @draganrakita Complexity probably?

Wei Han Ng:Replying to "What is the main ben..." One more upside - adding code size to the account fields will make EXTCODESIZE more performant (at least in geth AFAIK)

Kevaundray Wedderburn:Could we benchmark the performance increase for zk provers?

Trent:Replying to "What is the main ben..." @CPerezz I meant it unlocks larger contracts in a forward compatible way, given we couldn’t figure it out for fusaka

Kevaundray Wedderburn:Replying to "Could we benchmark t..." I think we would mainly need a POC

potuz:we feel you

Wei Han Ng:https://hackmd.io/RfHgXDnBSW2CZkWhANjeHw?view If anyone wants more data point regarding bytecode utilization, please check out this doc. TLDR - only small chunks of bytecodes are touch

Tim Beiko:https://eips.ethereum.org/EIPS/eip-7843

Tim Beiko:https://eips.ethereum.org/EIPS/eip-7793

Marius van der Wijden:Conditional transactions sound like a LOT of work in the mempool

Csaba:That enforced fixed position sounds something that needs lots of coordination.

Tim Beiko:https://github.com/ethereum/EIPs/pull/10218

Tim Beiko:https://github.com/ethereum/EIPs/pull/10220

Marc:Replying to "That enforced fixed …" why is that? only the builder needs to decide where to include the transaction

Marc:Replying to "Conditional transact…" I don’t think it necessarily would be, the desired position of the transaction is static and given up front

Marc:Replying to "Conditional transact…" would be good to discuss more later

Marius van der Wijden:I think its pretty unclean and the benefit is only to go around the overhead of discussing with the el devs?