All Core Devs - Execution #216

Transcript

Tim Beiko: Okay, could we move over to the live stream?

Josh Davis: You are alive.

Tim Beiko: Thank you. Welcome everyone to acde number 2, 16, 2 main things on the agenda today. So 1st updates on Fusaka and discussing yeah, where things are at, but also how we should approach trying to time the fork and especially in light of like the process we discussed after Petra going. Live as we can discuss this, and then there's a couple minor spec things as well. Then I wanted to at least open up the conversation around Amsterdam. We said we would spend the next 2 acds discussing on this. All of the teams have shared their preferences already, at least on the El side. So we can review that. And then also figure out like, Okay, what are the most important questions we need to answer in these next 2 calls, who's inputs? Do we perhaps want to solicit beyond just core devs? And then, yeah, take it from there.

But yeah, to kick us off. This Panda Ops want to give an update on the Fusaka devnets.

Barnabas Busa: Sure I can give a quick update. We have 2 running now for almost 2 weeks we had a very stable week this week. We have a few bugs, most of them coming from consensus layer clients. So we have a lighthouse bug regarding the Cgc value. They set a wrong Cgc value in their Enr. And the metadata field is showing the right one. So there's some mismatch there. There's a lot, Starbuck, where it is doing excessive polling and getting banned by different peers. The Kuboot node was crashing, due to being overloaded by request. Basically, too much request is going into the database, and it was unable to keep up to head. They have a bug in the our builder right now still working on the rebase from the rest side.

And ideally, we can get the workflow working by end of this week. Small. Your smaller issues Lucifer and Taku are waiting for a finalized Genesis validator. So basically, when you start up a new network they are going to wait for the 1st epoch to finalize before they update their T value, which is the wrong behavior. Prism metadata field is missing, and the blob schedule for lighthouse is in descending order instead of ascending order. and there seems to be a lighthouse minority for always prepare payload flag for trying to build all the blocks in the I'm using virtual and for prism the blob schedule is still missing from the spec. Beacon Api.

Thank you.

Tim Beiko: And any client teams have anything they want to add to this. Oh, prison has a Pr. To fix that issue about the drop schedule. Parents said in the chat. any other comments, thoughts from deadnet or sorry from client teams about deadnets. Okay, and I know we already had a rough spec for devnet 3 but I guess what I did want to bring up before that is the overall timeline for Petra or sorry for Petra, for Fusaka because after Petra or when we rolled out Petra, there were a couple of concerns. So 1st of all, sub teams in the ecosystem notably, I think a couple of the L. 2 teams said they would like to see a longer delay between the last release going on to Mainnet and the actual fork. So at least 30 days there and then

the other thing that came up was that on the Ef security side. and other people too, but mostly yes, security to to have a longer window between the actual client releases that go live on test nets and the 1st test network, in order to do things like have security audits, or raise the bug bounty and and bring people's attention to these release. So Frederick had drafted like a process for the upgrade that included a 30 day window at both of those steps in in in the hard work process. and we discussed this a few months ago. So assuming we followed that and then everyone says, we want to ship Fusaka this year. historically trying to ship before the big conference at the end of the year has worked better than after, because one, there's work to do when we ship the fork, and 2 after that you quickly fall into the holidays. So assuming we wanted to ship before def connect this year, this means we'd want Mainnet to happen early Ish November. And if you work backwards from that it means that

we would have to have clients releases sometimes late August. And I know that Alex also had, like a a shorter proposal in terms of the the schedule but even that basically had the clients releases come for the 1st testnet around early September. So I think regardless of like the specific rollout schedule that we have. if we want a good chance to like ship before Def connect If if we want a good chance to ship before Def connect, like, we should at least aim to be in a spot where we're able to start forking test nets at the end of August, or sorry have releases for the test notes at the end of August, maybe early September.

and I think this also implies some decisions about the scope of the fork so, for example, you know whether or not we keep 7, 9 0, 7 in as there's been like a bunch of of complications with that vip But yeah, I'll pause here. I guess I'm curious to hear from fine teams, like, 1st of all. do you think it's, you know, a realistic timeline. That's like, yeah, if we have these releases in, say, late August, early September, then we'd be in a spot to ship in November. And then assuming that's correct, like, what would we need to do to get there like? Is that possible? Should we change the scope? Are there other things we should be considering if we wanted to hit that.

Okay? So I maybe a better version of this question is if we said, we're aiming. Yeah, if we said we're aiming for client releases. For, say, you know, the 1st testnet 8 late August like. does any client think this is not possible? And then there's a point here around pure desk testing. So I don't know. Yeah. does anyone on the peer to side want to give some context there and like what they would see as the ideal testing scheduled.

Parithosh Jayanthi: And.

Emmanuel Nalepa: So we're going.

Parithosh Jayanthi: Yeah, I think at the very least, we're gonna need at least stable devnet 3, and no spec changes after that. Other than clarifications. We're going to need a large network collaborative, probably with Sunnyside labs, a non finality network Mainnet and Testnet Shadowfox, a test without get blobs, v. 2. As Dustin mentioned, and we have to run the analyses for what Bpo values. We actually want to set both on the Devnets as well, both for the test nets as well as on Mainnet, and I think this is apart from audits and having all the client changes pushed into branches that are mostly stable. at least from the testing side. This is the stuff we see, and I think the testing team also has their own list of eips, etc, that they want to test.

So yeah, the concrete ask would be, how quickly can we get to Devnet? 3. Cause I think that's the at least 1st step where we can freeze the spec and everything else can start kicking off.

Tim Beiko: Okay, and I guess on the El side, as I understand it, the biggest piece of work left. or like, I don't uncertainty with regards to Defnet 3 is Eip 7, 9 0, 7. So the code size limit increase. it seems like there's still many unresolved questions, and we've been looking at it for basically a month. Now, post, interrupt. So yeah, would it accelerate things to remove 7, 9 0, 7 from Fusaka? And are there other things that we could do that would accelerate.

Justin Florentine: I think, with regard to 79.0 7, you know, dropping, it may be prudent at the time it would definitely accelerate things. And also it would not slow things down, meaning that there are additional unknowns that we are going to unearth as we start testing 7,907, and I can't see any of those speeding us up.

marek: I agree with Justin from never mind side.

