All Core Devs - Execution #220

Transcript

Alex Stokes: Hello.

Tim Beiko: I don't know.

Okay, Josh, you want to move us to the livestream?

Josh Davis: You are alive.

Tim Beiko: Thank you. Welcome, everyone, to ACDE number 220. Couple things on the agenda today, As, yeah, as always, we're going to talk about Fusaka, some updates on the DevNets, and then we can follow up on, this thread around, the scheduling of the different testnets. Wanted to make some space if there's any updates on Glamsterdam with regards to, the progress on the headliners, so EPBS and block access lists. And then, the testing and specs team from the EL side, are working on merging the two repos, so they wanted to discuss the implications of that. And to wrap up, we have a bunch of EIPs, that people wanted to discuss, so we can, can go through those. Also, as a quick heads up, I'll be, on leave starting at the end of this month, and so from,

not next call, but the ACDE after that, AMSGAR will be chairing until the end of the year, so, yeah, we will… we will be stuck with him for several months. Just kidding, but, yeah, thanks, Oscar, for stepping in. To kick us off, I don't know if Barnabas or Perry wants to give an update on the state of Fusaka Devnitz?

Parithosh Jayanthi: Yeah, I can give us an update today. So we have Fusaka DevNet 3 running for the last couple of weeks now, and we did another round of non-finality testing. The DevNet was… left in the non-finalizing mode for a couple of days, and then we healed it yesterday. Participation rates went up, up until 62-ish percent, and then back down to 50-something. While looking into it, it doesn't… seem to be purely Fusaka-related. There's about 8-ish death instances that complain about new payload V4s, which seems completely unrelated to Fusaka, and would probably help with finality. I've pinged the team, and I guess they're investigating it, but we don't have too much more there. On interrupt, there's also a recovery summary thread, so have a look at the thread. It mentions which instances are how far away from head, and it would be nice if client teams can, start looking at their instances and figuring out what the remainder of the issues are, but in general, stuff seems to be progressing, and

Yeah, good job there. Okay, cool, GET apparently has a PR, and I can apply it soon and see how that goes. The other piece of testing information is we have DevNet 5 up and running. I can share the link in the chat. Note that we have, when you try to SSH in from now on, we have a SRV prefix after the server name, so it would be, for example, lighthouseNethermind1.srv.fusaka.5, and so on. It's just, it's for our new DNS setup, so that we can handle more nodes. This will be the format we use going forward, so it is a breaking change, so please update scripts, whatever. you're using. We're at 99.5% participation. The remaining 400 validators are just validators we have to use at exits and for, some other actions, and we plan to do those once we're at, like, epoch 256, or closer to the FUDU

transition, so that we can make sure that the queues are full during the transition. But yeah, we have the Mav stack running, and the plan is that there's one BPO that happens roughly every day, and in each day, the MEV stack will be running with withholding blobs for 12 hours, and for the remaining 12 hours, it'll be without the Mav stack. So we should have 12 hours of data for each set. times 5 pieces of data sets, and by next week, we should have everything ready for the analysis. There's a Fusaka analysis doc that, Sam has shared in a thread on Interop. I've tagged all the EL and CL teams on there to have a look. I can paste another link here, and this will specify everything we're gonna look at for the demo. So we have scripts ready, it should be a quick analysis once the data's there.

Does anyone have any questions? Okay, then I guess that's it from my side.

Tim Beiko: Nice, and so we'll have, by next week, we'll have done… most of the VPOs are at least half, correct?

Parithosh Jayanthi: Exactly, so 5 days from now, the last BPO goes live, or yeah, roughly 6 days from now, the last BPO goes live, but we should already… so the scripts are ready, and we'll be running them as and when a BPO is done, so that we don't have to wait for the last one to do, like, a mega-analysis.

Tim Beiko: Yeah, and there's a comment saying that we skipped over waiting for the other three to get back to finality, so, Yeah, I guess we launched it at 5 in parallel to fixing them at 3. Is there a risk that some of the issues from .NET 3 kind of… show up again, or, are you also updating the images on DevNet 5 as you get new ones?

Parithosh Jayanthi: We're also updating the images on DevNet 5, but as far as we know, we don't have any broken images right now, besides the getFix that we will apply.

Tim Beiko: Got it. They needed her… comments or questions about the VED5? Oh, so it's saying it should take more than a day to restore finality?

Parithosh Jayanthi: It's been roughly a day now. Part of the issues that we probably would have finalized already had those 8-ish instances been online, so… I don't think it's fully related to just Fusaka.

Lightclient (Matt Garnett): I'm just trying to figure out, because… You started at, like, 2 AM. Yesterday? Like, what's the expected time to recover for this?

