All Core Devs - Consensus #167

Transcript

Alex Stokes: Blue. Okay, let's give people another minute or two, and we will get started.

Hey, everyone who has joined. Let's give it one more minute, and we will kick things off. Okay, Josh, are you helping with the stream? I'm ready when you are.

Josh Davis: Alright, you're alive. Alex, take it away.

Alex Stokes: Okay, thank you. Hey everyone, welcome to ACDC. This is number 167. It's PM issue 1754 in the repo here. There's a link to the agenda in the chat. 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… 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. 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 Busa: Nothing really to add, it is still going forward. There's a couple of bugs that we have discovered, Regarding, database usage, I'm not dropping some blobs on the store side, but, has been… Sorted out, basically.

Alex Stokes: Okay, cool. then let's jump into Testnut. So, I believe since last week's ACD, we had Haleschi BP02, and also the Sepolia fork. 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? Let her go?

Enrico Del Fante: Yeah, nothing really specific to these events, but just to say that we have discovered a bug in the way we were subscribing to… column subnets. Essentially, we were only subscribing to all subnets in case we You configure the node as a super node. Otherwise, if you are running enough validators, but without the flag, it will… Techo was only subscribing. To 8, subnets. so, we haven't discovered that before, because essentially the node is still able to… get from EL plus from RPC calls, and manage to… To sync up the blocks in time. But yeah, something is something that we are fixing.

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. So, yeah, that's it.

Alex Stokes: Okay, cool. Yeah, nice find. Anything else on Haweski or Sepolia? Okay. So far, the testnets have gone really well. Definitely no issues like Pectra, so that's really exciting to see. Next up, Frederick here wanted to give an overview of the Fisiana contest that I believe has wrapped up. Let's see… Yeah, ended on the 13th, so… Frederick, are you here?

Fredrik Svantes: Yes, I am. Yeah, I just wanted to mention that the contest ended on Monday, so right now there's this process of 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… Cause any reason to postpone, Yeah, to postpone the hard first, basically. So, it seems like we're good.

Alex Stokes: Okay.

Fredrik Svantes: We will, release a, like, a full, List all vulnerabilities, etc, once, once it's done, probably, in a few weeks, from now.

Alex Stokes: Alright, sounds good, yeah. Also, exciting to hear, no major issues there. Okay. Next up, I did want to touch on the different blob APIs. So, I think some of this caught some people off guard. There's the proof change moving from the 4844 style blobs to the pure dust-style blobs. The first place you'd probably run into this is if you're submitting blobs, say, to the execution layer, a note there. And then also there have been some tweaks to the APIs to read blobs from the CL. I don't know if anyone wants to add anything here. Essentially, yeah, I think… there is some confusion around which nodes do what, or sorry, like, which implementations do what. I know that some clients

Try to maintain some of the previous behavior as a bit of a bridge. But, ultimately, 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. We'd all be happy to… to help you here. Yeah, Justin here is asking which L2s were affected. a good number of them, me and I think many others of us here have been talking to them this week, I… don't necessarily want to call anyone out, but some roll-ups seem to be on top of it and already. I think some…

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. 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. But I think, taken together, yeah, there's some miscommunications there. Yeah, Lucas here says, by the way, another month's considering enabling conversion like F. Yeah. So, if anyone has anything to add here, that would be nice. 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.

Marius?

Marius van der Wijden: Yes. Part of the problem was that it wasn't… well communicated on the… on the EF workforce. 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, I think just, it would be nice if ESP editors would also just put some lines about RPC filters that I needed. put the IPs in, so that we don't, don't, have this… I'll get into this, miscommunication again, in the future.

Alex Stokes: Yup, definitely a good idea. 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? 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. 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.

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. Many of the roll-ups, it sounds like, treat the testnets also as production. So then they don't quite have this, like, testing ground. 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. So that's definitely something. To keep in mind moving forward. Yeah, another good point from Nixo. We had Macong for Pectra, which is kind of like a long-standing user test…