Marius van der Wijden: I don't really want to speak for the guest team, but my feeling is also that 7, 9, 0, 7 introduces so many new edge cases, and we don't know how the future will look like regarding regarding what we do with the contract size. We only know that this mechanism will not be the final mechanism, because it just doesn't work in this way. And so I believe we should, rather rather than working on this this quick fix we should we should work on the final mechanism. Yeah, just because I I think it's just we. We still don't know yet. And I think at this point we should know. And we gave this eap and the Eap office basically 2 months to figure out whether whether we should put it whether we can figure out all of the edge cases, and

in my opinion we haven't figured that out yet. So.

Tim Beiko: Thanks. Roman.

Roman: Breath's point of view is that the the biggest source of contention on the cap is the pricing adjustments. and people not feeling comfortable that this would be the the final formula for calculating the the cost of code size load. So our opinion is that we morph the 7 9 0 7 into the variant that was proposed during Berlin interrupt, which is a plain code size increase by anywhere around 25 to 50% from what it is today, and call it a day.

Tim Beiko: Okay, Ben.

Ben Adams: Yeah, I was gonna sort of second that one and ask if it was too late to cause. I I think it would be a bit disappointing if we didn't have any increase in code size. and that's a much, much simpler change.

Tim Beiko: Right. I'm Derek.

Derek Lee: Hey? So I'm Derek from representing kind of off chain lines and arbitrum specifically. We would definitely love to see an increase of any kind here. I'm curious if to hear from folks, if the concerns kind of apply also to that modified approach of just raising it by, you know, 50% and calling it today as Roman described previously. And if you know the concerns, there are alleviated, or at least mitigated. This would be where we would love to see be be implemented.

Tim Beiko: So I guess one question I would have if for, like the naive, just raise it by 50% approach is like, how does this affect performance, and especially at like higher gas limits. Is this like. I assume there were some reasons why the the the limit was set this way. So like, yeah, I don't. But I don't have an intuition for what sort of wiggle room or buffer that we have. Oscar.

Ansgar Dietrichs: Yeah, I mean, I think part of the problem. That's also the problem with 7 97 is that we just don't have really good benchmarks. Yet on this not not not just the changes, but also just the situation today. And how that would just change with higher gas limits. I think, from people looking into it. I think maybe Marius has looked into it a bit, and it looked like it's not actually super close to being an issue right now. So like the intuition. But again, they're not yet super sustained. Intuition is that that we would have a bit of room. And so, of course. the very simple logic here is that the smaller the bump, the less likely that we will regret it. Basically. So I think Julius Eap right now, I can link it in chat as well, by the way.

proposed an increase from 24 to 32, which is, of course, less than 50%. So I think the chance that that ends up being something we regret, or that blocks us from going to 100 million gas or something, I think, is very small, but of course it's also not that helpful for developers. And so the further up we would go the higher the likelihood that it becomes a binding kind of scanning constraint, but of course, also the more useful it would become.

Tim Beiko: Perth, Charles.

Charles Cooper: Hello! I'm 1 of the Eip authors. I wanted to point out that the concern about how much code you can load in a block is actually worse if you bump the code size by 30 or 50% or whatever, because for 2,600 gas, you can now load more code basically per unit of gas, whereas 79 0 7 is much more strict in terms of how much code you can load per unit of gas.

Tim Beiko: Right? So I guess yeah, to Justin's comment. Like, if the reason we're doing this is to speed up Pusaka, and there's still some uncertainty. even with like ace, small bump which will take time to like test and review. I would lean towards just removing 7, 9 0. 7, and not changing the contract code size in this port and then figuring out like. quote unquote right way to do it for Amsterdam. it would be pretty bad if we if we I don't know, agreed that like a 30% bump or 50% bump is fine. Now and then, 2 weeks before peer dos goes, live someone highlights some dos issue that we missed. So yeah, I, it feels like we all wanted to do. 7, 9 0, 7. It's just taking longer than we expected to, so we should consider it for Amsterdam. But

if we want to speed up Fusaka doing nothing will probably be the quickest.

Lightclient (Matt Garnett): I just wanted to say that it's not going to consider for Glamsterdam, because there's so many other things, and if we're going to quote unquote, do it correctly. It's going to be a pretty large change. And that was like what a lot of the motivation for 7, 9 0. 7 was was that it's not gonna happen for Glamsterdam. It probably won't happen after Glamsterdam. So let's try and do something now, and I'm not saying that. No, we've had a lot of time. It's still unclear. Maybe it's good to just take it out. But, like, if we take it out, it's not going to Glam so damp, that's almost certain.

Tim Beiko: Because you think that like I don't know if we do like block access list or fossil or apbs. It'll just be too much to do this at the same time, or.

Lightclient (Matt Garnett): I mean to do it right. It seems that most people think that code chunking is the right thing to do. The.

Tim Beiko: Okay. I see.

Lightclient (Matt Garnett): Compatible thing, and that's going to be big.

Tim Beiko: I see? Yeah, yeah.

Lightclient (Matt Garnett): And so the way I think about a lot of these changes is that coach hunking is a 5 year old proposal. It seems like the right idea to do at some point in the future. But the future is uncertain.

Tim Beiko: And.

Lightclient (Matt Garnett): You know, people really want larger coat contract foot sizes. I get it. Fusaka is getting delayed by these decisions now. So it's probably the right thing to do to just drop it. But like, I wanna make sure that we're clear that if we drop it, the contract website is not gonna change for potentially years.

Tim Beiko: Thank you, Derek, and then to Derek, and then Charles.

Derek Lee: Sh! Sure, thanks. I just wanna like huge plus one behind. What? Like client just shared. This is our concern as well, and we genuinely believe that this increase would help developers a lot sounds like there's little to no appetite for delaying Fusaka as it is to even have some sort of or form of 7, 9 0, 7, But we, we feel strongly that like this is a huge benefit, if we can include it to include it. Now.

Tim Beiko: And I guess, Derek, there was a question in the chat. Do L. Two's want more blobs sooner or bigger contract sizes. So you're saying, you would rather have less blobs. Yeah. The the blobs coming in at a later time than this. Hi, potus.

Potuz: Yeah. So I don't really understand the issue with arbitrum, but it from from the little I understand. It seems to me that what they need would be 7,907, without any changes on l. 1. That would make it easier for them to maintain an increase on l. 2, which is what I suspect, what they actually need. I don't understand why L. 2 s. Would actually care about increasing the current contract limits on l. 1, and if it's no changes on l 1, perhaps that's doable, and that's less dangerous for us.