Parithosh Jayanthi: With four-ish days of non-finality and half the network, I'd imagine in about a day, the network should recover?

Lightclient (Matt Garnett): Okay.

Tim Beiko: Any other questions? And so, I guess, just to be clear then, the expectation is DevNet 5 should go relatively smoothly, and Unless there's any issues that come up that we didn't anticipate, it would be the last testnet before moving to testnet deployments. Is everyone on the same page about this?

Parithosh Jayanthi: And the only other thing to mention is that DevNet 5 will go down once all the data's been collected, but DevNet 3 will continue to run. So we can continue to do another round of non-finality testing, we can do all the tests we want. And the benefit of DevNet3 is that since it's been up for a while now, the state continues to pick… Get bigger, and yeah, it's a nicer location for testing.

Tim Beiko: Nice.

Parithosh Jayanthi: Oh, there was also one more, update. So, Barnabas has been looking into ShadowFox, and was able to do a local, Holsky ShadowFock. Once clients start making releases, or indicate that they have all of their PRs merged in, we'd also do a ShadowFock before. Holsky and before all the testnets.

Tim Beiko: Got it. And there's another comment about Lighthouse, getting bad responses from Get Blobs around the transition. I don't know if anyone from Lighthouse is here to discuss this. Okay, any… other ELs want to chime in beyond get?

Lightclient (Matt Garnett): How do other ELs deal with the conversion of, like, the legacy quobs at the fork boundary?

Tim Beiko: So… Not converting.

Parithosh Jayanthi: Yeah, I think when we had the discussion earlier, all the clients said that they would just drop, and Gets wanted to do the conversion.

Lightclient (Matt Garnett): Do we have any, like, reorgs over the fork boundary? Because you might get a situation where you… Re-inject legacy blobs into the pool. You would either want to ban it at the pool, or you would want to ban it at the block building. Or maybe that just goes through the same logic that you already have to drop them. That's true.

Tim Beiko: It seems like it gets filled out at the block building level. And then the transaction pool gets cleared on the fork. Is this… is this what GET does, or… No.

Lightclient (Matt Garnett): I mean, we were planning to convert them. But if everybody else is dropping, then we might consider this.

Tim Beiko: Okay. No, yes, yeah, just can look into it. Is there a… like, I guess, when would you want to make this change, and when… Is this something you want to test on .NET 5?

Lightclient (Matt Garnett): Is that for me?

Tim Beiko: Yeah, yeah, yeah.

Lightclient (Matt Garnett): Okay.

Tim Beiko: like…

Lightclient (Matt Garnett): Yeah, I mean, we're actively, like, looking into this right now, so I honestly don't know if we'll continue down this path of conversion. That was the original plan, was to start a thread to convert the legacy transactions The legacy sidecars at the transition. So… If everybody else is not doing that, it's definitely easier to just drop them. We need to understand the ramifications, but… That obviously seems great, and we'll either test it on DevNet5, or we'll test it on the test nodes.

Tim Beiko: Got it. Anything else on… Fusaka deployments? Okay, so there's a comment about the timeline in the chat. Before we get into the Fusaka-specific timelines, like, I wanted to bring up this PR about the process, so we've talked about this a couple times in the past few calls. Basically, after the picture issues, we, we put together this process, for deployment, and then, we'd never kind of ironed out the details around the testnets. We kind of said we would get back to them and never did. So we were stuck with the, like, 30 days that was there as a placeholder as the default. So we, yeah, reached out to a bunch of L2's info providers to try to get some feedback, and I guess there's…

a couple points that would be good to align on today, so we can agree on the process and then figure out what we do at Fusaka. The first is, do we care about Heleshky? Like, and, you know, do we actually want to consider this as part of the, part of the rollout schedule, given that the testnet is, being deprecated? So, you know, it probably doesn't make a ton of sense to wait for 30 days. The second is, what's the delay we actually want between the first testnet? Like, first quote-unquote supported testnet, and, and… And, the client releases, it seems like two weeks is kind of the bare minimum that people would be okay with, but it might be a bit short in some cases. And then the third point is, whether we're comfortable setting a block or slot for mainnet before we've seen all the testnet forks.

Reason for this is that, When Petra went wrong, we kind of already set these, and then, had to change them, because there were issues for the testnets, so we may prefer to wait until the actual testnets have all forked. some proposals I've heard, like, in the last week, speaking to people, is, like, maybe Alesh key can be done quite quickly after the client releases, so, you know, one to two weeks, but then potentially having a longer delay before we go to Sepolia, so something on the order of maybe more like 2-3 weeks, and then having 2 weeks before Houdi. Yeah, it would be good to agree on this. kind of today, and then, I don't think we should set a date for Fusaka today, because we still don't know how DevNet 5 has gone, but assuming everything goes right, in the next week with DevNet 5, by ACDC next week, we should be in a good spot to, to set dates.

