Mario Vega:Good mor- good day, everyone, good morning.
Transcript
Mario Vega:This is ACDT number 59, today is October 27th, just let's get started. The first thing in the agenda is Fusaka.
Mario Vega:So…
Mario Vega:Sepolia, BPO fork. BPO1 fork happened last Monday. I wanted to touch upon that topic first. Do we have any… anything transcendental happening, during the update? Any updates? Any…
Mario Vega:Yes, basically, anyone has any updates on that?
Barnabas:Yeah, so as Mario said, BPO1 has happened a while ago now. We are now focusing on BPO2, which is, going to happen in 9 hours, and then,
Barnabas:Later on the same day, we're going to have, the Hoodie fork as well.
Barnabas:And then a week from now, we're gonna be looking at the BP01 on Hulu.
Barnabas:So far, everything was, pretty calm.
Mario Vega:Alright, thanks. From the client side, was there any occurrence or important thing to share?
Mario Vega:That happened during the… in the passwords?
Mario Vega:I'm guessing not. If that's the case,
Mario Vega:We can… we can move on.
Mario Vega:Alright.
Mario Vega:The next thing is,
Mario Vega:definite status updates, I have this on the agenda, but I don't think there's many things to share here either.
Barnabas:Yeah, that's right. So, Devna 3, is still online. We have close to 100% participation. Couple of notes have run out of this guy. I'm just taking a look at cleaning them up. They should be good.
Mario Vega:Alright. Do we have, like, a timeline, sorry, of how long are we keeping Devna 3?
Barnabas:Oh, we were gonna do it till midnight.
Barnabas:So… Another month, at least.
Mario Vega:Alright, thanks. And…
Mario Vega:Last topic on Fusaka is Hoodie, I think you already mentioned. Is there anything else of value that we can share today?
Mario Vega:About tomorrow's activation?
Barnabas:Just make sure that you update your notes, and try to be online as much as possible.
Barnabas:We are expecting a smooth transition.
Mario Vega:Excellent. Yeah, thanks so much.
Mario Vega:Alright, with that out of the way, I think we can, quickly touch upon the Holesky, topic.
Mario Vega:Because it's being deprecated, do we have, like, any update on that?
Barnabas:I would just ask everyone to migrate away from Hosky as soon as possible, and yeah.
Barnabas:come to Sepoli and come to Hudi, if you want to keep testing stuff, but we are expecting,
Barnabas:OSC to start… to stop finalizing, maybe… Couple of hours from now.
Mario Vega:Alright.
Mario Vega:Thank you. So yeah, RIP Holesky, it's going down. So, yeah, please migrate away from this if you are still running on this chain.
Mario Vega:Yeah, yeah, please just jump into Sepolia or Hudi, which is the… Place to test.
Mario Vega:Yes… Min Hyuk.
Minhyuk Kim:Hello guys, I'm Minya from Sunnyside. I was recently working with Optimism for the Fusaka Hard Fork on Sepolia.
Minhyuk Kim:And previously, we could test upcoming forks on L2s with Holeski testnet, since it was scheduled before Sepolia forks, but with holeski being removed, we can no longer do that, because no other testnet is forking before Sepolia.
Minhyuk Kim:And as far as I know, many L2s use Zepolia as their, like, production testnets, so it would be nice to have Hoodie to fork before Zepolia to be, yeah, DevNets.
Minhyuk Kim:But, but like many L2, Optimism has, internal dev nets that are pointed towards, holistic as a longer-running network, so…
Minhyuk Kim:it would be nice if we could have hoodie to Fork before Sepolia, if there isn't any, like, complications regarding this.
Barnabas:So, we've been back and forth regarding this. The problem is that on Hudi, we had a lot more
Barnabas:people, basically. So, a lot more users, from, staking operators to, external users, basically home stakers, home users, so we want to make sure that,
Barnabas:we affect them the least. L2s can probably deploy on DevNet. L2s have the technical know-how, how to basically run a custom network.
Barnabas:event. So, I think we should, we should try to minimize the downtime for homestakers versus the L2 operators.
Minhyuk Kim:Got it, got it. I'll talk to them about this.
Minhyuk Kim:Thank you.
Marius van der Wijden:So, we encourage everyone to use Katosis for testing so that they can spin up their own testnets, but I guess… I know that Optimism already does this, but I think other tools should also.
Marius van der Wijden:While they're testing this.
Mario Vega:Thank you.
Mario Vega:Alright. Any other comments on this?
Mario Vega:Okay, yeah, thanks. Yeah, just to echo Barnabas, yeah, I think we should… if…
Mario Vega:you are still testing on Holeshki, you should just move to Hootie and just redeploy.
Mario Vega:And, yeah, this question has been back and forth many times already,
Mario Vega:With regards of, like, Sepolia is the place to… is the place to test now, but yeah, if something breaks in Hoodie, it's gonna break also in Sepolia, and vice versa, so I think we should have, like, make this… this redundance of… of deployments, if possible.
Mario Vega:Alright.
Mario Vega:Or anything else on Fusaka?
Mario Vega:From any of the client teams, or any other person involved.
Mario Vega:Alright.
Mario Vega:Yeah, if nothing else on Fusaka at the moment, we can jump into gas limit testing updates. We have only two topics here. The first one is the 60 million gas. Is there anything that was left here to discuss? I believe most of the clients have already
Mario Vega:Launch the clients with the 60 million, gas default. If I'm mistaken, please speak up.
Mario Vega:And one comment from Barnabas, who should be set to 60 million. Please confirm if that's the case.
Mario Vega:And Camille mentions that this was the case for Netherlands from a long time ago.
Mario Vega:Yeah, I think basically, yeah, the 60 million is the default, but to all the clients at the moment, so if that's not the case, please, let us know, and I think this should be an update from every client already. If that's not the case, please reach out.
Mario Vega:Alright, if… No other comments on 60 million. I think we can…
Mario Vega:Move on to the state test updates.
Mario Vega:I see… who's in this call?
Mario Vega:Camille?
Kamil Chodoła:Yep, hi.
Kamil Chodoła:So, from my end, for now, I was mostly focusing on making sure that after merging the support for stateful tests, there is nothing being broken, and in the meantime, I figured out one issue with compute tests.
Kamil Chodoła:Right now, all of the compute tests are running fine, but we have some weirdness around some of the scenarios being faster after merging that than before, so I'm trying to figure out if this is actually the valid performance, or I messed something up. Hopefully not.
Kamil Chodoła:And working with Luis now to get the latest version of those tests, to have everything on par with EST right now. And for stateful, yeah, very nice achievement last week was that I figured out how to overcome operational system caching for some paths from disk.
Kamil Chodoła:Which gives very, very nice stability of tests. So we are testing, actually, the worst case possible, which is applicable, for example, for block building. And yeah, this gives us stability in results, so we have much better ways of comparing the results.
Kamil Chodoła:And, yeah, still working out all of the scenarios, working with Carlos and Theohem on new cases, and also marching from our team right now.
Kamil Chodoła:Analyzing possibilities to get new scenarios.
Kamil Chodoła:into… in place.
Mario Vega:Amazing. Thank you so much. There's an update on the weld, which I think directly affect you guys, but we are leaving that to the end.
Mario Vega:Yes.
Mario Vega:Anything else on gas limit testing, or state, tests, or compute tests?
Kamil Chodoła:For compute tests only, that right now we are running those improved versions of compute tests, and some new bottlenecks have popped out. I already reached out to them directly.
Kamil Chodoła:In Nethermind, we had one nasty one, but we are fixing it, like, right now, and have already fixed.
Kamil Chodoła:So, yeah.
Kamil Chodoła:But it's good that it's appearing, and we have an opportunity to fix that. Also, interesting thing, maybe for other teams to consider, is that we are creating a custom Docker file.
Kamil Chodoła:Which is enabling very detailed tracing from the very beginning of the lifecycle of the software. So, we can simply start the client in that mode, and flash the traces after the shutdown.
Kamil Chodoła:So it gives us, like, the full cycle, and we can just download the traces and analyze them straight away. So maybe this is something to consider to other EL client teams, to create such a specialized Docker image where we can build it, and they will have traces in the form they like the most.
Kamil Chodoła:it already benefits Netarmine client, at least, quite a lot.
Mario Vega:Do you have, like, a… Document or link that you can share so other.
Kamil Chodoła:It's still on draft, but once we'll merge it, I will send it.
Kamil Chodoła:Because this will be unique for every client team, as I believe. For example, we are using .trace, which is for .NET applications.
Łukasz Rozmej:By traces here, I think Camille means profiling data.
Kamil Chodoła:Yes.
Łukasz Rozmej:So this is, so we are using tools dedicated for .NET for profiling, so we can not only, you know, track the performance, but actually dig deep into, like, you know, which method takes how much time, etc.
Marius van der Wijden:Yeah, we also have this… oh, we had this for a long time, then we…
Marius van der Wijden:Yes, you have to keep prof…
Marius van der Wijden:PProf starts the PProf server, and you can basically start.
Mario Vega:Maurice, we could barely hear you.
Marius van der Wijden:Sorry, yeah, we also have this, dash dash p-prof ngot.
Kamil Chodoła:No, that's nice to know. Yeah, so basically encouraging everyone to make something like this, either behind with flag or some custom Docker files, as we are doing in the Nevermind.
Kamil Chodoła:So it's…
Kamil Chodoła:making the effort much smaller, and also still analyze the possibility of using tools like Pyroscope, etc, to have those charts on Grafana. We have the first version of that, but it still doesn't work, like, ideally, so…
Mario Vega:Thank you.
Mario Vega:Alright. Any other comments on this topic?
Mario Vega:And there was… there was one question about the EIP that bumps the blood gas limit.
Mario Vega:And it was already answered in the chat, please take a look.
draganrakita:On that topic, I think it would be valuable to have, like, a list of AIPs that we are sure that it… AIP that was mentioned is general gas repricing.
draganrakita:But, maybe I'm not remembering this correctly, I thought that there were some pickup bars that we need to change the gas so we can bump the…
draganrakita:The gas limit to 100 million.
draganrakita:I was most, like, interested in those AIPs.
Toni Wahrstätter:Yeah, I guess you're talking about the Modex group pricing, right?
Marius van der Wijden:No.
draganrakita:I think.
Marius van der Wijden:I think you mean the stuff that we are not changing with Fusaka already, right? Like…
Marius van der Wijden:For Glamps are done.
Marius van der Wijden:And for Glamsterdam, the only one that really comes to mind for $100 million is possibly the EC ad, or.
draganrakita:Nice to see you.
Marius van der Wijden:Easily. Yeah.
draganrakita:Yeah, you see it.
Kamil Chodoła:But that's what I noticed.
Kamil Chodoła:No.
Kamil Chodoła:As far as I can tell, we were doing quite a lot of benchmarking and quite a lot of improvements through the landed over the time.
Kamil Chodoła:And… it seems like it is above the… and a risky threshold.
Kamil Chodoła:But we'll re-evaluate once more.
draganrakita:Okay, okay.
draganrakita:That's perfect. Thanks.
Mario Vega:Excellent.
Mario Vega:Alright.
Mario Vega:With that, I think we can move to the next topic, which is Amsterdam.
Mario Vega:So… Yeah, alright, we can start with the block access list updates. I think…
Mario Vega:Rahul had one presentation that he wanted to showcase. Rahul, are you around?
raxhvl:I am here.
raxhvl:Yeah, in terms of updates, I think, we have a new…
raxhvl:new release coming up, with about 20 test cases that covers Coinbase withdrawals.
raxhvl:And some edge cases for… Storage and account access.
raxhvl:But I also wanted to talk about,
raxhvl:An interesting bug that came up, when we were testing block access lists.
raxhvl:Let me share a mask.
raxhvl:Okay, can you see the screen now?
Mario Vega:Yes.
raxhvl:Okay, so, yeah, like, I just wanted to highlight a certain bug that escaped, all three clients. We were testing, like, the very early phase of testing.
raxhvl:And I just wanted to highlight a particular bug, that, that escaped.
raxhvl:So, there were, like, two test cases that escaped,
raxhvl:these three clients get another minor death. This is, like, from a month ago.
raxhvl:The first, reaction to it was, you know, whether it's something wrong with the testing framework itself.
raxhvl:So, we later discovered that the test was right.
raxhvl:And these kind of bugs that escape, you know, all clients are especially evil.
raxhvl:Because if we did not have tests for this, this could have, you know, continued to be hidden for a longer time.
raxhvl:So, I just wanted to understand, you know, how did… how did this test case came to be?
raxhvl:So this, came originally from Dragon.
raxhvl:But Dragon here is not, talking about the test case itself. So he's talking about, something that he's discovered with REVM.
raxhvl:And, you know.
Mario Vega:Sorry to interrupt you, but are you changing slides right now? Because we can only see the LibreOffice Impress window at the moment, not the full screen?
raxhvl:Okay, let me… let me… Appreciate it.
raxhvl:Can you see that now?
Mario Vega:Yeah, perfect. Thank you.
raxhvl:Okay.
raxhvl:So… Yeah, so just wanted to talk about a certain test case that got discovered.
raxhvl:So, like I said, our initial reaction was to figure out, you know, if there's something wrong with the test framework itself. So it turns out, like, it was a valid test case that all three clients were failing.
raxhvl:And these kind of clients are… in this kind of test, bugs are especially evil, because if there was not a test case to catch this, this could have escaped to maybe, like.
raxhvl:DevNets or testnets.
raxhvl:So I wanted to understand, like, how this test case came to be. So drag and dropped a message on Discord that is kind of tangential to the bug, but not essentially the test kit we're talking about.
raxhvl:So he's talking about some kind of bug that he faced, in REVM.
raxhvl:And we created a PR for it.
raxhvl:And we iterated on it, and this is Mario's comment.
raxhvl:you know, bringing in a fresh angle to their test case. And this is, like, the test case that caught the bug is… is from this comment from Mario.
raxhvl:So, we are experimenting with, like, a simple markdown file that captures all these ideas at one place.
raxhvl:And this is a simple…
raxhvl:Like, a tracker that can also be used, plus also, like, a discussion ground for iterating on ideas and to come up with more such test cases.
raxhvl:This is kind of difficult within, within Discord.
raxhvl:Because, you know, you get a lot of messages from everyone, and although we do our best, sometimes, like.
raxhvl:Ideas can get lost in the shuffle.
raxhvl:So, yeah, I'd like to propose, like, maintaining a formal, simple document, like a markdown document.
raxhvl:That also welcomes, you know, not just the test developers.
raxhvl:But other stakeholders, like client teams, security researchers, and EIP authors.
raxhvl:who may not, you know, first, specifically know how to write Python test case, but they can, you know, they maybe know the map of experiment better than a single person writing the test to, like, proport the test case and
raxhvl:And we'll, do the heavy lifting of actually implementing that in Python.
raxhvl:What I've also discovered is, LLMs really love this Markdown documents. For BAL, I think we have about
raxhvl:2300 lines of Python code.
raxhvl:But the Markdown file is only 60 lines. And I've tried, like, deleting all the test cases from the Python.
raxhvl:Python test cases and, tried
raxhvl:asking Claude to generate the test from the Markdown file. And it's been fairly accurate, so that, kind of implies that, you know.
raxhvl:LLM gain a deep level of understanding from, from, this markdown.
raxhvl:And we can use to switch, you know, data to, like.
raxhvl:Imagine if we had, like, this document for every IP, we could just, see how, cross-IP interactions happen.
raxhvl:There's also a lot of interaction, interesting stuff that,
raxhvl:the security team does with, AI.
raxhvl:So that this can also go in as an input to… has ingest our EIP specs.
raxhvl:this is, like, also being adopted by Fossil now, and my hope with this talk is to encourage more people to
raxhvl:Start using it.
raxhvl:And, that's about it.
raxhvl:Thank you.
Mario Vega:Thank you, Rahul.
Mario Vega:I think this is a great idea. I dropped a comment on the chat that I think we should probably make this Markdown document
Mario Vega:visible And… I suggest that we linked to it from the EIP, but that might be contentious.
Mario Vega:So, it's worth discussing.
Mario Vega:But yeah.
Marius van der Wijden:So, I do like the idea of EIP editors doing more work in the realm of testing.
Marius van der Wijden:I'm… I'm wondering, like, every… every EIP has a optional, like, test section.
Marius van der Wijden:I don't know if, like, an external document is better than just using that.
Marius van der Wijden:So maybe if we force the EIP… like, it seems like we have much more process around, the EIP champions now.
Marius van der Wijden:with Glamsterdam, so we can… I feel like we can kind of force them to write these test cases, at least in plain English, into the EAP in the test section, and not require an additional,
Marius van der Wijden:document that someone has to find and maintain and whatever, but, like, keep it.
Marius van der Wijden:alive in the EIP.
Mario Vega:Yeah, I absolutely agree. And I think we can make ways of working it into ills, for example, referencing it directly, or linking it, or giving a live, dynamic document.
Mario Vega:Just, just for marking completion and, and, and whatnot.
Mario Vega:But yeah. Tony?
Toni Wahrstätter:Yeah, I've been using the test cases section in the APs, but it feels like
Toni Wahrstätter:for example, for block 5 access lists, it would have been, like, 20 to 30 even more test cases in there, so it would have blowed the EAP.
Toni Wahrstätter:itself, and maybe a fair compromise could be to use the assets folder of the AP and put
Toni Wahrstätter:And basically enforce that there is a test cases, markdown document in there.
Toni Wahrstätter:Because then, also, everyone… we can link from the EAP to the assets folder, and then we…
Toni Wahrstätter:Solve the problem. And keep things clean.
Mario Vega:Thank you. One advantage of, for example, keeping the markdown in eels.
Mario Vega:Could be that we can mark
Mario Vega:the… the test case has completed, or has implemented, in the same PR Where we implemented.
Mario Vega:So, that's one thing to consider, right? I'm not, like, heavily…
Mario Vega:Leaned against any of the options, but that's just one thing that could make it, like, a little bit more trustworthy.
Mario Vega:Yep.
Mario Vega:Any other comments on this?
danceratopz:Hey, Marianne. Just a quick comment.
danceratopz:I can't find my hand to put up, so I'm just speaking up, sorry.
danceratopz:if we pushed, like, EIP versioning a bit harder, one possible future for that is the,
danceratopz:the Ethereum EIPs repo gets sort of more closely tied
danceratopz:To, in the case of the execution layer, execution specs.
danceratopz:In which case, for example, if you made a change to the specs in an EIP's markdown.
danceratopz:Then you'd have to back it up with an implementation In execution specs.
danceratopz:So this would be, for example, only for CFI EIPs?
danceratopz:And in which case, if you start making this tighter link.
danceratopz:Then you could definitely maintain a list of tests.
danceratopz:And execution specs.
danceratopz:But this is all a bit, vague and a bit of work in progress, but just an idea.
Mario Vega:Thank you, thank you.
Mario Vega:I think, yeah, there are still ways to go on execution specs implementation… I'm sorry, integration with EIP.
Mario Vega:So, I think we can keep on working on this. It's, it's an interesting topic on how we can discuss and just basically peer review and peer suggest test cases, which I think is very important.
Mario Vega:And just opening the discussion, I think it's, like, it's a great way to start.
Mario Vega:Yep.
Mario Vega:Yeah, by the way, I jumped way too quickly into the presentation, maybe. Is there any other block-level access list updates that anyone else wants to share?
Stefan Starflinger:Regarding the DevNets, it should be up by the end of today, the first one. I'm just doing some housekeeping.
Stefan Starflinger:And then it should be up pretty quickly.
Stefan Starflinger:And I've tried most of the clients today with Kurtosis, and they all seem to be running pretty stable. So if you're adding more test cases, or iterating on something, it would be good to know regarding the DevNet.
Mario Vega:Excellent. Just for everyone's,
Mario Vega:understanding is, which clients are being included in this, in this DevNet?
Stefan Starflinger:So, it seems that it's difficult to get two consensus layer clients working together, so I'm just gonna choose either Lodestar or Prism.
Stefan Starflinger:And for execution, I've tried Wrath, Nethermine, Geth, and Bezu. Those would be included.
Mario Vega:Excellent. I think we're missing a couple in there. If a… if, for example, Aragon has implementations finished, I think they can… they should be able to just join, if that's…
Mario Vega:My understanding, so yeah, please reach out to Stefan once.
Mario Vega:You have an implementation that you want to use to join the DevNet.
Mario Vega:Alright, thanks, Stefan.
Mario Vega:Cool.
Mario Vega:Any other… Updates on blocks list that anyone wants to share?
Mario Vega:Alright then, just one comment from Barnabas, that Helseshi has finally stopped finalizing.
Mario Vega:Officially.
Mario Vega:Alright.
Mario Vega:If nothing else on block-level access list, we can jump into EPVS.
Mario Vega:All right, so you… Justine, if you… I see that you're here, sure. Yep, all right.
Justin Traglia:I can give her a very quick update. There's not much. There is a new consensus specs release with some additional EPBS tests for COAS.
Justin Traglia:We don't have a ePPBS DevNet 0 up and running yet, so not much testing there.
Justin Traglia:The proposed structure change to attestations was rejected at the breakout call on Friday, and Mark identified a missing gossip condition check that we're gonna get fixed.
Justin Traglia:But, until there's a DevNet, not a whole lot from us.
Mario Vega:Alright.
Mario Vega:Thank you.
Mario Vega:Any comments from clients, regarding PBS that needs to be brought up?
Mario Vega:Alright, Justine, when is the next, EPVS breakout call?
Justin Traglia:I think it's… It's, like, 12 days from now? Or, it's, like, not this Friday, but next Friday.
Justin Traglia:I'll share a link to the agenda.
Mario Vega:Yes, please, thank you. Yeah, so please, clients, if you can just make it to this meeting, would be very helpful.
Mario Vega:Yep.
Mario Vega:Thank you.
Mario Vega:Alright, if nothing else on EPBS, I think we can jump into the last topics, which are not fork-related. So one topic we already, touched upon is the Holeshky deprecation.
Mario Vega:The next topic is regarding RPC updates.
Mario Vega:So yeah, basically, a week or two ago, we discussed about, enhancing the RPC testing framework, but I don't think there has been any much development as of now, but… and rather, this is a work in progress, in my opinion.
Mario Vega:But if there's anyone to comment on this, please raise your hand.
Mario Vega:If not, we can move to the next one.
Łukasz Rozmej:We have two topics, but they are not exactly related to this, but to the current test and current,
Łukasz Rozmej:how things are working. So, one thing is that We recently… change the, reverted…
Łukasz Rozmej:error code to be free, but I don't think the current ETH simulate tests reflect that, so I think they might need to be regenerated or something.
Łukasz Rozmej:So that's… that's one thing. And second thing that I don't really…
Łukasz Rozmej:Mmm… like, let's say, is,
Łukasz Rozmej:how… when you have sent transaction, or ETH Simulator, or whatever.
Łukasz Rozmej:There is some logic of how to resolve the transaction type if it's not sent explicitly.
Łukasz Rozmej:And I'm thinking this logic might not be optimal, and it's reflected in tests, so if we… we actually have a bit different logic, and we fail some tests because of that, so that might be a bigger discussion.
Łukasz Rozmej:I think, basically, we had… Some blob fields that are present in some tests.
Łukasz Rozmej:And the transaction was still, resulting in EIP1559 transaction, while we were… we were, treating it as… as blob transaction. And, yeah, that's…
Łukasz Rozmej:there's a question mark what to do and why, but I think potentially the default… Gaf,
Łukasz Rozmej:Behavior… should be discussed.
Łukasz Rozmej:At least.
keri:Can you, open an issue on the execution APIs repo?
keri:So we can take a look at it, and maybe start the conversation there.
Łukasz Rozmej:Okay, so I will try to open two, two of those. Thank you.
keri:Thank you.
Mario Vega:Excellent.
Mario Vega:Yeah, thanks, thanks for bringing this up. I think the place to put issues at the moment is… should be execution APIs. Yeah, please just…
Mario Vega:Raise the issue, and we can… just to have a place to discuss this.
Mario Vega:Alright.
Mario Vega:Yeah, just… Alright, sorry, before I jump in, anything else on RPC that we want to discuss today?
Mario Vega:Alright, if not, there was one issue, or rather, like, discussion topic that was raised by Marius today, regarding EIP7610.
Mario Vega:I'll share a link to the EIP if it needs refreshing. Basically, this was a discussion about, like.
Mario Vega:underspecified, if I'm correctly, or…
Mario Vega:basically just what happens in case that there's storage dangling in the contracts. So we want to discuss what to do in that case. Marius, do you want to open up the floor for discussion?
Marius van der Wijden:True.
Marius van der Wijden:I hope you can hear me a bit better, I was, I was driving, so it wasn't great. Yeah, so the idea was, this EIP kind of specifies pretty exactly what we are doing in the case of a contract that has no code.
Marius van der Wijden:But, storage, and there are… there are, because of, like, prior revisions of the EVM, there are 28 of them on mainnet right now.
Marius van der Wijden:That we kind of cannot really get rid of in a normal way.
Marius van der Wijden:And the idea is, or the problem is, someone could, in theory, deploy something there… And,
Marius van der Wijden:then the behavior is kind of underspecified. Like, what happens if you deploy a contract to
Marius van der Wijden:A… an account that has no code, but already storage.
Mario Vega:Marius, I think you cut off. We cannot launch you.
Marius van der Wijden:Not really good, because then you have a contract with a different code, and, like, kind of dangling storage. Or what you could also do is just delete all of the storage, if someone creates to this contract.
Marius van der Wijden:And, yeah, all of them have drawbacks, and we have added this EIP in,
Marius van der Wijden:I think in the PECRA fork, And,
Marius van der Wijden:And now Raz wants to reopen the discussion around it. Because the drawback of how we do this is that,
Marius van der Wijden:Every time we, every time we create, we would need to…
Marius van der Wijden:look at the chain again, and catch something from the chain again, and do a second lookup. For us, this lookup is kind of free, because of the way we restore stuff. We will just hit the cache, but for other implementations, it might not be
Marius van der Wijden:As, as cheap as it is for us.
Marius van der Wijden:I don't really think that the testing call is the right… Avenue to change this, because…
Marius van der Wijden:We kind of…
Marius van der Wijden:We have introduced this as an EIP, and it went through the whole process, so if we want to change it, we should also introduce it… introduce the change as an EIP, and have it go through the whole process, and maybe we propose to Glamsterdam. But yeah, we can quickly discuss it here, if…
Marius van der Wijden:People want to discuss.
Mario Vega:Yeah, Dragon?
draganrakita:This one of AIPs that was proactively activated. Not exactly the hard work, but because there was no…
draganrakita:This kind of edge case didn't happen in the history, and it's very unlikely that it's going to, but you need, like, hash collision for it to happen in the future.
draganrakita:So, we are talking… really talking about something that… It's mathematically impossible to happen.
draganrakita:The edge case that requires additional, like, for us and for Aragon, requires additional read from the database is not that great.
draganrakita:So…
draganrakita:Yeah, that's why I was wondering if… I think GET asked this AIP to be included, because they did some refactoring inside their code. I think Nethermine is, was fine with either, because they already have similar, format of the mercantries and accounts with storages.
draganrakita:So it affected us and Aragon mostly.
draganrakita:I'm not sure if there is,
draganrakita:But if the GET are fine to revert this, or having, like, we can make KIP and just make a change.
Gary Rong:So, I just want to mention that, maybe for Aragon, you need an additional database lookup.
Gary Rong:But it's only required if you… for the contract deployment. And,
Gary Rong:it's not necessary for all the transactions. So, I think for the overall performance, the impact is basically negligible.
Gary Rong:And
Gary Rong:And also, I think, semantically, it is, like, the cleanest way to… to define the… the…
Gary Rong:expected behavior around this age case. And, otherwise, for example, if we want to inherit the storage from the…
Gary Rong:the storage for the new contract, or we do some deletion for the old storage, it would basically bring a lot of complexity into the protocol.
Gary Rong:Yeah. So, from my point of view, I think…
Gary Rong:this I.O. overhead should be fine. And also,
Gary Rong:In theory, someone could craft a blog with a lot of contract creation.
Gary Rong:try to slow down the arrogant RESC note.
Gary Rong:But,
Gary Rong:it's meaningless for the guests, so it's also meaningless for the network. I don't think people will try to do it.
Gary Rong:To perform this kind of attack.
Gary Rong:Yeah.
Mario Vega:Mr. Rutterman.
draganrakita:On other hand, but how difficult would be to get to remove this check?
draganrakita:And… we can remove this check, we can, like, we have two options, to leave the storage as is.
draganrakita:Or delete storage and act as self-destruct.
draganrakita:Any… I think any… we are talking still about edge case, but any… that kind of option would work.
Gary Rong:So, if we leave the… leave this styling storage, as I said, is semantically Bad, because…
Gary Rong:we… it means that we will deploy some new code, but they can operate on the old storage, which I don't… I really don't like it. And,
Gary Rong:For deleting all the… Storage, when we try to deploy it.
Gary Rong:I think, it needs… we need, the ability to traverse all the dialing, storage, and,
Gary Rong:I can't remember all the details, but we do have some issues for it. It is the reason we proposed this EIP to disable this behavior.
draganrakita:In general, because, this really edge case, and…
draganrakita:it's probably not going to be triggered. I think it, from at least In my mind.
Gary Rong:Duh.
draganrakita:and… It doesn't matter if it is nice or not, it is more like what's easier.
draganrakita:If it is easier just to leave storage as is, and use that, maybe we can go with that.
draganrakita:From… Yeah, East…
Gary Rong:It's in theory impossible to be triggered, but it's not, like, so for security. It's not the 32 bytes, it's only 20 bytes, so it's still, like, possible to trigger this age case by the hash collection.
draganrakita:So, to repeat myself, it's not about what's nicer for the protocol, but what's easier for GET to implement. Is it easier to just leave storage as is, or to do self-destruct?
draganrakita:I'm hearing for you the self-distract would be harder, because you need to iterate over all storage, but what about living storage as is?
Gary Rong:Yeah, it should be fine, like, in the implementation level,
Gary Rong:Like, inherits all the living storage to the new account.
Gary Rong:It's not… it's not hard in the implementation.
draganrakita:Okay, it seems it makes sense to go to that path.
draganrakita:We're just discussing now, I think everybody should look into the code and check if this is okay or not.
draganrakita:I don't want to, like, crash something like that.
draganrakita:But for at least from this discussion, I'm hearing that it should be… it could be okay to leave storage as is.
Gary Rong:Yeah, it could be an option, but I still, hold my,
Gary Rong:stance, and I think it's not good for the protocol, but yeah, anyway.
Łukasz Rozmej:I agree with Gary a bit, that's, like, undefined a bit,
Łukasz Rozmej:result, which I also don't like.
draganrakita:Simon Cook.
draganrakita:That's why we are talking to define it.
Mario Vega:Alright, I think,
Mario Vega:Is there any other avenue where maybe we can continue the discussion? I think we're running out of time here,
Mario Vega:maybe we can continue to sync and revisit on ACDE, but I think it's important, regardless of the outcome, I think what we can do is just start coming up with a test case. I think we already have, but…
Mario Vega:Just to define it, and just make sure if… even if it's an unlikely scenario, we should, like, still come up to the same, consensus, regardless of what the…
Mario Vega:the solution is.
Mario Vega:But anyway, I think we should, probably still discuss this, offline, and then come up to the discussion again on ACDE, if that's okay? If this becomes an EIP. Am I understanding correctly?
Gary Rong:Yeah, sounds good to me.
Mario Vega:Alright, thanks.
Mario Vega:Okay.
Mario Vega:I see that we already have a discussion thread on the Steel Discord server, so I think we can continue on there.
Mario Vega:Please evaluate, and we can, try to see if we can come up, to a…
Mario Vega:To a conclusion, async.
Mario Vega:I'm there.
Mario Vega:Alright.
Mario Vega:Beautiful.
Mario Vega:Thanks for the input, Gary and Dragon.
Mario Vega:Yeah, the next and last topic is the wealth.
Mario Vega:yeah, I believe… Dan, do you want to give a summary of the status?
Mario Vega:on this?
danceratopz:Yeah. Hey, everyone.
danceratopz:I can give a brief summary.
danceratopz:So, just for context, the world is, about moving
danceratopz:the code from execution spec tests to the execution specs repo.
danceratopz:So that we can basically have the specs and the tests living alongside each other, and give a much better developer experience.
danceratopz:So we've been working hard on this for the last couple of weeks.
danceratopz:Oh, really?
danceratopz:I don't think I can fix that so quickly.
danceratopz:We'll turn it on a little bit.
danceratopz:Well, I'll carry on.
danceratopz:Thanks, Nixon.
danceratopz:Turn, turn your speaker down, Trent.
danceratopz:So, yeah, anyway, basically, I posted a little update, above, and I think that's probably all you need to know. So, it's still a work in progress,
danceratopz:But people who contribute to our libraries and the tests in execution spec tests will have noticed that the old repository is not used anymore, so yeah, don't direct any PRs to execution spec tests.
danceratopz:Don't open any issues there, open all PRs and issues, and… Execution specs, the…
danceratopz:Basically, the status is that for Osaka contributors, and for benchmarking contributors, you can basically start PRing straight away.
danceratopz:So we have, people should direct their PRs to the default fork, which is forks or SACA.
danceratopz:Amsterdam contributors may need to hold off for a little bit longer until we've rebased that fork on top of Fox Osaka.
danceratopz:I think everyone knows…
danceratopz:I think it's a relatively tight group of people who can just reach out to us if there's any problems there.
danceratopz:Just one caveat regarding benchmarking.
danceratopz:Luis has quite a large PR open.
danceratopz:Which will restructure the tests benchmarking folders.
danceratopz:So just be aware that that large change is underway, and will be merged soon.
danceratopz:Clients don't need to worry very much. HiFue is unaffected, and fixed releases are still a work in progress, but they should be completed this week.
danceratopz:And if you need to look at docs for testing, you can go to the old website. That's still a work in progress.
danceratopz:I think that's about it. If anyone wants to chime in from the Steel team…
danceratopz:With a bit more information, then please do.
Mario Vega:Great, thanks, thanks so much. So, TLDR is basically, please come to Execution Specs now for any testing or spec updates that you want to contribute, and we should be good to accept PRs now.
Mario Vega:So, yep.
Mario Vega:And also feedback. Feedback's really appreciated on this new structure. I think it's gonna… it's… from our perspective, it's better, because we have the…
Mario Vega:The specs and the tests are now in the same place, so if you want to start prototyping, and at the same time you want to do the test, there's no longer a requirement for you to go to two different repositories. So it's, in my opinion, a huge step up in the UX of our specification and testing frameworks.
Mario Vega:But yeah, anyway, any feedback, it's welcome, please feel free to come to Execution Specs and open issues and open PRs, yeah, as of now.
Mario Vega:Great. I think that was the last, topic remaining for today.
Mario Vega:Anything else that is worth discussing today?
Mario Vega:Anyone wants to race? We have 5 minutes, basically.
Mario Vega:If not, I think we can wrap up. Thanks, everyone, for joining, and I'll see you on ACDC on Thursday. Thank you.
felipe:Thanks.
Gary Rong:Here you go.
Louis:I don't see it.
Antoine James:Bye, Ron. Bye-bye.
Antoine James:Bye-bye.
Chat Logs
00:03:26
Yassine Ferhane:gm!
00:06:41
Kamil Chodoła:Falling below finalization like right now
00:06:58
Kamil Chodoła:Or very on the edge
00:07:44
Barnabas:devnets
00:07:56
nixo:can they use ephemery?
00:08:43
nixo:+ they’re harder to coordinate if something goes wrong
00:11:12
Barnabas:hoodi should be set to 60m please confirm
00:11:29
Kamil Chodoła:In Neth long time ago afaik
00:11:38
nixo:are all client defaults 60m already?
00:11:56
Barnabas:we see some blocks that are pulling it down still
00:14:45
draganrakita:Do we have list of EIPs that can help us to bump block gas limit even more?
00:15:21
Toni Wahrstätter:Replying to "Do we have list of E..."
Theres the repricing meta eip with many of those
00:16:22
Barnabas:very hard to hear you marius
00:17:06
Pooja Ranjan:Replying to "Do we have list of E..."
https://eips.ethereum.org/EIPS/eip-8007
00:17:10
draganrakita:https://eips.ethereum.org/EIPS/eip-8007
Waren’t there some precompile changes needed for next bump?
00:22:19
jochem-brouwer:Antwoord verzenden naar "Do we have list of..."
You might mean this one: https://eips.ethereum.org/EIPS/eip-7667
I thought we decided to remove this last ACDE but maybe my memories might not be correct there (because this is a price increase which was once proposed pre-Fusaka and carried over from the pre-Fusaka fork)
00:26:15
Mario Vega:I think this is a great idea, we could link this markdown directly in the EIP so people who have an idea of a test scenario can quickly find the link from the EIP
00:26:49
Toni Wahrstätter:Link to the doc:
https://github.com/ethereum/execution-spec-tests/blob/main/tests/amsterdam/eip7928_block_level_access_lists/test_cases.md
00:27:10
jochem-brouwer:Antwoord verzenden naar "I think this is a ..."
If this is an external URL I don't know if that works
00:28:13
jochem-brouwer:I think this is a good idea, but the fact that a doc is in the Testing phase of the EIP does not mean that this part is complete. (So should not give a false sense of safety that it is completely covered by tests)
00:28:34
Christine Kim:Replying to "Do we have list of E..."
7667 was removed, but mainly because of its relation to verkle, https://christinedkim.substack.com/p/acde-223
00:28:56
Pooja Ranjan:Test Cases (optional) - Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Tests should either be inlined in the EIP as data (such as input/expected output pairs) or included in ../assets/eip-###/<filename>. This section may be omitted for non-Core proposals.
^ from EIP-1
00:29:56
Barnabas:“I can’t find my hand” - hope its nothing serious 😂
00:30:28
felix (eest):Replying to "“I can’t find my..."
so this is what happens when you click the devops link..
00:31:33
Justin Traglia:We want to do something similar in the CL specs too. Defining a list of test cases 🙂
00:33:05
Barnabas:Holesky has stopped finalizing now officially.
00:33:21
Kamil Chodoła:RiP
00:35:02
Justin Traglia:https://github.com/ethereum/pm/issues/1783
00:35:06
Justin Traglia:It’s on Nov 7th.
00:39:04
Mario Vega:https://eips.ethereum.org/EIPS/eip-7610
00:39:46
jochem-brouwer:It is an addition on https://eips.ethereum.org/EIPS/eip-684
00:40:35
nixo:lol
00:40:47
Barnabas:Marius, get back to your car 😂
00:40:58
Toni Wahrstätter:Wasn't there an eip by martin to delete those storage slots from those accounts?
00:41:04
raxhvl:Looks like big tech doesnt want marius talking about this
00:41:36
Mercy Boma Naps-Nkari:This is on the error code side https://github.com/simsonraj/eth-err-tests smimz created a testing framework
00:41:43
jochem-brouwer:Extra lookup? We have already the collission check right
00:42:24
jochem-brouwer:I think the part which should be changed got dropped here?
00:43:46
Mario Vega:Just for clarification, how is this different from a 7702 account that sets the storage and then resets to non-delegation?
00:43:49
jochem-brouwer:Wanted to bring up that for 7702 it is thus possible to change delegated code but keep storage
00:44:10
Alexey:how much processing time would it save if you will not check the storage?
00:51:18
danceratopz:Context for the EELS/EEST Weld:
https://steel.ethereum.foundation/blog/blog_posts/2025-09-11_weld-announcement/
External Contributors:
- Osaka test and benchmarking contributors can now start PRing to the default execution-specs branch: "forks/osaka".
- But all benchmarkers should be aware of a large renaming underway in "./tests/benchmarks/"
- https://github.com/ethereum/execution-specs/pull/1681
- Amsterdam contributors (balers and gas repricers) should hold off until "forks/amsterdam" has been rebased on top of "forks/osaka"
Clients:
- Fixture releases are still WIP, should be completed this week.
- Hiveview unaffected,
Docs:
- WIP, for testing docs now https://eest.ethereum.org/main/
00:51:22
Gary Rong:Wasn't there an eip by martin to delete those storage slots from those accounts?
Probably no?
00:51:39
Trent:Lots of resonant frequency in your mic
00:51:46
Trent:If you’re in an echoing room
00:51:54
nixo:no it’s fine
00:52:00
Trent:Lol ok
00:52:26
Gary Rong:how much processing time would it save if you will not check the storage?
Depends on the number of contract creations within the block. 1 additional read for a contract deployment
00:52:44
jochem-brouwer:Antwoord verzenden naar "Wasn't there an ei..."
I did not completely get what the changes were supposed to be, but just wanted to note: 7610 is PFId for Glamsterdam. Will await the discussion thread on this topic
00:53:13
jochem-brouwer:Antwoord verzenden naar "how much processin..."
But we already need to do the collission check? So it is not an extra read?
00:53:41
Gary Rong:Wanted to bring up that for 7702 it is thus possible to change delegated code but keep storage
The nonce will be non-zero in this case.
The contract deployment is only allowed for 0 nonce and empty code. With EIP7610, we added the additional requirement for empty storage
00:53:52
jochem-brouwer:Antwoord verzenden naar "how much processin..."
(already need to open account RLP to check if it has no code by EIP-684)
00:54:24
Marius van der Wijden:Replying to "how much processing ..."
Depends on how you store the account
00:54:38
jochem-brouwer:Antwoord verzenden naar "how much processin..."
ahh gotcha, i see where the problem is
00:54:39
Gary Rong:(already need to open account RLP to check if it has no code by EIP-684)
Reth and Erigon don't store the storage root with other account metadata I guess.
For geth, there is no extra read
00:54:52
jochem-brouwer:Antwoord verzenden naar "how much processin..."
I assumed every directly stores account RLP
00:55:08
keri:RPC Call next!
00:55:22
felix (eest):Replying to "RPC Call next!"
clashes with protocol meet?
00:55:23
Marius van der Wijden:Congrats to the welders
Summary
18 highlights
· 4 decisions · 6 action itemsExperimental
Summary
18 highlights · 4 decisions · 6 action itemsExperimentalfork status and schedule
critical infrastructure
client updates
testing progress
- BAL release with 20 test cases covering Coinbase withdrawals and edge cases00:19:33
- Bug discovered that escaped all three clients in early BAL testing00:20:24
- BAL DevNet-0 to be ready by end of day with Geth, Nethermind, Besu, and Reth00:31:34
- New consensus specs release with additional ePBS tests for COAS00:33:31
documentation
Decisions
- L2s should deploy on DevNets rather than wait for testnets00:08:43
- 60 million gas limit is confirmed as the default for all clients00:10:58
- Proposed structure change to attestations for ePBS was rejected00:33:58
- All EL testing PRs and issues should now go to execution-specs repository, not execution-spec-tests00:52:27
Action Items
- All node operators: Update nodes and stay online for Hoodi fork activation00:05:59
- Barnabas: Clean up devnet 3 nodes that have run out of disk space00:05:24
- Kamil: Share custom Docker file documentation once merged00:15:30
- Stefan: Complete BAL DevNet-0 setup by end of day00:31:34
- Łukasz: Open two issues on execution APIs repo for error code and transaction type resolution00:38:02
- All teams: Continue EIP-7610 discussion async and evaluate implementation options00:50:43