All Core Devs - Testing #100

Transcript

Barnabas Busa: Hello.

Justin Traglia: Hey, how's it going?

Barnabas Busa: Good. Why are you so tired? Yeah.

Justin Traglia: I flew to Cambridge overnight. I arrived.

Barnabas Busa: this morning.

Justin Traglia: I'm there for the workshop.

Barnabas Busa: Oh So, a bit of jet lag, huh?

Justin Traglia: I mean, just a little bit. I mean, it should be 9am my time, but I only probably slept, like, 3 or 4 hours on that plane. Which isn't bad. Well… Whatever. Yeah, it's okay. I had, Mario and Jihoon ready to take over, just in case I, like, missed my flight or something.

Barnabas Busa: or.

Justin Traglia: Didn't have, like, a good situation.

Barnabas Busa: Oh, good place.

Justin Traglia: A bit dreary is what I'd say. Like it's a it was sprinkling a little bit earlier. And I think it's like. an average of 10 to 15 degrees Celsius this week. There's one day where it's 21.

Barnabas Busa: So you might see the sun as well.

Justin Traglia: Yeah, I might see the sun one day.

Barnabas Busa: Yeah, that sums up pretty much the weather in UK, I would say.

Justin Traglia: But yeah. Hey, Mario, how's it going?

Mario Vega: Hello. All good, thank you. How about you?

Justin Traglia: Doing good. I was just telling Barnabas I was a bit jet lagged or whatever, so. Yeah. Talking about the weather as well.

Mario Vega: I just hope you get over it fast.

Justin Traglia: I… I mean, I just don't sleep before, like, 10 PM, and then the next day, I'm typically fine. You can, I should say it. You shouldn't sleep early. Like, that first day. You just gotta power through it.

Barnabas Busa: Yep. Was it overnight flight, you said?

Justin Traglia: Yeah, I left Austin at… 6 p.m. And I arrived here in London at 9:15 AM and then I took a two and a half hour train to Cambridge.

Barnabas Busa: Right. Heathrow, I would say, right? I'll send you the receipt.

Justin Traglia: 0.

Barnabas Busa: That's pretty good.

Justin Traglia: Yeah, direct flight, that was really nice, actually. What was I thinking? The kid is still due or was due. Have you already had your child? Barnabas.

Barnabas Busa: Oh, yeah, yeah. Like, that's why I took September off. I'm a rebel.

Justin Traglia: us.

Barnabas Busa: presently.

Justin Traglia: That makes sense. Congratulations. I don't think I ever said that.

Barnabas Busa: you.

Justin Traglia: Yeah, I just remember the interop, you're like, we gotta get this done before September.

Barnabas Busa: Sure.

Justin Traglia: Ha ha ha.

Barnabas Busa: Sending me some pictures now.

Justin Traglia: How cute. Thanks. Very cute. Hello, everyone.

Jochem Brouwer: I added one more item, like… 30 minutes ago, which I will share in chat.

Justin Traglia: Okay, I see. Do you want to discuss that in the main chat, or in the EL breakout?

Jochem Brouwer: In the main chat, please, yeah.

Justin Traglia: Okay. I'll add that to the agenda. Thank you. When you say min-specs for Glamsterdam, you mean like hardware specs, right?

Jochem Brouwer: yes, exactly. I almost thought that I was making a mistake, that it should be Hegota, but no, we are still on Glamsterdam.

Justin Traglia: Yeah. Right, jochem. I have added it. It's after the, After the proposer selection discussion by Barnabas.

Jochem Brouwer: Yeah, thanks a lot.

Justin Traglia: Alright, hello everyone. Let's wait one more… one or two more minutes before getting started. Barnabas, will you be the one giving devnet updates. and network updates.

Barnabas Busa: Yeah, I can for… Some networks that I think Stefan can do for them. miniature fork. It was jochemnet fork.

Justin Traglia: I'll ask you in a few minutes. Or in a minute. All right, let's get started. Welcome, everyone, to ACDT100. Woo woo. Barnabas and Stefan, can you give us updates on the devnets and Sepolia? And how things are going?

Barnabas Busa: Yeah, I can start with the Gantz-Rudemann-Heath. So we have a few nodes that are offline. Potuz is one of them, I think he's on holiday, so he'll probably just turn off his mute. But… Realistically, Nimbus and Erigon nodes are offline, and in some of the Besu nodes, Lighthouse and Grandine Besu nodes are offline. So it would be nice if, The client teams could take a look, and Let me know if I can do anything. I can also send some DevoBlocks over, but I think everybody can do it themselves as well. And regarding Sepolia, it's been a very stable week since the fork. Every single node operator has, came up after the fork. There was a few slots missed.

But, but since then, we've been very close to 100%.