But yeah, maybe to start with, like, Holeski, like. would people feel comfortable having, like, one week between the releases and Holeshki, or two weeks, or what's, like, the right amount of time there?

Alex Stokes: just given the state of it, it doesn't seem like we need a ton of time, and I'm not sure… like, there are very valid concerns for infrastructure providers and everyone for the other, testnets, but for Heleshky, I'm not even sure they're still following that closely, so… This one is kind of a freebie. I think we can move a bit faster. But yeah, I'd love to hear what other people think. Like, if we said client releases, and then a week later, Dukeski, is that enough time to actually get the releases out?

Tim Beiko: Seems like there's some weak agreement in the chat, but… Yeah, so… Well, James, I guess, yeah, maybe, okay, to start from the… from this, like, how long until client releases? Assuming everything went well with DevNet 5, would client… and we, we, like, agreed on fork blocks, say, for, like, testnets next week, Can clients put out releases in, like, one or two days after that? Like, is it realistic to have testnet releases out, you know, say, by the Monday end of day, the 22nd? like I said, does any team have an issue with that? So, like, assume… again.

Assume everything goes right to the testnets. whenever we pick the call, or whenever we have the ACD, we agree on the blocks, then, Ideally, by, like, the Monday after that, we have a race with those. and so this means that, like, yes, assuming this was next week, we aim to have releases by the 22nd, so we would fork Oleshki on the week of the 29th, whenever there's, like, a nice, epoch boundary, circle accumulator boundary block. So, okay, so then, does anyone… it seems like people are fine with pretty minimal for the ski, so we could do, like, a week. between announcing and forking Holeski, Then, I guess the question is, how much time do we want before Sepolia? And…

you know, do we want some gap of time between Holeshki and Sepolia? One proposal could be to say we want, like, two weeks between testnets, so we… if we do Holeshki, you know, one week after the releases, maybe we do Sepolia two weeks after that. So this gives us Sepolia 3 weeks out, which is… More than, kind of, this, this, bare minimum that, two weeks that, that teams seem to want, and gives us time in case something goes very wrong, to, like, put out new releases. and then Stokes is saying he would prefer one week between Holeshki and Sepolia rather than two, so… Yes.

Alex Stokes: Because that still gives us the two weeks following the protocol. The process upgrade, I mean, document. in between tests, or, yeah, testnet releases and the first, quote, testnet. So we're kind of saying Halezky is… not a real testnet in this sense, which I think people generally agree with that assessment, so… That would be the logic.

Tim Beiko: Did people think that's too quick, or that's fine? I want a few days of silk release, but after release, one week sounds reasonable for Holeshki. When we can find, as long as we're not doing non-finalization testing. So yes, on the testnets, we were not doing that. Okay, so all these teams that are saying, though, one week is enough time to push a release. We just said earlier. is 2 days enough lead time to push for release? So, like, assuming that on… Alcore devs, we pick the blocks, if we pick Holeshki. and Sipolia, is it realistic to have those in the same release, or do people want separate releases for Holeshki and Sipolia?

Okay, so same… So… so yeah, so assuming we did this next week, this would look like… we… finalize the blocks on the 18th. The releases are out by the 22nd. On the week of the 29th, Holeshky Forks. And then… On the week of the 6th, on the week of the… of the 6th, potentially, we fork… we would fork, Sepolia. And that would be one week between the testnets. If we wanted two weeks. between the testnets and, like, 3 weeks between the release, then it would be forking Sipoly on the week of the 13th. So, yeah. Do people have a strong preference between one or two weeks between the Holeshky and Sepolia.

So… At the community level, if… I mean, I posted in… I posted this trend in the chat here, but I think 2 weeks is kind of the minimum that people want to see between a client release and quote-unquote real testnet. Some teams are, like, more on the… trying to get this as soon as possible side. Some would prefer more… more time. And then… yeah, Hudi… I think this is pretty clear, though, like, when we're onto real testnets, we should probably wait two weeks between them. So, like, yeah, Hootie would happen two weeks after?

Alex Stokes: Do you accept for Sepolio, you mean?

Tim Beiko: Yeah.

Alex Stokes: Yeah, okay.

Tim Beiko: Yeah, so, like, between production death notes, I think everyone agrees we should have two weeks. I think between… like, the releases and mainnet, everyone agrees we should have one month. The question is between the first releases and the first testnet, you know, do we want this two weeks, okay? And… And how do we count Hudi? Okay, so I guess, I don't know, if there's… It doesn't seem like there's super strong preferences, like… Are people comfortable doing one week between Houdi and Sepolia?