Ansgar Dietrichs: Yeah, that's always the problem with Evm equivalents, though, like, you can't really make changes on L 2. Because then, if the l 1 ever changes, which sounds like we will at some point do. Then you're basically out of sync, and then you have to find a migration path to bring the L. 2 back into sync with how the l 1 handles things, and it becomes a huge mess. So that's why generally l. 2 s. Are very, very reluctant to ever make such changes on their own.

Tim Beiko: And Charles.

Charles Cooper: Yeah, I wanted to point out another approach is shipping 79 0, 7, with an even smaller limit, such as it's already been reduced to 48 kB from the original 256 kB, and it could be shipped with maybe a 32 kB limit, or something like this. And as for shipping, 79 0 7 without increases, I think that's a little weird, because you don't know it's like a code path that's untested or like. It's a dead code path in production. So it might be very easy to have like consensus consensus issues.

Tim Beiko: And would that make people feel more confident? About 7, 9, 0, 7, if we reduced it? The 32. Yeah. Okay. Roman, yeah. Romance is no, and on scar as well. Like, yeah, my sense is like like the complexity of the mechanism. That's the that's the main bottleneck. yeah. So I guess we should assume if we do remove it. You know we can obviously propose for Amsterdam, but the odds of it being accepted are uncertain. So we should be fine with. you know, not having it go live for some period of time. I guess the question is like, Yeah, do client teams do client teams thing that it's worth removing this to make sure we get the ship. Osaka slightly quicker.

and I think Beizoo and Nethermind originally said they would rather drop it. Yeah. Yeah, Charles.

Charles Cooper: Yeah, I'm kind of curious from the client teams or the leads, or whoever's opposed to this, like what exactly they would want to see in order for it to be okay, to go in. I know codecrunch has been discussed, but there isn't really a finalized dip, as far as I know, and if we know what the blockers are for this getting in, then, either for free Soccer, Glamsterdam. I think it would be really good to have more clarity.

Marius van der Wijden: I think the problem is, we we don't know. like I have a list of stuff that I would like to see, and Johan has been working on it. But those are just the things that I was that I thought of, and I don't know. The more I think about it. The list grows longer and longer about edge cases. And I think my biggest argument right now is that the biggest argument that I see right now is that this mechanism is not future compatible. So we will need to change the mechanism anyway. And yeah, I don't. I don't know if we? We should enshrine this mechanism for potentially one or 2 hard folks. when we can either get the benefit with something very simple.

or go for the for the full proposal. That will be future proof in in the Ck. Evm. Fold.

Tim Beiko: Okay? I guess maybe one other data point. So Onskar asked in the chat. How people feel about it. And the emoji react. most of the responses would would remove it, but, like notably, it seems like pretty much. All of the testing team is in favor of removing this, I assume, due to the bandwidth it would take. And the biggest issue we have with tiered asses like, you know, our lack of testing and and focus on that. I think, based on that. I would lean towards removing it and not making another change, so that we can actually focus on on shipping period us. We can obviously have the conversation of like exactly what we want to see and which benchmarks we want for for Glamsterdam. But giving like testing is on the critical path at this point, and at least like a

decent subset of the client. Teams or client Devs want to remove it. I would lean towards just removing 7, 9 0 7, not doing any variant of it in this fork. And yeah, trying to make sure we can move to a spec freeze and testing Fusica as quickly as possible. and the implication is, yes, we can re-propose this for Amsterdam, but you know it's either we would need to include code chunking, which, is a significant lift or you know, have some better benchmark on a simpler proposal. But there's definitely no guarantee that it would go in. So yeah. Last call. But I think we should just move forward. Remove 7, 9 0, 7 from Osaka.

Okay? So we remove 7, 9, 0, 7 this changes the spec obviously for devnet 3 the other quick thing I wanted to flag in terms of the spec is that we also merge this Pr to reduce the maximum transaction size and then I think this is basically the finalish list of things for Devnet 3, and let me pull up. Barnabas shared the link a bit earlier. sorry I can't find the link, but oh, okay, I'll repost it at the bottom of the chat. That's quite far. Oh, thank you. So given this do. If we don't have 7, 9 0, 7 and then there's some updates to pure. Das the gas in a cap

to a couple of the eips. How the clients feel about timelines for Devnet 3. Is is it something we still think we can? is it something we still, we still think we can deploy next week? Yeah. 23rd of July that people think, is this realistic for definite 3 without 7, 9, 0, 7. Okay, we have some thumbs up. So we'll have at least some clients on the net. 3. I'm great, so let's aim for that And then we were kind of out of order here, but I think it's also worth directly talking about, like the rollout schedule for for Fusaka to make sure we're all on the same page. again, like when we shipped spectra. And there were these issues. We came up with this proposal, where we wanted to have 30 days, both before the 1st testnet and after after the last testnet before mainnet there's definitely been some push back on this in the coming weeks, so I think maybe a good place to start this. I know, Frederick, if you want to like.

give a bit more context around. why we decided on those numbers and like, why, it's important. And then we can see if we want to stick to them or change, or if people have concerns.

Fredrik Svantes: Yeah. So we had the Hodeshki incidents which kind of initiated this whole process to to start thinking about how we should be planning the the hard forks. The reason we picked 30 days between the clients release and the 1st testnet was basically to give enough time to have audit competitions. We wanted to have the the ability to have people reviewing the final code bases. both internally and externally. And yeah, doing it in 2 weeks is quite tight. Especially if something is found towards the end of it.

So that's why we picked 30 days between. The 1st client, client release and and test that the the other thing for the 30 days between the last testnet and mainnet was basically because we wanted to be sure that we had enough time to verify that everything was actually working as intended, so that after like, if we would have done a Mainnet release 2 weeks of the last testnet, and then something didn't really pop out immediately. Then that could have effects on the main net, and, you know, potentially end up with downtime or or similar. so the reasoning is, we just want some extra security to do that. And then. as you mentioned earlier in the call. There's been other

l twos and such. That's also expressed a desire to have 30 days so that they can have enough time to implement stuff on their side for the hard forks.

Tim Beiko: Thank you. One question I think this raises is, what's the level of finality that we want on the test net releases? Because obviously, if we assume that we want the test net releases to be as close as possible to the main net release, then we should almost, you know, have a much higher bar for that, and then assume that like, maybe the path between the last testnet and mainnet is is a bit shorter. On the other hand, if we assume that maybe it's fine. If the 1st testnet release is not as a final, let's say the the main net. Release it. It may be fine to have a bit less time between like that release and and the test net, because we're still testing