Stefan Starflinger: I can. go over, last week also, where we had the first version of the Shadow Fork, which was the mainnet. kind of, jochemnet… With the Gloas transition, so with the, with the fork. The configuration had some hiccups, but I just went with it, and we tested the fork. And then later used it to test, snap syncing. Found quite a few issues in a few clients there, syncing, especially in regards to, kind of stability and choosing the right, head. And then this week, I've now launched the second version of the jochemnet, but this time it's post the fork. with all of the state bloat that jochemnet comes with. Especially, 64, kilobyte, contracts, for doing, some… benchmarking against. And we will be running different scenarios, right now. There are still some…

wallet funding going on in the Shadow Fork, we need to fund the wallets a little bit differently. And then, some… benchmarking cases are gonna be run, by me and Lewis. And he's also checking if everything, is set up. The same way as it is in the benchmarking runs. That's pretty much it.

Justin Traglia: Cool, thank you. Any other observations or notes from? Anyone else, like clients? Okay, moving on. I want to quickly remind clients that releases for Hoodi are needed by this Friday, October 16th. I believe Alex Stokes is working on the blog post. And we intend to publish it that day. I see that Nico and Lodestar have published the release for Lodestar. Awesome. Yep, just let us know when those releases are in. I guess let Alex Stokes know, actually. Cool, thank you. Barnabas, would you like to talk about that proposer selection issue that came up within the past 24 hours?

Barnabas Busa: Yeah, we got a report on ETH R&D. That seems to be an actual issue. here's the fix for it. So the general issue was that if there was a proposal, that got, Selected for slot 31. And, decides to slash itself, because It can see a higher value in the following two epochs in a specific slot, then it could actually put its own validator index back into plus two Epoch. And this could basically cause that validator to get rewards that they shouldn't have gotten. I'm not sure if that made sense. Yeah.

Justin Traglia: Yeah, my understanding is that if they slash themselves and they're already included in the next, one of the next VDPOCs, they could cause like a reshuffling.

Barnabas Busa: No, they could include themselves. That's the actual problem, that they could just put whatever they want in their compute shuffle index, right? And then they could just include themselves in the following epoch. So they could, They could create a reshuffle, to their liking. That could benefit them.

Justin Traglia: Yeah, that's pretty much my understanding as well. CL clients, have you had a moment to look at this? I know it's just, like, very last minute. I'm curious to hear what you think about it. Justin Florentine, what do you mean by consensus over the shuffle?

Justin Florentine: I was just confused, I don't need to derail this, I'm just looking for some clarification from CL Devs. Essentially, I thought that there needed to be consensus over the result of the shuffle, but maybe I'm misunderstanding it.

Justin Traglia: I mean, there does need to be consensus. Yeah, this would be a breaking change. Consensus breaking change. Pawan, Pretty much, my understanding is that if a A proposer could slash themselves. At the end of an epoch to influence the next couple of epochs. of proposer selection. to like include themselves or different validators that they have. That would be proposed. Oh! I don't fully understand it either, like the details, but I'm just like, I've had time to look at it. I personally don't think that we're going to want to make this change, because it would very quickly break Sepolia, and we'd have to manage two different implementations of this if we don't want to do that.

And it's really just not… And to my opinion, in my opinion, my understanding is that This would be difficult to do, and with little benefit, and they would have to slash themselves. To even do it. So… My personal recommendation would be to wait for Hegota, and just fix it there as, like, a small Smart folks. Yep, thank you, Barnabas.

Barnabas Busa: Yeah, I'm not even sure if you want to fix it for Hegota. Like, this is a bit… Like, it's never really gonna happen, I feel like. And also, like, the benefit of fixing it is.

Justin Traglia: Yes, you can Nico. You can manipulate via the RANDAO. Yeah, I mean… I think we just need more time to think about this as well.

Barnabas Busa: Yeah, sure. But for sure, I would not push for Glamsterdam.

Justin Traglia: Yeah. Can we agree to this now, so that we can move forward? Is there anyone that would be supportive of doing this now in Glamsterdam. I know you haven't had that much time to think about it.

Barnabas Busa: Maybe we can make the final call on Thursday?

Justin Traglia: It might be too late to do it then, if client releases are expected to be… are expected before Friday.

Barnabas Busa: I mean, we would need to fix it only for Mainnet, no? Realistically. If you actually want to fix it.

Justin Traglia: I think if we need to make a call, the call should just be to push it to Hegota. If we want to do it.

Dustin Brody: There's also not, as far as just fix it for mainnet, that doesn't… work. It doesn't work because, at least for Nimbus, we do not have, and absolutely 100% do not want to start bifurcating, trifurcating, etc, our releases this way, though I know some CLs effectively do. A mainnet release or a Hoodi release, there's a Nimbus release, period. Done.