If so, we can move forward with that. the… I guess the downside of doing this is if we find any new issue on Paleshi that we… don't… Then we'll need to, like, put out new releases that move the blocks, you know, pretty quickly before Sepolia goes live, but… If things deploy smoothly, then we save a week. Yeah. Okay, like Plant is saying, we should do two weeks. How do other time teams fail between them? one and two weeks Okay, seems like 2 weeks is the… the support. So two weeks… one thing that's nice with two weeks is, like, the three testnets are kind of all the same, so we have…

client releases, two weeks after we have Holeshki, 2 weeks after we have Sepolia, 2 weeks after we have Cody, Okay, there seems to be some support for that, so… Does anyone feel strongly about one week? Otherwise, I think we just stick to two weeks. And this makes it also easy to just merge the changes, where I think we would just agree that any testnet Any testnet should just be two weeks after the releases, and make that the kind of official process. And then in this case, we kind of get a deprecated testnet as the first one. And then… Okay, so last point on the, on the process doc, then, is, do we… when do we want to set mainnet blocks? So do we want to wait until Houdi has forked successfully before we set a mainnet block, so that we don't have to change it? I think we can agree, like, we want to do a single release with all the client, or all the testnet blocks,

But before we, before we, have the mainnet block set, do we want to see who the Yeah, do you want to see who the, go live?

Alex Stokes: I mean, this is what we had in the document, and it was there, at least for a good reason in the context of Pictra.

Tim Beiko: Yeah. Okay, so I think we… yeah.

Alex Stokes: Yeah, we also have time to reevaluate this, you know, in a few weeks from now.

Tim Beiko: Yep. Okay, so, like, the default to just setting the block once Foodie goes live, yep. So then, just to make sure we're all on the same page, whenever we're happy with DevNet 5, and, you know, things look smooth. which is at the earliest next week. We can then, we can then pick some blocks where Holushki would be 2 weeks after when we expect to get client releases, and then Sepolia 2 weeks after that, Houdi 2 weeks after that. then once Houdee has, once Houdee has, like, safely upgraded, we would, We would pick blocks for mainnet and have a month between those blocks and the actual upgrade going live. Okay. And I'll get the PR merged, that kind of reflects all this later today.

Anything else on Sepolia? I'm sorry, on Sepul, yeah, on Fusaka? Okay, then for Glamsterdam, I wanted to check in if there were any updates on block access lists or EPVS people wanted to cover on this call.

Toni Wahrstätter: Yeah, I can… I can provide a quick update on what we discussed on yesterday's blocked access list call. We mainly discussed one proposal, basically. Right now, the bulk club access list contains, like, transaction indices for all the changes, so every time we have a diff, like a non-diff or a storage diff. balance diff, and so on. There is a transaction index mapped to that div. And we currently don't do that for everything that is only touched. So for S-loads, for balance opcode. call opcode, and so on. Everything that is just touched is included in the block club access list, so not the value, but the fact that it's touched, so the address and the storage slot.

And we currently don't map it to transaction indices. And it came up that it might be valuable for provers, or for, parallel execution. If we actually include the transaction indices for that. So, this was… this topic was not fully resolved, I would say. It's a rather small change, so, it's not, like, problematic that we are still discussing this, but we might want to, yeah, discuss it again in the next breakout call, which happens in two weeks, Wednesday, 2PM DTC. So everyone who has an opinion on that, please be there. And we also discussed, like, timelines for a first, DevNet. And it looks like, by the end of month, we should be ready to go.

Tim Beiko: Okay, thank you. Karen said that there's a BPVS breakout on Friday. Anything you want to share? on that?

Terence Tsao: Well, I would just say join the breakout call. I mean, like, we're actively working on the SPAC, and the SPAC test, and finalizing the scope for Death End Zero, which is end of October. So yeah, if any client's implementing EPBS, I would highly encourage, join the breakout call.

Tim Beiko: Thanks! Okay, from the chat, it seems like there's confusion about the test timeline, so I want to make sure we actually get this right. So we said one week between Holeshki and the client releases, because the SNS is deprecated. then… I thought we agreed to 2 weeks after Poleski before Seppolya, but Alex thinks it's.

Alex Stokes: Yeah, I thought that was one, but maybe I misunderstood.

Tim Beiko: Yeah, I don't know, like, yeah, like, client Justin and… or the people who, like, plus one, like. when you say 2 weeks, you mean two weeks between Holeshky and Sepolia, correct?

Justin Florentine: Yes. Two weeks… two weeks for all the, downstream testnets.