Long-standing, user-facing testnet. 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. 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. Yeah, I think this is something we'll need to work through, 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. But, in any case, yeah, I think something altogether we can work on. So… Related to that, there is a comment here on the agenda from…

Cohen MTP1, from Aztec. 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. 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. 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. Basically, currently in the current system, we have to require everyone to run super nodes, which is not ideal, given the bandwidth constraints.

Alex Stokes: Yeah, understood. Let me grab a link here to your post. There's a nice message here on 8th Magicians. 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. 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. 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.

Let's see… Yeah, Dustin's pointing out here in the chat that basically… there is a tension here between how pure dust works and how you get the blobs. 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. Cause then from there, you can reconstruct the blob, and then you're kind of good to go. 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. 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.

So… Again, lots of comments in the chat. I don't know if anyone wants to speak up. Otherwise, I would suggest we take…

Enrico Del Fante: Sorry, just for… so… 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… tiny window of storing those blobs, just to serve the API, and then throw them away in… 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: 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, Mmm… disconnected, but in practice, you want to listen to all the nodes, all the columns. Yeah, correct.

Alex Stokes: Notice.

Potuz: Prism is implementing precisely that. 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. 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. 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: Is that sufficiently reliable? I mean, in practice, but not maybe in.

Potuz: if you're… I mean, if.

Enrico Del Fante: 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. 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: 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.

Alex 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. either reach out to the various rollouts to Fogniz, or go to Magicians here, and yeah, it sounds like there are… Adjustments on the way to facilitate this use case. And if not, there are other… other options. Manu?

Emmanuel Nalepa: Yeah, just, to say, Currently at SuperNode, stores 128 proofs and 128 cells. 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. This way, we could save, for SuperNode, we could save up to almost 50% of this usage.

Alex Stokes: Yeah, I think the concern is more bandwidth here, but yeah, that's also helpful on storage as well. Our roll-up's definitely gonna need to store. All of their blocks, which is probably equivalent to all of their blobs. Okay. Anything else on the topic? I think one takeaway, again, if you're listening, as a non-core dev. 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. Yeah, walking through some of these changes. Okay. So… Then another tangential thing to this… is an RFC from Jimmy, I believe. Let me grab the link here.

So… 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. I was talking… okay, Chava already commented on here. I think he brought up the point that this might… 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. 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.

I don't know if Choppa's here. He could say more right now? 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. Okay. Then, next on the agenda… through stock on Mainnet, the time that we've likely all been waiting for. So, if we… Went to ship through Saka this year. The time is actually pretty much now to go ahead and start talking about this. Barnabas had that proposal here. Again, let me grab this link. that would put mainnet on December 3rd. And then schedule our two BPOs, one of them on December 17th, and then one, into next year on January 7th.

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. That would imply, following our process, that we have, essentially everything ready by November 3rd, which is actually coming up quite soon. So, that would mean client releases by then, we'd get another EF blog post out, and, you know, everything there. So I think today, I just wanted to get a temp check from whoever's present on, yeah, the feasibility of this, and… 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.

Frederick.

Fredrik Svantes: Yeah, I just want to say that if, if we do decide this, today, then we, do a divergence. Well, maybe not the divergence, but… 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. And also, yeah, I mean, it's a should, but I think it's something worth considering, at least. If we need to set it now, or if we should set it at a later stage.

Alex Stokes: Yeah, there's… Something there. So… 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. Let me double check when hoodie is, because then that's another question. Let's see, hoodies… the 12th of November, So… Oh, no, sorry, the 28th of October. So… Let me just run through the calendar here… 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. 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…

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. So, thanks for bringing that up. We do have the process for a good reason. 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? Aiming for mainnet releases on November 3rd, and then mainnet on December 3rd. And again, this is just a temp check. I think we'll probably need another week or two to actually get to An official, determination of the dates. I've not seen anything in the chat yet around any issues there.

