Tim Beiko:especially in light of like the process we discussed after Petra going. Live as we can discuss this, and then there's a
Transcript
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:But yeah, to kick us off. This Panda Ops want to give an update on the Fusaka devnets.
Barnabas: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.
Barnabas: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.
Barnabas:There's a lot, Starbuck, where it is doing excessive polling and getting banned by different peers.
Barnabas: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.
Barnabas:They have a bug in the our builder right now still working on the rebase from the rest side.
Barnabas:And ideally, we can get the workflow working by end of this week.
Barnabas:Small. Your smaller issues Lucifer and Taku are waiting for a finalized
Barnabas: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.
Barnabas:Prism metadata field is missing, and the blob schedule for lighthouse is in descending order instead of ascending order.
Barnabas:and there seems to be a lighthouse minority for always prepare payload flag for
Barnabas:trying to build all the blocks in the I'm using virtual
Barnabas:and for prism the blob schedule is still missing from the spec. Beacon Api.
Barnabas:Thank you.
Tim Beiko:And any client teams have anything they want to add to this.
Tim Beiko:Oh, prison has a Pr. To fix that issue about the drop schedule. Parents said in the chat.
Tim Beiko:any other comments, thoughts from deadnet or sorry from client teams about deadnets.
Tim Beiko: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
Tim Beiko:the overall timeline for Petra or sorry for Petra, for Fusaka because after Petra
Tim Beiko: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
Tim Beiko:the other thing that came up was that on the Ef security side.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:and we discussed this a few months ago.
Tim Beiko:So assuming we followed that and then everyone says, we want to ship Fusaka this year.
Tim Beiko: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
Tim Beiko:we would have to have clients releases sometimes late August. And I know that Alex also had, like a
Tim Beiko:a shorter proposal in terms of the the schedule
Tim Beiko:but even that basically had the clients releases come for the 1st testnet around early September.
Tim Beiko:So I think regardless of like the specific rollout schedule that we have.
Tim Beiko:if we want a good chance to like ship before Def connect
Tim Beiko: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
Tim Beiko:at the end of August, or sorry have releases for the test notes at the end of August, maybe early September.
Tim Beiko: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
Tim Beiko:But yeah, I'll pause here. I guess I'm curious to hear from fine teams, like, 1st of all.
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:Okay? So I maybe a better version of this question is if we said, we're aiming.
Tim Beiko:Yeah, if we said we're aiming for client releases. For, say, you know, the 1st testnet
Tim Beiko:8 late August like.
Tim Beiko:does any client think this is not possible? And then there's a point here around pure desk testing.
Tim Beiko:So I don't know. Yeah.
Tim Beiko:does anyone on the peer to side want to give some context there and like what they would see as the ideal
Tim Beiko:testing scheduled.
Parithosh Jayanthi:And.
Manu: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.
Parithosh Jayanthi: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
Parithosh Jayanthi:all the client changes pushed into branches that are mostly stable.
Parithosh Jayanthi: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.
Parithosh Jayanthi: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.
Tim Beiko:or like, I don't uncertainty with regards to Defnet 3 is Eip 7, 9 0, 7. So the code size limit increase.
Tim Beiko:it seems like there's still many unresolved questions, and we've been looking at it for basically a month. Now, post, interrupt.
Tim Beiko:So yeah, would it accelerate things to remove 7, 9 0, 7 from Fusaka?
Tim Beiko:And are there other things that we could do that would accelerate.
Justin Florentine (Besu):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
Marius van der Wijden: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.
Marius van der Wijden:And so I believe we should, rather rather than working on this this quick fix we should we should work on the final mechanism.
Marius van der Wijden: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
Marius van der Wijden:in my opinion we haven't figured that out yet. So.
Tim Beiko:Thanks.
Tim Beiko:Roman.
Roman:Breath's point of view is that the
Roman:the biggest source of contention on the cap is the pricing adjustments.
Roman: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
Roman:we morph the 7 9 0 7 into the variant that was proposed during Berlin interrupt, which is a plain code size increase by
Roman: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
Ben Adams:it would be a bit disappointing if we didn't have any increase in code size.
Ben Adams:and that's a much, much simpler change.
Tim Beiko:Right.
Tim Beiko: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.
Derek Lee:I'm curious if to hear from folks, if the concerns kind of apply also to that modified
Derek Lee:approach of just raising it by, you know, 50% and calling it today as Roman
Derek Lee:described previously. And if you know the concerns, there are alleviated, or at least mitigated. This would be where we would
Derek Lee: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
Tim Beiko:performance, and especially at like higher gas limits. Is this like.
Tim Beiko:I assume there were some reasons why the the
Tim Beiko:the limit was set this way. So like, yeah, I don't.
Tim Beiko:But I don't have an intuition for
Tim Beiko: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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 (vyper):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
Charles (vyper):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
Charles (vyper):basically per unit of gas, whereas 79 0 7 is much
Charles (vyper):more strict in terms of how much code you can load per unit of gas.
Tim Beiko:Right?
Tim Beiko: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.
Tim Beiko:even with like ace, small bump
Tim Beiko:which will take time to like test and review.
Tim Beiko: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.
Tim Beiko:quote unquote right way to do it for Amsterdam.
Tim Beiko:it would be pretty bad if we
Tim Beiko:if we I don't know, agreed that like a
Tim Beiko: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.
Tim Beiko:So yeah, I,
Tim Beiko: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
Tim Beiko:if we want to speed up Fusaka doing nothing will probably be the quickest.
lightclient: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.
lightclient:So let's try and do something now, and I'm not saying that.
lightclient: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
Tim Beiko: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:I mean to do it right.
lightclient:It seems that most people think that code chunking is the right thing to do. The.
Tim Beiko:Okay. I see.
lightclient:Compatible thing, and that's going to be big.
Tim Beiko:I see? Yeah, yeah.
lightclient:And so the way I think about a lot of these changes is that coach hunking is a 5 year old proposal.
lightclient:It seems like the right idea to do at some point in the future. But the future is uncertain.
Tim Beiko:And.
lightclient:You know, people really want larger coat contract foot sizes.
lightclient:I get it. Fusaka is
lightclient: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
Derek Lee: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,
Derek Lee: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.
Tim Beiko:Yeah. The the blobs coming in at a later time than this.
Tim Beiko: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.
Potuz:That would make it easier for them to maintain an increase on l. 2, which is what I suspect, what they actually need.
Potuz: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,
Potuz: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 (vyper):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.
Charles (vyper):And as for shipping, 79 0 7 without increases, I think that's a little weird, because
Charles (vyper):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?
Tim Beiko:The 32.
Tim Beiko: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
Tim Beiko:that's the main bottleneck.
Tim Beiko: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.
Tim Beiko:you know, not having it go live for some period of time.
Tim Beiko:I guess the question is like, Yeah, do client teams
Tim Beiko:do client teams thing that
Tim Beiko:it's worth removing this to make sure we get the ship. Osaka slightly quicker.
Tim Beiko:and I think Beizoo and Nethermind
Tim Beiko:originally said they would rather drop it.
Tim Beiko:Yeah.
Tim Beiko:Yeah, Charles.
Charles (vyper):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
Charles (vyper):okay, to go in.
Charles (vyper):I know codecrunch has been discussed, but
Charles (vyper):there isn't really a finalized dip, as far as I know, and if
Charles (vyper):we know what the blockers are for this getting in, then, either for free Soccer, Glamsterdam.
Charles (vyper):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.
Marius van der Wijden:like I have a list of stuff that I would like to see, and Johan has been working on it.
Marius van der Wijden:But those are just the things that I was that I thought of, and
Marius van der Wijden:I don't know. The more I think about it. The list grows longer and longer
Marius van der Wijden:about edge cases. And I think
Marius van der Wijden:my biggest argument right now is that
Marius van der Wijden:the biggest argument that I see right now is that
Marius van der Wijden:this mechanism is not future compatible. So we will need to change the mechanism anyway.
Marius van der Wijden:And
Marius van der Wijden:yeah, I don't. I don't know if we? We should enshrine this mechanism for potentially one or 2 hard folks.
Marius van der Wijden:when we can either get the benefit with something very simple.
Marius van der Wijden:or go for the for the full proposal. That will be future proof
Marius van der Wijden: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.
Tim Beiko: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
Tim Beiko:tiered asses like, you know, our lack of testing and and focus on that.
Tim Beiko: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
Tim Beiko:decent subset of the client. Teams or client Devs want to remove it.
Tim Beiko:I would lean towards just removing 7, 9 0 7, not doing any variant of it in this fork. And
Tim Beiko:yeah, trying to make sure we can move to a spec freeze and testing Fusica as quickly as possible.
Tim Beiko:and the implication is, yes, we can re-propose this for Amsterdam, but you know it's either
Tim Beiko: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
Tim Beiko:yeah.
Tim Beiko:Last call. But I think we should just move forward. Remove 7, 9 0, 7 from Osaka.
Tim Beiko:Okay?
Tim Beiko: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
Tim Beiko:and then I think this is
Tim Beiko:basically the finalish list of things for Devnet 3, and let me pull up. Barnabas shared the link a bit earlier.
Tim Beiko:sorry I can't find the link, but
Tim Beiko:oh, okay, I'll repost it at the bottom of the chat. That's quite far.
Tim Beiko:Oh, thank you.
Tim Beiko:So given this do. If we don't have 7, 9 0, 7
Tim Beiko:and then there's some updates to pure. Das the gas in a cap
Tim Beiko:to a couple of the eips.
Tim Beiko:How the clients feel about timelines for Devnet 3. Is
Tim Beiko:is it something we still think we can?
Tim Beiko:is it something we still, we still think we can deploy next week?
Tim Beiko:Yeah. 23rd of July that people think, is this realistic for definite 3 without 7, 9, 0, 7.
Tim Beiko:Okay, we have some thumbs up. So we'll have at least some clients on the net. 3.
Tim Beiko:I'm great, so let's aim for that
Tim Beiko:And then we were kind of out of order here, but I think it's also worth
Tim Beiko:directly talking about, like the rollout schedule for for Fusaka to make sure we're all on the same page.
Tim Beiko: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.
Tim Beiko:give a bit more context around.
Tim Beiko: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:Yeah. So we had the Hodeshki incidents which kind of
Fredrik:initiated this whole process to to start thinking about how we should be
Fredrik:planning the the hard forks.
Fredrik:The reason we picked 30 days between the
Fredrik:clients release and the 1st testnet was basically to give enough time to have
Fredrik:audit competitions. We wanted to have the the ability to have
Fredrik:people reviewing the final code bases.
Fredrik:both internally and externally. And
Fredrik:yeah, doing it in 2 weeks is
Fredrik:quite tight. Especially if something is found
Fredrik:towards the end of it.
Fredrik:So that's why we picked 30 days between. The 1st client,
Fredrik:client release and and test that
Fredrik: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
Fredrik:like, if we would have done a Mainnet release 2 weeks of the last testnet, and then something
Fredrik:didn't really pop out immediately. Then that could have effects on the main net, and, you know, potentially
Fredrik:end up with downtime or or similar.
Fredrik:so the reasoning is, we just want some extra
Fredrik:security to do that. And then.
Fredrik:as you mentioned earlier in the call. There's been other
Fredrik:l twos and such. That's also expressed
Fredrik:a desire to have 30 days so that they can have enough time to implement
Fredrik:stuff on their side for the hard forks.
Tim Beiko:Thank you. One question I think this raises is, what's the level of
Tim Beiko:finality that we want on the test net releases? Because obviously, if we assume that
Tim Beiko:we want the test net releases to be as close as possible to the main net release, then
Tim Beiko: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
Tim Beiko: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: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
Fredrik:I mean we could shorten the time. We could probably do 2 weeks if that's the case.
Fredrik:because if if it ends up breaking, and we don't really
Fredrik:worry too much about that on the testnet. Then
Fredrik: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
Fredrik:incidents.
Parithosh Jayanthi:We got from the community. He says that we're not supposed to break test nets.
Fredrik:Yeah, yeah, that's so. In that case we should we? We should be
Fredrik:doing our best to to minimize that that risk.
Fredrik:I mean from from change point of view. I will
Fredrik:like when we've done these audits and the
Fredrik:competitions in the past, there's been findings, and we obviously clients
Fredrik: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.
Fredrik: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
Tim Beiko:a proper security review
Tim Beiko:And then we assume that some clients will have some bugs through that process.
Tim Beiko:and obviously we don't want that to happen on Mainnet
Tim Beiko:and I guess, and and so I guess I guess the maybe the difference here is like you
Tim Beiko:you want to release. That's like stable. And you know.
Tim Beiko:you think works for the 1st testnets. But
Tim Beiko:but you also want time to like get bugs. So
Tim Beiko:like, why should should we just start basically the
Tim Beiko: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.
Tim Beiko:hopefully, it doesn't bring down an entire test net, but the
Tim Beiko:yeah, like the the issues we found on ho! On like Holeski last time. We're not
Tim Beiko:like security.
Tim Beiko: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
Tim Beiko:pretty unique edge cases that would require some amount of like ingenuity to to exploit.
Tim Beiko: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:I mean it will. It will increase the risk of something happening on on the testnets.
Fredrik:I mean, that's that's the only thing. Like, yeah, there. There were
Fredrik:consensus issues and other things that were found.
Fredrik:I don't know about the likelihood of someone exploiting that on testnets to to cause issues, etcetera. But
Fredrik:obviously things can be found that could
Fredrik:have an impact on the test nets.
Tim Beiko:Yeah, yeah, obviously, you know, you don't have a hundred percent certainty. But
Fredrik:I mean, the idea would be that we start the audit competition on the on the day that the
Fredrik:clients have a release candidate for the 1st testnet out, and that's the current plan and probably run it for 4 weeks.
Fredrik: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.
Fredrik:so people will have time to find issues. The kind of barred thing here is that these changes are
Fredrik:quite complex. It usually takes
Fredrik:a few weeks for people to kind of wrap their head around the changes and and
Fredrik:start finding issues.
Fredrik: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.
Tim Beiko:but in a way, it's like, yeah, could you
Tim Beiko:could you get people to start reviewing? And then the, you know this sort of
Tim Beiko: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:Yeah, I mean the the announcement about the competition and guides and stuff will be released earlier.
Fredrik:so some people would probably do it. The other thing that we're doing is that
Fredrik:we're opening up the bug bounty program ahead of time. Once things are seen as ready. So
Fredrik: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.
Fredrik:So that will be updated
Fredrik: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
Fredrik:helped with finding issues. Early on.
Tim Beiko:Okay, yeah. I see, Soyuz said. It's up for a while.
saulius: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
saulius:you kind of still fully functioning, but at the same time is going to be sunset
saulius:quite soon. So so my
saulius: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
saulius: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
Tim Beiko: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.
Tim Beiko:I guess the the one thing.
Tim Beiko:none of this kind of changes is like, yeah.
Tim Beiko:to the extent we want to do a lot of testing potentially an extra test net.
Tim Beiko:I think it means we. We have to have the client releases for the 1st test that's out. Sometime late August, early
Tim Beiko:early September.
Tim Beiko:Is this like somewhat realistic if we freeze the scope now.
Tim Beiko:and what do we need to do.
Tim Beiko: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
Tim Beiko:Is that just the the main thing is focusing on pure Das testing
Tim Beiko:is there anything else specifically on the El side that
Tim Beiko:we should be doing over the next month or 2?
Tim Beiko:Okay, so this seems to be mostly a Cl testing thing, and on the El we removed the most problematic eat.
Tim Beiko:so I think we can.
Tim Beiko: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
Tim Beiko: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
Tim Beiko:How we're thinking about it.
Tim Beiko:Anything else on Fusaka that people wanted to discuss.
Tim Beiko:Okay, then, next up at Amsterdam. So
Tim Beiko: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.
Tim Beiko:So I think it might be helpful to get at least on the El side, an overview of the different teams.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:but yeah, I guess from the different el teams it would be good to hear like, what do you think?
Tim Beiko:Oh, and and sorry, Potus. I don't mean that like
Tim Beiko:I don't mean that epbs should not be the headliner, but more that like it's mostly a
Tim Beiko:Cl. EIP. And I don't think there's
Tim Beiko:any work on the El, so
Tim Beiko:I want to make sure that, like we zoom into the preferences on the el side. Yeah.
Tim Beiko:And then next week, obviously, we can discuss Dbbs in depth on the on the Cl call.
Tim Beiko:But yes, the 2 that come up consistently are block level access list and fossil on the outside.
Tim Beiko:And yeah, I guess it would be good to hear from different teams like.
Tim Beiko: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.
Tim Beiko:yeah.
Tim Beiko:And Ben.
Ben Adams:Yeah. Block level access list is the most aligned to the strategic focus of Amsterdam.
Ben Adams: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
Roman:it is possible not to keep them around for a long time.
Roman:like for for clients, just to use it for
Roman:a month or 2, or worth of recent blocks.
Roman: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.
Tim Beiko: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.
Ben Adams: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 (Besu):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 (Besu):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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs:much more rigorous benchmarking. All of this is ramping up in the background. But I think
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Tim Beiko:Hi, Justin.
Justin Florentine (Besu):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.
Justin Florentine (Besu):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.
Justin Florentine (Besu):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 (Besu):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.
Tim Beiko:Roman.
Roman:Yeah, I wanted to voice
Roman: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
Roman:it feels like it requires much less work than then. The the headline bar.
Roman:so we would like to see something else.
Roman: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
Tim Beiko:maybe not as like they're clearly not as big as something like epbs. Yeah.
Tim Beiko:And let's do Justin. And then Ben.
Ben Adams:Yeah, I I just like to to highlight. Well, one
Ben Adams: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.
Ben Adams: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
Ben Adams:would all imply larger blocks.
Ben Adams: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
Łukasz Rozmej:and head blocks are very like they were modifying the state, using all the gas to modify the state
Łukasz Rozmej: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.
Łukasz Rozmej: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,
Tim Beiko: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
Tim Beiko:if if we do want like a code chunking or re contractor pricing headliner proposal. This is something that
Tim Beiko:someone should put together in the next 2 weeks. We are already past the headline and deadline. But if
Tim Beiko:yeah, if court does feel this is important, then we definitely need someone to like own that
Tim Beiko:does anyone want to volunteer for this.
Justin Florentine (Besu):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
Justin Florentine (Besu):code, chunking designs, if any. I think that's gonna inform whether or not this is even
Justin Florentine (Besu):a viable to eip.
Tim Beiko:Okay.
Tim Beiko: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.
Tim Beiko: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.
Som - Erigon:Well on the Cl. Side. We still think epbs is going to be
Som - Erigon: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
Som - Erigon:block level access lists are going to be the kind of headliner, and of course.
Som - Erigon:just implementing the specs of it is not the end of the game. You'd also have to
Som - Erigon:supplement that with implementations of parallel execution that supports it.
Som - Erigon:So we'll be focusing on that
Som - Erigon:as the headliner. Of course there are going to be, and I expect them to be
Som - Erigon:more eips, supplementing, scaling, and other targets that we have.
Tim Beiko:Okay, do any of the client teams
Tim Beiko:have other opinions they want to share. I I we kind of didn't go through the list. That's super cleanly. But
Tim Beiko:yeah, any other teams have strong opinion.
Tim Beiko:Okay? Actually, yeah. Andgar has a question in the chat around fossil. So I think
Tim Beiko:fossil is a bit of a
Tim Beiko:tricky one where it's it's not clear.
Tim Beiko:if it's an El or cl topic, it obviously involves both. I think it's something that
Tim Beiko:a good chunk of the teams felt was like, if not a
Tim Beiko:like number one priority, at least something that should be like considered as a stretch goal or for the next fork.
Tim Beiko:I
Tim Beiko:my vibe space intuition here is that like combining it with, say, Epvs in a single fork is
Tim Beiko:probably too much. But what? Yeah, how the client teams think about this, like the relationship between
Tim Beiko:fossil epbs and potentially some of the other el vips around scaling like block access to the survey pricing.
Tim Beiko:Yeah, I'm on, not Roman.
Ahmad Bitar | Nethermind:Yeah. So the Nethermind team feels that fossil should only be implemented after or alongside epbs.
Ahmad Bitar | Nethermind: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
Roman:it is upon Cl teams to evaluate how?
Roman: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.
Potuz: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.
Potuz: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.
Potuz:Having said so.
Potuz: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.
Potuz:I'm not sure if it's doable, but I believe it to be true.
Potuz: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.
Tim Beiko:yes, fossil does feel big enough that there's high uncertainty
Tim Beiko: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
Tim Beiko:the alcohol next week, at the very least, we should agree on a prioritization between them. But I think.
Tim Beiko:like, yeah, we should. We? We need to decide like, okay.
Tim Beiko:if we had to choose between these 2.
Tim Beiko:Which one are we gonna ship? And you know, from the client teams? Perspective. So far, it seems like epbs is the bigger priority.
Tim Beiko: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
Tim Beiko:it. It. It does feel like fossil is big enough that it it. It warrants like that level in.
Tim Beiko:Historically, we've just been
Tim Beiko:very bad at trying to do 2 big changes on one layer at the same time, and maybe we should just like
Tim Beiko: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
Tim Beiko:but we can have that conversation, I guess, on the Cl call next week.
Tim Beiko:Maybe one other thing I would like to look into is this idea around like
Tim Beiko:scaling as a headliner and block access lists and repricing being maybe, like
Tim Beiko:you know, only components to it on the el side.
Tim Beiko:we get yeah. Tomorrow, if you want to go, we can
Tim Beiko:do your fossil comments, and then.
thomasthiery:A bit about fossil, but more generally, I don't really understand the
thomasthiery:sort of policy around not being able to submit
thomasthiery: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
thomasthiery: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.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:we, we can't do like epbs and say shorter slot times in a single fork like both of those are pretty huge. And
Tim Beiko: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
Tim Beiko: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
Tim Beiko: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
Tim Beiko:and then export and then sorry when I say, I guess the answer's comment is, you know.
Tim Beiko: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.
Tim Beiko: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
Ben Adams:he compiles, and all that sort of stuff, and they would all fit under that same rocket.
Tim Beiko:I mean Tony.
Toni Wahrstaetter: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
Toni Wahrstaetter:quite trivial. But then
Toni Wahrstaetter:you need to actually use them for parallelization. You need to actually use them for parallelizing between execution and the post state updates.
Toni Wahrstaetter:then you might want to use them for snap sync. So there are many different things.
Toni Wahrstaetter: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.
Łukasz Rozmej: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 Wahrstaetter: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.
Toni Wahrstaetter: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
Tim Beiko: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.
Tim Beiko:And one, I guess one other thing we haven't touched on yet is just outside of client devs like
Tim Beiko:who are groups that we would maybe want to see, weigh in on things like fossil epbs.
Tim Beiko:block access lists, or repricing if relevant like, are there people we should be bringing on these calls that
Tim Beiko:or, you know, getting their feedback before the next call.
Tim Beiko:I guess down to comment like that. Stakeholders want scaling, I guess.
Tim Beiko:Yeah. Like, are there people like specific stakeholders. We think we should loop in and it's fine, if not. But
Tim Beiko:yeah, this would be the times to start reaching out.
Tim Beiko:Okay? So no strong opinions. And then, okay, the last thing maybe I wanted to propose is that so we
Tim Beiko:you know, we have these headliners.
Tim Beiko:What do we want as a deadline for people to submit just like
Tim Beiko: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
Tim Beiko: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 (Besu):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 (Besu):Yep.
Tim Beiko:Okay. If we were to do that, then I would say, it means all the small eip should be proposed
Tim Beiko: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.
Tim Beiko:Anyone opposed to that.
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.
Tim Beiko:So should the deadline.
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.
Tim Beiko:but yeah.
Tim Beiko:and we don't. Yeah, we don't have to settle this now, but
Tim Beiko:As we finalize the headliner, we should be clear about what
Tim Beiko:our deadline is, and then, if
Tim Beiko: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.
Tim Beiko:yeah.
Tim Beiko: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
Tim Beiko:a bit later on.
Tim Beiko: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.
Tim Beiko:Barnabas.
Barnabas: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
Barnabas: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.
Barnabas: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.
Barnabas:and the sooner we can have ball and up and running parallel to Futaka.
Barnabas: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
Barnabas: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.
Tim Beiko: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.
Tim Beiko:then, yeah. It feels a bit easier to then tell teams like you should have someone on this.
stokes:Yeah, I'd rather focus on Dev. Note 3 for the next week or 2 until it's up and ready
stokes:before opening that topic.
Barnabas:I mean, every single client team has made their
Barnabas: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.
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: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
sean:in the in the chat he's working on like a write up on his point of view.
sean: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.
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
stokes: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.
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.
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
Roman: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
Tim Beiko:you know, on the Cl side Epvs is like, you know, the main contender fossil is like, you know.
Tim Beiko: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
Tim Beiko:yeah. It's it's it's not
Tim Beiko:like it is a bit. It is a bit of like a a a circular dependency. But
Tim Beiko:you kind of shed part of the circle at each round or something. Yeah.
Tim Beiko: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.
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.
stokes:And again, I think it's just kind of this thing where more information is better, you know.
stokes: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.
stokes:you know, just having more people
stokes: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.
Roman: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
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:But I yeah, I don't think that, like we
Tim Beiko: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.
Tim Beiko:yeah.
Tim Beiko:I think that's all we had on the agenda.
Tim Beiko:Anything else people wanted to bring up before we wrap up.
Tim Beiko:Charles.
Charles C: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
Charles C: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.
Tim Beiko:I assume that's not the case for 7, 9 0, 3. But if that's.
Charles C: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
Tim Beiko:like trivially easy to do, and something we want? Or
Tim Beiko:I think if it adds any like complexity or uncertainty, we should not do it in for Seca.
Tim Beiko:Okay?
Tim Beiko:7, 9, 0, 3.
Tim Beiko:Yeah. It doesn't seem like there's strong support or understanding, so I would lean against it.
Charles C:Is that something that we could discuss on the next Acd.
Charles C:At least people and take a look.
Tim Beiko:I think we're already like
Tim Beiko:like 7, 9 0 7 was already like the last minute extension that we did past the deadline as this like a final
Tim Beiko:attempt to include something, and that turned out to be more complicated. But yeah, I don't think like
Tim Beiko:trying to understand or add new vips at this point makes sense. Yeah.
Tim Beiko:But yeah, obviously, we can discuss it for Amsterdam. But
Tim Beiko:I think for Fuseca we remove 7 9 0, 7 and call it a day.
Tim Beiko:Anything else before we wrap up.
Tim Beiko:Okay.
Tim Beiko: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.
Tim Beiko:Talk to you all soon.
Fredrik:Thank you.
Fredrik:Thank you. Bye-bye.
Justin Traglia:Bye, everyone.
Marius van der Wijden:But.
Chat Logs
00:00:30
Justin Florentine (Besu):Replying to "Justin had that one ..."
nope. strictly improv over here.
00:02:41
Dustin:which MEV? devnet-3 will change it
00:03:26
terence:prysm has a PR to fix it, it will soon be merged
00:03:31
terence:(for blob schedule)
00:04:02
Barnabas:devnet 3: http://notes.ethereum.org/@ethpandaops/fusaka-devnet-3
00:04:12
Trent:lmao
00:04:26
Trent:9 month time travel to the past
00:05:20
Marius van der Wijden:Replying to "devnet 3: http://n..."
fusaka-devnet-3 targets to launch on 23rd Jul 2025
is this still accurate @Barnabas
00:05:35
Barnabas:Replying to "devnet 3: http://not..."
thats my goal yes
00:05:37
stokes:Replying to "devnet 3: http://not..."
I think we will discuss next
00:05:42
stokes:Replying to "devnet 3: http://not..."
But next week should be the target
00:05:53
Potuz:we could always pressure to delay devconnect if we aren't making it :)
00:05:54
Tim Beiko:Mainnet ~> Nov 5-12
Last testnet ~> Oct 6-10
First testnet ~> Sep 22 - Oct 3
Client testnet releases ~> Week of Aug 25
00:05:58
Barnabas:Replying to "devnet 3: http://not..."
I don’t think we can hit monday anymore due to uncertainty in 7907
00:06:08
stokes:Replying to "devnet 3: http://not..."
I hope to resolve that today
00:06:18
Ansgar Dietrichs:but there are real tradeoffs here, right? this entire time period between first testnet client releases and mainnet fork is a time where core devs can’t yet fully focus on the next fork. so the more we drag that out, the more delayed the next fork will be
00:06:33
Barnabas:Replying to "we could always pres..."
or dedicate 1 day in devconnect to make mainnet client releases 😂
00:06:42
stokes:Fusaka this year is more important than a few months on glammy IMO
00:06:58
Ansgar Dietrichs:Replying to "but there are real t..."
my point is we need both, no?
00:07:37
Ansgar Dietrichs:Replying to "but there are real t..."
so I would be reluctant to add extra delays both between client releases and testnet fork, and then again for mainnet. that is just extra time that will delay glamsterdam
00:07:49
Barnabas:Timeline looks tight, but doable.
00:07:52
Marius van der Wijden:We need real peerdas testing
00:07:58
Marius van der Wijden:Haven't seen that yet
00:08:03
pawan:Replying to "We need real peerdas..."
THIS
00:08:05
stokes:Replying to "Haven't seen that ye..."
Month of august
00:08:08
Barnabas:Replying to "We need real peerdas..."
we need happy case working first
00:08:19
Justin Florentine (Besu):is dropping 7907 on the table?
00:08:23
Tim Beiko:Replying to "is dropping 7907 on ..."
yes
00:08:33
Dustin:should test without getBlobsV2
00:08:38
Potuz:Replying to "We need real peerdas..."
+1
00:08:48
Phil Ngo:Would like to see NFT devnet
00:08:58
Phil Ngo:(Non-finality)
00:09:04
Manu:And tests with perfect peerdas
00:09:24
marek:Replying to "is dropping 7907 on ..."
I think we should drop it if we're undecided on what to do with this EIP, especially if there's a risk of delaying the fork
00:09:41
Dustin:also for getBlobsV3: I know Raul et al really want to get this into Fusaka as a latently available thing, but that becomes a tradeoff too
00:10:04
Barnabas:7907 and getblobsv3
00:10:30
Marius van der Wijden:Replying to "is dropping 7907 o..."
Yes same
00:10:39
pawan:Replying to "7907 and getblobsv3"
Imo, we should skip getBlobsV3 for fusaka. It does not affect fusaka at all
00:10:48
Dustin:Replying to "7907 and getblobsv3"
agree
00:10:49
stokes:Replying to "is dropping 7907 on ..."
Also agree w/ this
00:10:58
stokes:Replying to "is dropping 7907 on ..."
Think Fusaka this year is our #1 priority ATM
00:11:05
Mikhail Kalinin:Replying to "7907 and getblobsv3"
but currently we have getblobsv2 with the semantics of v2 and v3
00:11:08
Dustin:Replying to "7907 and getblobsv3"
it's a nice to have that's getting shoved in last-moment
00:11:24
draganrakita:Replying to "is dropping 7907 on ..."
Lets at least increase the code size by 50%
00:11:32
Dustin:Replying to "7907 and getblobsv3"
@Mikhail to be usable it needs testing and there's no CL testing ecosystem for it currently
00:11:34
Dustin:Replying to "7907 and getblobsv3"
nor on a devnet
00:11:35
Mikhail Kalinin:Replying to "7907 and getblobsv3"
you propose to revert v2 to its original version with no partial responses support and remove v3?
00:11:39
Tim Beiko:Also want to flag if we remove 7907, we can add it back to Glamsterdam
00:11:41
Dustin:Replying to "7907 and getblobsv3"
yes
00:11:42
pawan:Replying to "7907 and getblobsv3"
V2 got reverted to no partial responses afaik. None of the clients implemented partial responses. So there’s nothing to do
00:12:00
stokes:Replying to "7907 and getblobsv3"
We may still need to update the spec, but I can handle that today if that’s the blocker
00:12:02
Mario Vega:Replying to "is dropping 7907 on ..."
My problem with 7907 is that it feels that there’s a better solution, not only for us devs but also for users, as an user, I don’t want to pay for a large contract access if I only want to read my balance in some token
00:12:03
Mikhail Kalinin:Replying to "7907 and getblobsv3"
Raul’s point is that v3 should be supported by ELs, nothing to do with CLs in Fusaka
00:12:04
Ansgar Dietrichs:is it too late now to ship giulio’s EIP instead? just bump max code size from 24kb to 32kb, no pricing or other changes at all?
00:12:09
Gabriel Trintinalia | Besu:Replying to "Also want to flag if..."
We're not opposed to eip-7907, Besu's implementation is nearly finalised, but we agree that this is the time to freeze the spec and focus on hardening for the testnets. We wouldn’t object to moving 7907 to Glamsterdam and removing it from Fusaka. The fact that we still don’t have consensus on its risks and broader consequences is a strong signal that its inclusion should be reconsidered, especially just a few days before the launch of the final Devnet 3.
00:12:18
Dustin:Replying to "7907 and getblobsv3"
that's not possible to assert sans full testing
00:12:47
Justin Florentine (Besu):Replying to "is it too late now t..."
it's not a big enough lift, it's yolo'ing stuff without enough leverage
00:12:58
Mikhail Kalinin:Replying to "7907 and getblobsv3"
it won’t be tested by CLs. there will be a separate devnet for that after Fusaka if we accept the v3 proposal
00:13:08
pawan:Replying to "7907 and getblobsv3"
Implementing v3 has no effect on furthering fusaka progress. It can only slow it down. I think its a waste of resources
00:13:13
draganrakita:Replying to "is it too late now t..."
Supporting this, it is two lines change in Reth.
00:13:15
Dustin:Replying to "7907 and getblobsv3"
after Fusaka won't make it unconditionally available
00:13:22
Dustin:Replying to "7907 and getblobsv3"
it doesn't accomplish Raul's stated goals
00:13:31
Mikhail Kalinin:Replying to "7907 and getblobsv3"
if implementing partial responses support by ELs delays Fusaka then we should likely remove partial responses from Fusaka
00:13:38
Dustin:Replying to "7907 and getblobsv3"
exactly
00:13:41
pawan:Replying to "7907 and getblobsv3"
yes
00:13:46
Parithosh Jayanthi:What’s the implementation difficulty for the smaller increase? And what tests would we need and how long might they take?
00:14:09
Mikhail Kalinin:Replying to "7907 and getblobsv3"
EL devs please speak out if v3 delays Fusaka on your side
00:14:15
Mario Vega:Replying to "What’s the implement..."
All consensus tests are parametrized to handle the increase, the problem might be benchmarking
00:14:25
Gabriel Trintinalia | Besu:Replying to "7907 and getblobsv3"
Besu has a PR already for v3
00:14:27
Marius van der Wijden:I think 100% increase without mitigation is out of the question for me, not super sure about 50%
00:14:38
Marius van der Wijden:Replying to "I think 100% incre..."
I think it is probably doable
00:14:42
pawan:I think its not the implementation complexity, its the time its taking away from other important testing (in terms of devnet testing)
00:14:44
Dustin:Replying to "7907 and getblobsv3"
Notably: "implemented" means "has been tested" insofar as whether CLs can rely on it
00:14:45
Charles (vyper):i think 50% increase actually has a worse effect on the total amount of code that can be loaded in a tx/block than 7907
00:15:19
Marius van der Wijden:Replying to "i think 50% increa..."
Yeah thats what worries me
00:15:23
Ansgar Dietrichs:https://eips.ethereum.org/EIPS/eip-7954
00:15:26
Ben Adams:32kB would be +1/3
00:15:51
Mikhail Kalinin:Replying to "7907 and getblobsv3"
i believe they can test it in Hive, but the ultimate testing of the whole feature is impossible w/o CL
00:15:53
Francesco:Replying to "7907 and getblobsv3"
I am fine with whatever is done with v2/v3, but this seems entirely an EL issue at this point, I think CL teams can just ignore v3 completely? So it’s not clear to me in what way it is a distraction to CL teams
00:16:01
Marius van der Wijden:Replying to "i think 50% increa..."
Similar to 7907 we have have not crunched the numbers on it yet
00:16:06
Justin Florentine (Besu):still doesn't speed up Fusaka release as much as changing nothing
00:16:21
Francesco:Replying to "7907 and getblobsv3"
Either way, I think just making a truly final decision is more important than the outcome here
00:16:23
Dustin:Replying to "7907 and getblobsv3"
"So it’s not clear to me in what way it is a distraction to CL teams" I'm not sure who's making that claim?
00:16:26
stokes:Replying to "7907 and getblobsv3"
I think at least Barnabas wants to have some stub implementation of v3 at a minimum if we go w/ it
00:16:32
Gabriel Trintinalia | Besu:Replying to "7907 and getblobsv3"
Fine either way as well
00:16:51
stokes:We can put a contract size adjustment in Glamsterdam
00:16:52
pawan:Replying to "7907 and getblobsv3"
If you are spending resources testing V3, you are taking away resources from testing other important stuff like malicious testing. That’s my main point
00:16:56
Dustin:Replying to "7907 and getblobsv3"
My broader claim is, it's disingenuous to claim it's there and works unless it's been actively tested in a devnet environment
00:16:59
Ansgar Dietrichs:Replying to "still doesn't speed ..."
right, it is more a symbolic gesture that we are not dropping it because we don’t care about app devs
00:17:01
marek:Replying to "still doesn't speed ..."
Let's do it right in Glamsterdam
00:17:02
Marius van der Wijden:Replying to "We can put a contr..."
We need to
00:17:18
Dustin:Replying to "7907 and getblobsv3"
And the pitch for V3 is it's so simple it doesn't even really need to be tested in that way, but that's fallacious
00:17:41
Dustin:Replying to "7907 and getblobsv3"
And therefore it can't be assumed to work, from the CL side, anyway, during Fusaka
00:17:47
pawan:Replying to "7907 and getblobsv3"
V3 is irrelevant for fusaka. I don’t understand why we need to implement it today. getBlobsV1 was also prototyped and implemented outside of a fork. Its easy to add later when we have time
00:17:50
Charles (vyper):the limit for eip-7907 has already been reduced to 48kb
00:17:55
Ansgar Dietrichs:To be clear though, timeline to have a proper Glamsterdam proposal is maybe ~3 months, so we actually need to get going on figuring out a principled strategy here
00:19:07
Barnabas:Do L2s want bigger contract sizes or want more blobs sooner?
00:19:16
stokes:Replying to "Do L2s want bigger c..."
More blobs sooner
00:19:25
J Sunnyside Labs:Replying to "Do L2s want bigger c..."
More blobs +1
00:19:25
Marius van der Wijden:People have lived with the 24k limit for a looong time now, I don't really see an IMMEDIATE need for Fusaka instead of Glamsterdam
00:19:32
Roman:Replying to "Do L2s want bigger c..."
are you an L2 @stokes ? 😅
00:19:35
Ansgar Dietrichs:of course we can’t do code chunking in Glamsterdam.
but by then we can know what exactly we want to do long-term, and can work backwards to short-term changes that don’t introduce tech debt
00:19:36
stokes:Replying to "Do L2s want bigger c..."
;)
00:19:36
FLCL:we are also includng secp256r1, which I'm not aware of proper gas benchmarking of
00:19:40
Parithosh Jayanthi:We can also do the hacky approach that we planed on doing for fusaka, but in glamsterdam. And that gives us time to atleast make it less hacky.
00:19:45
Marius van der Wijden:We could do a 50% increase in Glamsterdam if we have the full numbers
00:19:50
Derek Lee:Bigger contract sizes
00:19:53
Derek Lee:We can scale in other ways
00:20:05
Derek Lee:We already annoucned plans to scale in other ways
00:20:13
Francesco:Replying to "We already annoucned..."
What other ways?
00:20:21
Barnabas:Replying to "We already annoucned..."
L3s
00:20:29
Marius van der Wijden:Its implemented in all clients
00:20:51
Trent:EVM L2s differentiating is unlikely
00:21:00
draganrakita:It becomes maintenance problem
00:21:00
Mikhail Kalinin:yeah, that was my original point on not introducing v3. I am fine either way. The fact that we are debating on this for two weeks already makes me inclined towards v2 with no partial responses and without v3. v3 can be introduced once CL is ready to consume it
00:21:12
Potuz:but that' s my point
00:21:16
Derek Lee:Replying to "We already annoucned..."
Multidimensional gas is one of them that we are already taking steps to implement
00:21:20
Marius van der Wijden:Simple code size increase would be possible on L2s though imo
00:21:30
Potuz:have 7907 without increases and then L2 can simply change the limit in their code
00:22:06
Marius van der Wijden:Replying to "have 7907 without ..."
But they can do it already with the current scheme
00:22:11
Ansgar Dietrichs:if we reduce it, we should just do Giulio’s EIP
00:22:16
Francesco:Replying to "7907 and getblobsv3"
Agreed that this debate has gone on way too long and it’s better to do kick the can down the road than continue having it
00:22:26
Mikhail Kalinin:Replying to "7907 and getblobsv3"
OTOH, [`null`, `null`, column_c, column_d] in V2 is the invalid response right? CLs will have to handle this somehow even if partials aren’t supported
00:22:48
Barnabas:This sounds more uncertain than EOF was…
00:23:00
Dustin:Replying to "7907 and getblobsv3"
"handle" can include reject/ignore
00:23:06
Dustin:Replying to "7907 and getblobsv3"
it just means don't crash
00:23:17
Trent:Do people really agree that a simple increase (not code chunking) would really not be considered for glamsterdam? (As LC argues)
00:23:23
Derek Lee:Just repeating lightclient’s point: if not now, then when?
00:23:31
Marius van der Wijden:Replying to "Do people really a..."
I think I disagree
00:23:42
stokes:Replying to "Just repeating light..."
Not sure why we couldnt revisit this in glamsterdam
00:23:59
Ansgar Dietrichs:temperature check:
👎 for no change
👍 for Giulio’s EIP (bump to 32kb)
🔥 for 7907 (48kb and new pricing)
00:24:04
Justin Florentine (Besu):Replying to "Just repeating light..."
idk, Code Chunking + BAL on the EL doesn't seem nuts to me
00:24:27
draganrakita:I need to call more people 😄
00:24:30
Francesco:Replying to "Just repeating light..."
+1, doesn’t seem like Glamsterdam will have a large EL-focused headliner
00:24:51
Mikhail Kalinin:Replying to "7907 and getblobsv3"
right, how ignoring in the case of failure differs from ignoring a valid partial response?
00:25:37
Trent:Assuming perfect execution, One or two hard forks could be +12 months (but I lean for an imperfect solution in glamsterdam)
00:25:56
pawan:Replying to "7907 and getblobsv3"
From the PR to revert partial responses,
if the request is `[A_versioned_hash, B_versioned_hash, C_versioned_hash]` and client software has data for blobs `A` and `C`, but doesn't have data for `B`, the response **MUST** be `null`.
00:26:01
pawan:This is for V2 ^
00:26:39
Dustin:Replying to "7907 and getblobsv3"
it might (depends on details of error handling) manifest as an EL failure or bug @Mikhail Kalinin
00:26:54
Ansgar Dietrichs:Panda has officially overtaken Giulio’s EIP as leading replacement candidate
00:27:16
stokes:Lets do it
00:27:36
Parithosh Jayanthi:So simpler proposal in glamsterdam seems like a potential outcome right?
00:27:38
Tim Beiko:https://github.com/ethereum/EIPs/pull/9986
00:27:51
Charles (vyper):🐼😥
00:27:52
stokes:Replying to "So simpler proposal ..."
Or even 7907 itself in glamsterdam
00:28:04
Barnabas:https://notes.ethereum.org/@ethpandaops/fusaka-devnet-3
00:28:20
Justin Florentine (Besu):which way to the latest code chunking designs?
00:28:36
Mikhail Kalinin:Replying to "7907 and getblobsv3"
yes, the thing is that CL will have a codepath for this case anyway, it can log “apparently partial response received, ignored due to lack of support yet” instead of “EL failure: invalid response due to unexpected null value”
00:28:40
Barnabas:target 23rd of Jul
00:29:03
Barnabas:Only open question is engine_getBlobsV3
00:29:22
stokes:Replying to "Only open question i..."
Lets make a final decision Monday, if we can’t do it async before
00:29:25
Parithosh Jayanthi:Replying to "Only open question i..."
What’s the open questions there?
00:29:30
stokes:Replying to "Only open question i..."
If we want it or not
00:29:31
pawan:Replying to "Only open question i..."
I think we should kill it
00:29:53
Dustin:Replying to "Only open question..."
agree
00:29:57
Mario Vega:Replying to "target 23rd of Jul"
We are almost ready for an eest release, we’ll update on the R&D server when it happens so everybody can test for consensus issues
00:30:02
stokes:Replying to "Only open question i..."
Could be useful to get EL’s take today tho
00:30:42
pawan:Replying to "Only open question i..."
Nobody’s gonna consume the endpoint. Why should it be a devnet target?
00:30:44
Tim Beiko:Replying to "a0j7dn.jpg"
4 months is more than a second 😄
00:30:44
Ansgar Dietrichs:If we really add overall an extra full month to rollout here (extra time before first testnet, and again before mainnet), how are we thinking about not losing that time for the next fork (here Glamsterdam)?
00:31:27
Ansgar Dietrichs:Replying to "If we really add ove..."
then we really need to get better at staged work basically
00:31:27
stokes:Replying to "If we really add ove..."
I think we should trim some time on the testnet timing
00:31:29
Mikhail Kalinin:Replying to "Only open question i..."
strictly, it cannot be a devnet target
00:31:33
stokes:Replying to "If we really add ove..."
So we have more room to harden implementations
00:32:12
Marius van der Wijden:Replying to "a0j7dn.jpg"
I know, I just wanted to make a meme
00:32:56
Potuz:Am I the only one that thinks the Devconnect deadline is a little bit ridiculous? it' s fine to aim for it, but if we can't we can't and just simply schedule a month later, it's not a big deal. Safely testing would make us all sleep better
00:33:14
Parithosh Jayanthi:Replying to "If we really add ove..."
We also have glamsterdam that would start ramping up around this time, so this is shortening time.
00:33:19
Justin Florentine (Besu):Replying to "Am I the only one th..."
i think it is also an "end of year" holidays concern
00:33:24
stokes:Replying to "Am I the only one th..."
I think we should try and see what it would take to get there
00:33:27
Dustin:testnets breaking is an optics risk and needs buy-in to be willing to just kill/recycle the testnet
00:33:32
Dustin:that did not happen last time
00:33:35
Tim Beiko:Replying to "Am I the only one th..."
It is a bit arbitrary, but 0 deadline probably means we don’t ship this year?
00:33:44
Łukasz Rozmej:Replying to "Am I the only one th..."
Hm… I wanted late August ;)
00:33:50
Parithosh Jayanthi:Replying to "If we really add ove..."
If we’re doing one fork at a time, I agree we can reduce times
00:33:51
Potuz:Replying to "Am I the only one th..."
yeah I agree with the end of day, but if we're talking not about work, but actually setting up the release schedule, it should be fine
00:33:52
Barnabas:we can always just launch hoodi v2
00:33:54
Trent:Replying to "Am I the only one th..."
December/jan is historically hard to coordinate through
00:34:00
Dustin:Replying to "Am I the only one ..."
agree with Potuz
00:34:32
Dustin:Replying to "Am I the only one ..."
@Trent then February. I get the push really hard thing, maybe it's too much? The compromises are clear
00:34:35
Potuz:Replying to "Am I the only one th..."
I think we should aim for September on testnets, but if we don't get there, it's fine to delay a couple of weeks at the last moment, they are testnets
00:34:37
Trent:It’s not just an optics risk, companies and projects depend on stable staging/test env, migrating has huge overhead
00:34:47
Dustin:Replying to "Am I the only one ..."
But the main thing is, if anything goes wrong
00:34:52
Francesco:Replying to "Am I the only one th..."
@Dustin going from November to February is precisely the concern
00:34:55
Dustin:Replying to "Am I the only one ..."
are people willing to delay
00:34:59
pawan:Replying to "Am I the only one th..."
Agree that it’s very optimistic. But I’d still like to target it (including all safety testing of course)
00:35:07
Parithosh Jayanthi:Replying to "testnets breaking is..."
The explicit feedback we received from plenty of community members is that we have to reduce testnet churn
00:35:07
saulius:We could simply ship asap on Holesky. That's OK if it dies.
00:35:08
Potuz:Replying to "Am I the only one th..."
Yeah I agree that we should not delay longer than 2025
00:35:21
Potuz:Replying to "Am I the only one th..."
2025 should be a hard deadline unless there's a big bug found
00:35:25
Dustin:Replying to "Am I the only one ..."
there are already significant testing shortcuts, already discussed here
00:35:50
Justin Florentine (Besu):Replying to "testnets breaking is..."
we haven't really sorted out the conflation of intent since last time 🙁
00:36:08
Trent:Replying to "Am I the only one th..."
@Dustin feb is a coordination failure imo
00:36:41
Trent:Replying to "testnets breaking is..."
Not clear what “conflation of intent” means here
00:37:43
Enrico Del Fante (tbenr):Replying to "We could simply ship..."
Set a last BPO to 512 and let it die with a big boom
00:37:48
Justin Florentine (Besu):Replying to "testnets breaking is..."
different actors need the same things from the same networks for different reasons: everyone wants mainnet simulation, we want it because we want to break it, apps want it because they want to develop against it. it's a fundamental dilemma
00:38:02
Gabriel Trintinalia | Besu:Replying to "We could simply ship..."
@Enrico Del Fante (tbenr) hahahahah
00:38:03
Potuz:Re: getBlobV3, Manu has been saying for a while that it's imperative to test Peer-DAS without any getBlobs version, devnets apparently were never stable without them
00:38:15
Trent:(Edit, forgot that hole sky is being sunset)
Again, testnets dying is not good
00:38:36
Dustin:Replying to "Re: getBlobV3, Man..."
Yes, discussed earlier in this call, agree
00:38:37
Mario Vega:PSA that we have eth_config (https://eips.ethereum.org/EIPS/eip-7910) and tests for it now, please reach out to the R&D server for instructions on how to run them: https://discord.com/channels/595666850260713488/1392648788371570838
00:39:42
terence:Replying to "Re: getBlobV3, Manu ..."
I've been testing devnet2 without get blobs on prysm, no both normal node and full super node. The data looks good, but we need large scale testing, and preferably ethpandaops take over this
00:39:59
pawan:Agree as well. Sunny side labs have been doing these tests quite often iirc
00:40:36
Phil Ngo:Replying to "testnets breaking is..."
Can we just shadow fork a testnet and then upgrade that for us to do what we want on it?
00:40:44
Potuz:I agree with Saulius, Holesky being killed right before sunsetting it is not a big risk
00:41:10
Dustin:CLs still tend to support Holesky
00:41:17
Dustin:in a way they don't support random devnet
00:41:23
Parithosh Jayanthi:Replying to "testnets breaking is..."
We would do that, the issue is that peerdas is a networking update and a shadow fork is basically just a devnet. It teaches us nothing new.
00:41:23
Fredrik:When Breaknets ?
00:41:31
Parithosh Jayanthi:Replying to "testnets breaking is..."
But yes it gets config issues out of the way
00:41:54
Parithosh Jayanthi:Replying to "When Breaknets ?"
We need fusaka-devnet-3 first. Otherwise its just wasting money
00:41:59
Justin Florentine (Besu):Replying to "When Breaknets ?"
lets turn off the chainid safeties on the breaknets and just replay testnet traffic into it
00:42:12
Enrico Del Fante (tbenr):Holesky consensus state is still big, it will be a nice stress test
00:42:22
Potuz:+1
00:42:40
Parithosh Jayanthi:Replying to "When Breaknets ?"
We already do this with a mempool bridge
00:43:39
Potuz:The one thing with Holesky is that It's surely going to be a non-finalizing test: I don't expect we would have enough time to convince NOs of upgrading on time
00:43:56
Potuz:So even in the happy case
00:44:09
Potuz:WTF???? all clients but 2 signalled 7732
00:44:16
Potuz:Literally all clients but 2
00:44:22
Potuz:set it as their preference
00:44:42
Barnabas:Looking through all the client’s take:
EL pref:
block level access
focil
CL pref:
epbs
focil
00:44:58
Ansgar Dietrichs:caveat: I think on EL side “headliners” are less telling the full story.
I think EL focus should be scaling for Glamsterdam. That's BALs, but that's also a lot of benchmarking & repricing work. Not a headliner, but maybe the most important thing to do on EL side.
00:45:20
nixo:Replying to "Looking through all ..."
terence did a good full overview: https://x.com/terencechain/status/1945837782376788296
00:45:43
Justin Florentine (Besu):for headliners i think its fine for ELs to have CL opinions, just not to be estimators of workload
00:45:59
Justin Florentine (Besu):it's all one ethereum
00:46:05
Barnabas:Replying to "Looking through all ..."
I don’t think we have ever had this much agreement on which headliners client teams want.
00:46:07
Enrico Del Fante (tbenr):Replying to "The one thing with H..."
I think there are still a lot of lagging clients considering the noise on the attestations.. so it won’t be a flawless transition for sure
00:46:11
marek:Replying to "caveat: I think on E..."
yes, strongly agree
00:46:39
draganrakita:Dropping it from history aka p2p
00:47:07
Ansgar Dietrichs:the topic came up at interop, what Ben said is right, we would generally want to drop the BALs pretty quickly
00:47:24
Tim Beiko:I’m not sure we should create a dependency between BAL and rolling history expiry. We didn’t do that for blob data.
00:47:33
Marius van der Wijden:We should keep them for a decent amount of time for improving snap sync
00:47:36
Ben Adams:Want to keep them at least for snap sync period
00:47:37
Ansgar Dietrichs:Replying to "the topic came up at..."
BALs are different from normal history, because you can always re-build them locally
00:47:44
Potuz:Would we be in a place where you'd need BALs to sync and won't be possible without? cause then you'd need to request them when snap syncing
00:47:44
Marius van der Wijden:Like on the order of ~ 1 month
00:47:53
Potuz:ahh jinx
00:47:56
Łukasz Rozmej:Replying to "Want to keep them at..."
thats like 128 blocks
00:47:59
Barnabas:It feels like we could comfortably SFI 7928 (BAL) and 7732 (ePBS) for glamsterdam today, and CFI 7805 (focil).
00:48:09
Łukasz Rozmej:Replying to "Want to keep them at..."
but we should keep them for like a week or two
00:48:21
Ben Adams:Replying to "Want to keep them at..."
sure, longer is fine too :)
00:48:40
Łukasz Rozmej:Replying to "Want to keep them at..."
might be useful for nodes to catch up if they are offline for some amount of time
00:48:52
Tim Beiko:Replying to "It feels like we cou..."
I think we should wait a bit before CFI/SFI’ing headliners. There’s no rush to do it, but maybe we should make it clear that all the other ones (at least EL) are “DFI”’d?
00:49:11
Barnabas:Replying to "It feels like we cou..."
epbs-devnet-0 next week?
00:49:21
Tim Beiko:Replying to "It feels like we cou..."
I thought it was already implemented 😄
00:49:23
Potuz:Replying to "It feels like we cou..."
Need to merge a couple of PRs yet
00:49:50
Barnabas:Replying to "It feels like we cou..."
and please rebase on top of fulu
00:49:59
Potuz:Replying to "It feels like we cou..."
that will take longer
00:50:11
Potuz:Replying to "It feels like we cou..."
we want to test first implementations on top of Electra
00:50:18
Potuz:Replying to "It feels like we cou..."
at least the two teams that implemented them
00:50:31
Barnabas:Replying to "It feels like we cou..."
okay, so devnet-0 by first week of aug? 😄
00:50:34
Ansgar Dietrichs:wait @Justin Florentine (Besu) you say you don't want to split headliners, but then you mention both ePBS and FOCIL
00:50:42
Dustin:how important is exactly one theme as a constraint? it seems arbitrary
00:50:51
stokes:Replying to "It feels like we cou..."
Nope, lets focus on fusaka
00:51:00
Ansgar Dietrichs:ePBS is scaling theme
00:51:13
Łukasz Rozmej:Replying to "Would we be in a pla..."
so depends:
for snap sync, yes we will request them, and at some point of MGas/s there are EDGE cases where BAL's will be life-saving, but this windows is very short (128-192 blocks)
For archive processing, BAL's will speed up things for just processing, but with decent hardware shouldn't be necessary
00:51:18
thomasthiery:What makes the difference between a headliner and not a headliner?
00:51:18
Tim Beiko:Replying to "how important is exa..."
Yeah I think it should be about non-overlapping code changes
00:51:33
Potuz:Replying to "Would we be in a pla..."
Thanks!
00:51:38
Łukasz Rozmej:I propose to rename BAL's to BALLs
00:51:38
Tim Beiko:Replying to "What makes the diffe..."
Max 1 headliner per layer, and can’t re-propose headliners as vanilla EIPs
00:51:39
Ben Adams:Needs a fancier name?
00:51:43
Dustin:Replying to "What makes the dif..."
a headliner is an EIP that gets considered earlier, that's apparently it
00:51:47
Barnabas:7907 properly with BAL
00:51:55
Justin Florentine (Besu):bals and code chunks?
00:51:59
Dustin:Replying to "What makes the dif..."
I mean, people will say other things, but functionally that
00:52:00
Marius van der Wijden:Replying to "What makes the dif..."
There's no clear distinction yet
00:52:18
Carson | STEEL:Marketability/Branding * Impact
00:52:35
Toni Wahrstaetter:BALs aren't big from in-protocol perspective but making proper use of them is additional work
00:53:00
thomasthiery:Replying to "What makes the diffe..."
Right that was my feeling as well. If it’s more about signaling candidates on ethmagicians then I don’t understand why it couldn’t be repurposed as vanilla EIPS
00:53:05
Ansgar Dietrichs:agree with Ben, BALs are small if you just talk spec compliance. but they are much heavier to fully utilize them for higher performance
00:53:07
Roman:Replying to "BALs aren't big from..."
i agree and would still put them at medium scope of work
00:53:12
Tim Beiko:Replying to "What makes the diffe..."
Because realistically we won’t have bandwidth for them
00:53:25
FLCL:having bals to talk about eof
00:53:27
Tim Beiko:Replying to "What makes the diffe..."
e.g. I do think FOCIL and EPBS/BALs is not realistic
00:53:36
thomasthiery:Replying to "What makes the diffe..."
But if headliners are not correlated with implementation complexity how does this make sense
00:53:37
Caspar Schwarz-Schilling:hardfork would be delayed for headliners until ready but not for non-headliners, they would just get dropped?
00:53:40
Tim Beiko:Replying to "What makes the diffe..."
Or, say, shorter slots if EPBS
00:53:47
Tim Beiko:Replying to "What makes the diffe..."
@thomasthiery they should be
00:53:54
Justin Florentine (Besu):what fresh hell have you all unleashed....
00:53:55
Ansgar Dietrichs:Replying to "What makes the diffe..."
“can’t re-propose headliners as vanilla EIPs” - why? decision could be that BALs are too small for headliner
00:54:18
Roman:we should also stop calling it BALs, because it’s not just the access list in the current iteration and it’s confusing to folks who are not that familiar with the proposal
00:54:28
thomasthiery:Replying to "What makes the diffe..."
@Tim Beiko but they are not in practice, it’s just about whether they were posted on ethmagicians or not
00:54:32
stokes:Replying to "we should also stop ..."
What should we call it?
00:54:46
Sophia Gold:From a zkEVM (by far most significant tool for scaling) perspective, the hard requirements are either ePBS or DE in Glamsterdam and FOCIL in either Glamsterdam or the subsequent fork
00:54:50
Roman:Replying to "we should also stop ..."
let me ask claude
00:54:56
Ansgar Dietrichs:is repricing a “headliner” though?
00:55:25
Wei Han Ng:https://eips.ethereum.org/EIPS/eip-2926
00:55:29
Ben Adams:Replying to "is repricing a “head..."
Is major as every single test would need to change?
00:55:31
Tim Beiko:Replying to "What makes the diffe..."
Sure, it’s our first time doing this, not perfect, but I think if we remove an EIP from headliner because it’s too small, that’s maybe fine, but we shouldn’t do it for “obvious” hedliners
00:55:42
Ansgar Dietrichs:Replying to "is repricing a “head..."
I’d be happy to write a “repricing for scaling” headliner proposal
00:55:44
Wei Han Ng:Replying to "https://eips.ethereu..."
this is the current code chunking EIP
00:55:59
Marius van der Wijden:Replying to "agree with Ben, BA..."
Execution is not that big of a lift, the biggest one ist the snap syncing optimizations
00:56:22
Tim Beiko:Replying to "is repricing a “head..."
Maybe the headliner should just be “scaling"?
00:56:24
Toni Wahrstaetter:I'm not sure if we would want to do another "EL headliner" alongside BALs and potentially ePBS or FOCIL. This sounds like enough.
00:56:44
Tim Beiko:Replying to "I'm not sure if we w..."
I think those three are probably too much in a single fork?
00:56:44
Dustin:meh, ePBS doesn't imply more centralization, it just acknowledges that it's already centralized
00:57:00
Marius van der Wijden:Replying to "we should also sto..."
block witnesses :P
00:57:01
Ansgar Dietrichs:Replying to "I'm not sure if we w..."
right, I think the only option would be to swap BALs and repricing as headliner vs normal EIP
00:57:07
Potuz:Replying to "I'm not sure if we w..."
BALs and ePBS are completely independent, FOCIL can be accomodated IMO
00:57:11
Francesco:Replying to "I'm not sure if we w..."
Epbs on CL (fully contained), BALs + repricing on EL seems doable, whether you want to call the latter headliners or not
00:57:27
Potuz:Replying to "I'm not sure if we w..."
@Barnabas yet again got it right
00:57:36
Barnabas:If EL devs want more than just BALs they can also have EOF 😂
00:57:38
FLCL:in addition to the headliner: 7907 + repricing + parts of pureth?
00:57:40
Lion dapplion:After of another week I more against EIP-7732, and in favor of 7886
00:57:45
Roman:Replying to "we should also stop ..."
i’m failing at LLMing, need more time
00:57:45
DA | Flashbots:Feels hard to disentangle EL/CL, If ePBS isn’t chosen, is the preference still BALs > DE?
00:57:46
Ansgar Dietrichs:can we briefly talk about ePBS + FOCIL? it keeps coming up. can we decide whether this would be an ACDC-only topic?
00:57:56
Dustin:Replying to "in addition to the..."
Nimbus obviously in favor of Pureth
00:57:57
Lion dapplion:I am writing a piece with detailed rationale that I hope to publish tomorrow
00:58:00
Som - Erigon:ePBS = "Ethereum failed to decentralize"
00:58:17
Ansgar Dietrichs:Replying to "can we briefly talk ..."
I personally am very hesitant about ePBS + FOCIL in one fork
00:58:24
stokes:Replying to "After of another wee..."
why?
00:58:27
Marius van der Wijden:Replying to "I am writing a pie..."
about?
00:58:30
Dustin:Replying to "ePBS = "Ethereum f..."
yes, past tense (perfect)
00:58:34
terence:FOCIL -> more changes on CL rather than EL, as someone that looked at implementations on both sides
00:58:54
Justin Florentine (Besu):i think both need to happen before restructuring slot timing.
00:58:55
stokes:Replying to "I am writing a piece..."
I think this was his comment above that he is against 7732
00:59:05
Dustin:Replying to "ePBS = "Ethereum f..."
MEV exists, it won, block building will continue to centralize
00:59:06
Jihoon:Replying to "FOCIL -> more change..."
As another person who looked both implementations, I can second this.
00:59:11
Barnabas:Replying to "FOCIL -> more change..."
since when do you impl EL? 😄
00:59:22
Lion dapplion:I don’t feel the urgency to enshrine the role of the builder on-chain and we can achieve the same scaling benefits with delayed execution and decoupling. Less complexity and we don’t commit to a specific ePBS flavor yet
00:59:24
Jihoon:Replying to "FOCIL -> more change..."
Terence reviewed Geth impl
00:59:40
Charles C:Would it be worth re-proposing 7903? Remove or at least increase initcode limit
00:59:45
Som - Erigon:Replying to "ePBS = "Ethereum f..."
Why should resources be spent for that? There would be innovations off-protocol, and it's one of those
00:59:49
Łukasz Rozmej:ePBS+FOCIL+BAL is fine...
01:00:09
Marius van der Wijden:I think repricings/BALs are more important than FOCIL at the moment for the EL. If we decide to not do FOCIl, we should consider doing optional inclusion lists
01:00:16
Francesco:Replying to "ePBS+FOCIL+BAL is fi..."
Easy for you to say, it’s all CL lol
01:00:23
Justin Florentine (Besu):Replying to "ePBS+FOCIL+BAL is fi..."
might even defect to Teku to make this happen
01:00:36
Lion dapplion:In essence, take EIP-7732 and delete all the fork-choice changes, the bid market and the builder role
01:00:37
Łukasz Rozmej:Replying to "ePBS = "Ethereum fai..."
giving people more time to propagate the block is failure of decentralization?
I don't get it...
01:00:38
stokes:Replying to "ePBS+FOCIL+BAL is fi..."
Yeah, I think epbs and focil would be a lot to do in one fork
01:00:38
terence:Replying to "ePBS+FOCIL+BAL is fi..."
right, I think.. FOCIL + BAL is fine. FOCIL + EPBS is what needs debate
01:00:41
Ansgar Dietrichs:the conversation around ePBS is confusing to me.
ePBS is a specific (very good!) opinionated version of slot restructuring plus delayed execution. main benefit is significant scaling, more slot time available for propagation + execution.
implications around decentralization are mostly remnants of past discussions imo, very little real impact
01:07:09 Ben Adams: EL headliner, CL headliner and EL+CL headliner
:)
01:00:44
stokes:Replying to "ePBS+FOCIL+BAL is fi..."
Just in terms of scope
01:01:18
Roman:well, we do care about ePBS implementation, we are just not the ones implementing it
01:01:18
Trent:Replying to "the conversation aro..."
Yeah, im still a bit confused about the temporary name change to “execution payload separation"
01:01:23
Barnabas:Potuz agrees with me 3 acd in a row?
01:01:24
Toni Wahrstaetter:Replying to "is repricing a “head..."
This would yet be another headliner. Repricing should be a no-brainer inclusion, doesn't matter if headliner or not.
01:01:37
Francesco:Replying to "In essence, take EIP..."
I don’t disagree with the broader point, but note that decoupling does come with fork-choice changes regardless of whether the PTC exists (they are not too bad though)
01:01:46
Łukasz Rozmej:Replying to "EL headliner, CL hea..."
1 for each
01:01:50
Ansgar Dietrichs:Replying to "the conversation aro..."
“ePBS for scaling” - valid, it will be high impact there
“ePBS for censorship resistance / decentralization” - I think that’s mostly a meaningless thing to say
01:02:13
Justin Florentine (Besu):"where's Ethereums AMBITION?!?!?" -cryptotwitter, probably
01:02:24
FLCL:Replying to "in addition to the h..."
Might be good to make all clients ssz ready, upgrade some apis - make pureth easier to handle later
01:02:30
Trent:Replying to "the conversation aro..."
“ePBS for censorship resistance / decentralization” - I think that’s mostly a meaningless thing to say
There seem to be a lot of people (core devs and community/stakers) who believe this is true
01:02:33
Dustin:Replying to "the conversation a..."
well, my read is that it's becaue ePBS is the only EIP which acknowledges the existence of the external block building ecosystem
01:02:33
stokes:Replying to ""where's Ethereums A..."
Id rather have more focused, more frequent forks
01:02:41
stokes:Replying to ""where's Ethereums A..."
Which just suggests FOCIL in H-star IMO
01:02:47
Łukasz Rozmej:Replying to "is repricing a “head..."
repricing should be details EIP to be honest, in terms of implementation and testing it is fairly easy, need thoroughness though,
01:02:47
Phil Ngo:Replying to "in addition to the h..."
Lodestar as well, we see the benefits there on CL+EL
01:03:05
Phil Ngo:Replying to "in addition to the h..."
Been pushing for SSZing for a while now
01:03:07
Ansgar Dietrichs:Replying to "the conversation aro..."
it doesn’t though, I think the predictions of how it will change that ecosystem are very naive
01:03:22
Ansgar Dietrichs:Replying to "the conversation aro..."
so if that would be the justification for it, I would strongly oppose ePBS
01:03:24
Potuz:Replying to "the conversation aro..."
It doesn't need to be a reason for inclusion, but it is nonetheless a useful property, like it or not
01:03:24
Dustin:Replying to "the conversation a..."
yes, it allows separate signing of the payload by the "relay" / builder
01:03:27
Ansgar Dietrichs:Replying to "the conversation aro..."
I like it for scaling though
01:03:33
Dustin:Replying to "the conversation a..."
that's qualitatively new
01:03:45
Barnabas:I have heard rumors that implemnting epbs takes 1 unit time.
Implementing focil takes 1 unit of time.
Implementing focil + epbs doesn’t take 2 units of time, but rather takes 1.1 unit of time.
01:03:48
FLCL:Replying to "in addition to the h..."
which part of pureth would you bring firstly?
01:03:59
Barnabas:Replying to "I have heard rumors ..."
so we might as well bundle it
01:04:03
stokes:Replying to "I have heard rumors ..."
disagree
01:04:03
Potuz:FOCIL should be submitted as a vanilla EIP regardless of what comes out of headliner inclusion
01:04:08
stokes:Replying to "I have heard rumors ..."
Best case it would be like 1.5
01:04:20
stokes:Replying to "I have heard rumors ..."
And just seems like a lot to all test together
01:04:23
Ansgar Dietrichs:Replying to "the conversation aro..."
right, but there were many delayed execution variants that had that as well. my skepticism is specifically around the unconditional payment
01:04:25
Roman:Replying to "ePBS = "Ethereum fai..."
could Erigon team please expand on this opinion? these takes are unclear for other participants
01:04:29
ethDreamer (Mark):Replying to "I have heard rumors ..."
It’s less than 2 but not 90% less
01:04:34
stokes:Replying to "I have heard rumors ..."
Worst case it becomes like 2.3
01:04:49
Justin Florentine (Besu):we have to accommodate scheduling synergies when we find them
01:04:51
Barnabas:Replying to "I have heard rumors ..."
potuz’s copium juice
01:05:01
Dustin:Replying to "in addition to the..."
FLCL: https://pureth.guide/implementations-ssz/
01:05:12
Trent:Replying to "the conversation aro..."
I’d love to know how relays/ MEV pipeline feel this will play out practically
01:05:21
Cayman Nava:Replying to "in addition to the h..."
maybe eth transfer logs 7708, 7799?
01:05:31
stokes:Replying to "the conversation aro..."
Going to bring up in the mev-boost community call next week
01:05:35
Potuz:Replying to "I have heard rumors ..."
lol yes, no one really knows. Terence is the actual only person in the world able to evaluate this
01:05:43
Ansgar Dietrichs:I would want Glamsterdam live on mainnet in April 2026.
I don’t think with ePBS + FOCIL that is realistic
01:05:52
DA | Flashbots:Replying to "the conversation aro..."
We’ll hopefully post something before next week. Just slow internally having never done this before.
01:05:54
stokes:Replying to "the conversation aro..."
@Trent https://titanbuilder.substack.com/p/builders-and-relays-in-epbs
01:06:08
terence:here is my 2c:
- FOCIL is more on the CL then on the EL. FOCIL is fairly easy on the EL, just 2-3 engine api implementation.
- FOCIL shouldn't be a EL headliner rather than a CL headliner discussion
- Any EL headliner + FOCIL should be fine, but this is outside my domain
- The real debate is Epbs + FOCIL, but ACDC may be a better venue for this
01:06:11
Roman:Replying to "I would want Glamste..."
ePBS + FOCIL + 6s slot times. we need to lock CL devs in a room until then!!!
01:06:19
thomasthiery:Makes sense. Just feels like dropping FOCIL because it touches both layers (more CL than EL) and is not big enough to be a solo headliner, and too small to be a vanilla EIP is a bit trick.
01:06:31
Barnabas:Replying to "I would want Glamste..."
ELs will have too much time on their hand
01:06:40
DA | Flashbots:Replying to "the conversation aro..."
But we expect relays to be bypassed —> switches auction to sealed bid. Which we think is much healthier for the Network.
01:06:43
Dustin:Replying to "in addition to the..."
Also depends on SSZ. One option is EIP-7916/EIP-7495/EIP-7688, the SSZ trio
01:06:58
Dustin:Replying to "in addition to the..."
or rather those don't, sorry, those can be separate
01:07:00
thomasthiery:Replying to "Makes sense. Just fe..."
And it feels like FOCIL will probably always be in that position as well. For future forks too I mean.
01:07:02
Dustin:Replying to "in addition to the..."
so sure
01:07:12
stokes:Replying to "I would want Glamste..."
Time for maintenance, refactoring etc
01:07:18
Ben Adams:Also have to verify the BALs are correct
01:07:20
Ansgar Dietrichs:if we do ePBS + BALs + repricing, and basically nothing else in Glamsterdam, that’s a realistic scope.
And would be the largest single-fork throughput bump in the history of Ethereum. Might only ever be topped by the fork that enshrines zkEVM.
01:07:31
Justin Florentine (Besu):only the ones that are out of protocol
01:07:44
Potuz:Replying to "I would want Glamste..."
lol
01:07:59
Som - Erigon:Replying to "ePBS = "Ethereum f..."
Please read the comment on the pm thread and the linked post
01:08:00
stokes:Replying to "the conversation aro..."
How would you get cancellations in this structure?
01:08:12
Justin Florentine (Besu):Replying to "I would want Glamste..."
dude, i couldn't even convince this crowd to take a week off after pectra
01:08:17
Potuz:Replying to "I would want Glamste..."
Ansgar, no fork is viable in April, not with Fusaka happening end of year
01:08:25
ethDreamer (Mark):Replying to "ePBS = "Ethereum fai..."
What comment? What linked post?
01:08:37
Barnabas:Replying to "I would want Glamste..."
epbs-devnet-0 by end of this week
01:09:05
Justin Florentine (Besu):Replying to "I would want Glamste..."
it's already running in potuz's basement
01:09:08
Parithosh Jayanthi:Replying to "I would want Glamste..."
Yeah no fork seems likely in April. That would basically imply we start forking in feb after having shipped a fork in nov.
01:09:21
Ansgar Dietrichs:Replying to "I would want Glamste..."
@Potuz I don't think that's true, e.g. just BALs plus repricing would be ready by then. if ePBS isn't, we should reconsider it
01:09:23
DA | Flashbots:Replying to "the conversation aro..."
That’s the main open question that we’re spending time on.
01:09:33
Potuz:Replying to "the conversation aro..."
I can't heart DA's coment, no emojis here
01:09:40
Ansgar Dietrichs:well it seems clear that stakeholders want scaling, no?
01:09:44
Barnabas:are BALs and repricing worth its own fork? without epbs
01:09:53
Ansgar Dietrichs:Replying to "well it seems clear ..."
like this one seems easy in terms of visibility of preferences
01:10:04
Potuz:Replying to "the conversation aro..."
cancellations is not an issue: you request only once, it's a pull system
01:10:06
Potuz:Replying to "the conversation aro..."
not a push system
01:10:17
ethDreamer (Mark):Replying to "ePBS = "Ethereum fai..."
The only thing erigon said about ePBS was that it doesn’t fit with the overall goals - this is false - ePBS is way better for scaling and minimizing overhead which allows you to minimize latency
01:10:22
Parithosh Jayanthi:Replying to "I would want Glamste..."
I also think we’d get everyone putting all of their attention on these two only in Jan realistically. So assuming no one finds anything and we start shipping in feb seems unrealistic as well.
01:10:24
Marius van der Wijden:Hard to reach out to people being censored on chain atm
01:10:37
Parithosh Jayanthi:Replying to "I would want Glamste..."
And paying attention to it before Jan implies we aren’t focussed on fusaka and will distract fusaka
01:10:45
Som - Erigon:Replying to "ePBS = "Ethereum f..."
Slot restructuring is what u r referring to
01:10:48
Ansgar Dietrichs:Replying to "I would want Glamste..."
@Barnabas definitely! they would get us from 100M to say 200M
01:11:00
stokes:Replying to "the conversation aro..."
So even if a proposer calls me, I’d just block until I think I have my best bid as a builder?
01:11:02
DA | Flashbots:Replying to "the conversation aro..."
Cancellations is really the free option problem. And we’re trying to figure out if we agree with you that it’s not a problem.
01:11:21
Potuz:Replying to "the conversation aro..."
the proposer calls right before proposing,no need for any delay
01:11:40
Potuz:Replying to "the conversation aro..."
that is the main point against the tx inclusion delay arc
01:11:42
Potuz:Replying to "the conversation aro..."
also
01:11:43
Som - Erigon:Replying to "ePBS = "Ethereum f..."
That one is cool
01:11:52
FLCL:we will have a fork between osaka and amsterdam, right?
01:12:11
Parithosh Jayanthi:Replying to "I would want Glamste..."
Also im no opposed to quick forks, im just presenting real facts of how this plays out
01:12:21
Barnabas:We need at least 1 CL dev on epbs starting next week, if we wanna ship in realistic time glamsterdam
01:12:25
draganrakita:Would be good to be open for gas price changes
01:12:31
Potuz:Replying to "the conversation aro..."
DA: I did not say that one is not a problem though, I acknowledge it, just think it's not something that worries me
01:12:36
Barnabas:Replying to "We need at least 1 C..."
same as we did for peerdas
01:12:50
Marius van der Wijden:Yes, the repricings will likely take more than a month to be finalized
01:12:52
Som - Erigon:Replying to "Hard to reach out ..."
Yeah those who tried couldn't be reached either
01:12:55
Ansgar Dietrichs:Replying to "Hard to reach out to..."
I think general agreement is that censorship today is not a problem - it's just this topic where we need to make sure it is in a great place before it ever becomes a problem
01:13:06
Marius van der Wijden:Replying to "Yes, the repricing..."
We can propose stuff earlier than that
01:13:34
Ansgar Dietrichs:Replying to "Hard to reach out to..."
easy to keep saying “it's not a priority”. that will be true all the way until it wasn’t.
01:13:41
Charles C:Replying to "the conversation aro..."
Can we discuss 7903 as a replacement for 7907? It increases initcode only and doesn't touch state. It's not as ideal as 7907 but has some similar UX benefits since it allows you to deploy larger systems of contracts in one txn
01:13:50
Trent:Replying to "we will have a fork ..."
No
01:14:05
stokes:Replying to "the conversation aro..."
I think you want to post in the outer chat thread
01:14:06
Justin Florentine (Besu):Replying to "we will have a fork ..."
BPOs maybe
01:14:15
FLCL:Replying to "we will have a fork ..."
Yeah I mean BPO
01:14:15
Ansgar Dietrichs:I know ePBS is light on EL, but can someone briefly talk about what the very specific scope of changes would be?
01:14:25
terence:Replying to "I know ePBS is light..."
there's 0 change
01:14:28
FLCL:Replying to "we will have a fork ..."
Which may delay amsterdam, that's why mentioned
01:14:31
thomasthiery:Censorship today not being a problem is very different than having a network resilient to censorship when it happens.
01:14:56
Charles C:Replying to "the conversation aro..."
Ah thanks. On mobile
01:15:03
Ansgar Dietrichs:I think we should try to have a “BAL plus repricing” devnet as soon as possible.
So we can use that as primary benchmarking target to iterate on the repricings
01:15:04
Marius van der Wijden:Make the call for BALs now
01:15:07
Ben Adams:Replying to "I know ePBS is light..."
may want to change time we have to build local block 🙂
01:15:08
Justin Florentine (Besu):Replying to "I know ePBS is light..."
FOCIL overlaps, ePBS does not
01:15:12
Charles C:Can we discuss 7903 as a replacement for 7907? It increases initcode only and doesn't touch state. It's not as ideal as 7907 but has some similar UX benefits since it allows you to deploy larger systems of contracts in one txn
01:15:34
Potuz:These two things are not incompatible and we are not taking time from eachother
01:15:41
Toni Wahrstaetter:Replying to "Make the call for BA..."
yeah agree, I can setup regular breakouts
01:15:43
Barnabas:Erigon is not a real CL team tho…
01:15:46
Marius van der Wijden:Replying to "Can we discuss 790..."
Not a headliner imo, should be proposed and strongly considered imo
01:15:49
DA | Flashbots:Replying to "the conversation aro..."
P: Right. Our view is that validators aren’t incentivized to blacklist builders who fail to deliver because builders having the option to cancel makes blocks more valuable —> incentives validators to not care if delivery happens.
01:15:50
Ahmad Bitar | Nethermind:Replying to "I know ePBS is light..."
@Ben Adams constant change, will take a whole fork to implement :p
01:16:02
Ansgar Dietrichs:Replying to "Make the call for BA..."
wait Marius do you mean a call call, or a decision?
01:16:04
Barnabé Monnot:Are we not waiting mid-August for headliner selection?
01:16:07
Ben Adams:Replying to "I know ePBS is light..."
😂
01:16:10
stokes:Replying to "Are we not waiting m..."
I think we should
01:16:16
Marius van der Wijden:Replying to "Make the call for ..."
I mean a decision to SFI
01:16:17
Łukasz Rozmej:Replying to "I know ePBS is light..."
Nethermind already implemented ePBS ;)
01:16:28
Parithosh Jayanthi:Replying to "Are we not waiting m..."
Signal now and focus on community input till then?
01:16:30
Tim Beiko:Replying to "Make the call for BA..."
I think we should wait at least until next ACDE
01:16:36
Toni Wahrstaetter:Replying to "Make the call for BA..."
haha yeah, got you wrong. but we should do both to get on track asap
01:16:41
Daniel Lehrner (Besu):Replying to "Are we not waiting m..."
If we want to ship in April, we shouldn’t wait that long
01:16:55
Fredrik:Replying to "Hard to reach out to…"
In 1TS discussions the importance of censorship resistance has been an important topic from quite a lot of institutions
01:17:02
Anders Elowsson:Replying to "Are we not waiting m..."
@Parithosh Jayanthi SFI - signalled for inclusion
01:17:05
Barnabas:SFI BALs is a no brainer
01:17:13
Potuz:Replying to "I know ePBS is light..."
lol
01:17:20
Ansgar Dietrichs:I think on the CL side resource overlap is more critical. PeerDAS really seems like it will still take a lot of effort, so I’d be uncomfortable if people were to already start focusing on ePBS now
01:17:28
Francesco:Replying to "Are we not waiting m..."
This might well be the right choice, but it is quite unlikely we will put a month of effort into it and then reverse the decision based on community input
01:17:34
Tim Beiko:Replying to "SFI BALs is a no bra..."
Then it will be a no brainer in 2 weeks 😄
01:17:45
Marius van der Wijden:Replying to "SFI BALs is a no b..."
Can we CFI it?
01:17:48
Ahmad Bitar | Nethermind:"Community input" (cough VCs input cough)
01:17:56
Marius van der Wijden:Replying to "SFI BALs is a no b..."
Axxelerate
01:18:18
Barnabé Monnot:Replying to "Are we not waiting m..."
I think signalling now but still doing a convincing effort at ironing it out with larger sets of people would be good. sets a good precedent vs already breaking the proposal that was made for glamsterdam
01:18:32
FLCL:Replying to "Make the call for BA..."
what can go wrong if we have 1 ACDE per week btw? We have ACDT which looks like another ACDE
01:18:55
Trent:This is a strange blanket comment?
01:19:06
Ansgar Dietrichs:on EL side it seems much more straight forward with community opinion
on CL side, much more open:
shorter slots vs ePBS / delayed execution
ePBS vs other delayed execution
add FOCIL vs faster fork
01:19:08
Barnabas:Replying to "SFI BALs is a no bra..."
shipit
01:19:43
sean:Replying to "I think on the CL ..."
It requires a lot of focus just to make an informed decision on ePBS
01:20:07
Dustin:Lion isn't primarily a "community" member
01:20:21
Charles C:Replying to "Can we discuss 7903 ..."
How about for fusaka?
01:20:34
Ansgar Dietrichs:what decision are we even delaying on EL? seems like we already have pretty broad agreement?
Or is there someone who would want no scaling changes and only FOCIL?
Otherwise to me scaling is locked in, only EL question would be “would we be okay with FOCIL added to the fork”?
01:21:49
stokes:Replying to "what decision are we..."
Only new info here would be a strong demand from the community for FOCIL vs something else
01:22:27
Som - Erigon:Replying to "what decision are ..."
++ (FOCIL + Delayed Execution)
01:22:56
Ansgar Dietrichs:Replying to "Screenshot 2025-07-17 at 8.14.57 AM.png"
my bad
01:23:19
Som - Erigon:Replying to "SFI BALs is a no b..."
But the blocks become 40% bigger, if you scale it 10x, it's a lot!
01:23:21
Justin Florentine (Besu):idk, first i'm hearing of it
01:23:24
Justin Florentine (Besu):link?
01:23:33
Ben Adams:https://eips.ethereum.org/EIPS/eip-7903
01:23:36
stokes:Changing scope at all at this point injects uncertainty
01:23:37
Barnabas:Replying to "idk, first i'm heari..."
not a good first sign
01:24:04
spencer:it feels against the process tbh - fusaka frozen etc
01:24:05
Barnabas:this is something we could discuss for glamsterdam scope
01:24:33
Charles C:Replying to "idk, first i'm heari..."
I discarded it in favor of proposing 7907
01:24:51
Toni Wahrstaetter:Replying to "SFI BALs is a no bra..."
block (excl. blobs) though
01:25:01
Łukasz Rozmej:how would that initcode work for 1Ggas block?