Alex Stokes: Okay, I feel like we said we're, like, Kolushki was kind of a pseudo-testnet in this case, and so then… you still have the two weeks between releases and Sepolia. But, again, if everyone is clear on the other thing, then… I will not push back on that.

Tim Beiko: Yeah, I guess… yeah, just to be clear, that's what people wanted, right? Like, so… One week before the end-of-life testnet. After that testnet goes live, 2 weeks before the next testnet, and then 2 weeks, like, 2 weeks between all the, quote, real testnets.

Justin Florentine: Yes, and I would also make the argument that it might be worth doing 2 weeks on an end-of-life testnet, because it gives you more time to actively abuse it, but I'll leave that to, our testers to think about.

Tim Beiko: Well, we would have 2 weeks. Between… so, okay, so sorry. So, we have the client releases. then there's one week, then Holeshky Forks. then there's 2 weeks where we can do whatever on Holeshki, and then Sepolia forks. And then there's 2 weeks. And then a HUDI fork. So every testnet, we would get the same amount of time on before the next testnet forks. The only difference is that there's less time between the initial client releases and the Holeshki fork. And this means less time for people to upgrade their nodes, we control still the majority of the nodes on the Holeshki, I believe, so, you know, it's like a very small set of people that actually have to upgrade their nodes for the hard fork to work. But if we leave two weeks between Koleshki and Sepolia, we do see as much data on Holeshki as on the other testnets.

Justin Florentine: Alright, Stan corrected, and that sounds great.

Tim Beiko: Okay. Does anyone… Not like this plan. Okay. Actual last call, before we move on, and then… yeah, I'll make this as clear as I can in the PR after this call. Okay. So, yes. Two weeks after Holeshki. Last call. Okay.

Okay, sweet, sorry, so back on track, The, steel team has been working on merging the testing and specs repos. The name The Merge was already taken, so they've called this the Weld. And they want to chat a bit about the implications of that. Yeah, so I will hand off the floor to Dan.

Danceratopz: Hey everyone, how's it going? It's Dan here from the Steel Team. Yeah, basically, the message is pretty simple. Hope you can see my screen, by the way.

Jochem Brouwer: Yeah, we can.

Danceratopz: Perfect. The mesh is pretty simple, so basically, at the moment, we have two repositories, and, after the weld. they're going to be one. So basically, all the code, and that means all the Python test source code, all the test frameworks, so the test vector generation framework, but also the Hive simulators and all the tooling around that, that now lives in spec tests, will move to execution specs, leaving us with one repository afterwards. The timeline's a little bit vague, it won't… probably won't happen in September, so it's gonna be Q4 2025. And that's basically because the priority remains for us, obviously, for Saka, Glamsterdam, and scale, the L1. So why the weld? I mean, it's pretty intuitive that specs and tests, belong together, especially for the same features.

And the current status quo is we have two repositories, and the tests speak to the specs through another tool called the Resolver, which obfuscates quite a lot of the communication. So, the aim is really to provide better developer experience for spec implementers and test contributors. So there'll only be one clone afterwards, you don't have to worry about two configurations, and then configuring one repo to talk to the other. There'll be no more version compatibilities between the specs and the tests. And test coverage becomes extremely simple, just a simple command line. And another nice advantage is that because we lose this resolver, we can drop straight from running test code into the spec. In a debugger.

So, what changes for developers? So for spec devs, so what's the situation right now? For spec devs, basically, you make PRs and specs, and for test devs, you make PRs into tests. And client devs currently download releases from executions by tests. And after the weld, to be honest, not that much changes. For SpecDevs, they continue as before, but they have their tests. Test devs… now they direct their PRs to execution specs, and we will still publish the client devs, we will still publish our releases on execution spec tests as tarballs, so basically there's no change for client devs. They don't need to worry. And update their CIs for that. So, we really hope that this will go through with minimal disruption,

It should actually only really affect East contributors, so to the tests, Obviously, we'll have to close, hopefully merge, all the pending PRs in the test repo. We will allow for a small time where we won't try not to accept any external contributions while we do a little bit of cleanup. The main reason is due to line length change, we just don't really want people opening PR straight away and then having to rebase venue PR immediately, that just seems a bit pointless, so there will be a little freeze, but it won't be very long. And then afterwards, testers can then direct their PRs to execute and spec tests, and continue with the same tooling as before, so it should be quite seamless, but they'll just have a better developer experience.

So, There's more details on the blog, if you want to understand a little bit about the architecture now and why that's so cumbersome. But basically, we… we hope this will be a big win, for… for EIP authors who want to spec out their, their EIPs. And, you know, they'll just be able to more seamlessly and more quickly work with our tooling. So we hope it's a big win. For… for the ecosystem. That's about it. If there's any questions…

