Tim Beiko:Thank you.
Transcript
Tim Beiko:Welcome, everyone, to ACDE number 220. Couple things on the agenda today,
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:And to wrap up, we have a bunch of EIPs, that people wanted to discuss, so we can, can go through those.
Tim Beiko:Also, as a quick heads up, I'll be, on leave starting at the end of this month, and so from,
Tim Beiko:not next call, but the ACDE after that, AMSGAR will be chairing until the end of the year, so,
Tim Beiko:yeah, we will… we will be stuck with him for several months. Just kidding, but, yeah, thanks, Oscar, for stepping in.
Tim Beiko: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…
Parithosh Jayanthi: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…
Parithosh Jayanthi: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.
Parithosh Jayanthi: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
Parithosh Jayanthi:Yeah, good job there.
Parithosh Jayanthi:Okay, cool, GET apparently has a PR, and I can apply it soon and see how that goes.
Parithosh Jayanthi:The other piece of testing information is we have DevNet 5 up and running. I can share the link in the chat.
Parithosh Jayanthi: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.
Parithosh Jayanthi:you're using.
Parithosh Jayanthi: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
Parithosh Jayanthi: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.
Parithosh Jayanthi: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.
Parithosh Jayanthi: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.
Parithosh Jayanthi:Does anyone have any questions?
Parithosh Jayanthi: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…
Tim Beiko: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,
Tim Beiko:Yeah, I guess we launched it at 5 in parallel to fixing them at 3. Is there a risk
Tim Beiko:that some of the issues from .NET 3 kind of…
Tim Beiko: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.
Tim Beiko:They needed her… comments or questions about the VED5?
Tim Beiko: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
Parithosh Jayanthi:8-ish instances been online, so… I don't think it's fully related to just Fusaka.
lightclient:I'm just trying to figure out, because…
lightclient:You started at, like, 2 AM.
lightclient:Yesterday?
lightclient: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:Okay.
Tim Beiko:Any other questions?
Tim Beiko:And so, I guess, just to be clear then, the expectation is DevNet 5 should go relatively smoothly, and
Tim Beiko:Unless there's any issues that come up that we didn't anticipate, it would be the last testnet before moving to testnet deployments.
Tim Beiko: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.
Parithosh Jayanthi:And the benefit of DevNet3 is that since it's been up for a while now, the state continues to pick…
Parithosh Jayanthi: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.
Parithosh Jayanthi:Holsky and before all the testnets.
Tim Beiko:Got it.
Tim Beiko:And there's another comment about Lighthouse, getting bad responses from Get Blobs around the transition.
Tim Beiko:I don't know if anyone from Lighthouse is here to discuss this.
Tim Beiko:Okay, any… other ELs want to chime in beyond get?
lightclient: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:Do we have any, like, reorgs over the fork boundary?
lightclient:Because you might get a situation where you…
lightclient:Re-inject legacy blobs into the pool.
lightclient:You would either want to ban it at the pool, or you would want to ban it at the block building.
lightclient:Or maybe that just goes through the same logic that you already have to drop them.
lightclient:That's true.
Tim Beiko:It seems like it gets filled out at the block building level.
Tim Beiko:And then the transaction pool gets cleared on the fork.
Tim Beiko:Is this… is this what GET does, or… No.
lightclient:I mean, we were planning to convert them.
lightclient:But if everybody else is dropping, then we might consider this.
Tim Beiko:Okay.
Tim Beiko:No, yes, yeah, just can look into it. Is there a… like, I guess, when would you want to make this change, and when…
Tim Beiko:Is this something you want to test on .NET 5?
lightclient:Is that for me?
Tim Beiko:Yeah, yeah, yeah.
lightclient:Okay.
Tim Beiko:like…
lightclient: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
lightclient:The legacy sidecars at the transition.
lightclient:So… If everybody else is not doing that, it's definitely easier to just drop them.
lightclient:We need to understand the ramifications, but…
lightclient: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.
Tim Beiko:Anything else on… Fusaka deployments?
Tim Beiko: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.
Tim Beiko:Basically, after the picture issues, we, we put together this process, for deployment, and then,
Tim Beiko: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.
Tim Beiko:So we, yeah, reached out to a bunch of L2's info providers to try to get some feedback, and I guess there's…
Tim Beiko: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,
Tim Beiko: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.
Tim Beiko:The second is, what's the delay we actually want between the first testnet? Like, first quote-unquote supported testnet, and, and…
Tim Beiko:And, the client releases,
Tim Beiko: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.
Tim Beiko:Reason for this is that,
Tim Beiko: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.
Tim Beiko:some proposals I've heard, like, in the last week, speaking to people, is, like, maybe
Tim Beiko:Alesh key can be done quite quickly after the client releases, so, you know, one to two weeks, but then potentially
Tim Beiko: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.
Tim Beiko:Yeah, it would be good to agree on this.
Tim Beiko: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.
Tim Beiko:But yeah, maybe to start with, like, Holeski, like.
Tim Beiko: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?
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…
stokes:This one is kind of a freebie. I think we can move a bit faster.
stokes:But yeah, I'd love to hear what other people think.
stokes: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…
Tim Beiko:Yeah, so…
Tim Beiko:Well, James, I guess, yeah, maybe, okay, to start from the… from this, like, how long until client releases?
Tim Beiko:Assuming everything went well with DevNet 5,
Tim Beiko:would client… and we, we, like, agreed on fork blocks, say, for, like, testnets next week,
Tim Beiko: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?
Tim Beiko:like I said, does any team have an issue with that? So, like, assume… again.
Tim Beiko:Assume everything goes right to the testnets.
Tim Beiko:whenever we pick the call, or whenever we have the ACD, we agree on the blocks, then,
Tim Beiko:Ideally, by, like, the Monday after that, we have a race with those.
Tim Beiko:and so this means that, like, yes, assuming this was next week,
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:between announcing and forking Holeski,
Tim Beiko:Then, I guess the question is, how much time do we want before Sepolia? And…
Tim Beiko: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.
Tim Beiko:So this gives us Sepolia 3 weeks out, which is…
Tim Beiko: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.
Tim Beiko:and then Stokes is saying he would prefer one week between Holeshki and Sepolia rather than two, so…
Tim Beiko:Yes.
stokes:Because that still gives us the two weeks following the protocol.
stokes:The process upgrade, I mean, document.
stokes:in between tests, or, yeah, testnet releases and the first, quote, testnet. So we're kind of saying Halezky is…
stokes:not a real testnet in this sense, which I think people generally agree with that assessment, so…
stokes:That would be the logic.
Tim Beiko:Did people think that's too quick, or that's fine?
Tim Beiko:I want a few days of silk release, but after release, one week sounds reasonable for Holeshki.
Tim Beiko:When we can find, as long as we're not doing non-finalization testing.
Tim Beiko:So yes, on the testnets, we were not doing that.
Tim Beiko:Okay, so all these teams that are saying, though, one week is enough time to push a release.
Tim Beiko:We just said earlier.
Tim Beiko:is 2 days enough lead time to push for release? So, like, assuming that on…
Tim Beiko:Alcore devs, we pick the blocks, if we pick Holeshki.
Tim Beiko:and Sipolia, is it realistic to have those in the same release, or do people want separate releases for Holeshki and Sipolia?
Tim Beiko:Okay, so same… So… so yeah, so assuming we did this next week, this would look like… we…
Tim Beiko:finalize the blocks on the 18th. The releases are out by the 22nd. On the week of the 29th, Holeshky Forks.
Tim Beiko:And then… On the week of the 6th,
Tim Beiko:on the week of the… of the 6th, potentially, we fork… we would fork, Sepolia.
Tim Beiko:And that would be one week between the testnets. If we wanted two weeks.
Tim Beiko:between the testnets and, like, 3 weeks between the release, then it would be forking Sipoly on the week of the 13th.
Tim Beiko:So, yeah.
Tim Beiko:Do people have a strong preference between
Tim Beiko:one or two weeks between the Holeshky and Sepolia.
Tim Beiko:So… At the community level, if…
Tim Beiko: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.
Tim Beiko:Some teams are, like, more on the…
Tim Beiko:trying to get this as soon as possible side. Some would prefer more… more time. And then…
Tim Beiko:yeah, Hudi… I think this is pretty clear, though, like, when we're onto real testnets, we should probably wait two weeks between them.
Tim Beiko:So, like, yeah, Hootie would happen two weeks after?
stokes:Do you accept for Sepolio, you mean?
Tim Beiko:Yeah.
stokes:Yeah, okay.
Tim Beiko:Yeah, so, like, between production death notes, I think everyone agrees we should have two weeks. I think between…
Tim Beiko:like, the releases and mainnet, everyone agrees we should have one month. The question is between the first releases and the first testnet,
Tim Beiko:you know, do we want this two weeks, okay? And…
Tim Beiko:And how do we count Hudi?
Tim Beiko:Okay, so I guess, I don't know, if there's…
Tim Beiko:It doesn't seem like there's super strong preferences, like…
Tim Beiko:Are people comfortable doing one week between Houdi and Sepolia?
Tim Beiko:If so, we can move forward with that.
Tim Beiko:the… I guess the downside of doing this is if we find any new issue on Paleshi that we…
Tim Beiko:don't…
Tim Beiko:Then we'll need to, like, put out new releases that move the blocks, you know, pretty quickly before Sepolia goes live, but…
Tim Beiko:If things deploy smoothly, then we save a week. Yeah.
Tim Beiko:Okay, like Plant is saying, we should do two weeks.
Tim Beiko:How do other time teams fail between them?
Tim Beiko:one and two weeks
Tim Beiko:Okay, seems like 2 weeks is the…
Tim Beiko: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…
Tim Beiko:client releases, two weeks after we have Holeshki, 2 weeks after we have Sepolia, 2 weeks after we have Cody,
Tim Beiko:Okay, there seems to be some support for that, so…
Tim Beiko:Does anyone feel strongly about one week? Otherwise, I think we just stick to two weeks.
Tim Beiko:And this makes it also easy to just merge the changes, where I think we would just agree that any testnet
Tim Beiko:Any testnet should just be two weeks after the releases, and make that the kind of official process.
Tim Beiko:And then in this case, we kind of get a deprecated testnet as the first one.
Tim Beiko:And then… Okay, so last point on the, on the process doc, then, is,
Tim Beiko: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,
Tim Beiko:But before we, before we, have the mainnet block set, do we want to see who the
Tim Beiko:Yeah, do you want to see who the, go live?
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.
stokes:Yeah, we also have time to reevaluate this, you know, in a few weeks from now.
Tim Beiko:Yep.
Tim Beiko:Okay, so, like, the default to just setting the block once Foodie goes live, yep.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:then once Houdee has, once Houdee has, like, safely upgraded, we would,
Tim Beiko:We would pick blocks for mainnet and have a month between those blocks and the actual upgrade going live.
Tim Beiko:Okay.
Tim Beiko:And I'll get the PR merged, that kind of reflects all this later today.
Tim Beiko:Anything else on Sepolia?
Tim Beiko:I'm sorry, on Sepul, yeah, on Fusaka?
Tim Beiko: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.
Toni Wahrstätter:We mainly discussed one proposal, basically.
Toni Wahrstätter: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.
Toni Wahrstätter:balance diff, and so on. There is a transaction index mapped to that div.
Toni Wahrstätter:And we currently don't do that for everything that is only touched. So for S-loads, for balance opcode.
Toni Wahrstätter: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.
Toni Wahrstätter:And we currently don't map it to transaction indices.
Toni Wahrstätter:And it came up that it might be valuable for provers, or for, parallel execution.
Toni Wahrstätter:If we actually include the transaction indices for that.
Toni Wahrstätter: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.
Toni Wahrstätter:So everyone who has an opinion on that, please be there. And we also discussed, like, timelines for a first, DevNet.
Toni Wahrstätter:And it looks like, by the end of month, we should be ready to go.
Tim Beiko:Okay, thank you.
Tim Beiko:Karen said that there's a BPVS breakout on Friday. Anything you want to share?
Tim Beiko:on that?
terence: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!
Tim Beiko: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
Tim Beiko:Holeshki and the client releases, because the SNS is deprecated.
Tim Beiko:then… I thought we agreed to 2 weeks after
Tim Beiko:Poleski before Seppolya, but Alex thinks it's.
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.
Tim Beiko:when you say 2 weeks, you mean two weeks between Holeshky and Sepolia, correct?
Justin Florentine (Besu):Yes. Two weeks… two weeks for all the, downstream testnets.
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.
stokes:But, again, if everyone is clear on the other thing, then…
stokes: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…
Tim Beiko:One week before the end-of-life testnet.
Tim Beiko: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 (Besu):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.
Tim Beiko:Between… so, okay, so sorry. So, we have the client releases.
Tim Beiko:then there's one week, then Holeshky Forks.
Tim Beiko:then there's 2 weeks where we can do whatever on Holeshki, and then Sepolia forks.
Tim Beiko:And then there's 2 weeks.
Tim Beiko: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.
Tim Beiko:And this means less time for people to upgrade their nodes,
Tim Beiko:we control still the majority of the nodes on the Holeshki, I believe, so,
Tim Beiko: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 (Besu):Alright, Stan corrected, and that sounds great.
Tim Beiko:Okay.
Tim Beiko:Does anyone… Not like this plan.
Tim Beiko:Okay.
Tim Beiko:Actual last call, before we move on, and then…
Tim Beiko:yeah, I'll make this as clear as I can in the PR after this call.
Tim Beiko:Okay.
Tim Beiko:So, yes.
Tim Beiko:Two weeks after Holeshki.
Tim Beiko:Last call.
Tim Beiko:Okay.
Tim Beiko:Okay, sweet, sorry, so back on track,
Tim Beiko: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.
Tim Beiko: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.
danceratopz: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.
danceratopz: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.
danceratopz:The timeline's a little bit vague, it won't… probably won't happen in September, so it's gonna be Q4 2025.
danceratopz:And that's basically because the priority remains for us, obviously, for Saka, Glamsterdam, and scale, the L1.
danceratopz:So why the weld? I mean, it's pretty intuitive that specs and tests, belong together, especially for the same features.
danceratopz: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.
danceratopz:So, the aim is really to provide better developer experience for spec implementers and test contributors.
danceratopz: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.
danceratopz:And test coverage becomes extremely simple, just a simple command line.
danceratopz:And another nice advantage is that because we lose this resolver, we can drop straight from running test code into the spec.
danceratopz:In a debugger.
danceratopz: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.
danceratopz:And client devs currently download releases from executions by tests.
danceratopz:And after the weld, to be honest, not that much changes. For SpecDevs, they continue as before, but they have their tests.
danceratopz:Test devs…
danceratopz: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.
danceratopz:And update their CIs for that.
danceratopz:So, we really hope that this will go through with minimal disruption,
danceratopz:It should actually only really affect East contributors, so to the tests,
danceratopz: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
danceratopz: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.
danceratopz: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.
danceratopz:So,
danceratopz: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.
danceratopz:But basically, we… we hope this will be a big win, for… for EIP authors who want to spec out their, their EIPs.
danceratopz: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.
danceratopz:For… for the ecosystem.
danceratopz:That's about it.
danceratopz:If there's any questions…
Tim Beiko:Thank you.
Tim Beiko:Sounds exciting. Any questions?
Tim Beiko: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.
danceratopz:Yup.
Tim Beiko:Okay, sounds great.
danceratopz:Excellent.
Tim Beiko:Thanks, Sam.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:Ailey, the champion created a nice Eighth Magicians thread for people to review async.
Tim Beiko: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.
Tim Beiko: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,
Danno Ferrin: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…
Danno Ferrin:Meet the post-quantum cryptography standards.
Tim Beiko:Thanks. Anyone else have thoughts, comments on this?
Tim Beiko:Yeah, Felix?
Felix:Yeah, I would also say that, this…
Felix:It kind of seems like if we're gonna add support for one more, like, specific elliptic curve in transaction signatures.
Felix:It will be much wiser to spend the bandwidth we have to just enable
Felix:Like, a current abstraction or things like that.
Felix:Because… Bifurcating on the…
Felix:number of, like, elliptic curves we support is not a… I don't think it's a good use of…
Felix:It makes no difference, basically.
Tim Beiko:Got it, thanks.
Tim Beiko: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
Danno Ferrin: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:I'm sorry, I did not fully understand the question.
Danno Ferrin:So,
Danno Ferrin:Are you against bringing in new signatures in general, or just the elliptic curve ones? For example, there is,
Danno Ferrin: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: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.
Felix: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…
Felix:trying to…
Felix:somehow create a framework for introducing more signature types as precompiles, but also as transaction signatures, so that part. And, I mean.
Felix: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
Felix:signatures. I mean, this is a big step for Ethereum to just, you know, start this at all, but we always, so far, like.
Felix:Had this… had it in mind that
Felix: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…
Felix:Transactions anymore in the, like, Traditional way, sort of.
Felix:And then…
Felix: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
Felix: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
Felix:Adding precompiles is never the issue, even for elliptic curve.
Felix: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…
Felix:It's just basically never been done.
Felix: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…
Felix: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…
Felix:It's just the hash of the…
Felix: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…
Felix: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.
Danno Ferrin:The NFT in the financial task forces.
Danno Ferrin: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: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
Felix:just use a PQ and algorithm, and then really try to make everything work with that.
Felix:Like, that would be my personal opinion.
Felix:way, too.
Felix: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.
Tim Beiko:But yeah, Carl.
Carl Beekhuizen:Correct, yeah, I, like, for the Edwards curve, I think with R1 and…
Carl Beekhuizen: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…
Carl Beekhuizen: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.
Carl Beekhuizen:Or something similar. And it would be great if we can avoid that. I don't think there's, like, a huge deadline, like.
Carl Beekhuizen:We can still ship
Carl Beekhuizen: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.
Antonio Sanso: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.
Antonio Sanso: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 (Besu):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
Justin Florentine (Besu):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…
Justin Florentine (Besu):almost schema questions that we need to resolve fairly early,
Justin Florentine (Besu):In order to adopt a wider range of these signatures.
Tim Beiko:Thanks.
Tim Beiko: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.
Tim Beiko:Yeah.
Tim Beiko:Tony, please.
Toni Wahrstätter:Yeah, just some quick context on those two EIPs.
Toni Wahrstätter:Both of them tackle the worst-case block size. We already reduced the worst-case block size quite effectively in Pectra.
Toni Wahrstätter: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%.
Toni Wahrstätter:And around 1.5% of the transactions will be affected.
Toni Wahrstätter:So we already had some factor transactions, I think it was, like, 0.9.
Toni Wahrstätter:With 7623, and now this would increase slightly, but it's still, like, a very big, worst-case block size reduction.
Toni Wahrstätter:for only very few users being affected, those that use a lot of call data. And the other AAP is proposing to
Toni Wahrstätter:put a data cost on top of 2930 access lists. So right now, we price access lists only for their storage, and…
Toni Wahrstätter:This led to the situation where access lists can be used today to create the worst case block size.
Toni Wahrstätter: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
Toni Wahrstätter: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.
Toni Wahrstätter:I think this makes sense, but yeah, happy to discuss it.
Toni Wahrstätter: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?
Tim Beiko:For this?
Antonio Sanso:No, sorry, I… sorry, lower it.
Tim Beiko:Okay. Anyone have questions or comments?
Tim Beiko:about the Teled ECA piece?
Tim Beiko:Oh.
Tim Beiko:Yes, sir, Lucas?
Łukasz Rozmej:Quick comment from me, so… I think we've…
Łukasz Rozmej:balls, right, with block access lists. Standard access lists don't make any sense for block processing.
Łukasz Rozmej:So, it's good to remove them from…
Łukasz Rozmej:Block history, and kind of agree with that.
Łukasz Rozmej:But, I still see a potential, usage for those access lists in block production, so…
Łukasz Rozmej: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.
Łukasz Rozmej:Compared to resources that are decentralized, so… That's a good question. About…
Łukasz Rozmej:the next thing we should probably tackle post-Lamsterdam, which is,
Łukasz Rozmej:Working on potential ways to optimize block building, and not only block processing.
Łukasz Rozmej:So, just a comment in general. But I think in general, it's fine to remove them.
Łukasz Rozmej:At the moment.
Tim Beiko:Thanks!
Tim Beiko:Any other comments?
Tim Beiko:Okay and then last up, we had Ben, which wanted to present EIP27ALE.
Tim Beiko:Ben.
Ben Adams:Yeah, this was, originally brought up just over 5 years ago. I went back and listened to the
Ben Adams:ACD at the time, and there was, some concern about state growth, and… That's solved by…
Ben Adams:So this is… reducing, the transaction base cost to $6K.
Ben Adams:And the state growth is resolved by, if you create a new account, to charge the same as core, which is $25K,
Ben Adams:Gas?
Ben Adams:Whereas at the moment,
Ben Adams: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.
Ben Adams:And then if you create an account, it would… Charged 25K on top.
Ben Adams:And that gives us… that would give us, what is it, on average?
Ben Adams:It's the equivalent of… Putting the gas limit up to, 50.
Ben Adams:You know, fair.
Ben Adams:About 52, megagas.
Ben Adams:From 45, so it's quite a bit different.
Ben Adams: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.
Ben Adams:Because if we split them up into individual transactions, then essentially all the opcode costs and everything are irrelevant, because the
Ben Adams:Cost of a single transaction is so high.
Ben Adams:So we…
Ben Adams: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.
Ben Adams:Which then leans into parallelization with bowels and so forth.
Tim Beiko:Thanks, there's… yeah, there's a comment in the chat.
Tim Beiko:Okay.
Ben Adams:I mean…
lightclient:The concern was slightly different.
Ben Adams:I mean… yeah, but that sort of leans into… Generally increasing, gas limit, regardless.
lightclient:frame.
Ben Adams:Which we're doing anyway.
lightclient:Yeah, but 5 years ago, that was, like…
lightclient:The thing we didn't want to do.
lightclient: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.
Ben Adams:But it's also the… the transaction's essentially the smallest unit of account, and…
Ben Adams:That's what, in a way, the… the fee is to… the gas fee is determining. But it's… it's very large.
Ben Adams:I don't know.
Ben Adams:At 21K.
Ben Adams:No, we don't check the state, but when…
Ben Adams:When you're sending to a new address, if you're creating
Ben Adams:an account from that, then you… then you add. So it's not… it's not changing the intrinsic, essentially.
Ben Adams: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.
Tim Beiko:Any other questions or comments about the CIP?
Tim Beiko:If not, yeah, that's pretty much everything we had on the agenda. One thing,
Tim Beiko: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…
Tim Beiko: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,
Ansgar Dietrichs:of course, looking forward to just filling in for a little bit here, and I'll try my very best to
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs:I'll try very hard to make it, like, a very clean separation between participant and
Ansgar Dietrichs: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…
Ansgar Dietrichs: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…
Ansgar Dietrichs:And filling in for you for a couple weeks.
Tim Beiko:Thanks!
Tim Beiko:Okay, anything else before we wrap up?
Tim Beiko:Great for ya.
Tim Beiko: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.
stokes:Thanks, everyone.
Antonio Sanso:But…
Toni Wahrstätter:Dude, I bet.
danceratopz:Thank you, bye-bye.
Chat Logs
00:03:29
stokes:Excited for Ansgar 🎉
00:04:34
lightclient:We have a PR with fix
00:04:45
lightclient:it’s due to another PR for eth_config :(
00:05:04
Parithosh Jayanthi:https://dora.fusaka-devnet-5.ethpandaops.io/
00:06:37
Parithosh Jayanthi:https://notes.ethereum.org/@samcm/fusaka-devnet-5-analysis
00:07:25
lightclient:i feel like we skipped over waiting for devnet 3 to getting back to finality
00:08:17
lightclient:so it should take more than a day to restore finality?
00:09:49
stokes:sgtm
00:10:23
lightclient:lighthouse was also getting bad response for get blobs around the transition for a few clients i think?
00:10:38
Tim Beiko:Replying to "lighthouse was also ..."
Anyone from LH on the call to give context?
00:10:53
lightclient:Replying to "lighthouse was also …"
i know geth was incorrectly returning v0 and v1 sidecars
00:11:13
lightclient:Replying to "lighthouse was also …"
i’m not sure how other ELs deal with conversion at the fork boundary
00:12:08
Roman:reth does not convert
00:12:12
Gabriel Trintinalia | Besu:we just don’t return
00:12:12
Alexey:we agreed to not convert
00:12:30
Mario Vega:Replying to "lighthouse was also ..."
We have hive tests for get blobs, but not at the fork boundary, it might be a good idea to try to add some
00:12:58
potuz:yeah, +1
00:13:14
Alexey:both
00:13:19
Roman:we filter them out on the block building level
00:13:33
Alexey:we clear txpool from old ones on fork
00:13:33
Gabriel Trintinalia | Besu:we filter them out on the block building level
Besu as well
00:15:04
pk910:devnet-5 fulu activation is in 3h :D probably too short
00:15:23
Ansgar Dietrichs:given the very limited one-time relevance, seems like dropping is the pragmatic path
00:15:37
spencer-tb:Legacy means blobs at Prague?
00:15:44
Lumi | Offchain Labs:Are we ready to set a new tentative timeline (assuming devnet 5 goes well) for Fusaka rollout today ->
22 Sep - RC client releases
?? - Sepolia
?? - Hoodi
?? - Mainnet
00:15:52
stokes:Replying to "Legacy means blobs a..."
yep
00:16:00
stokes:Replying to "Legacy means blobs a..."
New proof format in fusaka
00:16:02
Tim Beiko:https://github.com/ethereum/pm/pull/1715
00:16:33
stokes:Replying to "Legacy means blobs a..."
The blobs are still fine, but either need to convert to this new format at the fork boundary, or just do nothing
00:17:27
stokes:Replying to "Legacy means blobs a..."
Most clients just doing nothing
(And this only applies to transactions in mempool)
00:17:34
Gabriel Trintinalia | Besu:for getBlobsV2, spec says: if the request is [A_versioned_hash_for_blob_with_blob_proof], the response MUST be null as well.
00:18:37
stokes:I think we need minimal time b/t releases and holesky
00:19:32
Fredrik:I agree with stokes on Holesky
00:19:52
stokes:Ill assume silence is yes ;)
00:19:59
James He:How long until client releases?
00:20:16
Lumi | Offchain Labs:Replying to "How long until clien..."
Last call 22 Sep was mentioned
00:20:48
Enrico Del Fante (tbenr):👍
00:22:24
stokes:I’d say 1 week b/t Holesky and Sepolia
00:22:30
stokes:Unless there’s a good reason for more time
00:23:19
James He:We want a few days soak before release but after release 1 week sounds reasonable for holesky . I think 1 week might be short if we find any reason to rerelease .
00:23:36
stokes:Replying to "We want a few days s..."
Fair, I think we can re-evaluate then
00:23:36
Justin Florentine (Besu):i think 1 week is fine as long as we're not doing non-finalization testing
00:23:38
stokes:Replying to "We want a few days s..."
If that happens
00:23:48
stokes:Replying to "i think 1 week is fi..."
Hopefully we are not on the testnets
00:23:49
Phil Ngo:1 week is enough lead time for Lodestar to push a release
00:24:25
Justin Florentine (Besu):same release pls
00:24:39
stokes:I can have proposed fork epochs by next ACDC
00:24:40
Alexey:all testnets dates at a time
00:25:38
Justin Florentine (Besu):does the commiunity?
00:25:44
saulius:Replying to "i think 1 week is fi..."
My guess is that we may have non intentional non-finality on Holesky.
00:25:54
Tim Beiko:https://github.com/ethereum/pm/pull/1715
00:25:57
stokes:Replying to "i think 1 week is fi..."
Yeah, and I’d propose to not try to hard to recover
00:26:01
stokes:Replying to "i think 1 week is fi..."
Learn what we can and move on
00:26:05
Alexey:hoodi?
00:26:19
Gabriel Trintinalia | Besu:In Besu, we usually have a burn-in period before releasing. The burn in itself takes two days usually. I would like to have at least 4 days
00:26:22
Lumi | Offchain Labs:Replying to "hoodi?"
Week of 20th?
00:26:44
Lumi | Offchain Labs:Replying to "hoodi?"
Assuming holeski is 1 week
00:28:01
saulius:Replying to "i think 1 week is fi..."
well, client teams should try to make their clients work if non-finality happens on Holesky, but yea, likely we don't want to drop everything and focus on recovering it because of time/resources constrains.
00:28:12
lightclient:2 weeks
00:28:38
Justin Florentine (Besu):more is better, loosely held
00:29:07
stokes:My gut does say 2 weeks
00:29:53
Mario H:Ephemery will fork monthly after Sep 25
00:29:59
lightclient:i think arbitrum said they preferred more time between releases and first testnet
00:31:03
Lumi | Offchain Labs:Replying to "i think arbitrum sai..."
For Fusaka we are goo to go with shorter timelines, we started margining pre-release geth
00:31:26
stokes:Good plan for now
00:32:21
Lumi | Offchain Labs:So to summarize timelines?
22 Sep - RC client releases
Week of 29th - Holeski (1 week after client releases)
Week of 13th - Sepolia (2 weeks from Holeski)
Week of 27th - Hoodi (2 weeks from Sepolia)
?? - Mainnet (min 30 days from RC, don’t want to propose mainnet timeline yet)
00:32:42
Tim Beiko:Replying to "So to summarize time..."
Yes, if devnet-5 has no issues
00:32:49
terence:there's an epbs breakout this friday: https://github.com/ethereum/pm/issues/1714
00:33:01
stokes:Replying to "So to summarize time..."
Didn’t we say we were ok w/ 1 week b/t Holesky and Sepolia?
00:33:07
Tim Beiko:Replying to "So to summarize time..."
No, 2 weeks
00:33:26
Tim Beiko:Replying to "So to summarize time..."
Didn’t you explicitly say that too 😅?
My gut does say 2 weeks
00:33:34
stokes:Replying to "So to summarize time..."
Hm I thought that was 2 weeks b/t client releases and sepolia
But I’ll review after the call
00:33:43
stokes:Replying to "So to summarize time..."
That was b/t sepolia and hoodi
00:34:10
Tim Beiko:Replying to "So to summarize time..."
Let’s align now 😄
00:34:55
Justin Florentine (Besu):2 weeks
00:35:18
Tim Beiko:EOL Testnet → 1 week
Live testnet → 2 weeks
00:37:06
Justin Florentine (Besu):understood, works for us
00:37:20
Fredrik:1 week between EOL -> Live testate would imo feel very short to find issues and then get a new release out if something does go wrong (and if we fail to get fixes out in time etc then the whole chain of upgrades will go out of sync), so I support the 2 weeks
00:37:46
stokes:Replying to "1 week between EOL -..."
Fredrik agreeing w/ what Lumi wrote
00:37:59
lightclient:Replying to "1 week between EOL -…"
so 2 weeks after holesky?
00:38:02
lightclient:Replying to "1 week between EOL -…"
or no?
00:38:13
stokes:Replying to "1 week between EOL -..."
Lumi’s msg
00:38:15
Enrico Del Fante (tbenr):Replying to "1 week between EOL -..."
Yes
00:38:16
stokes:Replying to "1 week between EOL -..."
Is our agreement
00:38:17
lightclient:Replying to "1 week between EOL -…"
👍
00:38:42
lightclient:the merge 2.0
00:38:59
Tim Beiko:Replying to "the merge 2.0"
Merge Phase 2
00:40:03
Ansgar Dietrichs:I love the WELD framing, very cinematic
00:40:07
Felix:the generated tests will remain in execution-spec-tests?
00:40:07
Trent:We have been missing merges in our lives. I can get behind this =)
00:40:53
Mario Vega:Replying to "the generated tests ..."
Yes, we are making fixture releases still in EEST
00:42:49
danceratopz:Weld Blog Post:
https://steel.ethereum.foundation/blog/blog_posts/2025-09-11_weld-announcement/
Slides:
https://notes.ethereum.org/@danceratopz/weld-announcement#/
00:43:31
terence:Replying to "Weld Blog Post:
http..."
403 for the slides : )
00:44:20
Tim Beiko:https://ethereum-magicians.org/t/the-case-for-eip-7932-eip-7980-inclusion-in-glamsterdam/25293
00:44:25
danceratopz:Replying to "Weld Blog Post:
http..."
Thanks! Fixed;
https://notes.ethereum.org/@danceratopz/weld-announcement
00:47:34
Justin Florentine (Besu):it's accomadating decoupling sig types
00:48:47
Gary Schulte:it would be unfortunate if p256verify became a special snowflake, if we were to adopt a signature framework
00:49:23
Tim Beiko:Will time box this convo after Felix so we can move to the next EIPs 😄
00:51:12
Tim Beiko:Next up, @Toni Wahrstätter with EIP-7976 and EIP-7981.
00:51:30
nixo:Replying to "https://ethereum-mag..."
fyi this author confirmed that he’s listening but can’t attend - so any CTAs for him can be called out
00:52:41
Antonio Sanso:https://ethresear.ch/t/falcon-as-an-ethereum-transaction-signature-the-good-the-bad-and-the-gnarly/21512/5
00:52:59
Antonio Sanso:https://ethresear.ch/t/so-you-wanna-post-quantum-ethereum-transaction-signature/21291
00:53:09
Danno Ferrin:No PQ signatures have NIST supported key recovery
00:53:31
Toni Wahrstätter:https://eips.ethereum.org/EIPS/eip-7981 and https://eips.ethereum.org/EIPS/eip-7976
00:53:33
potuz:you can always have an ECRecover from any signature scheme
00:53:34
Antonio Sanso:https://ethresear.ch/t/the-road-to-post-quantum-ethereum-transaction-is-paved-with-account-abstraction-aa/21783
00:53:46
Alexey:if new pq sig is compromised, it might be cool to have a quick way to intro new one
00:53:56
Antonio Sanso:Replying to "you can always have ..."
Not from any 🙂
00:54:11
potuz:Replying to "you can always have ..."
yes, you just add the public key to the signature
00:54:13
Justin Florentine (Besu):Replying to "No PQ signatures hav..."
so thats a whole thing that needs redesign - the ability to ecrecover from a sig does a lot of heavy lifting for us
00:54:27
Antonio Sanso:Replying to "No PQ signatures hav..."
Falcon has a key recovery mode
00:54:31
Danno Ferrin:Replying to "you can always have ..."
Put the pubkey in the signature then it’s recoverable. I think that’s probably the best path forward on non-recoverable algorithms
00:55:06
Danno Ferrin:Replying to "No PQ signatures hav..."
NIST supported key recovery? They explicitly passed on it for falcon
00:56:24
Antonio Sanso:Replying to "No PQ signatures hav..."
However, as Renaud Dubois pointed out, Section 3.12 of the Falcon paper introduces a key recovery model.
00:56:53
Antonio Sanso:Replying to "No PQ signatures hav..."
Not NIST supported but in the falcon paper
00:56:58
potuz:Replying to "No PQ signatures hav..."
reposting in this thread cause it seems to repeat the above: any signature scheme has a recovery method: just append the pubkey to the signature
00:57:30
Justin Florentine (Besu):Replying to "No PQ signatures hav..."
yes, this is my point, we just need to design for that in the sig abstraction mechanic. we should do that asap.
00:57:55
Tim Beiko:EIP-2780
00:58:29
Justin Florentine (Besu):i like 2780 seems like pretty good return for low risk
00:59:16
lightclient:that’s a little different. i think the state growth concern is more about the newly available gas due to the reduction that can now be generally used to increase state size
01:01:35
Mario Vega:The intrinsic gas cost calculation seems weird to me in this EIP, do we have to check the state now to determine the intrinsic gas cost now?
It’s a very minor concern and I’m sure it can be addressed
01:02:37
Ben Adams:Replying to "2 * WARM_ACCOUNT_ACC..."
no :)
01:02:46
Alexey:Replying to "2 * WARM_ACCOUNT_ACC..."
why?
01:02:56
Ben Adams:Replying to "2 * WARM_ACCOUNT_ACC..."
because are all in header
01:03:24
Ben Adams:Replying to "2 * WARM_ACCOUNT_ACC..."
isn't discovered as part of tx
01:03:32
Alexey:Replying to "2 * WARM_ACCOUNT_ACC..."
does not mean we don't need to load it
01:03:48
Ben Adams:Replying to "2 * WARM_ACCOUNT_ACC..."
perfectly parallizable
01:03:58
Alexey:Replying to "2 * WARM_ACCOUNT_ACC..."
as all access with BALs
01:04:16
Justin Florentine (Besu):Ansgar needs a safeword
01:04:21
Ben Adams:Replying to "2 * WARM_ACCOUNT_ACC..."
BALs aren't parallelizable to builder
01:04:27
Alexey:Replying to "2 * WARM_ACCOUNT_ACC..."
disk access is still disk access, parallelisation is not an arguement
01:04:47
Ben Adams:Replying to "2 * WARM_ACCOUNT_ACC..."
2 for free then :)