Barnabas Busa: Yeah, I mean, we would need to have a slashing event happen on one of the testnets for this to be triggered, and that would lead to a… A fork. So, assuming that there's no slashing… You could just throw out a new update on Sepolia nodes. And we could make sure that this doesn't get exploited. I know on Hoodi, this would not be the case, but Exactly. Like, I don't think there's a benefit in doing this in Amsterdam, because I think this would just cause more headache than. That benefit.

Justin Traglia: Yep, I agree. Okay, if we need to make a decision on that, I… let's just push it. To the next fork. Are we fine with that? All right. Cool. Let's move on. Jochem, can you discuss your thing about the minimum hardware requirements for Glamsterdam?

Jochem Brouwer: Yes. So this is about this EIP. So EIP 7870. And this EIP needs an update because we currently have a minimum reads write sequential speed of 500 megabytes per second. And if he… fork to Glamsterdam, then we are both increasing the contract code size from 24 to 64. We are increasing the gas limit from 60 to 200, and we are slightly increasing the gas cost to call an account from 2600 to 3000. Now you might ask, why are you discussing this here and not on the EL channel? The point is that we need to communicate this to the community. We need to update this EIP and there are basically two things how we can do this. This is currently a living EIP.

And… We can either change this EIP or we can create a new EIP for every fork so that it is clear what the minimum specs are for the fork. And there's also the question like how to what number we want to increase this. So let me share the at least in discussion. So that's also linked. This is on Discord, the discussion about this. And here is a draft EIP how we can, how we can, We could create this new EIP. So this is basically open. I think this is not a discussion or a decision what we can make today because I think this will lead to some discussion. But the main point is that we should update this EIP because the minimum specs as it is currently stated on this EIP, it is wrong.

And they should at least increase this from 500 megabyte to 1000 megabyte per second. But I would advise to go to 2000 megabytes per second. But currently these specs are clearly too low because with these specs, the worst glavScanBlock on the outside runs in eight seconds and that's simply too slow. So we should do something about this now and I would like to hear what people think. Like should we update this EIP or should we fork the EIP?

Justin Traglia: I would support updating the EIP so that it's a living document. Maria.

Maria Silva: Sorry, sorry, I was muted. I would also say, like. Just to be clear, I don't think this is just a question of, oh, we realize we have a bottleneck, and now we need to up the… up the specs. It's really… looking at the specs, they seem to be weirdly low, to a sense that it's hard to find machines that are actually that For performing. And so it's… it's not only about saying, like, yeah, without… like, these are the minimum specs because of the new EIP, but it's really, like, trying to get to what is the realistic specs that nodes today are running. And so in that case, it's not just let's update the minimum specs at every fork is more like, yeah, we now looked into this and it seems like it's strangely low, so we should update it. So I think this is also part of the rationale is not only about that we now realize this is a bottleneck.

But yeah, just wanted to add.

Justin Traglia: Ben?

Ben Adams: Yeah, just following up on Maria's point, the disk speed, Never existed for NVMEs, that's in the spec, so it's like a, it is a high-end SSD. But the spec also says that you need a NVMe eDrive. And even a four gig NVMe drive and that The low speed that's specified has never existed as an NVMe drive at 4 gigs.

Justin Traglia: Yep, that's right.

Dustin Brody: That said, I want to push back a little against this narrative of the specs being on 7870. I mean… For specifically IOPS or sequential or random reads, I have no strong view on that. I'll be honest. I've never looked into that or checked this, so I'm going to stipulate slash trust that everything everyone just said here is true. I will say, as far as a lot of the rest, that as far as, amount of disk capacity, well, disk capacity, but memory, CPU cores, and speed, those have actually struck me as, from the beginning, as crazy high. Now, I understand the rationale for this. I discussed this at the time with people, and I look, it's that, well, there's future hard forks, and we want to do this. Great.

But the point is for Ethereum as it existed then and Ethereum as it exists today, claiming that you need 64 gigabytes of memory to attest is absolutely 100% crazy. I'm sorry. And to say that those are too low and not realistic is no. We have to be, like… no.

Ben Adams: I don't know if we're trying to push up the, CPU and, memories. It's just the… The disk speed is crazy low.

Dustin Brody: That may be, and this is why I'm starting by stipulating that may be the case. But, like, I'm more responding to Maria's point and her more general narrative that she's trying to sell. Here.

Łukasz Rozmej: So,

Dustin Brody: Okay, I see.

Łukasz Rozmej: If I can chime in here for one thing, it's one thing to have, Something running on some relatively low-end hardware compared to the spec, because the average blocks are… really easy to run in practice. And there's a second thing that we… what we craft, the worst case block, so potential DOS attack vector block, and the… hardware we put in the EIP as a requirement has to handle the worst-case block, and that's the distinction. So, in practice, if you don't have an attack, you can get by by hardware that is Few times slower. At least. But if there were an attack, you potentially need this type of hardware to… then we can guarantee you will be able to handle the load fine, and don't even register it much.

Justin Traglia: Can we agree to…

Dustin Brody: Yeah.