Tim Beiko: Thank you. Sounds exciting. Any questions? If people do have questions, after this call, like, when's the right… where's the right place to ping you? Is it just on the testing channel, on Discord, or somewhere else?

Danceratopz: EF R&D is fine, and the EL testing channel probably makes the most sense. Yup.

Tim Beiko: Okay, sounds great.

Danceratopz: Excellent.

Tim Beiko: Thanks, Sam. Oh, yeah, there is an access issue on the slide, so probably need to change the permissions there.

Danceratopz: Oh, let me phase that up, sorry.

Tim Beiko: Great. Okay, so last thing we had on the agenda today were a bunch of different EIPs people wanted to bring up. Again, we're not going to discuss inclusions at the fork for this, but hopefully we can give some context and answer some questions and, yeah, go through some of them. These first two, I'm actually not sure if the author is on the call, but, wanted to at least point out, EIP7932 and 79 Ailey, the champion created a nice Eighth Magicians thread for people to review async. Yeah, I'm not sure if they're on the call, or if anyone else on the call wanted to discuss anything about these EIPs. Oh, yeah, Dana?

Danno Ferrin: I have two questions, but these might be better for the, ETH Magician thread. The first one, is about the structure of the transaction. Is SSV… SSV going to be a blocker to it, or are people generally open to the idea of, the structure of it, if it were expressed in RLP, would it be more palatable, but if the author's not here, it's probably not the right time. But my second concern is about the proposed ED25519 signature. It is not a quantum-resistant signature, and I do not think it's wise for us to spend time and effort adding new signatures that are not quantum resistant to… Meet the post-quantum cryptography standards.

Tim Beiko: Thanks. Anyone else have thoughts, comments on this? Yeah, Felix?

Felix Lange: Yeah, I would also say that, this… It kind of seems like if we're gonna add support for one more, like, specific elliptic curve in transaction signatures. It will be much wiser to spend the bandwidth we have to just enable Like, a current abstraction or things like that. Because… Bifurcating on the… number of, like, elliptic curves we support is not a… I don't think it's a good use of… It makes no difference, basically.

Tim Beiko: Got it, thanks. Oh, yeah. Is that Elkin?

Danno Ferrin: How about non-elliptic curve algorithms, like, say, Falcon or Dilithium? Should we be bringing in precompiles for those? I see there was a couple of old EIPs about it that got closed for stagnant, but if one of those were to be revived, would you be, amenable to bringing those in in a Glancer time frame?

Tim Beiko: Is that a question for Felix?

Danno Ferrin: Felix, or any other core dev that wants to answer?

Felix Lange: I'm sorry, I did not fully understand the question.

Danno Ferrin: So, Are you against bringing in new signatures in general, or just the elliptic curve ones? For example, there is, A couple of EIPs that were proposing Falcon, which is a post-quantum signature algorithm. If one of those were revived, would you be okay with bringing that in as a pre-compile?

Felix Lange: That's something I'm actually working on right now, but I want to see if there's any problems in advance of doing that. I mean, so, I mean, I… the way I understood the proposed EIP is that it is not just specifically about this, about this type of signature, it is… trying to… somehow create a framework for introducing more signature types as precompiles, but also as transaction signatures, so that part. And, I mean. Maybe it's a step in the right direction in some way, that someone is trying to tackle this by saying, yeah, the basic protocols should support different types of signatures. I mean, this is a big step for Ethereum to just, you know, start this at all, but we always, so far, like.

Had this… had it in mind that We will just keep working on account abstraction until we get it to work, and then this is gonna fix this issue, because nobody will be signing… Transactions anymore in the, like, Traditional way, sort of. And then… The danger with adding… I mean, with precompiles, in some way, it is, like, the policy has always been, right, that we can add specific cryptographic operations as precompiles, and in the next fork in Osaka, we are adding the SECP256R one, finally, after a long time, so I feel that Adding precompiles is never the issue, even for elliptic curve. someone has to propose it, and a good case has to be made for it, and the gas calculation has to be justifiable, but then, like, adding precompiles is… is basically always fine. Changing the transaction signatures is…

It's just basically never been done. So that's why, like, any new proposed transaction signature scheme is gonna face the question of, should we do it at all, because it's just not been done before. And the… you know, there's some couple other uses of signatures. Now, for example, we have the 7702 delegations, and… I mean, it just opens the floor to all these questions, like… I mean, so far, the definition of an Ethereum account is, like, it's… It's just the hash of the… key on this curve. So, what's… how does this change when we introduce different curves for transaction signatures like this? All these questions, and these questions just… they need an answer, yeah, but it's not…

It's gonna be a long way.