Fredrik Svantes: I think it depends a bit on how we see the test notes. Like, if we're okay with them breaking like it happened in Lasky. Then I think that's I mean we could shorten the time. We could probably do 2 weeks if that's the case. because if if it ends up breaking, and we don't really worry too much about that on the testnet. Then that seems like a reasonable timeframe. But if we want to ensure that the test nets are up and running, and we don't have the same incidents.

Parithosh Jayanthi: We got from the community. He says that we're not supposed to break test nets.

Fredrik Svantes: Yeah, yeah, that's so. In that case we should we? We should be doing our best to to minimize that that risk. I mean from from change point of view. I will like when we've done these audits and the competitions in the past, there's been findings, and we obviously clients are updating. But I would expect that there aren't like massive changes between the release candidate and the the 1st testnet. But it's primarily things like. yeah, fixes.

Tim Beiko: Right? So I guess, like, yes, the the bounding constraint is almost like, when do we want to have a client release that's ready for like a proper security review And then we assume that some clients will have some bugs through that process. and obviously we don't want that to happen on Mainnet and I guess, and and so I guess I guess the maybe the difference here is like you you want to release. That's like stable. And you know. you think works for the 1st testnets. But but you also want time to like get bugs. So like, why should should we just start basically the should, should we basically just start the security reviews on the 1st testnet release? Would that like buy us some time? And then if if we find some like weird edge case.

hopefully, it doesn't bring down an entire test net, but the yeah, like the the issues we found on ho! On like Holeski last time. We're not like security. We're we're not outcomes of the security reviews. They were more like configuration issues. Whereas, as I understand it, a lot of the Security Review stuff found, you know, pretty pretty unique edge cases that would require some amount of like ingenuity to to exploit. yeah, so is it. Is it reasonable to say, like, we have to, perhaps a shorter path to the test nets. We assume the releases on the test. Nets are stable. We then do like a thorough security review of them, and we want to have a longish period of time for that. Before we actually have the main net release.

Fredrik Svantes: I mean it will. It will increase the risk of something happening on on the testnets. I mean, that's that's the only thing. Like, yeah, there. There were consensus issues and other things that were found. I don't know about the likelihood of someone exploiting that on testnets to to cause issues, etcetera. But obviously things can be found that could have an impact on the test nets.

Tim Beiko: Yeah, yeah, obviously, you know, you don't have a hundred percent certainty. But

Fredrik Svantes: I mean, the idea would be that we start the audit competition on the on the day that the clients have a release candidate for the 1st testnet out, and that's the current plan and probably run it for 4 weeks. Obviously, that could work. Still, if the test net is launched after 2 weeks. It just means that there will be a 2 week period where the competition is still running. so people will have time to find issues. The kind of barred thing here is that these changes are quite complex. It usually takes a few weeks for people to kind of wrap their head around the changes and and start finding issues. But again, if it's.

Tim Beiko: Is there a way? Can we just announce it before? So like, I imagine that you know, in the 2 weeks before the competition starts. Clients have code that's like pretty close to what will be in their final releases. Obviously, they might still be fixing some issues. but in a way, it's like, yeah, could you could you get people to start reviewing? And then the, you know this sort of previous release with the expectation that's like, only the test net releases in scope for the bug bounty. Because obviously, if they're fixing bugs before the like test net release

Fredrik Svantes: Yeah, I mean the the announcement about the competition and guides and stuff will be released earlier. so some people would probably do it. The other thing that we're doing is that we're opening up the bug bounty program ahead of time. Once things are seen as ready. So once the spec is finalized, for example, that that will be in scope of the bug bounty program. Once Client X has completed their implementation of the feature Y, then that will be in scope. So that will be updated and so we will have quite a few features in the bug bounty program ahead of the 1st official client release, so that I think that would help so helped with finding issues. Early on.

Tim Beiko: Okay, yeah. I see, Soyuz said. It's up for a while.

Saulius Grigaitis: Yeah. So I already wrote that on on the chat, but wanted to raise this that. I think we have a quite unique situation with with the test nets. Now, with which is you kind of still fully functioning, but at the same time is going to be sunset quite soon. So so my my idea would be. Maybe it really makes sense to try to to do a holistic upgrade as as fast as soon as possible, and you know, if I mean it, it will. It will be a very good indication how ready we are for for the serious deployment of Osaka. So I mean, if if something not good happens, then well, anyway, that the this test net is going to be to sunset quite soon.

Tim Beiko: Yeah, I I think it makes sense like we, you know, we should definitely deploy the wholeshki and see if there's any issues. I don't know if we even need to treat it as like a public test that like we can like, I mean, if we need like a full announcement, and all of that given. There's not that many users. But the yeah. The timeline could be quite, quite quick here. I guess the the one thing. none of this kind of changes is like, yeah. to the extent we want to do a lot of testing potentially an extra test net. I think it means we. We have to have the client releases for the 1st test that's out. Sometime late August, early

early September. Is this like somewhat realistic if we freeze the scope now. and what do we need to do. you know, in the meantime, to to make this happen? Because there's a lot we can chat about the specifics of Peer Das on on next week's call, too. But Is that just the the main thing is focusing on pure Das testing is there anything else specifically on the El side that we should be doing over the next month or 2? Okay, so this seems to be mostly a Cl testing thing, and on the El we removed the most problematic eat. so I think we can. We can wrap this up. We don't have to obviously set the dates today. That wasn't quite the intention, but more to like highlight that

pretty much independent of the specifics of like the the ordering of test nets and whatnot. If we want to ship sometime in November, then we have about a month and a half to 2 months to get to a spot where we're forking the test nets. And that should be How we're thinking about it. Anything else on Fusaka that people wanted to discuss. Okay, then, next up at Amsterdam. So we agreed last time that the next 2 calls on the El side. Following this one would be the calls where we where we try to figure out the headliner for Glamsterdam. Most, if not all, of the client teams have shared their preferences in the past in the past week or so.

So I think it might be helpful to get at least on the El side, an overview of the different teams. And then try to highlight like, okay for the most likely headliners. What do we want to figure out in the next couple of weeks. block, level access list and fossil seem like the 2 biggest ones that have come up repeatedly. Obviously, Pbs is, is quite popular. But I think that's been, or that's obviously mostly a Cl thing. So we we don't have to focus on this too much here. but yeah, I guess from the different el teams it would be good to hear like, what do you think? Oh, and and sorry, Potus. I don't mean that like