I'll also be reaching out to each client team, async, just in case there's other things that come up, but… okay. 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. I think we're looking good there. Let me find the agenda… So, cool. And I think the last thing with Husaka today is just calling out, Sepolia BPO next week. I should say BP01. Let's see, that is… 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.

Okay. That was all I had for Fusaka. Anything else that we should bring up today? Okay. Then we will move to Glamsterdam. So, with Glamsterdam, yeah, as we see, Fusaka's moving along well, so it's definitely time to start thinking about Glamsterdam. The first agenda item here, is following up on the last call we had with Trustless Payments and EPBS. So… Last call, someone had brought up… well, I think there's a presentation from Lynn, so… 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.

There was an EPVS breakout last week, there is more discussion, but ultimately, I don't think there is a resolution either way. What I would say at the moment. Well, maybe I'll pause there. Is there anything anyone would like to add on this topic right now? Yellow.

Lin Oshitani: Yeah, so, yeah, as a person who kind of reopened this whole can of worms, I can share what my thoughts are right now. So, like, I think I still do believe that we, like, should have separated this EIP. And… 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. I think it wasn't discussed enough compared to that. But, like we discussed in last week's… breakout room that… For those raised points that. doing EPBS without process payments, it's also, like, under-discussed. We don't have, like, concrete specs, and… Like, there were some open problems that he mentioned.

And another thing is that we had discussions around, like, how do we support just, off-protocol payments. within the clients. As a standard, like, not as, like, each client to implement on their own, or… 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. Having such things will… like… minimize the impact to the ecosystem, which is, I think, a good direction. I think a lot of people. Or, like, did not have the impression that, like, the core devs were open to this, so, like, it's very… Which maybe they did, but, like, that was impression, so I think it's very nice to see discussion on that direction.

So… Like, while… in conclusion, like, while I still do things that… It's better to be separated, and it was better to have been separated, like… I think we should have had this discussion much earlier. I think the EIP SFI process, like, there's probably some improvements that that we made around this, or how we split or bundle EIPs together. But personally, I won't, like… Based on the portal's point, and that fact that off-protocol payments is going to be properly supported, I'm not gonna push Like, further on the separation? Noted.

Alex Stokes: Sure. Yeah, thank you. Enrico?

Enrico Del Fante: just a general comment. So, given that the… at the moment they are spec'd out together, So, I'd like to have a split in the spec, just after we decided that they should come separated, and the PPS should go in without trustless. a payment, so I don't want… I would like to not be in a world where 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… 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…

Let's go EPPS without, you know…

Alex Stokes: Yeah, makes sense. Definitely many trade-offs here around how we go about shipping this. Mark?

Mark Mackey: Yeah, I mean, I guess I would just echo some of the things. I think Lynn's… take was… But pretty decent as well, and so it's… Enrico, I… like… Sorry, I'm a little bit blanking here. Like… it does seem easy to look at EPBS and see it as, like, a monolith. Or as an opinionated design, but… We did do a fair amount of exploring. Everything from a lot of different angles. And, I mean, I guess if there were more people involved for longer periods of time, we could come up with Some kind of progressive spec of separating out these features while keeping most of the things, but… in terms of, like, I think where we ended up.

I guess my personal opinion is, like. You know, sometimes you have to work with the information you have at the time. 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… 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… Things that you get from block payload separation, so… 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.

Alex Stokes: Thanks. Okay. Dimitri.

Dima Gusakov: 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. Especially for LiDAR, and there are two… like, even though I genuinely support the trustless payments idea. I really wanted to voice out that the current proposed design adds a bit of a complexity on both off-chain and on-chain support for this thing. So, for example, should 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…

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. 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 Because now you need not only to look at the off-chain market, which we… 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…

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… 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.

Alex Stokes: Yeah, thanks. Let's see, there's their… Oh, Francesca.

Francesco D'Amato: Yeah, just a quick comment responding to Mark. 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. They give us better properties. Whereas if the goal is just more… the more restricted, just… 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.

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… 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. 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.

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… 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.