Danno Ferrin: So, we are kind of working against a somewhat artificial deadline. Whether or not you believe post-quantum computers are going to happen in the next 5 or 10 years. The NFT in the financial task forces. that, are supporting transactions like this are saying that we need to get rid of… we need to deprecate ECDSA by 2030, and we shouldn't be using them by 2035. So there is kind of a deadline. We can't just keep tooting forever on account abstraction. We need to get some workable solution. And given that the speed things work, we should probably be starting now.

Felix Lange: Yeah, but I think in that case, the easiest way, like, I'm not the best person to answer this, but from my personal view, I would say that, like, we should choose one specific post-quantum candidate and focus on that, and not try to introduce a generic framework for assigning transactions. Just basically define just use a PQ and algorithm, and then really try to make everything work with that. Like, that would be my personal opinion. way, too. approaches.

Tim Beiko: Okay, just because we have a bunch of other EIPs, to cover, maybe to Carl, Antonio, and Justin, and then we'll move on to the other ones. But yeah, Carl.

Carl Beekhuizen: Correct, yeah, I, like, for the Edwards curve, I think with R1 and… trying to move over, potentially, to post-quantum signatures, or what the timelines mentioned, then yeah, I'm not so sure it makes sense. But that we… we should be open to re… rehashing this in the future, for the, quantum signature schemes. I think more the issue here is, like, picking the specific one. Like, we can pick things today which are, like, easy to go with, and we are, like, pretty confident or secure. The concern is just we end up catch-tracking ourselves again. Or something similar. And it would be great if we can avoid that. I don't think there's, like, a huge deadline, like. We can still ship

this later, and we're not, like, confined to being able to, like, we have to ship this now, because otherwise people aren't going to be able to change in time, and those kinds of things.

Tim Beiko: Thanks, Antonio.

Antonio Sanso: Yep, just, like, checking people are aware of the fact that we are working on some Falcon EIPs. To be proposed, I don't know, for which, actually, hard fork. And, if someone is interested, I kind of wrote, three articles, the beginning of the year, where it motivates why Falcon was actually chosen. and what the future is… looks like from our perspective. That's… that's about it.

Tim Beiko: Thanks. Yeah, if you can post the link, that would be great.

Antonio Sanso: Okay, I'll put them on the chat.

Tim Beiko: Thank you. And Justin.

Justin Florentine: I'd like to maybe say that we should prioritize the ability to abstract out the signatures from the transactions earlier in our process, rather than later, because regardless of what new signature scheme we go to, the contract, I'm using scare quotes here, with that signature algorithm could change. So, for instance, if you have an algorithm that doesn't have an easy EC Recover to get the public key back from the signature, you now have to design an abstraction that includes some way of signing over that, to verify it. So, there are some… almost schema questions that we need to resolve fairly early, In order to adopt a wider range of these signatures.

Tim Beiko: Thanks. Okay, let's move on to, the next set of EIPs. So, Tony had two EIPs he wanted to bring up, EIP 7976 and 7981. Yeah. Tony, please.

Toni Wahrstätter: Yeah, just some quick context on those two EIPs. Both of them tackle the worst-case block size. We already reduced the worst-case block size quite effectively in Pectra. With 7623, and the first EIP would basically just, raise the floor cost, so this is, like, a constant change from 10 to 15, which would mean, the worst-case block size would be further decreased by 33%. And around 1.5% of the transactions will be affected. So we already had some factor transactions, I think it was, like, 0.9. With 7623, and now this would increase slightly, but it's still, like, a very big, worst-case block size reduction. for only very few users being affected, those that use a lot of call data. And the other AAP is proposing to

put a data cost on top of 2930 access lists. So right now, we price access lists only for their storage, and… This led to the situation where access lists can be used today to create the worst case block size. So today, the worst case block size uses, like, call data and access lists together, because for access lists, you only pay storage and nothing for the actual data footprint, and this EAP would basically in a friendly way, deprecate access lists, so they would still be possible, but you would pay more for them. So, from an economic standpoint, it would not make sense anymore to use access lists after that. I think this makes sense, but yeah, happy to discuss it.

And, right, the size reduction would be, like, 21% for, putting the call data costs on top of access lists, which means for a zero byte and for a non-zero byte, you would just pay the call data prices for your access list.

Tim Beiko: Got it, thanks. Antonio, is your hand up? For this?

Antonio Sanso: No, sorry, I… sorry, lower it.

Tim Beiko: Okay. Anyone have questions or comments? about the Teled ECA piece? Oh. Yes, sir, Lucas?