I don't mean that epbs should not be the headliner, but more that like it's mostly a Cl. EIP. And I don't think there's any work on the El, so I want to make sure that, like we zoom into the preferences on the el side. Yeah. And then next week, obviously, we can discuss Dbbs in depth on the on the Cl call. But yes, the 2 that come up consistently are block level access list and fossil on the outside. And yeah, I guess it would be good to hear from different teams like. why do you feel this way about headliners? And then, if there's uncertainty or things that they still want to figure out, what are those, and how can we answer them in the next in the next month or so? Are there specific people that we want to weigh in parts of the community? Are there some other discussions we should have or schedule.

yeah. And Ben.

Ben Adams: Yeah. Block level access list is the most aligned to the strategic focus of Amsterdam. In terms of scanning the other one.

Tim Beiko: Okay, thank you. Hi, everyone.

Roman: One thing that I would like to be figured out additionally for a block level access list, if it is possible not to keep them around for a long time. like for for clients, just to use it for a month or 2, or worth of recent blocks. because otherwise it just still data that.

Tim Beiko: You mean, like, we could prove them like the blobs, basically.

Roman: Yes, yes, exactly.

Tim Beiko: Okay, yeah. does anyone have like a quick take on that or otherwise, we can sort this out, I think. But it is an important question.

Ben Adams: Yeah, if we if we maintain a block level access list as route in some way. then it can always be. They can always be rebuilt by rerunning the block, so, therefore, they could be joined.

Tim Beiko: Okay.

Justin Florentine: Do we think that history expiry covers this.

Tim Beiko: It's a different time scale, though. Right like history. Expiry like now, is pre merge. And maybe we'll get to like a rolling window. But we're not there yet, so I.

Justin Florentine: That's specifically what I mean is the rolling window.

Łukasz Rozmej: So you can think of keeping block access list in the history if you want to keep them forever. Anyway, it would be equivalent of keeping archive note in history, right? In a way. So basically, you're running an archive note from the point of block access list being added. So I'm also for trimming it.

Tim Beiko: Andre.

Ansgar Dietrichs: Yeah, I just wanted to to. Highlight said that in chat that I think if we, to the extent that we agree that scaling is the kind of the theme on the El side for Glam Saddam, which I think I mean fossil, is a bit of a special topic. We can talk a bit about fossil. But but other than that, I think people broadly seem to roughly agree on this. and then I think headliners, in a sense, are less of a clear cut fit on the El side. Yes, I think buckler boxes list. We decided to make it a headliner. Maybe it can be a combined headliner with something on the Cl side or so. But I think that's a bit more of a stand-in. It's clearly a smaller feature. I think it's going to be great for scaling, but I think even more crucial through scaling on the L side will be repricing like you can imagine if we ship just buglar boxes list. But we don't change the price relative to say data.

and then we can't scale more at all. It won't give us any more headroom, because bulk level access don't help with data. Right? So basically, now, data would just be the bottleneck. So clearly, block level access already needs to come with some sort of repricing to even make any use of it for scaling. But more so, I think basically, there needs to be like this broad repricing effort. And there's already a lot of work ongoing on this. But across compute across state, across data that also requires a lot of much more rigorous benchmarking. All of this is ramping up in the background. But I think the headliners here really are not the ideal instrument to express that, because if I think about what in my mind would make it worth delaying. Gram Saddam. In a way I wouldn't even care about block love access list if that for some reason takes more time. We can always push it like we could not ship Glam Saddam without repricings, because otherwise we're basically just completely capped in terms of scaling, so just wanted to say.

repricing is obviously not a headliner, but it's, I think, to me, at the very core of scaling on the alpha.

Tim Beiko: Great. Thank you. Hi, Justin.

Justin Florentine: Yeah, I think I want to challenge a little bit of what Anskar said with regard to having different headliners for the El and the Cl. I'm not sure that's a thematic approach we want to take. There will inherently be conflicts there, you know. We think that censorship resistance is perfectly fine for a headlining theme across both layers and still accommodates pursuing scale via block access lists. You know, and there are a number of scaling improvements that you get with things like epbs. So you know, I would want us to think a little bit more deeply about having split themes and split headline intents, if you will, across the different layers. I don't think that these are mutually exclusive, and I also think that maybe we should take a deeper look over the next week. With regard to some of these code chunking ideas as well, I know that we are planning 2 weeks to consider headliners, and if the contract size thing remains an issue that folks are concerned about. Since it's being dropped, then we should accommodate that.

Tim Beiko: Yeah, I guess one question. Yeah, maybe answer question is, you say you don't want 2 headliners. But then you say you want Epvs and fossil.

Justin Florentine: No, no, I said, I didn't want 2 themes, and to me epbs and fossil are very much the same theme.

Tim Beiko: Okay. Roman.

Roman: Yeah, I wanted to voice support for Ansker said. In our view on Glomsterdam headliners. We mentioned that having balls as a headliner for El is a little bit underwhelming because it is a high impact change, but it feels like it requires much less work than then. The the headline bar. so we would like to see something else. the bundled alongside balls on on the execution layer, and maybe, I guess where pricing is that.

Tim Beiko: Yeah. And obviously, we can do more eips between that. But I think it's important to say, like, Yeah, this is like the main thing. And it's true that access block access lists are maybe not as like they're clearly not as big as something like epbs. Yeah. And let's do Justin. And then Ben.

Ben Adams: Yeah, I I just like to to highlight. Well, one block level access list by itself isn't necessarily that big. But making use of it and doing parallelism, doing improved syncing, it becomes bigger. However, even though it's Cl, I'd I'd like to highlight, you know, epbs and variants like it are quite important, because all of all of the El changes essentially, you know, from fossil to bowls to even resource repricing would all imply larger blocks. So yeah, there we go.

Tim Beiko: Thanks.

Łukasz Rozmej: 1 1 thing about pulse, if I can chime in, is that Camille was doing some testing on the Bloatnet State Bloatnet, and at some point with very big state and head blocks are very like they were modifying the state, using all the gas to modify the state at some point. I don't know the exact details. Clients started to have problems with healing when they were syncing, because each block would change the tree so much that they had problems with healing, and the balls would help here definitely, because all that data would have to be discovered. It could be just taken from the access list. So there's a like a scaling limit with snap sync healing, which we will potentially hit at some point at least at the edge case. And this could be a remedy.