Justin Traglia: I'm sorry you can go.

Dustin Brody: Sorry, I just wanted to acknowledge, Lukasz's point and say, yeah, that is, that is, that is a fair point, about, about the worst case blocks and, you know, we don't I haven't… on these SBCs and such, I haven't seen systematic testing of how they respond to that, so… sure. Rented.

Justin Traglia: jochem, to answer your question, recommended generally is above the minimum. The minimum will depend per client. is my understanding like Nimbus would have a lower hardware minimum than Teku. But can we agree to, raise the… Random read-write IOPS for… Oh. the recommended hardware requirements to something a bit more realistic.

Jochem Brouwer: Yeah, there's one more thing I want to add because I want to explain why I think we should have a minimum-specs EIP bare fork. This might sound like, okay, now you are creating like a lot of EIPs, but I think it is more clear in the communication. Because currently if clients or users which are not really were new to the ecosystem, they might want to add a node for Glamsterdam. They go to this EIP. And then they assume that the current specs are right. And. But… These are actually the specs for IGES Tech for Pectra and for Fusaka. But in Glamsterdam, we are seeing that some of the specs needs to get updated. So that's why.

this GantzNanFork would get their specific EIP for the new recommended specifications. Because otherwise, this document keeps to flip-flop around, and then it is not clear if this EIP is the minimum hardware… sorry, the recommended hardware specs for the current fork or for the next fork. So I think in communication it is more clear, but for now I'm fine with putting this into 7870.

Łukasz Rozmej: So I disagree a bit. I think if we have multiple EIPs with spec configurations, it will be even more confusing than having one. I would just, put the specifications for the… next future hard fork. We are scheduling that we know the the spec has to recommendations has to change asap and have a explicit history for previous hard forks in that EIP, and I would keep it as one just for simplicity, because now you will Google spec for Ethereum, and you will get multiple EIPs, and each of them would be… now you have to go through them, and if you don't go to the latest, do the older one link to the latest? It's too confusing. I would just keep it as one.

And if we know, for example, that, I don't know, Hegota needs a change, we should put it ASAP, that, okay, for Hegota, we have this requirement, so if you're building now a Prepare for Hegota, right? It should be the most far-seen thing we can actually define.

Justin Traglia: Yeah, I agree with that. Oh. Does anyone else want to say anything on this topic? Otherwise, we should move on. Pooja?

Pooja Ranjan: I just wanted to add on. What was just mentioned here, if we can prepare it for Hegota, perhaps for this upgrade as well, we can just start the section in the… present hardware EIP, and just mention specifically that all these are changes From Glamsterdam EIP, so we don't have to wait. Until next, we can update the EIP, and we can also preserve the history.

Justin Traglia: Yep. Okay. Thank you. Okay, let's move on to the next section. we need to discuss plans for the next Hegota devnets. Originally, I only planned on talking about this for the CL side, but we can do this for the EL side here as well. Since it affects both layers. For the CL side, I would like to propose the next, devnet be named FOCIL devnet 2. It includes FOCIL and all three of the currently CFI'd EIPs. is… To the CL clients. support this, or… Maybe not support this. What do you all think?

Pawan Dhananjay: Is it just about the naming, or something else?

Justin Traglia: I'm sorry, say that again? Just about the what?

Pawan Dhananjay: Is it just about the naming that you're asking or is it?

Justin Traglia: No, no, it's mostly about which EIPs to include in the devnet. That's the important bit. And I forgot to mention, I propose the devnet launch by October 28th. To give us enough time to implement these. Matthew?

Matthew Keil: Yes, I do support, so I'm assuming you're talking about, the… 0x00, closing the door to that, the ETH1 data and FOCIL, correct?

Justin Traglia: And quick slots.

Matthew Keil: And quick slots. And then, just a quick question on the naming. Why call it FOCIL devnet, and why not just call it Heze 0?

Justin Traglia: That's what I wanted to, but EthPandaOps said that it's sort of a pain in the butt to change it, so they would… They want to do FOCIL devnet 2. And then for the next upgrade cycle, start with like the ISTAR naming. Maybe EthPandaOps can talk more about this.

Barnabas Busa: I mean, we can… we can make the change, But then, what we would do is basically. Possibly to has a devnet to So that the indexing stay the same. I don't know if that's acceptable. It's really no storm.

Justin Traglia: Oops, there you go.

Barnabas Busa: Yeah, and then, basically, then the frames devnet would also be renamed for, Is it Bogota? Definitely.

Justin Traglia: Yeah, no strong opinions for me. Spencer, are you saying that 2 will be easier than 0? for the index. And I'm sorry, I wasn't looking at the comments. Yes, all three of those CFI'd EIPs. Matthew listed, including quick slots. And if, for whatever reason, clients are unable to, or they don't have enough time to get all of these in, I propose we leave the slot duration. To be 12 seconds. So… Sort of, it'd be an optional EIP at that point. But if we can test it locally in Kurtosis and see that, like, at least 3 clients support Different slot durations, then we could change it to 10 seconds in the dev net. Does that seem reasonable?