Łukasz Rozmej: Quick comment from me, so… I think we've… balls, right, with block access lists. Standard access lists don't make any sense for block processing. So, it's good to remove them from… Block history, and kind of agree with that. But, I still see a potential, usage for those access lists in block production, so… That would be a good question. Should we… should we try something instead for block production? And you can always simulate it yourself, by being a block producer and get that access list. But on the other hand, that… that takes resources that are centralized. Compared to resources that are decentralized, so… That's a good question. About… the next thing we should probably tackle post-Lamsterdam, which is,

Working on potential ways to optimize block building, and not only block processing. So, just a comment in general. But I think in general, it's fine to remove them. At the moment.

Tim Beiko: Thanks! Any other comments? Okay and then last up, we had Ben, which wanted to present EIP27ALE. Ben.

Ben Adams: Yeah, this was, originally brought up just over 5 years ago. I went back and listened to the ACD at the time, and there was, some concern about state growth, and… That's solved by… So this is… reducing, the transaction base cost to $6K. And the state growth is resolved by, if you create a new account, to charge the same as core, which is $25K, Gas? Whereas at the moment, a base transaction is 21K, and it doesn't matter if you create an account or not, it's charged the same. So… so it would reduce it to 6K. And then if you create an account, it would… Charged 25K on top. And that gives us… that would give us, what is it, on average?

It's the equivalent of… Putting the gas limit up to, 50. You know, fair. About 52, megagas. From 45, so it's quite a bit different. And it's… it specifically targets that first bit of the transaction, and we know from perf testing we can handle this, and all our worst-case scenarios, like ModXP, etc, how we generate those is in single, large transactions. Because if we split them up into individual transactions, then essentially all the opcode costs and everything are irrelevant, because the Cost of a single transaction is so high. So we… And this would also encourage smaller transactions, rather than people batching transactions to avoid the base cost, because you can sort of avoid it now.

Which then leans into parallelization with bowels and so forth.

Tim Beiko: Thanks, there's… yeah, there's a comment in the chat. Okay.

Ben Adams: I mean…

Lightclient (Matt Garnett): The concern was slightly different.

Ben Adams: I mean… yeah, but that sort of leans into… Generally increasing, gas limit, regardless.

Lightclient (Matt Garnett): frame.

Ben Adams: Which we're doing anyway.

Lightclient (Matt Garnett): Yeah, but 5 years ago, that was, like… The thing we didn't want to do. I'm just trying to say that, like, I don't think that there's a change to the CIP that, like, fixes that concern. I think it's just that we decided we don't care as much about that concern.

Ben Adams: Yeah, yeah. But it's also the… the transaction's essentially the smallest unit of account, and… That's what, in a way, the… the fee is to… the gas fee is determining. But it's… it's very large. I don't know. At 21K. No, we don't check the state, but when… When you're sending to a new address, if you're creating an account from that, then you… then you add. So it's not… it's not changing the intrinsic, essentially.

But it's saying, if you also, as part of that operation, create a new account, then you add 25K on top.

Tim Beiko: Okay. Any other questions or comments about the CIP? If not, yeah, that's pretty much everything we had on the agenda. One thing, So, at the start of the call, I mentioned Angar would be taking over while I'm away. He was a couple minutes late to the call, but he wanted to also say a few words, well, yeah, how he's planning to approach this, so… Anskar, the floor is yours.

Ansgar Dietrichs: Yeah, hey. I mean, yeah, I don't, I don't think I have much to say. I'm, very, of course, looking forward to just filling in for a little bit here, and I'll try my very best to to do a good job. The one thing that I did want to say briefly is just that, especially because I think timing-wise, a lot of the, kind of, those weeks that I'll… or, like, those, kind of, few months that I'll fill in for will be, kind of, specifically the Glamstadam, kind of scoping discussion and whatnot, and Given that I will also basically, at the same time, participate in that discussion as someone with strong opinions and with, kind of, involvement in some of the, kind of, ERPs discussed.

I'll try very hard to make it, like, a very clean separation between participant and a moderator, but if there ever is moments where you feel like anyone gets the feeling that maybe I'm kind of paling at that, or basically just, in any way, basically, like, bias the decision towards… in any way, please, like, hold me accountable for that, and reach out to me, and… That's really, like, my intention very much is to avoid that, but I do think it's going to be a bit tricky. But yeah, other than that, I'm very much looking forward to… And filling in for you for a couple weeks.

Tim Beiko: Thanks! Okay, anything else before we wrap up? Great for ya. Thanks, everyone. Let's see how DevNet 5 goes, and hopefully we get DevNet 3 finalizing again today, and we'll talk to you all soon.

Potuz: Bye-bye.

Alex Stokes: Thanks, everyone.

Antonio Sanso: But…

Toni Wahrstätter: Dude, I bet.

Danceratopz: Thank you, bye-bye.

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