Tim Beiko: Okay, So I guess. Yeah. 1 1 thing that, the block access list needs is just like, yeah, more research. After dropping them, we should figure out if we do want like a code chunking or if if we do want like a code chunking or re contractor pricing headliner proposal. This is something that someone should put together in the next 2 weeks. We are already past the headline and deadline. But if yeah, if court does feel this is important, then we definitely need someone to like own that does anyone want to volunteer for this.

Justin Florentine: So I asked this question in chat, and it was a little bit crickets of a response. But can anyone post links to the current code, chunking designs, if any. I think that's gonna inform whether or not this is even a viable to eip.

Tim Beiko: Okay. okay, this is coming by Sophia saying that like for Zkvm in terms of scaling the the hard requirements, or either epbs or delayed execution in Amsterdam. I guess. Okay. So we heard, actually, yeah. Aragon, I think, has, like some fairly different opinions from other teams on the headliners. I don't know if anyone from Aragon wants to give their perspective. There.

Somnath Banerjee: Well on the Cl. Side. We still think epbs is going to be a little bit controversial from decentralization point of view. But that's like a debate. But from El side it's clear to us that block level access lists are going to be the kind of headliner, and of course. just implementing the specs of it is not the end of the game. You'd also have to supplement that with implementations of parallel execution that supports it. So we'll be focusing on that as the headliner. Of course there are going to be, and I expect them to be more eips, supplementing, scaling, and other targets that we have.

Tim Beiko: Okay, do any of the client teams have other opinions they want to share. I I we kind of didn't go through the list. That's super cleanly. But yeah, any other teams have strong opinion. Okay? Actually, yeah. Andgar has a question in the chat around fossil. So I think fossil is a bit of a tricky one where it's it's not clear. if it's an El or cl topic, it obviously involves both. I think it's something that a good chunk of the teams felt was like, if not a like number one priority, at least something that should be like considered as a stretch goal or for the next fork. I my vibe space intuition here is that like combining it with, say, Epvs in a single fork is

probably too much. But what? Yeah, how the client teams think about this, like the relationship between fossil epbs and potentially some of the other el vips around scaling like block access to the survey pricing. Yeah, I'm on, not Roman.

Ahmad Bitar: Yeah. So the Nethermind team feels that fossil should only be implemented after or alongside epbs. as like doing the restructuring and the bandwidth expansion does is kind of a prerequisite kind of like, not really prerequisite, but like it makes more sense to do the restructuring and bandwidth expansion before implementing fossil and and balls as well.

Tim Beiko: Okay. Everyone.

Roman: I just wanted to say that on, we wanted to put fossil as a strategy goal, and it is upon Cl teams to evaluate how? Yeah, whether they can fit both epbs and and fossil within within the same fork, and whether it's feasible for for us to ship both.

Tim Beiko: Oh, yeah, pull this.

Potuz: I wanted to mention. If the discussion is about like how these cips interact. I think it should be very clear. I think it is clear. But let's just explicitly state it. But block level access list and epbs don't even talk to each other. I don't really care how balls are implemented. I want to touch that code, and no one from the El cares about how epbs is implemented. We can code this in parallel. They don't talk to each other. The one thing that touches both sides is fossil and fossil is heavy on the Cl. Not on the El. It shouldn't have even been mentioned as an El headliner. It's minor on the El side. It's heavier on the Cl. Side.

Having said so. my personal opinion is what Barnabas said early on the call, we can easily. Now it seems that there's broad support. We could easily agree on trying to schedule for bolts and epbs, and actually, Cfi fossil that has broad support. I personally believe that it's doable. I'm not sure if it's doable, but I believe it to be true. That's going to take time after rebasing and actually looking at implementations.

Tim Beiko: Yeah. And yeah, I, I definitely agree with that. Like the the block access list, conversation is is like, pretty separate from Epbs. It matters. Obviously whether or not we do Eps in the grand scheme of things. And then. yes, fossil does feel big enough that there's high uncertainty whether this could all be like bundled in a single fork. So we can have that conversation, maybe in more depth on the on the the alcohol next week, at the very least, we should agree on a prioritization between them. But I think. like, yeah, we should. We? We need to decide like, okay. if we had to choose between these 2. Which one are we gonna ship? And you know, from the client teams? Perspective. So far, it seems like epbs is the bigger priority.

but and maybe the solution there is like, yeah, fossil is just like a vanilla eip. It's not necessarily a headliner, but I it does feel it. It. It does feel like fossil is big enough that it it. It warrants like that level in. Historically, we've just been very bad at trying to do 2 big changes on one layer at the same time, and maybe we should just like ship epbs as soon as we can ship. You know block access list, or repricing or whatnot as soon as we can, and then, you know, have fossil in the next work, if that's what people feel strongly about but we can have that conversation, I guess, on the Cl call next week.

Maybe one other thing I would like to look into is this idea around like scaling as a headliner and block access lists and repricing being maybe, like you know, only components to it on the el side. we get yeah. Tomorrow, if you want to go, we can do your fossil comments, and then.

Thomas Thiery: A bit about fossil, but more generally, I don't really understand the sort of policy around not being able to submit a headliner as a vanilla aip. It feels like, yeah, maybe people agree that. For so, for example, is too big for being like a vanilla IP, but like generally, I don't think like the rule is like a good one, just because it's basically your headliner. If you took the time to go on like if magicians and write to post about it, but like it doesn't inform anything about the like. The complexity of implementing it, or how well it fits with other eips or anything else.

Tim Beiko: I think I think most headliners are actually quite complex. And yeah, maybe some of them are like on the line. And this is the 1st time we do this. So it's a bit, you know. there's like some uncertainty block access list to me feels more like that where it's like, yeah, it's like a big vip. But it's, you know, if you compare it to things, we've historically centered forks around like whether it's 4, 8, 4, 4 or pure dos. Or, you know, 1559, like, it's block access list feels like much smaller. and yeah, I don't know. Maybe fossil is right at the limit where it's like a small headliner or a big vip. And it's it's a tricky edge case. But then, if you look at something like, you know. Epbs, then that's clearly big enough that, like