Barnabas Busa: Then why not just launch a bit earlier, like a week earlier, if it's optional anyway?

Justin Traglia: Greg.

Barnabas Busa: Every EIP is our first time. Like, I only… I wasn't dead, like, basically. I mean, we could…

Justin Traglia: We could launch as soon as, three clients have support for all of this.

Barnabas Busa: Yeah, I agree.

Justin Traglia: Okay. I saw some reactions, In support of this. Is there anyone that's against this?

Stefan Starflinger: I have a quick question, if I understood it correctly. So you want to change the name, but it's still only focused on the CL side, or you want to change it, and you want to combine CL and EL EIPs?

Justin Traglia: I would want it to be only focused on the CL side before I joined Hegota devnet.

Stefan Starflinger: Okay, and you don't want to have the headliner as the leading, kind of slug you want it to be? As a… instead.

Justin Traglia: I mean, yeah, that's what makes sense to me, but it doesn't really matter. It's just a name.

Stefan Starflinger: Yeah, I don't have a strong opinion on the name either.

Justin Traglia: Let's just do whatever's easiest for you guys now, is my opinion. And then, like, think more about it next time.

Barnabas Busa: So the only time I would do this if we also rename the frames devnet stuff, because we also kept adding some new EIPs there, so then that would become just, Bogota devnet 0, Bogota devnet 1. And then let's… let's just do the renaming there as well. And then, we basically going forward. We're not never gonna do like headliner, devnet specific. But we're gonna do maybe CFI, devnet specific, so, like, if we CFI a… a specific EIP, then… then we're gonna just call it that fork name, and that's zero. And then so frame devnet one will not happen. It just can be called Bogota devnet one. And then all the URLs we're gonna basically change to Bogota and Heze.

and so forth, and firms. But then please make sure that you're also running on your branches accordingly.

Justin Traglia: Alright, that sounds great to me, Barnabas, let's do that. I see lots of support for it in the comments. Okay, I… Sorry, I just want to give one more opportunity for CL Devs to… reject the proposal that I made. Is there anyone that thinks that this is not a good idea? Or that this is not possible for them. Alright, like the end of October. Justin Florentine, yeah, I mean, October 28th would be the latest, I would say. We need 3 clients by then. We don't need, it's just a goal. I mean, it's all arbitrary.

Jihoon Song: Just to be clear, we're talking about 12 seconds, right?

Justin Traglia: Yes. Unless, just… by, like, October 26th or something, 3 or more clients say that they have support for quick slots. That's production ready. Or, like, prototyping ready.

Dustin Brody: Nimbus is not likely to have that, I mean, that's actually sort of the key question for us. Right? But we're not going to be ready for quick slots in this time frame. The other stuff is harder to say. I mean, we've fossilized.

Barnabas Busa: That's why it would be optional. That's… that would be the point.

Dustin Brody: Well, but it's not optional if it's 10 seconds, or unless it starts at 10 seconds. So, no, that… this is… this is not…

Barnabas Busa: Functionality is not real.

Dustin Brody: all.

Barnabas Busa: The option, like, if we would be able to launch next week, we could keep it optional, but if we push it by 2 weeks, then I would say that at that time, everybody that wants to be participating should already have 10 seconds. capabilities to to adjust it. Yeah.

Dustin Brody: Okay, I mean, it's fine either way, but… Just… If it's the latter Nimbus is very likely not to join.

Justin Traglia: Can we agree?

Dustin Brody: Not more than 3 cards.

Justin Traglia: Can we agree now to just keep this slot duration the same for heze-devnet-2? And then just do local testing with Kurtosis with different slot durations, maybe. Jihoon?

Matthew Keil: Agreed.

Jihoon Song: Yeah, I think Teku also said that. They support for 12 seconds quick slots. Something wrong. In the chat.

Justin Traglia: I must have missed it, sorry. But this sounds good to me. I think we should just do this.

Barnabas Busa: But can still merge in the PR, right? For some times, that…

Justin Traglia: Into the specs.

Barnabas Busa: Yep.

Justin Traglia: I mean…

Barnabas Busa: Because we have a bunch of blockers on that, Pierre.

Justin Traglia: Yeah, June.

Barnabas Busa: To add the support, at least in the tooling side, so that next time when we're actually ready to change it, then… Yeah.

Jihoon Song: We're supposed to discuss it in the CL breakout, but… Speaking of which, maybe we can also decide on that.

Justin Traglia: Yeah, we should discuss it really quickly here. I mean, can we agree to just merge EIP8198 into Heze as soon as possible? As soon as all the tests and stuff work?

Barnabas Busa: So I think we have, like. Teku and Lodestar that have already implemented even the shorter slots, so… Like, we just need one more CL client to have three, and then we could even launch devnet.

