stokes:Hey everyone, welcome to ACDC. This is number 167.
Transcript
stokes:It's PM issue 1754 in the repo here.
stokes:There's a link to the agenda in the chat.
stokes:So… yeah, there's quite a bit on the agenda today, so let's go ahead and get started, some things with Fusaka, and some things with Amsterdam, so…
stokes:First up, I figured I'd ask if there's anything to touch on with DevNet 3. As far as I know, it's still chugging along.
stokes:But it might just… yeah, I don't know if there's anything. Barnabas or Perry, I don't know if you're on the call and have something to add?
Barnabas:Nothing really to add, it is still going forward. There's a couple of bugs that we have discovered,
Barnabas:Regarding, database usage, I'm not dropping some blobs on the store side, but, has been…
Barnabas:Sorted out, basically.
stokes:Okay, cool.
stokes:then let's jump into Testnut. So, I believe since last week's ACD, we had Haleschi BP02, and also the Sepolia fork.
stokes:As far as I've seen, they generally went well. There was some turbulence, more on the operations side, but I don't think there were any client issues. Anyone have anything else to add to either of those events?
stokes:Let her go?
Enrico Del Fante (tbenr):Yeah, nothing really specific to these events, but just to say that we have discovered a bug in the way we were subscribing to…
Enrico Del Fante (tbenr):column subnets. Essentially, we were only subscribing to all subnets in case we
Enrico Del Fante (tbenr):You configure the node as a super node.
Enrico Del Fante (tbenr):Otherwise, if you are running enough validators, but without the flag, it will… Techo was only subscribing.
Enrico Del Fante (tbenr):To 8, subnets.
Enrico Del Fante (tbenr):so, we haven't discovered that before, because essentially the node is still able to…
Enrico Del Fante (tbenr):get from EL plus from RPC calls, and manage to…
Enrico Del Fante (tbenr):To sync up the blocks in time. But yeah, something is something that we are fixing.
Enrico Del Fante (tbenr):And we are also working on some improvement on the sampler, so we would like to have another… another release for Hoodie with these improvements in.
Enrico Del Fante (tbenr):So, yeah, that's it.
stokes:Okay, cool. Yeah, nice find.
stokes:Anything else on Haweski or Sepolia?
stokes:Okay.
stokes:So far, the testnets have gone really well. Definitely no issues like Pectra, so that's really exciting to see.
stokes:Next up, Frederick here wanted to give an overview of the Fisiana contest that I believe has wrapped up.
stokes:Let's see… Yeah, ended on the 13th, so… Frederick, are you here?
Fredrik:Yes, I am. Yeah, I just wanted to mention that the contest ended on Monday, so right now there's this process of
Fredrik:doing a final review of the severities of the… of the findings, but all in all, I would say that there isn't… there hasn't been anything that's…
Fredrik:Cause any reason to postpone,
Fredrik:Yeah, to postpone the hard first, basically. So, it seems like we're good.
stokes:Okay.
Fredrik:We will, release a, like, a full,
Fredrik:List all vulnerabilities, etc, once, once it's done, probably, in a few weeks, from now.
stokes:Alright, sounds good, yeah. Also, exciting to hear, no major issues there.
stokes:Okay.
stokes:Next up, I did want to touch on the different blob APIs. So, I think some of this caught some people off guard.
stokes:There's the proof change moving from the 4844 style blobs to the pure dust-style blobs.
stokes:The first place you'd probably run into this is if you're submitting blobs, say, to the execution layer, a note there.
stokes:And then also there have been some tweaks to the APIs to read blobs from the CL.
stokes:I don't know if anyone wants to add anything here. Essentially, yeah, I think…
stokes:there is some confusion around which nodes do what, or sorry, like, which implementations do what. I know that some clients
stokes:Try to maintain some of the previous behavior as a bit of a bridge.
stokes:But, ultimately,
stokes:yeah, that's kind of where we're at. I think most of the things have been sorted out by now, but yeah, I guess if you're listening, and this is a surprise, or you're not sure what we're talking about, please reach out to someone on this call.
stokes:We'd all be happy to… to help you here.
stokes:Yeah, Justin here is asking which L2s were affected.
stokes:a good number of them, me and I think many others of us here have been talking to them this week,
stokes:I…
stokes:don't necessarily want to call anyone out, but some roll-ups seem to be on top of it and already. I think some…
stokes:either weren't following, ACD as closely, and yeah, missed this, or they also… I mean, one thing that came up was the EIP itself says it's backwards compatible.
stokes:Which, when I read that, I think that means backwards compatible with respect to, you know, protocol features, and to me, the RPC kind of sits outside the protocol.
stokes:But I think, taken together, yeah, there's some miscommunications there.
stokes:Yeah, Lucas here says, by the way, another month's considering enabling conversion like F.
stokes:Yeah.
stokes:So, if anyone has anything to add here, that would be nice.
stokes:Although part of the issue was people not listening to ACD, so I don't know if this is the right forum to get that information out.
stokes:Marius?
Marius van der Wijden:Yes.
Marius van der Wijden:Part of the problem was that it wasn't…
Marius van der Wijden:well communicated on the… on the EF workforce.
Marius van der Wijden:And it's also not super well communicated in the EIP itself. EIP itself says that it's fully backwards compatible, which on some level it is, but,
Marius van der Wijden:I think just, it would be nice if ESP editors would also
Marius van der Wijden:just put some lines about RPC filters that I needed.
Marius van der Wijden:put the IPs in, so that we don't, don't, have this…
Marius van der Wijden:I'll get into this, miscommunication again, in the future.
stokes:Yup, definitely a good idea.
stokes:Dustin had a good question here. Is there basically some way to, you know, make sure this doesn't happen last minute in the event there are changes like this in the future?
stokes:Something else that came up, is different users testing on DevNets, so something that's probably good for us to try to do, you know, with feature forks. When we get to the final DevNet, so, for example, we have Husaka DevNet 3, and, you know, generally it's been out there and stable.
stokes:it would be nice, then, if, you know, for example, rollups, different users could go and test there. And part of the thing here is that, you know, I think for most of us here, mainnet is, like, quote, our production environment.
stokes:The testnets are more staging, and so, you know, if there are things like this that come up at the last minutes, that's, like, exactly why you have a staging environment before production.
stokes:Many of the roll-ups, it sounds like, treat the testnets also as production.
stokes:So then they don't quite have this, like, testing ground.
stokes:One thing we could offer is, once we get to, you know, very late-stage dev nuts for a given fork, have people deploy there and work through some of these things ahead of time.
stokes:So that's definitely something.
stokes:To keep in mind moving forward.
stokes:Yeah, another good point from Nixo. We had Macong for Pectra, which is kind of like a long-standing user test…
stokes:Long-standing, user-facing testnet.
stokes:It's kind of a mouthful. But yeah, I mean, part of it is, I think, we were also just trying to move faster here as a group, and yeah, didn't quite have time for something like that.
stokes:Okay, there's a lot of stuff in the chat. People can read this, I suppose. Like Peter here mentions, testing on Shadowfork would be easier than DevNuts.
stokes:Yeah, I think this is something we'll need to work through,
stokes:I think that's partly why, you know, these different users haven't deployed to DubNets. I think it's not straightforward for them to target these new environments.
stokes:But, in any case, yeah, I think something altogether we can work on.
stokes:So… Related to that, there is a comment here on the agenda from…
stokes:Cohen MTP1, from Aztec.
stokes:They have a point here around blob retrieval. I don't think this is directly related to the APIs, but it is touching on bandwidth concerns and the more general issue of, like, how we expect people to retrieve blobs, under PureDOS.
stokes:I think I… yeah, Cohen, you're here. Would you like to say anything else?
Koen (Aztec):I think it kind of speaks for itself, but the, basically the… I think there's currently no really good way for L2s to be able to retrieve blobs.
Koen (Aztec):Or at least if you're running decentralized sequencers to allow the node of the L2 to be able to retrieve blobs on, like, the home staker level, that's kind of where our concern is.
Koen (Aztec):Basically, currently in the current system, we have to require everyone to run super nodes, which is not ideal, given the bandwidth constraints.
stokes:Yeah, understood. Let me grab a link here to your post.
stokes:There's a nice message here on 8th Magicians.
stokes:going through this issue, I think there's kind of two types of solutions you have here. One is this notion of, like, a light super node. There's also the other option, essentially, of, like, custom tooling, somehow.
stokes:Yeah, I think so. I know at least some of us at DF were discussing this over the last day or so, and yeah, there's probably something here with this, like, light super node, operation style.
stokes:Yeah, so, thanks for flagging, and I don't know if anyone has had a chance to look at this and has anything else to add. Otherwise, we'll just keep it on the table and see what we can do there.
stokes:Let's see… Yeah, Dustin's pointing out here in the chat that basically…
stokes:there is a tension here between how pure dust works and how you get the blobs.
stokes:I think one thing that Coin might be asking for is a middle ground, where rather than trying to get everything, you just get half the columns.
stokes:Cause then from there, you can reconstruct the blob, and then you're kind of good to go.
stokes:Terrence is also saying, yeah, a lot of bulbs are in the mint pool, so you need them from there. And there was some stuff there, that Cohen also mentioned around, yeah, essentially, like, separate tooling.
stokes:I think there's a bit of a design space here, depending on, for example, what the roll-up is, how they work, what their use case is, and making that happen.
stokes:So… Again, lots of comments in the chat. I don't know if anyone wants to speak up.
stokes:Otherwise, I would suggest we take…
Enrico Del Fante (tbenr):Sorry, just for… so…
Enrico Del Fante (tbenr):We don't want a node to actually signal that he's custodying all the nodes, but you want to have a kind of a middle ground node that's subscribed to all subnets, and have a kind of…
Enrico Del Fante (tbenr):tiny window of storing those blobs, just to serve the API, and then throw them away in…
Enrico Del Fante (tbenr):Something like that.
Koen (Aztec):Yeah, that would be super helpful. Basically, just, like, a super node that only custodies, like, 4 columns, or, like, whatever the 4 is the minimum currently, and then it, you know…
Enrico Del Fante (tbenr):So you don't want to actually, to, to, to signal that you are a super node in the custody, yeah, in Arabic, because otherwise you get,
Enrico Del Fante (tbenr):Mmm… disconnected, but in practice, you want to listen to all the nodes, all the columns. Yeah, correct.
stokes:Notice.
potuz:Prism is implementing precisely that.
potuz:exactly what Enrico said, where you're discussing the minimal, but sampling for more until you can recover. However, I believe that for this particular issue.
potuz:and for most users, but I believe it's what's happening in Aztec, and I know it's happening for, as a matter of fact, for Arbitrum, this would be much easier to be treated on the EL.
potuz:You just track on the EL the transactions from… with blobs that you are interested in, and the DL should just save those. So this would be a useful flag on the EL side. Just save me the blobs from the transactions that I'm interested in.
Enrico Del Fante (tbenr):Is that sufficiently reliable? I mean, in practice, but not maybe in.
potuz:if you're… I mean, if.
Enrico Del Fante (tbenr):Thank you for me.
potuz:For the cases that I have in mind, which is, for example, a roll-up that is sending these transactions in the public mempool, then yes, because the mempool today is not chartered.
potuz:And it's always found there. And then you can just have as a fallback the CL. But anyways, as I said, Prism is already implementing this feature.
Enrico Del Fante (tbenr):One thing is having the consensus layer dealing with grabbing everything. Another way is relying on a mempool that can be flushed out, or… yeah. It's a different level of reliability in my mind.
stokes:Okay. So yeah, come on, thanks for flagging this. There was another comment here I won't read right now on this post, but yeah, I think if people want to engage.
stokes:either reach out to the various rollouts to Fogniz, or go to Magicians here, and yeah, it sounds like there are…
stokes:Adjustments on the way to facilitate this use case.
stokes:And if not, there are other… other options. Manu?
Manu:Yeah, just, to say,
Manu:Currently at SuperNode, stores 128 proofs and 128 cells.
Manu:Something we could do is only storing 64 cells, but 128 proofs. Proofs are very cheap to store, but expensive to reconstruct, and cells are expensive to store, but cheap to reconstruct.
Manu:This way, we could save, for SuperNode, we could save up to almost 50% of this usage.
stokes:Yeah, I think the concern is more bandwidth here, but yeah, that's also helpful on storage as well.
stokes:Our roll-up's definitely gonna need to store.
stokes:All of their blocks, which is probably equivalent to all of their blobs.
stokes:Okay.
stokes:Anything else on the topic?
stokes:I think one takeaway, again, if you're listening, as a non-core dev.
stokes:If you have an issue here, please reach out. I think the changes are pretty straightforward, but there have been some changes, and yeah, also, I'll call out Marius's blog post, from the EF that was linked somewhere in the chat.
stokes:Yeah, walking through some of these changes.
stokes:Okay.
stokes:So… Then another tangential thing to this…
stokes:is an RFC from Jimmy, I believe. Let me grab the link here.
stokes:So…
stokes:I don't know if he's here, but essentially what this does is change a condition in the spec that, I believe now it should, and the proposal is to change it to May. And this basically lets you, reduce the bandwidth requirements, for non-super nodes.
stokes:I was talking… okay, Chava already commented on here. I think he brought up the point that this might…
stokes:I'm actually not sure. I need to catch up on this. But I did want to call this out. I don't know if anyone's had time to take a look.
stokes:From what I've seen from Teshaba, I think there's some intricacies here between Gossip Sub and how the propagation actually works that may not mean this is that important.
stokes:I don't know if Choppa's here. He could say more right now?
stokes:But if not, yeah, please take a look here. This might be another small change we want to add, again, to help with some of these rough edges.
stokes:Okay.
stokes:Then, next on the agenda…
stokes:through stock on Mainnet, the time that we've likely all been waiting for. So, if we…
stokes:Went to ship through Saka this year. The time is actually pretty much now to go ahead and start talking about this.
stokes:Barnabas had that proposal here.
stokes:Again, let me grab this link.
stokes:that would put mainnet on December 3rd.
stokes:And then schedule our two BPOs, one of them on December 17th, and then one, into next year on January 7th.
stokes:And the reason I wanted to bring this up today, or at least I think we should talk about it today, is that if we want to aim for December 3rd with Fusaka on Mainnet.
stokes:That would imply, following our process, that we have, essentially everything ready by November 3rd, which is actually coming up quite soon.
stokes:So, that would mean client releases by then, we'd get another EF blog post out, and, you know, everything there.
stokes:So I think today, I just wanted to get a temp check from whoever's present on, yeah, the feasibility of this, and…
stokes:If it looks good today, then I'd take this to ACD next week, and that might even be the call where we formally set the dates, once we get sign-off from both CL and EL clients.
stokes:Frederick.
Fredrik:Yeah, I just want to say that if, if we do decide this, today, then we, do a divergence.
Fredrik:Well, maybe not the divergence, but…
Fredrik:kind of go against the process, at least, that's been set up. With regards to upgrades. As we do say, mainnets should not have an upgrade date set until all testnets have been upgraded.
Fredrik:And also, yeah, I mean, it's a should, but I think it's something worth considering, at least.
Fredrik:If we need to set it now, or if we should set it at a later stage.
stokes:Yeah, there's… Something there. So…
stokes:I think it will take us, you know, at least this call and next call to actually, like, quote, set the dates, and at that point, we would have moved much further along.
stokes:Let me double check when hoodie is, because then that's another question.
stokes:Let's see, hoodies… the 12th of November, So…
stokes:Oh, no, sorry, the 28th of October.
stokes:So… Let me just run through the calendar here…
stokes:That would basically be next ACDC. And so, following the process, I think there's a reading where basically we would formally set the dates on the 30th, so 2 weeks from now.
stokes:I wanted to go ahead and bring this up now, because, you know, if we say on the 30th, hey, let's have releases by the 3rd, that's only a few days for clients to actually do that. So…
stokes:I think we're pipelining things a bit, but also I think there is a reading that's consistent with the process document that we have.
stokes:So, thanks for bringing that up.
stokes:We do have the process for a good reason.
stokes:Let's see, there were some comments in the chat here around going ahead and shipping it, moving ahead with November 3rd. Anyone think that that would be an issue?
stokes:Aiming for mainnet releases on November 3rd, and then mainnet on December 3rd.
stokes:And again, this is just a temp check. I think we'll probably need another week or two to actually get to
stokes:An official, determination of the dates.
stokes:I've not seen anything in the chat yet around any issues there.
stokes:I'll also be reaching out to each client team, async, just in case there's other things that come up, but… okay.
stokes:Generally, I would take this as a thumbs up for the temperature check, and I think the next step then would be to bring this to next week's ACD, and again, just make sure everything's good on the EL side, but otherwise, yeah.
stokes:I think we're looking good there.
stokes:Let me find the agenda…
stokes:So, cool. And I think the last thing with Husaka today is just calling out, Sepolia BPO next week.
stokes:I should say BP01.
stokes:Let's see, that is…
stokes:I believe this is still Tuesday UTC. Again, I think we all know where to find the times, but yeah, keep that on your radar as the next, Fusaka event.
stokes:Okay.
stokes:That was all I had for Fusaka. Anything else that we should bring up today?
stokes:Okay.
stokes:Then we will move to Glamsterdam.
stokes:So, with Glamsterdam, yeah, as we see, Fusaka's moving along well, so it's definitely time to start thinking about Glamsterdam.
stokes:The first agenda item here, is following up on the last call we had with Trustless Payments and EPBS.
stokes:So… Last call, someone had brought up… well, I think there's a presentation from Lynn, so…
stokes:He had brought up some concerns around trustless payments, essentially pointing to the complexity of the feature and, you know, essentially if it's, like, the right time to enshrine this part of EPVS.
stokes:There was an EPVS breakout last week,
stokes:there is more discussion, but ultimately, I don't think there is a resolution either way.
stokes:What I would say at the moment.
stokes:Well, maybe I'll pause there. Is there anything anyone would like to add on this topic right now?
stokes:Yellow.
Lin Oshitani | Nethermind:Yeah, so, yeah, as a person who kind of reopened this whole can of worms, I can share what my thoughts are right now.
Lin Oshitani | Nethermind:So, like, I think I still do believe that we, like, should have separated this EIP.
Lin Oshitani | Nethermind:And…
Lin Oshitani | Nethermind:I do think that process payments, like, it was under-discussed, especially compared to, like, the complexity, and the complexity here being, like, the ecosystem impact, or the user impact complexity that this has.
Lin Oshitani | Nethermind:I think it wasn't discussed enough compared to that.
Lin Oshitani | Nethermind:But, like we discussed in last week's… breakout room that… For those raised points that.
Lin Oshitani | Nethermind:doing EPBS without process payments, it's also, like, under-discussed. We don't have, like, concrete specs, and…
Lin Oshitani | Nethermind:Like, there were some open problems that he mentioned.
Lin Oshitani | Nethermind:And another thing is that we had discussions around, like, how do we support just, off-protocol payments.
Lin Oshitani | Nethermind:within the clients.
Lin Oshitani | Nethermind:As a standard, like, not as, like, each client to implement on their own, or…
Lin Oshitani | Nethermind:like, have forks. We can have, like, standards that are shared among the clients that work out of the box for the off-protocol payments.
Lin Oshitani | Nethermind:Having such things will… like… minimize the impact to the ecosystem, which is, I think, a good direction.
Lin Oshitani | Nethermind:I think a lot of people.
Lin Oshitani | Nethermind:Or, like, did not have the impression that, like, the core devs were open to this, so, like, it's very…
Lin Oshitani | Nethermind:Which maybe they did, but, like, that was impression, so I think it's very nice to see discussion on that direction.
Lin Oshitani | Nethermind:So… Like, while… in conclusion, like, while I still do things that…
Lin Oshitani | Nethermind:It's better to be separated, and it was better to have been separated, like…
Lin Oshitani | Nethermind:I think we should have had this discussion much earlier. I think the EIP SFI process, like, there's probably some improvements that
Lin Oshitani | Nethermind:that we made around this, or how we split or bundle EIPs together.
Lin Oshitani | Nethermind:But personally, I won't, like…
Lin Oshitani | Nethermind:Based on the portal's point, and that fact that off-protocol payments is going to be properly supported, I'm not gonna push
Lin Oshitani | Nethermind:Like, further on the separation?
Lin Oshitani | Nethermind:Noted.
stokes:Sure.
stokes:Yeah, thank you.
stokes:Enrico?
Enrico Del Fante (tbenr):just a general comment. So, given that the… at the moment they are spec'd out together,
Enrico Del Fante (tbenr):So, I'd like to have a split in the spec, just after we decided that
Enrico Del Fante (tbenr):they should come separated, and the PPS should go in without trustless.
Enrico Del Fante (tbenr):a payment, so I don't want… I would like to not be in a world where
Enrico Del Fante (tbenr):We end up having them both shipped, and then we had spent a lot of time separating things, and have a trustless payment as a separate feature, and this will be a…
Enrico Del Fante (tbenr):a waste of time. So, I think, like, we should accept what we have now, and keep discussing, and if we decide that we want to postpone just trustless, let's then do the job of separating SPAC, and let…
Enrico Del Fante (tbenr):Let's go EPPS without, you know…
stokes:Yeah, makes sense. Definitely many trade-offs here around how we
stokes:go about shipping this. Mark?
ethDreamer (Mark):Yeah, I mean, I guess I would just echo some of the things. I think Lynn's… take was…
ethDreamer (Mark):But pretty decent as well, and so it's… Enrico, I… like…
ethDreamer (Mark):Sorry, I'm a little bit blanking here. Like…
ethDreamer (Mark):it does seem easy to look at EPBS and see it as, like, a monolith.
ethDreamer (Mark):Or as an opinionated design, but…
ethDreamer (Mark):We did do a fair amount of exploring.
ethDreamer (Mark):Everything from a lot of different angles.
ethDreamer (Mark):And, I mean, I guess if there were more people involved for longer periods of time, we could come up with
ethDreamer (Mark):Some kind of progressive spec of separating out these features while keeping most of the things, but…
ethDreamer (Mark):in terms of, like, I think where we ended up.
ethDreamer (Mark):I guess my personal opinion is, like.
ethDreamer (Mark):You know, sometimes you have to work with the information you have at the time.
ethDreamer (Mark):And it would be quite a bit of work to separate out things, try to come up with a bunch of different designs. I mean, the only design that we even had for trustless payments was from Daplain and…
ethDreamer (Mark):It was rushed, so he didn't have much time, but, like, that would cut out a lot of the benefits of removing, like, the blinded blocks and code pass and…
ethDreamer (Mark):Things that you get from block payload separation, so…
ethDreamer (Mark):Anyway, yeah, it's like, I largely agree. At this point, it would just take more time to separate out these things. It would just slow us down. There may be improvements to EPBS that we can make in V2 in the future, some of which that I've thought about, but right now, for a V1, I think we're in a fine place.
stokes:Thanks.
stokes:Okay. Dimitri.
Dmitry Gusakov | Lido:Yeah, hello there. Kind of different comment from my side. So, we've been taking a look at the current design of the trustless payments from the point of view of the staking protocol maintenance.
Dmitry Gusakov | Lido:Especially for LiDAR, and there are two… like, even though I genuinely support the trustless payments idea.
Dmitry Gusakov | Lido:I really wanted to voice out that the current proposed design adds a bit of a complexity on both
Dmitry Gusakov | Lido:off-chain and on-chain support for this thing. So, for example, should
Dmitry Gusakov | Lido:the staking protocol, like Lido, Rocketpool, or whoever else, decide to support this builder validators within a protocol, the… all of the interactions regarding, like, proving balances and keeping the accounting tight between the consensus layer and the protocol becomes…
Dmitry Gusakov | Lido:pretty contentious, I would say. And the other thing is that since trustless payments do not guarantee that they will be the only way to make payments, and we will effectively have two markets, so the same as we have right now, which is an off-chain one.
Dmitry Gusakov | Lido:And the on-chain one with the stressless payments, it basically means that the amount of work that is… that should be done by the protocol to ensure that all of the validators within a protocol maintain… behave according to the rules is effectively doubled
Dmitry Gusakov | Lido:Because now you need not only to look at the off-chain market, which we…
Dmitry Gusakov | Lido:we currently do, and we… I think we are pretty successful in it. But with the introduction of the trustless payments, again, given that they will exist in parallel to the existing off-chain market, we will now have to do the…
Dmitry Gusakov | Lido:the second amount of work to also keep an eye on trustless payments and making sure that everything is right with the trustless payments as well. So again, I genuinely support the idea of trustless payments, however, I really want to voice out that it wouldn't be…
Dmitry Gusakov | Lido:It would add complexity not just for core developers, but for the staking protocols as well, should they ever decide to support validators, or even if they will not decide to support building validators, they will still have, like, a significant portion of additional efforts to be done with regards to off-chain monitoring.
stokes:Yeah, thanks.
stokes:Let's see, there's their… Oh, Francesca.
Francesco:Yeah, just a quick comment responding to Mark.
Francesco:I think it's a bit of a myth that, like, yes, we did do a lot of this exploration of the design space a few months ago, but I think, like, it was with a different goal than just saying, like, splitting up the current EIP. It was more, saying, like, okay, are there different ways to do this, like, that maybe, I don't know, where, like, you don't have the commitment, or, like, a bunch of other stuff.
Francesco:They give us better properties.
Francesco:Whereas if the goal is just more… the more restricted, just…
Francesco:do exactly the same kind of pipeline in the current EIP does, but don't have all of this other stuff that's sort of on top of it. We know how to do that, like, it's possible to do that. Yes, no one has written a spec for this, because I think, like.
Francesco:it's… I mean, it seems a bit pointless to do when… I don't know, like, we haven't really decided that this is something we actually want, but, like, it's really not that complicated to just…
Francesco:not do the whole trustless payment part and just say, for example, like we were discussing on Discord, you can just have a pub key instead of the builder index. Now you don't need stake builders anymore, and you do everything else exactly the same, except you don't have the payment, you don't have staking, and so on. Now, should we do this? I don't know. I've not been arguing to do this. I've not been, like, writing a spec for this.
Francesco:But just, I think, yeah, like, we shouldn't bring up, I think, as an argument, the fact that, like, oh, we don't know how to do this, it's impossible, like, I think it's a bit like… yeah, I mean, it's just not true.
Francesco:And yeah, I mean, still, I kind of agree with a lot of what's been said around, I don't know, it is quite late in the process, and, like, if the goal is just to save some time, it's probably not gonna save any time, so I think if we really wanted to do something like this, then it has to be, like, a bigger kind of…
Francesco:decision around, like, complexity and more, like, kind of future considerations, but yeah, I think it might, it might will be that, at this point, we should just go with this design, regardless.
stokes:Thank you. Sophia?
Sophia Gold:Yeah, I don't think that we should split out the EUP and have a separate one for trustless payments. Like a lot of other people, I'm concerned that that would
Sophia Gold:delay actually shipping the hard fork, or even that, eBBS could go the way of Pyrodos, and we have to split Glamsterdam.
Sophia Gold:You know, acknowledging that we should have had these discussions, months ago, I think that we should try to make all the hard decisions around trustless payments and other elements of eBPS design as soon as possible.
Sophia Gold:from a decision tree standpoint, I think that it would be the easiest to decide on this if we had a judgment on the severity of the free option problem. I do know that that is…
Sophia Gold:very difficult to, at least for me, to have a strong opinion on. But if you think that the free option problem is quite severe or would have negative outcomes, then it seems to me we should remove trustless payments and use LINS design that commits to the parent header.
Sophia Gold:If not, I'm not sure that's dispositive of, including trust's payments, but it does mean that I think we should have a dual PDC deadline, which is another,
Sophia Gold:I think from, at least conceptually, quite large design aspect of ePPS that, we have, sort of been ignoring.
Lin Oshitani | Nethermind:We'll just do… Oh, sorry, Mr. Sponge.
stokes:No, go ahead.
Lin Oshitani | Nethermind:I think, like, the free option problem, I do agree it's a problem, but it's… I think it should be discussed completely separately from removing process payments. I think you can have trust payment
Lin Oshitani | Nethermind:design that has pre-option problem or doesn't have pre-option problem. I think they're pretty independent.
Lin Oshitani | Nethermind:So, I do agree we should discuss it, but I think…
Lin Oshitani | Nethermind:Leave it out of this specific discussion for now.
stokes:Okay.
stokes:Any other comments while we're here? That I was… I was surprised there were so many hands.
stokes:Okay, so yeah, I think this conversation highlights that… This is…
stokes:I don't think contentious is necessarily the right word, but there's just a lot here, and, you know, there are potentially large impacts.
stokes:There are many different dimensions to consider, like how quickly we can ship the feature, you know, how do we think about it with respect to governance, the actual, you know, implementation and complexity of the thing itself.
stokes:from what I'm hearing, it doesn't sound like anyone's making the strong case to take them out, and that would just suggest leaving the thing as it is.
stokes:You know, acknowledging the fact that it does add some complexity in different ways, and that's just a choice we're making as a core developer community.
stokes:So… I… at least where I'm at right now, is I think we leave things as is.
stokes:And keep moving forward with Amsterdam.
stokes:this unblocks, you know, implementation on the feature, so we can actually ship the thing instead of spending, you know, another number of calls going ahead and, you know, just discussing it in circles. So…
stokes:I think that's a good summary of where we're at now.
stokes:Any last words?
stokes:I do think one thing that would change here is, again, with any EIP, if it came out, you know, later in the process, that there was actually a security issue, which I don't really foresee with this, but…
stokes:You know, there's always an option, we need to reevaluate, but…
stokes:My assessment at the moment, again, talking to many of you, and trying to summarize, you know, the conversation just now, I think we're in a pretty good spot.
stokes:So, I'd say leave as is.
stokes:Any final comments?
stokes:Okay.
stokes:then that is settled. We have trustless payments, as is in the IP.
stokes:Okay.
stokes:So, we should be good there,
stokes:I could ask about implementation progress, but I don't think there's been much,
stokes:people have been busy with Fusaka, and also we are kind of waiting on this question to… Moving forward.
stokes:So, that being said.
stokes:It would be nice to see DevNets sometime this year, so just have that on your radar. I know, again, it'll be busy with Ozaka, but another thing on the plate.
stokes:Next up, we have… Okay, so…
stokes:This was about… let me just double-check this comment. Okay, so… Etan brought this up.
stokes:he… Oh, there's a question. Let me address this. Onsgar…
stokes:I don't know what you mean on scar.
stokes:Headliners.
Ansgar Dietrichs:Yeah, I just wanted to check, because there was some requests in chat for people who said, look, let's just make a final decision, meaning not just the decision of leaving it in the EIP as it is, but also saying on future
Ansgar Dietrichs:ACD calls about Amsterdam, it would be basically out of scope.
Ansgar Dietrichs:Off-limits to revisit removing it at all.
Ansgar Dietrichs:Other than, of course, for security considerations, which, I mean, yes, that's always possible, or for other, like, completely unforeseen major issues coming up around it, but not as in just as part of a normal governance conversation.
Ansgar Dietrichs:Versus just the decision of saying, it stays in the EIP, we move forward, and in case we decide, governance-wise, to remove it later.
Ansgar Dietrichs:we do it then. I think those two are meaningful enough separate to just decide which of the two paths we just decided to go on.
stokes:Yeah, it seems like we're deciding now, like…
stokes:I think it would be hard…
stokes:Yeah, okay, so I guess you're suggesting, like, there could be a situation in some weeks where it's like, hey, maybe because of other EIPs we want to include, then we want to reevaluate this.
stokes:I think, given the way the headliners worked, I think then that, yeah, this is the feature, this is the headliner, and that includes justice payments, so then it would be really weird to then try to take it out because of some other EIP that was not the headliner.
Ansgar Dietrichs:Yeah, then I just wanted to ask one last comment on this, say, and I understand most people disagree with me on this, but I think, as a matter of fact.
Ansgar Dietrichs:this will mean that we will not ship fossil in Amsterdam. I understand that's a weird connection to draw, because there's not a connection between those two features, but we already, everyone I talk to already, is concerned about the CL side of Glamsterdam being the slower one this time around, that it's heavier, because EPBS just is a really big feature.
Ansgar Dietrichs:And that we are basically already kind of at the limit, and as we now will also talk in general about, like, some scoping, that really we should only add, like, very, very minor features, if anything, on the CL side, and mostly keep it as is, scope-wise.
Ansgar Dietrichs:That was my motivation, why I kind of also, when this was proposed, to join back in, and at least considering removing stake builders, so we would have a bit more headroom to add fossil. I personally really, really, really think it should be in Amsterdam, but I also don't think we can just, like, make it a 12-months fork to get there.
Ansgar Dietrichs:I understand people probably think these are orthogonal decisions, I don't, but…
Ansgar Dietrichs:If we want to make it a final decision, and then…
Ansgar Dietrichs:People don't think that means we exclude fossil, then that's fine with me.
stokes:I think we can have the conversation about Fussell once we get there,
stokes:I think that'll be pretty soon, and a few calls coming up.
stokes:But all that being said, you know, we went through the process of having a theme for the headliner selection. That theme was scaling. I think it's been hard for people to justify Fossil as a scaling EIP, and so that's why we have what we have today.
stokes:Yeah, I mean, it's tricky. I think given the decisions we've made, we should stick to EPVS as is, including trustless payments, and move forward there.
stokes:It would be…
stokes:Strange to pull it out later, just because we want to include something else down the line.
stokes:Okay.
stokes:Thank you, Oscar.
stokes:I will go back to… the agenda item we had here, so… Etan brought this up.
stokes:I think, again, it's a bit early, because we aren't quite to the stage where we should be discussing other Lemstream EIPs in earnest, but he did want to call out EIP7688.
stokes:This introduces, generalized indices, which I think most of us have seen this feature by now.
stokes:And he's proposing to put it, into the fork. So…
stokes:Again, I don't think we should necessarily discuss it much further today.
stokes:Because we will talk about inclusion around the full set of PFID IPs, again, in a few calls.
stokes:What we had said is we'd wait until Fusaka Mainnet date was set, which, again, should be coming up soon. Then we can turn to the rest of the Glenster Damn scope.
stokes:That being said, he did want to bring this up.
stokes:And I will also, call out that DIVA and, Lido both gave support for this EIP.
stokes:On the agenda, and you can look at the comments there if you want to see more.
stokes:So… Let me just make sure I got everything… Yeah, okay.
stokes:That was everything on the spec for Amsterdam. Anything else that we'd like to discuss today?
stokes:There's some more comments in the chat that we could touch on.
stokes:If people would like to, because we do have some time.
stokes:I mean, it looks like it's coming down to the fossil question, which, again, this is the tricky thing, because…
stokes:We have one headliner, essentially, and it's hard to do both.
stokes:They're both relatively big EIPs.
stokes:Barnabas is asking, why not discuss fossil? I think… I'm not sure people are prepared, honestly. We'd also want to discuss in the context of all the other PFIDIPs.
stokes:And there's actually quite a long list. I was just looking at the Meta EIP
stokes:Yesterday… let me go find it…
stokes:There's quite a bit that's been proposed.
stokes:This is EIP7773, and yeah, there's…
stokes:29 EIPs here. So we're gonna have fun sorting through all of those.
stokes:But ultimately, yeah, I think it's a bit early, honestly.
stokes:Yeah, Dimitri's asking about 7688. So it's a bit early to discuss inclusion,
stokes:It should be in this PFI list, and if not… I saw it somewhere
stokes:Yeah, it's here. So it's on the MetaEP, and then the way that we're handling this is we wanted to wait until Fusaka's out the door, and then we would turn to talking about the rest of the Glenstream scope.
stokes:So…
stokes:It's… again, the call today is just that it's been PFI'd, and we will discuss further in probably 2 or 3 calls, once we have Fusaka more settled.
stokes:Kev's asking about the Max Blob slag. I think that's what you mean, Kev, right?
stokes:Yeah.
stokes:I don't think it's needed, clients are working on support, but yeah, it's definitely there.
stokes:Okay.
stokes:Anything else?
stokes:Otherwise, we'll go ahead and wrap up for the day.
stokes:Okay, thank you all, and again, yeah, keep an eye on Sepolia. We have VP01 coming up next week.
stokes:Thank you all. I'll see you next time.
Marius van der Wijden:Thank you, bye.
Marius van der Wijden:Bye-bye.
Pooja Ranjan:Thank you.
Chat Logs
00:02:42
stokes:https://github.com/ethereum/pm/issues/1754
00:04:18
Kalo | Obol:On obol side we missed bumping some nodes… pardon for that
00:04:53
Justin Traglia:Pretty cool that it worked as well as it did with RPC 😅
00:06:11
Ameziane Hamlat:@Enrico Del Fante (tbenr) Was that issue related to the behaviour we saw on the drop in network activity on besu/teku validators on Holesky ?
00:06:13
Enrico Del Fante (tbenr):Replying to "Pretty cool that it ..."
RPC+EL seems pretty reliable
00:07:05
Enrico Del Fante (tbenr):Replying to "@Enrico Del Fante (t..."
Not sure TBH
00:07:06
Justin Florentine (Besu):anyone know what L2s were affected by this? https://blog.ethereum.org/2025/10/15/fusaka-blob-update
00:07:38
Enrico Del Fante (tbenr):Replying to "@Enrico Del Fante (t..."
The node manages to get everything via EL and send them out anyway.. so not sure actually
00:08:29
Łukasz Rozmej:Nethermind is considering enabling conversion like Geth has. We generally have the code for it already.
00:08:52
Ahmad Bitar | Nethermind:Replying to "Nethermind is consid..."
Hidden behind a flag
00:08:56
Marius van der Wijden:Tbh most rollups have learned about it this week
00:08:59
Łukasz Rozmej:Replying to "Nethermind is consid..."
both for sumbiting through eth_sendTransaction and those in TxPool
00:09:28
Peter:Replying to "Tbh most rollups hav..."
We learned about it from last week’s ACDE call
00:09:29
Dustin:is there a way to ensure that some testing occurs before it's last-minute in future forks?
00:09:36
Trent:Audio a bit bad marius
00:09:47
stokes:Replying to "is there a way to en..."
devnets
00:09:53
stokes:Replying to "is there a way to en..."
Let me say something
00:10:02
Ben Edgington:MicDAO
00:10:57
Łukasz Rozmej:Replying to "Nethermind is consid..."
@Ahmad Bitar | Nethermind we might change defaults for it
00:10:59
nixo:re: andrew’s question - why was there a “mekong” for pectra but not for other forks?
00:11:17
Etan (Nimbus):Replying to "re: andrew’s questio..."
there was also a zhejiang for shanghai
00:11:18
Peter (Scroll):Testing on shadowfork networks would be easier than redeploying on devnets
00:11:23
Marius van der Wijden:Replying to "Audio a bit bad mari..."
Sorry, am in a loud cafe
00:11:29
Parithosh Jayanthi:Replying to "re: andrew’s questio..."
We used to have 2 testnets, this time we had 3 and didn’t want to have a 4th
00:13:26
stokes:https://ethereum-magicians.org/t/blob-retrieval-guarantee-post-fusaka/25822
00:13:33
Dustin:this isn't super-avoidable, past a 2x factor
00:13:38
Dustin:it's just how 1D peerdas works
00:13:52
Dustin:one needs an "almost-supernode" regardless
00:13:53
terence:if the blob is public, you can get it from the EL mempool as well
00:14:19
Etan (Nimbus):Replying to "if the blob is publi..."
do the testnets have mevboost / private transactions?
00:14:29
kingy_sigp:Replying to "one needs an "almost..."
light supernode > sidekick node? 🤔
00:14:38
Dustin:that's 2D peerdas
00:14:41
Francesco:One note is that it’s a problem that’s meant to be resolved with cell-level messaging and row subnets
00:14:49
Francesco:Replying to "One note is that it’..."
You don’t need any 2D for this
00:14:53
Ansgar Dietrichs:in general blobs are not meant as the propagation layer for L2s, just as a publishing guarantee. L2s are meant to have their own propagation mechanisms on top, with L1 just as integrity guarantee
00:14:54
Dustin:2D peerdas was repeatedly rejected
00:15:02
Francesco:Replying to "2D peerdas was repea..."
2D is not related to this
00:15:03
Etan (Nimbus):Replying to "One note is that it’..."
“2D” meaning cells, no more supernodes.
not meaning “FullDAS”, in this context, I think
00:15:16
Francesco:Replying to "One note is that it’..."
Well it’s still 1D so let’s not call it that?
00:15:18
potuz:we're working on implementation of this: custody the minimal but sampling from 64 so as to recover the blobs and returning them
00:15:27
Dustin:Replying to "2D peerdas was rep..."
well, need access to rows
00:15:27
potuz:so it doesn't signal it but it saves
00:15:37
Dustin:Replying to "2D peerdas was rep..."
i.e. cells
00:15:39
Francesco:Replying to "2D peerdas was repea..."
Sure but there’s no 2D encoding
00:16:29
Manu:Regarding the disk space needed, a technique would be to store only 64 cells, but 128 proofs.
Proofs are cheap to store but expensive to reconstruct.
Cells are expensive to store and cheap to reconstruct.
00:16:42
Dustin:Replying to "One note is that it..."
literally it's two dimensions
00:16:46
Dustin:Replying to "One note is that it..."
rows. and columns. two dimensions
00:16:48
Dustin:Replying to "One note is that it..."
2D
00:17:00
Dustin:Replying to "One note is that it..."
it is not 1D, no
00:17:04
Ansgar Dietrichs:wait the EL never sees the blobs, right?
00:17:16
stokes:Replying to "wait the EL never se..."
They are in the mempool
00:17:20
Ansgar Dietrichs:Replying to "wait the EL never se..."
right, there is a chance you see it in the mempool
00:17:21
Dustin:Replying to "2D peerdas was rep..."
look at those goalpost moving
00:17:32
stokes:Replying to "wait the EL never se..."
At least for now, almost no private blobs
00:17:39
Ahmad Bitar | Nethermind:El mempool needs to be sharded eventually though, no?
00:17:39
Parithosh Jayanthi:Replying to "wait the EL never se..."
The entire get blobs optimisation relies on this anyway
00:17:47
terence:Replying to "wait the EL never se..."
and batch poster should def have the blob tx, they can store it for later
00:17:52
Ansgar Dietrichs:Replying to "wait the EL never se..."
that’s an optimistic case optimization though
00:18:04
Dustin:Replying to "wait the EL never ..."
yes, it's why it's dicey and ther eshould have been more testing without it (some happened, yes)
00:18:04
Ansgar Dietrichs:Replying to "wait the EL never se..."
obv blob users can’t rely on optimistic case mechanisms
00:18:12
terence:Replying to "wait the EL never se..."
they just need to know if it is included or not
00:18:24
Ahmad Bitar | Nethermind:Also, most L2 use builder apis to publish blobs. So you wont see the blobs in mempool in this case
00:18:38
FLCL:Replying to "wait the EL never se..."
if so it can be extracted from el block
00:18:43
Enrico Del Fante (tbenr):interesting
00:19:31
Marius van der Wijden:Replying to "Also, most L2 use bu..."
Iirc most l2s don't do that at the moment (might change in the future)
00:19:46
stokes:https://github.com/ethereum/consensus-specs/pull/4657
00:19:55
Francesco:Replying to "Also, most L2 use bu..."
Almost no l2s do this
00:20:03
Trent:The post from Marius https://blog.ethereum.org/2025/10/15/fusaka-blob-update
00:20:15
Peter (Scroll):Replying to "Also, most L2 use bu..."
We used to only rely on the public mempool. But our blobs took long to get included so now we post to multiple APIs.
00:20:42
Marius van der Wijden:Replying to "Also, most L2 use bu..."
(Which is the correct behavior I think)
00:20:44
FLCL:Replying to "wait the EL never se..."
blobs can be used to recontruct l2 state, so I guess they would be still needed
00:21:28
stokes:https://notes.ethereum.org/@bbusa/fusaka-bpo-timeline
00:21:50
Barnabas:ship it
00:22:18
Sam Jernigan:ship
00:22:27
Enrico Del Fante (tbenr):LFG
00:22:30
Marius van der Wijden:Nov 3. sounds good to me
00:23:26
Fredrik:Mainnet
Mainnet should not have an upgrade date set until all testnets have been upgraded.
The upgrade must have gone through at least two testnets.
Mainnet must not upgrade less than 30 days after the final testnet has been verified to have been successfully upgraded. This is to ensure enough time has been given to test and spot potential issues before going live on mainnet and to allow for downstream projects to plan their upgrades. L2s need time to produce DAO proposals, organize their own upgrades, etc.
00:23:31
Phil Ngo:Although this is probably implying that we don’t have anything from the Hoodi fork that would be of concern, Nov 3 release is doable.
00:23:39
Fredrik:https://github.com/ethereum/pm/blob/master/processes/protocol-upgrade.md#mainnet
00:23:41
Phil Ngo:Hoodi is on 28th October
00:23:51
Francesco:Replying to "2D peerdas was repea..."
...
00:23:53
Barnabas:should not is not must not :D
00:24:16
Fredrik:Indeed, but we should at least take it into consideration
00:24:35
kingy_sigp:we've already put dec 3 ascii art in lighthouse, we're gtg
00:25:02
Justin Traglia:I support this 👍
00:25:09
Łukasz Rozmej:No issue for Nerhermind
00:26:44
potuz:release named "dia de los muertos", a little prophetic for the fork :)
00:26:48
Raúl Kripalani:Replying to "2D peerdas was repea…"
AFAIU, this isn’t really about 2D PeerDAS, but about resolving for some user access patterns
00:28:16
Raúl Kripalani:Replying to "2D peerdas was repea…"
What these nodes are interested in is in accessing their own blobs, which custodying specific row indices wouldn’t give them anyway
00:28:27
Marius van der Wijden:Have we prototyped trustless payments? Have we tested trustless payments? How would the userflow work?
00:28:58
Justin Traglia:Replying to "Have we prototyped t..."
Trustless is the current spec, so yes.
00:30:10
Dustin:why do people keep trying to split the trustless payments part off? it was one of the things justifying its complexity, and it keeps coming up
00:30:54
Barnabé Monnot:Replying to "why do people keep t..."
imo this is a contentious feature, despite broad core dev agreement to the contrary
00:31:43
Ansgar Dietrichs:I think I agree. let’s treat them as separate for governance, but keep them together in EIP / spec, unless / until we were to decide to not have staked builders in Glamsterdam.
00:31:44
Christoph Schlegel:Replying to "why do people keep t..."
But what is so contentious about them? It’s a feature feel free to not use it
00:31:48
Dustin:Replying to "why do people keep..."
Ok, from my perspective that's just straight-up bait and switch if it's dropped now. The vast majority of ePBS complexity is in place anyway, and this drops an actual benefit from having two signers
00:32:33
Barnabé Monnot:Replying to "why do people keep t..."
@Christoph Schlegel features take time to ship and have consequences on future designs. that said yes we are imo too far down in the implementation tree to reverse course at this point
00:32:37
Justin Florentine (Besu):Replying to "I think I agree. let..."
not sure i understand how that is practicable?
00:32:56
Dustin:Replying to "why do people keep..."
the builder API has been broken and created weird trust relationship ("unbundling attacks") etc for years, and this is finally an alternative
00:32:56
Ansgar Dietrichs:Replying to "I think I agree. let..."
well as in, we make the final decision soon (say pre devconnect)
00:33:24
Ansgar Dietrichs:Replying to "I think I agree. let..."
then it would still be possible to split
00:33:41
Barnabé Monnot:Replying to "why do people keep t..."
@Dustin your arguments, not mine
00:34:17
Christoph Schlegel:Replying to "why do people keep t..."
@Barnabé Monnot but on the future consequences part I haven’t heard any convincing argument. The only argument I could envision is that we could design them in a better way. Or was there anything else?
00:34:30
terence:Replying to "I think I agree. let..."
for CL client, its hard to make any substantive progress on glamsterdam until we can come down to a firm decision
00:34:58
Ansgar Dietrichs:Replying to "I think I agree. let..."
well I think you should move forward for now assuming they stay together
00:35:05
Barnabé Monnot:Replying to "why do people keep t..."
@Christoph Schlegel better write-up here https://discord.com/channels/595666850260713488/874767108809031740/1428346638606532689
00:35:07
Francesco:Replying to "why do people keep t..."
For example supporting them has an effect on the consensus protocol design. When we want to change this in the future to improve the current very sub-optimal protocol, there’s likely going to be a price to pay
00:35:13
Ansgar Dietrichs:Replying to "I think I agree. let..."
it is already understood that a split would be somewhat disruptive
00:35:42
terence:Replying to "I think I agree. let..."
split would mean a new EIP, new consens spec, new everything imo
00:36:48
Ansgar Dietrichs:Replying to "why do people keep t..."
why do people keep trying to split the trustless payments part off
I can only speak for myself: I really want FOCIL in Glamterdam, but staked builders + FOCIL is just too big of a scope to me. So I’d rather do FOCIL instead of staked builders.
00:37:51
Justin Florentine (Besu):i'm having a hard time imagining scheduling just staked building in a future hardfork.
00:37:57
Ansgar Dietrichs:Replying to "I think I agree. let..."
not sure “new spec” is an accurate way of describing it, we constantly make changes to EIPs as we get closer to a hard fork
00:38:16
ethDreamer (Mark):I didn’t say it was impossible or super difficult. I just said that at this point in the process it will almost certainly take more time.
00:38:34
Ansgar Dietrichs:Replying to "i'm having a hard ti..."
that should be a sign then that it is not a super impactful feature.
That’s exactly why I prefer to ship FOCIL in the first place.
00:39:06
Barnabé Monnot:Replying to "i'm having a hard ti..."
If the point is that it could have only been shipped as an omnibus feature, I think it’s not a very convincing argument for shipping trustless payments
00:39:09
potuz:free option problem has nothing to do with trustless payments
00:39:21
terence:wait, trustless payment has nothing to do with free option problem
00:39:45
Ansgar Dietrichs:Replying to "I didn’t say it was ..."
more time than having not had it in ePBS in the first place? or more time than keeping it in? I really think the reworking of all of the testing efforts to accommodate the new dual building pipeline will be a huge headache
00:39:51
Ansgar Dietrichs:Replying to "free option problem ..."
agree.
00:40:01
Justin Florentine (Besu):Replying to "i'm having a hard ti..."
i take it more as a signal that it is controversial, and has opposition. not that it isn't low impact. I think it's very high impact and pretty fundamental to ePBS
00:40:02
Christoph Schlegel:Replying to "free option problem ..."
Well if you don’t have a trustless payment, you would need to have a relay helping you with the free option
00:40:22
Christoph Schlegel:Replying to "free option problem ..."
But generally agree that it would still be there with or without
00:40:36
ethDreamer (Mark):Replying to "I didn’t say it was ..."
More time to come up with an alternative spec at this point in the process and hash out the debate and rework the code
00:41:07
Sophia Gold:Replying to "free option proble..."
Can't you mitigate it by commiting in the slot after the reveal? How would that work with trustless payments?
00:41:31
Justin Traglia:I support leaving it as it is.
00:41:31
Ansgar Dietrichs:Replying to "i'm having a hard ti..."
does it have opposition? my opposition is purely about opportunity cost. if we ever have a hard fork where we don’t have anything more important, we should ship it!
00:41:44
Dmitry Gusakov | Lido:The question is does it add a meaningful benefit to outweigh the complexity
00:41:50
Barnabas:Can we just make a decision and stick to it?
00:42:03
Justin Traglia:Replying to "Can we just make a d..."
Yes please.
00:42:04
Barnabas:Lets not drag it on for 2 more weeks
00:42:08
potuz:Replying to "Can we just make a d..."
yes please
00:42:09
Francesco:Replying to "i'm having a hard ti..."
I have some level of opposition to it because it’s very much not clear that it’s a “free” feature (or rather that the cost is only the work it takes to ship it)
00:42:22
Ansgar Dietrichs:Replying to "Can we just make a d..."
I think making the decision before making a decision on FOCIL means effectively killing FOCIL.
00:42:24
Justin Traglia:So we have decided to leave it as it is?
00:42:25
Dmitry Gusakov | Lido:Replying to "Can we just make a d..."
Agree, that the decision is needed
00:42:41
Francesco:Replying to "i'm having a hard ti..."
There are costs, we just don’t 100% know what they are and we will only find out later
00:42:47
Fredrik:As is it is
00:42:56
Francesco:Replying to "i'm having a hard ti..."
Otherwise it’s obviously a good feature, we just don’t know what we are trading it off against
00:43:19
Ansgar Dietrichs:wait the decision was explicitly not to give it “headliner proteciton status” though, right?
00:43:42
Ansgar Dietrichs:Replying to "wait the decision wa..."
I understand that that is what people want to do anyway, so in practice I don’t see it being removed. just asking as a matter of process
00:44:39
Enrico Del Fante (tbenr):I think more the second
00:45:22
Marius van der Wijden:Yeah, pulling it out in 6 weeks for focil is bad imo
00:45:58
Dustin:FOCIL being deliberately put after ePBS was always making it contingent, that was the deal
00:46:03
Justin Florentine (Besu):EL devs putting on their CL hats...
00:46:37
soispoke:I don’t think we should necessarily make the decision about FOCIL right now tbh, to me it also depends on other EIPs?
00:46:55
Ansgar Dietrichs:staked builders are also not a scaling feature
00:47:03
Ansgar Dietrichs:Replying to "staked builders are ..."
that’s the point
00:47:27
Justin Florentine (Besu):cries in CROPS
00:47:38
Ansgar Dietrichs:Replying to "staked builders are ..."
we decide to prioritize staked builders over FOCIL as the main non-scaling part of the CL-side Glamsterdam scope
00:47:47
Ansgar Dietrichs:Replying to "staked builders are ..."
I think that is a really really bad decision
00:48:05
Ansgar Dietrichs:Replying to "cries in CROPS"
I mean same. I really think this might effectively be the death of censorship resistance on Ethereum, full stop
00:48:12
Dmitry Gusakov | Lido:Replying to "staked builders are ..."
I have a feeling that staked builders will not see a major use. Cause there is not real reason for builders to switch from off-chain
00:48:30
Marius van der Wijden:Replying to "cries in CROPS"
Thats a bit hard, I don't think so
00:48:34
soispoke:Replying to "cries in CROPS"
agreed, are people 100% confident we wouldn’t be able to ship both?
00:48:36
Ansgar Dietrichs:Replying to "cries in CROPS"
at least 20% chance that by H-Star FOCIL is too controversial to be shipped
00:48:38
Justin Florentine (Besu):Replying to "cries in CROPS"
can't the devs do something?
00:49:03
Barnabé Monnot:Replying to "cries in CROPS"
I’m 80% confident we shouldn’t ship both
00:49:16
Ansgar Dietrichs:Replying to "cries in CROPS"
@soispoke I mean I think that is where most ppl here disagree with me. to me, yes, shipping both would be super irresponsible. but I think there is a chance we do that anyway
00:49:22
Sophia Gold:Replying to "staked builders ar..."
Agree FOCIL is much more useful than trustless payments, but it's not clear to me that's the tradeoff
00:49:35
Dmitry Gusakov | Lido:On 7688. It will be great to finally have it
00:49:35
Barnabas:We have time, so why not discuss FOCIL in or out?
00:49:43
terence:isnt that too early?
00:49:59
Josh Davis:30
00:50:03
Justin Florentine (Besu):tbf FOCIL is CFI
00:50:07
Etan (Nimbus):quite a few EIPs actually depend on 7688 too, e.g., terence’s 8015 would be enabled
00:50:07
wolovim:Glamsterdam point of contacts/champions are listed on forkcast now: https://forkcast.org/upgrade/glamsterdam — some assumptions made, reach out if anything is not as expected.
00:50:13
Etan (Nimbus):that’s why I brought it up early, as it’s foundational
00:50:17
nixo:yea i do think there’s good reason to treat focil differently from the PFIs
00:50:22
Parithosh Jayanthi:Replying to "isnt that too early?"
If we struggle to agree on the major EIPs before fusaka is shipped, then we can’t start pipelining anything
00:50:28
Dmitry Gusakov | Lido:Sorry, what is the resolution on 7688?
00:50:38
Ansgar Dietrichs:majority of PFI’d EIPs are EL-side
00:50:43
Dmitry Gusakov | Lido:But why?
00:50:50
Ansgar Dietrichs:Replying to "majority of PFI’d EI..."
so CL side should be a bit more manageable
00:51:02
Marius van der Wijden:Replying to "But why?"
Process reasons
00:51:02
Barnabas:Replying to "isnt that too early?"
we need to accelerate somewhere
00:51:19
kev:On PeerDAS, is max-blobs needed for Fusaka?
00:51:28
Marius van der Wijden:Replying to "But why?"
We should focus on getting fusaka out the door before we start the tedious process of filtering new eips
00:51:30
kev:Replying to "On PeerDAS, is max-b..."
yep
00:51:32
soispoke:People are not necessarily prepared to talk about FOCIL (it wasn’t on the agenda or anything) but I do think it should be somewhat treated differently than PFId EIPs
00:51:35
Barnabas:Replying to "On PeerDAS, is max-b..."
thats more of an EL question
00:51:56
Dmitry Gusakov | Lido:Replying to "But why?"
Fair. Let’s not just drop it for the third time lol
00:51:57
Barnabé Monnot:Replying to "isnt that too early?"
What new information would be known later? Seems we already know that it would add some constant amount of delay to the fork
00:51:58
soispoke:Replying to "People are not neces..."
And have a FOCIL specific discussion soonish