Alex 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 delay actually shipping the hard fork, or even that, eBBS could go the way of Pyrodos, and we have to split Glamsterdam. 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. 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…

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. 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, I think from, at least conceptually, quite large design aspect of ePPS that, we have, sort of been ignoring.

Lin Oshitani: We'll just do… Oh, sorry, Mr. Sponge.

Alex Stokes: No, go ahead.

Lin Oshitani: 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 design that has pre-option problem or doesn't have pre-option problem. I think they're pretty independent. So, I do agree we should discuss it, but I think… Leave it out of this specific discussion for now.

Alex Stokes: Okay. Any other comments while we're here? That I was… I was surprised there were so many hands. Okay, so yeah, I think this conversation highlights that… This is… 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. 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. 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. 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.

So… I… at least where I'm at right now, is I think we leave things as is. And keep moving forward with Amsterdam. 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… I think that's a good summary of where we're at now. Any last words? 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… You know, there's always an option, we need to reevaluate, but…

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. So, I'd say leave as is. Any final comments? Okay. then that is settled. We have trustless payments, as is in the IP. Okay. So, we should be good there, I could ask about implementation progress, but I don't think there's been much,

people have been busy with Fusaka, and also we are kind of waiting on this question to… Moving forward. So, that being said. 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. Next up, we have… Okay, so… This was about… let me just double-check this comment. Okay, so… Etan brought this up. he… Oh, there's a question. Let me address this. Onsgar… I don't know what you mean on scar. 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 ACD calls about Amsterdam, it would be basically out of scope. Off-limits to revisit removing it at all. 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. 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.

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.

Alex Stokes: Yeah, it seems like we're deciding now, like… I think it would be hard… 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. 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. 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. 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.

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. I understand people probably think these are orthogonal decisions, I don't, but… If we want to make it a final decision, and then… People don't think that means we exclude fossil, then that's fine with me.

Alex Stokes: I think we can have the conversation about Fussell once we get there, I think that'll be pretty soon, and a few calls coming up. 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. 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. It would be… Strange to pull it out later, just because we want to include something else down the line. Okay.

Thank you, Oscar. I will go back to… the agenda item we had here, so… Etan brought this up. 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. This introduces, generalized indices, which I think most of us have seen this feature by now. And he's proposing to put it, into the fork. So… Again, I don't think we should necessarily discuss it much further today. Because we will talk about inclusion around the full set of PFID IPs, again, in a few calls. 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.

That being said, he did want to bring this up. And I will also, call out that DIVA and, Lido both gave support for this EIP. On the agenda, and you can look at the comments there if you want to see more. So… Let me just make sure I got everything… Yeah, okay. That was everything on the spec for Amsterdam. Anything else that we'd like to discuss today? There's some more comments in the chat that we could touch on. If people would like to, because we do have some time. I mean, it looks like it's coming down to the fossil question, which, again, this is the tricky thing, because…

We have one headliner, essentially, and it's hard to do both. They're both relatively big EIPs. 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. And there's actually quite a long list. I was just looking at the Meta EIP Yesterday… let me go find it… There's quite a bit that's been proposed. This is EIP7773, and yeah, there's… 29 EIPs here. So we're gonna have fun sorting through all of those. But ultimately, yeah, I think it's a bit early, honestly.

Yeah, Dimitri's asking about 7688. So it's a bit early to discuss inclusion, It should be in this PFI list, and if not… I saw it somewhere 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. So… 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. Kev's asking about the Max Blob slag. I think that's what you mean, Kev, right?

Yeah. I don't think it's needed, clients are working on support, but yeah, it's definitely there. Okay. Anything else? Otherwise, we'll go ahead and wrap up for the day. Okay, thank you all, and again, yeah, keep an eye on Sepolia. We have VP01 coming up next week. Thank you all. I'll see you next time.

Marius van der Wijden: Thank you, bye. Bye-bye.

Pooja Ranjan: Thank you.

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