Jihoon Song: Lighthouse, I believe. Yeah, so…

Barnabas Busa: telephone.

Jihoon Song: 3. Yeah, yeah. And then… indefinite to… With 12 seconds slot duration, we can also have Nimbus and… did I miss one more client? So we can add.

Barnabas Busa: looking forward.

Jihoon Song: 5 clients. Yeah.

Justin Traglia: Okay, sounds great. Any other comments on the CL side before moving on to the L side of this? Okay, great. Spencer, are you here to discuss the EL side of this, or… I'm not sure who… Wants to discuss this or lead this.

Spencer Taylor-Brown: Yeah, I mean, I think… I think on the EL, And… I think what the plan is to launch frames devnet one on Thursday. Is that still correct from the EthPandaOps side?

Barnabas Busa: It's not called Bogota, that's not wrong.

Stefan Starflinger: Yeah.

Spencer Taylor-Brown: Sorry. Yeah, we can do that.

Stefan Starflinger: How are the tests looking?

Spencer Taylor-Brown: Yeah, so, we released, a test release on Friday, but there are… There was one consensus. change that was merged in that I think we wanted to discuss in the EL breakout. to agree whether we want to add that to the devnet or not, but I think… yeah, so it's… And frames… keyed nonces, recent roots and transaction assertions in the new Bogota devnet. one. But yeah, maybe we can defer the… consensus breaking change to the EL breakout.

Stefan Starflinger: Sounds good.

Justin Traglia: Okay, is there anything else you guys would like to discuss on that topic? Or is that it?

Spencer Taylor-Brown: I guess I had a small kind of adjacent topic kind of around devnet planning. And I guess I wanted to ask. How do client teams feel about Potentially planning what goes into devnets. A bit further ahead than where we are now, so, like, maybe having, like, a devnet Plus to look ahead of what EIP should go in. I'm not saying we should do that for this fork, but maybe for… The process for the next works.

Justin Traglia: In general, in general, I'm supportive of planning ahead, but I acknowledge that it can be a bit Difficult to plan ahead. When it comes to, like, CFI'd EIPs. Like, for example, QuickSlots was only CFI. Like, last week, or two weeks ago. Dustin.

Dustin Brody: Oh, so yeah, and I want to specifically say, might maybe have a misunderstanding or misapprehension of the purpose, or what CFI is supposed to mean, but part of it is to see that it works, and I would say one risk of this kind of. planning pipelining is that it starts assuming outcomes we don't yet know for earlier devnets. I guess generically a risk with, you know, planning, but… This is, this is something I would be cautious about. Generically, and wonder… would want to see some payoff for…

Matthew Keil: It definitely feels like there's a push to bake in 10 seconds, or whatever that number is. And I think the whole point of CFI-ing how we did was to see how it works with the rest of… the other features, and I just… I'm… I fear we're gonna put the cart before the horse.

Spencer Taylor-Brown: Yeah, I guess I'd add, like, I feel like planning for this fork, it wouldn't… It wouldn't be ideal just where we are now, but for example, could we extend the process for the next fork so that when we have CFI'd all the EIPs. We immediately start going to this kind of. process of… What EIPs do we want in the next… three devnets, so that we kind of allow clients, client teams to work ahead. If the… if they are able to. And… I guess the whole point of this is, can we… Work in a way that helps us move faster and with less burnout.

Justin Traglia: Justin?

Justin Florentine: I think this is, well meant, and I think this is actually a viable thing to do, but I would love to make sure that we're super aware of interactions. So for instance, if we imagine a world where we just implement everything that's CFI, everything's feature flagged, and then we test it all and we decide which subset of that is going to get SFI'd, we have a nasty problem when it comes to interactions. Right? So I think FOCIL and Frames is a great example of one of the reasons we want to get them. you know, on a devnet quickly is because we expect those interactions. And because those interactions could be severe enough that it impacts capacity.

So we have a little bit of a circular issue in Ouroboros, if you will, that I think we need to maybe sort out before we head towards a world where we're more aggressive in including things that are CFI'd on devnets, so that we can determine whether or not, you know, they're effective later in the planning process.

Spencer Taylor-Brown: From my side, these are really good points, and sorry for bringing this up without putting it on the agenda, but maybe this is something we can discuss. To Mumbai. Yep.

Justin Traglia: Yeah, I like that idea as well. Okay, I think we need to move on from this and jump into the breakout calls. Any last comments before… doing so. Okay, I will share the link in just a second to the CL breakout call. Alright, I'm gonna hop in… I'm gonna hop to the other call. Bye, everyone.

Mario Vega: Hi, everyone. I don't see topics on the EL breakout agenda, but the topic will… so I guess we should just jump into the… straight into the topic that you mentioned, Spencer, regarding the specification change. It is not in the agenda, but I think we should just go into that.