we, we can't do like epbs and say shorter slot times in a single fork like both of those are pretty huge. And yeah, historically, we would just waste more time trying to merge them than to to like do one after the other. So I think it's important to all agree, like, what is the most important thing we want in this hard fork potentially, those things are separate on the layers because they don't interact. So I think it's fine to have a headliner per layer. We don't necessarily need to. But saying, like, you know, Epvs is the most important thing on the Cl, and then block access list or something else, is the most important thing on the El

and they really don't interact. That seems reasonable. But I I really want, like, we need to make a decision about what our actual priority is and then export and then sorry when I say, I guess the answer's comment is, you know. part of this is also, when do we want the fork to ship like to the extent we want to have quicker forks, which is something that's come up a lot in the past. Then we should just reduce the scope as much as possible. yeah, Ben.

Ben Adams: I think what you said of like a a matter. Maybe a Meta eip would make sense where we put block level access lists in there. But there, there are many other things we already know that we want to do. So some additional repricings on he compiles, and all that sort of stuff, and they would all fit under that same rocket.

Tim Beiko: I mean Tony.

Toni Wahrstätter: Yeah, I just wanted to add that I wouldn't underestimate the work that has to go into block of accesses, because, of course, the in protocol implementation might be quite trivial. But then you need to actually use them for parallelization. You need to actually use them for parallelizing between execution and the post state updates. then you might want to use them for snap sync. So there are many different things. that come after the protocol implementation and clients might need time to actually make use from them.

Łukasz Rozmej: But, Tony, we clients don't have to make use of it. asap. They can adapt it in their own on their own schedule. So that's why like it's not consensus features, so we don't have to carry them at at the fork time.

Toni Wahrstätter: Yeah, totally agree. That's that's that's quite nice. But still, if you want to use them for scaling clients at some point need to kinda make use of them. and in the end we do them for scaling. So at some point we expect clients to actually use them.

Łukasz Rozmej: Yes.

Tim Beiko: And then, if we.

Łukasz Rozmej: Clients can roll them out between the fork and the next version right? So they have more time to test it and to polish.

Ben Adams: At the very least, though you have to, we'd have to verify that the block level access lists are correct and reject the block if they're not.

Łukasz Rozmej: And generate them during book production.

Ben Adams: Yeah.

Tim Beiko: Okay? I guess one other question like, yeah, that we should think about before the next call is what do we want? The timing of the next work to be, and this will inform the scope. Obviously, we can't know. We can't know it like perfectly in advance, but like yes, to the extent we wanna have smaller forks. Then we should keep the scope as tight as possible. If we're fine having longer forks, then we you know, we can obviously add more things. But I think this should kind of play into yeah, to what extent we're willing to accommodate more features. And one, I guess one other thing we haven't touched on yet is just outside of client devs like

who are groups that we would maybe want to see, weigh in on things like fossil epbs. block access lists, or repricing if relevant like, are there people we should be bringing on these calls that or, you know, getting their feedback before the next call. I guess down to comment like that. Stakeholders want scaling, I guess. Yeah. Like, are there people like specific stakeholders. We think we should loop in and it's fine, if not. But yeah, this would be the times to start reaching out.

Okay? So no strong opinions. And then, okay, the last thing maybe I wanted to propose is that so we you know, we have these headliners. What do we want as a deadline for people to submit just like normal eips for the fork to to do these proposals? Do we want to say that, like the proposals for regular eips, should end like when we select the headliner when Fusaka goes, live some other time. How do people feel about this like. Historically, we've had proposals come in quite late in the process. So it's probably better to set a deadline that reflects reality than to like optimistically say, Oh, you know, we want them to all be there in August, and then in December of this year, we're still adding vips. But yeah, curious. If people have strong opinions on this.

Justin Florentine: Is it realistic to say that the spec is frozen, as it were, at shipping time for the previous hard fork, Fusaka.

Tim Beiko: So by spec, you mean, like the vips included.

Justin Florentine: Yep.

Tim Beiko: Okay. If we were to do that, then I would say, it means all the small eip should be proposed by the date we choose the headliner, so that you know, as soon as we're done with the headliner we can review the other ones, and currently, that would be August 21, st which is about a month from now. Anyone opposed to that.

Alex Stokes: I might be slightly, just because I'd rather focus on Fusaka and not have to also be thinking about these other eips.

Tim Beiko: Right? Yeah, I guess this is, yeah. So should the deadline.

Alex Stokes: This is fine, but if you know, I think we have some breathing room. So just something to think about before we lock in a date.

Tim Beiko: One kind of weird compromise could be like the Fusaka testnet releases or the 1st Fusaka testnet fork or something. but yeah. and we don't. Yeah, we don't have to settle this now, but As we finalize the headliner, we should be clear about what our deadline is, and then, if if we finalize the headliner one month and we haven't solved it in one month, and we haven't solved this. Then I think we can't say like, oh, now, proposals are closed. yeah. okay, Maris is saying. Repricing will take more than one month to be finalized. I think. Then, yeah, clearly, it's not realistic to have the final proposals for the end of the headliner selection. So let's see how things go, and we can set a deadline

a bit later on. and if people want to propose the Ips that are not headliner, just open a Pr. Against the Meta eip for the fork and listed there, and once we're done with the headliner conversations, we will get back to that list. Barnabas.

Barnabas Busa: If you want to ship a fork by, let's say next year this time. Then that means we actually need to get people to start looking into and working on epbs and access list. At least one dev per client team. This is the exact same thing as what we did for peer desk. And that is why we are actually able to ship this year and not sometime next year. and the sooner we decide in what is actually gonna go into Amsterdam, the sooner we can actually get people to dedicate a specific person into this problem. and the sooner we can have ball and up and running parallel to Futaka. and I actually disagree with Stokes. I don't think we need every single person from every single team focusing on Fusaka, because that's counterproductive. What we need is we need better parallelization. And we need more devnets. And

basically, that's the only way we can ship faster.

Tim Beiko: I guess one question there is. The Cl teams feel like next week on the call. They could actually decide. Like to go with epbs. If so, then I think we're in a good spot, but it feels a bit weird to make a decision about the cl headliner now. But if we can agree to make the call for the cl headliner next week. then, yeah. It feels a bit easier to then tell teams like you should have someone on this.

Alex Stokes: Yeah, I'd rather focus on Dev. Note 3 for the next week or 2 until it's up and ready before opening that topic.