Spencer Taylor-Brown: Yeah, no, sounds good. I was unmuted, sorry. Yeah, this PR, Do we want to add this to… No, not Frames devnet 1, but Bogota devnet 1. It's basically just the open question. And if, Clients are happy to do that. We will… Tag in a release, I guess, hopefully by the end of today. And then I guess the question is… Assuming we release by the end of today, is, are we still ready for… Launching a devnet on… Thursday.

Mario Vega: Just for context, could you list the EIPs that are included in this release?

Spencer Taylor-Brown: So, I keep unmuting and I get muted again. 8141. 8250. 8272, and then 7906. So that's frames… Keyed nonces, recent roots, and transaction assertions. And I believe ethrex and Nethermind are already passing. Our existing release that we released? On Friday? So, as far as I know, on the specs and tests, yeah, so we released released…

Add tests for all these EIPs. On Friday, the VE… Am I right? Just, like, tagged it there. And the only difference is, Essentially, that single EIP's. PR. We haven't included in that release. But yeah, we can add that really, really quickly, and… a tag of v1.1.0. But yeah, it seems like the feeling is… Yes, so maybe we should just do that.

Stefan Starflinger: I'm happy to look into, launching it on Thursday, and if clients have images for me to test, just ping me. I'm a little bit distracted with the shadow fork, but I'm happy to Also prioritize this.

Spencer Taylor-Brown: And I guess on the change, my understanding is that it's, that keyed nonces get, are added to the block access lists now. Is that, is that right? Toni, I think it's your change.

Toni Wahrstätter: And was that a recent PR? That you're referring to here?

Spencer Taylor-Brown: Yeah. Let me link it again in the chat.

Toni Wahrstätter: This was just a clarification, because the keyed nonces are just a system contract, so the nice thing is it's basically just regular state. And as every other piece of regular state, it would just be… In the BAL. And also. the EIP had a custom installation process. Basically, it inserted that contract at the state… at the fork transition. And this was also changed recently. And now it just uses Nick's method to deploy the contract before the fork. And… Yeah, so no edge cases with regards to BAL.

Mario Vega: Yeah, Guru.

Guruprasad Kamath: Yeah, but the way I understood it, there's also some updates to how the floor gas is calculated, so, there might be consensus Related changes to this, so… correct me if I'm wrong here, Toni, but So I think we'll need to need all clients to implement the changes as well.

Toni Wahrstätter: Yeah, yeah, because the keyed nonce is basically also a part of the transaction envelope, and with frame transactions, we put the floor gas pricing over the entire transaction envelope. So, doing frames, and doing frames and keyed nonces. Gives you different call data prices.

Mario Vega: Okay, so I think we need to double-check then, if this changes any of the tests, or we need to add more tests, and then v1.1.0 should be the one that we try to release today. Is that clear, for everyone? Spencer, does that sound good?

Spencer Taylor-Brown: Sounds good to me.

Mario Vega: Sounds good. Any questions regarding this topic, release, or the timeline?

Stefan Starflinger: Don't forget to rename your branches now.

Mario Vega: Yes, we also renamed the release, yes. Okay, it seems like this is, Okay, oh, Toni. is asking in the chat whether this is too early to start discussing next devnets. What is everybody's… opinion on that. Should we start today? I think, there was… there was an issue, right, Spencer, where you listed… the next… devnet's ideas. Let me see if I can find it so I can share it. Maybe we can start from that. I had it open and I lost it. Let me see. Oh, there it is.

Give me just one second. I think this is… this is everything that we have for next devnets, at least in terms of, like, a starting point. If you go into that issue Spencer listed. Well, what is now called Bogota devnet 1, and then Hegota devnet 0 through 3, and just tentative EIPs to add to each one of them. Of course, I don't think there's much opinion at the moment, but I feel like we could use this as a starting point, perhaps, and then decide on the next ACDTs. Does anybody feel like want to make the case for any specific EIPs that need to be present in the next devnet? Otherwise, my suggestion would be that we use this issue as a tracker, and maybe people can come and just state preferences, and then we can discuss them live in the next call.

Spencer Taylor-Brown: Yeah, at least from my side personally, I'd be interested to hear what other people want specifically and like researchers and client teams, because I think. And. Yeah, it. From my side, I think it was mostly… I tried to keep it kind of thematic, but then it Yeah, I mean, it's not really anything until we discuss, in my opinion, because I think it's good to… See where everyone else is at. And, like, maybe there are things that… . have not been, looked at clearly. I think one EIP that I would like I believe jochem would like it in as well, is, the 8253, the nonce bump. MEIP. Yeah, it seems important that we test this early on, given that the testing is surrounded mostly at the transition of of the fork.

I don't know if you want to say anything on that, Jochem.

Jochem Brouwer: Yes, so this EIP yeah, I just linked it. It's, it's behavior only happens at the fork, so if you want to test this, Then we want to test this on as many devnets as possible. And the other thing is that specifically for Stefan, we DM'd about this. that, for the devnet template, there should be these specific accounts into, the devnet template. So I will also open a PR for that. And… Yeah, let me also quickly link to the EIPs which I should merge because that clarifies how this Is stated on non-mainnet network, so we can also test on. Devnets. Yeah, I will link to things yet.

Spencer Taylor-Brown: PBS.

Maria Silva: I'm not sure…

Spencer Taylor-Brown: Go for it.

Maria Silva: Oh, I was going to say, I'm not sure if this will be true, but would adding DEACTIVATE self-destruct earlier on actually help with testing? Because it would remove some… Edge cases, or not really?

Spencer Taylor-Brown: I think it would, actually, yeah. Okay.

Maria Silva: Then even though it's not a very complex EIP, it makes sense to just add it. earlier.

Jochem Brouwer: Yeah. Okay. Then just for the record, then I also want to mention that if we indeed ship the DEACTIVATE self-destruct, then we also have to ship EIP-8360, so TCREATE. Because if you deactivate self-destruct, then, currently some patterns which use self-destruct will get economically, well. More expensive in Amsterdam, and if you also deactivate Delft self-destruct, then that actually removes this pattern, so we should also include EIP-8360, Maybe not in the next devnet, but prioritize it.

Mario Vega: Yeah, go for it, Justin.

Justin Florentine: I think, I think jochem's, point is correct, but a little orthogonal to Maria's. Does that make sense? Like, I don't know that we need to be testing TCreate or accelerating how we test TCreate the same way that we wanna do with self destruct.

Jochem Brouwer: Yeah, okay, that's actually a good point. I was more thinking about this as the perspective from The community, especially the ecosystem, how this might be perceived. So if we have a devnet with DEACTIVATE self-destruct and not TCREATE, then people might somewhat panic. But we can communicate it clearly. Yeah, okay, that's a good point, thanks.

Mario Vega: All right, another EIP that I see strong opinion or at least mentions in chat is SetCodeFrom. Do we have anyone who wants to make the point? To include this early? Yeah, Carlos.

CPerezz: Yeah, I mean, we have the tests. It's Mainly the only way that we have, to have some post-quantum migration, if needed, early. And Nethermind Geth already implemented the entire thing and are passing all of the tests in the EEST PR. And it would also allow us to test a lot more the integration with frames, which is… not trivial, I would say. So yeah, I think it would be good, but of course, if we prefer to test frames exhaustively by itself, I'm not gonna oppose, so to say. It's just that I think the earlier we start testing everything, the better.

Mario Vega: And lastly, from the chat, Spencer, you want to make a point. Which interactions do you mean specifically with FOCIL?

Spencer Taylor-Brown: Sorry, I guess maybe this is more a question for Equal on the Alps. at least my understanding right now is that we… we would have this, Bogota devnet 1, and then… Has the dev net to you? And then my assumption is that these two devnets will be merged into a Hegota devnet 0. So that we can test, like, the FOCIL frames interactions. And then after that, it adds. Cool, okay, yeah, I think it's good that we're looking ahead, I think planning is good, but I guess I want to make sure that we… To me, it makes sense that we prioritize Testing that, yeah, that's… yeah.

Mario Vega: Stefan, do you want to make a point or?

Stefan Starflinger: No, just… that's, spot on, I think. From my perspective, it makes sense to first Get the features, to work somewhat stable, to test the main, edge cases, the obvious ones, and then to. see how the interactions will affect each of those EIPs when we have both CL and EL. I think it would slow us down if we… Had a mixed network too early, because then it's, harder to find, issues, and then to, contribute them back to testing.

Mario Vega: Okay,

Stefan Starflinger: doesn't.

Mario Vega: Sorry.

Stefan Starflinger: Or was there still something open?

Mario Vega: I think the main, the main… I mean, maybe we don't have to get to a conclusion today, but just to have, like, a clear idea of what the next devnet would look like, I don't think we're gonna find the answer today. My proposal would be that we keep, We list the comments that were raised today in this tracker. And then please come to the tracker, and we will try to reach to a conclusion on the next call, but please leave your comments in this issue. Perhaps we can… we can use it to get to, or formalize the discussion somehow.

Stefan Starflinger: Sounds good. I'm not sure if we've created a spec sheet yet. I will also look into that. for the devnet.

Mario Vega: All right. Cool. Any other comments on this? If not, I think we can close it, today. We're gonna keep the discussion going for the next call. Thanks, everyone, for, raising the points today. I think it was very, very fruitful. Cool.

Jochem Brouwer: Thanks, all.

Mario Vega: Thank you everyone. Bye-bye. Goodbye.

Łukasz Rozmej: Bye.

Marcos | Nethermind: Bye, guys.

CPerezz: Cheers.

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