Barnabas Busa: I mean, every single client team has made their blog post, and every every single one of them clearly said that they want to do like.

Tim Beiko: I think every yeah. Aragon is maybe the only one, and it's like an El team. So I think every Cl team has said the Pbs and the vast majority of El teams. Yeah.

Alex Stokes: Right. But we also said we wanted to bring on more community input. And so this is something we're working on and that's just gonna take some more time.

Sean Anderson: Yeah. So just wanted to say for lighthouse. We put out a blog post. That was Mark's opinion on Epbs, and I think a lot of the team feel similar to Mark, but we're not entirely on the same page, like line mentioned in the same in the in the chat he's working on like a write up on his point of view. And also I just wanted to say, we've had Mark pretty much full time on Epbs for a while. So I think other sales teams are probably in the same boat where we're already dedicating a fair amount of effort to it. And it's I don't think it's detracting from the pure desk development. So far.

Alex Stokes: Yeah, Perry has a comment here that could be interesting. So like, sure, we can go ahead and signal the intent. But then have again, maybe another period of a few weeks to get community input and see where that takes us.

Tim Beiko: Okay.

Parithosh Jayanthi: I do?

Tim Beiko: And.

Parithosh Jayanthi: So with that approach, we have to also figure out whose input we're looking at. I think Twitter sentiment doesn't really work. So whose actual input? Are we waiting for over the next couple of weeks? Who do we need to reach out to.

Alex Stokes: Well, I think it depends on the headliners. But you know, for example, if we say Epbs is the headliner we want on the seal. Then, you know, we can bring in all the different players there. Anyone else we can think about who might be impacted.

Parithosh Jayanthi: Yeah, I think right now there's a strong signal for Epbs and block level access list. So taking these 2 as a signal from the Cl. I guess the next step is getting a signal from the community, so we should have a straight path from who these eips affect to, who we need to talk to right.

Alex Stokes: Yeah, I think for Evs, it's pretty clear for Bil's maybe less clear.

Roman: If I may interrupt, isn't there like a weird recursive relationship where we need to community input to decide the headliners? But we need like some soft commitment to the headliners to to decide who in community to talk to.

Tim Beiko: I don't think that's yeah. That doesn't seem that crazy. Like, I think, like, we've clearly narrowed down the set. There were like, what like 9 or 10 things proposed as headliners as I checked and now it's clear that, like you know, on the Cl side Epvs is like, you know, the main contender fossil is like, you know. something that a lot of people want to see, and there's some uncertainty and then block level access list feel like a no brainer. So I think it's yeah. It's it's it's not like it is a bit. It is a bit of like a a a circular dependency. But you kind of shed part of the circle at each round or something. Yeah.

And I do think, like, yeah, the the Cl side is more complex here versus the El side seems pretty straightforward. Yeah.

Roman: Yeah, I I just strongly agree with partash, like, if we're delaying the the decision because we need to talk to the community, we need to understand who who in community to talk to.

Tim Beiko: Yeah. So I guess on the oh, yeah, Alex, please.

Alex Stokes: Well, just to kind of a side comment, just to make that point a little clearer, like data always was here in the chat, saying, you know, they're working on a sort of their view of epbs. And again, I think it's just kind of this thing where more information is better, you know. It could be the case that there's some angle of perspective they see that helps us inform the design, and you know, even downstream of like do we do it or not? Like you could imagine in both worlds. you know, just having more people look at the problem is probably going to lead to a better solution.

Tim Beiko: Yeah. And that plan as well.

Roman: Okay. So just to put it into words, we're just giving everybody time to give their input. Given that all of the teams already published their opinions. So if people don't give input by the next Ecd, we assume that they're fine and we can make a final decision, then is that correct?

Tim Beiko: Yeah, I would think so. Like, I think, you know, if we said we needed 2 calls, and we end up making a decision on one that seems reasonable, but I do feel a bit uncomfortable saying, like we kind of signaled that we would make this decision, you know, not today, but 2 weeks from now and potentially 4 weeks from now. And if we kind of front run the community and we say, Oh, like, we just chose block access list like it feels a bit off, and if on the El side, if it's like so straightforward, then it shouldn't change in the next few weeks, and I think on the Cl side, then we will benefit from having more people weigh in and again, potentially at after next week. We all feel like, okay, epbs is still like the main thing, and everyone's happy with it. Then, great, let's just commit to that.

But I yeah, I don't think that, like we I I don't think that like we gain much by making like a hard commitment today, especially given where Fusaka is at and again, if, like things are so clear, then they should still be clear in 2 weeks. yeah. I think that's all we had on the agenda. Anything else people wanted to bring up before we wrap up. Charles.

Charles Cooper: Hello, I just wanted to follow on this 79 0, 7 discussion. I paste in the chat. Basically, I had an alternative, Vip. 7,903, which only touches the net code limit, and I was wondering if I could propose that as an alternative to 79 0, 7 for Fusaka, because it's not as ideal, but it does give some of the same ux benefits because it allows you to deploy groups of contracts in a single transaction.

Tim Beiko: Unless every client team has like a full implementation already, and the testing team has a full test suite. I don't think we should add anything to Fusaka at this point. I assume that's not the case for 7, 9 0, 3. But if that's.

Charles Cooper: In some way. It's a stripped down version of 79 of 7.

Tim Beiko: I'd be curious to hear from like testing and client teams like, is this like trivially easy to do, and something we want? Or I think if it adds any like complexity or uncertainty, we should not do it in for Seca. Okay? 7, 9, 0, 3. Yeah. It doesn't seem like there's strong support or understanding, so I would lean against it.

Charles Cooper: Is that something that we could discuss on the next Acd. At least people and take a look.

Tim Beiko: I think we're already like like 7, 9 0 7 was already like the last minute extension that we did past the deadline as this like a final attempt to include something, and that turned out to be more complicated. But yeah, I don't think like trying to understand or add new vips at this point makes sense. Yeah. But yeah, obviously, we can discuss it for Amsterdam. But I think for Fuseca we remove 7 9 0, 7 and call it a day. Anything else before we wrap up. Okay. thanks, everyone. And yeah, let's get them to 3 up I'll update the Meta Eip to remove 7, 9 0, 7, and we can talk about the headliners some more next week for the Cl. Call.

Talk to you all soon.

Fredrik Svantes: Thank you. Thank you. Bye-bye.

Justin Traglia: Bye, everyone.

Marius van der Wijden: But.

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