stokes:Okay, everyone, let's see, let me find the agenda… so… This is ACDC, number 166.
Transcript
stokes:It's issue 1740 in the PM repo.
stokes:Here's a link here.
stokes:And… yeah, on the agenda today, pretty straightforward, some Osaka things, some Web Amsterdam things, and then a few…
stokes:other things around different EIPs and the process.
stokes:So let's go ahead and jump into Fusaka. I thought I'd ask if there are any DevNet updates. I know there was some chatter on Discord across the week to this effect. There might not be anything. We did have the Heleshky fork, which we'll talk about next.
stokes:Anything on the DevNets that we should discuss?
Parithosh Jayanthi:Yeah, we tried non-finality on Fusaka DevNet 3, and we had non-finality for about 2-ish days, and then healed the network again, and it's been finalizing since.
Parithosh Jayanthi:I'm not sure if Barnabis had any other… Updates to add?
stokes:He says no.
stokes:Okay, cool.
stokes:then let's move to Aleshki. So we had the fork activation, about a few days ago, and yeah, as far as I can see, it went pretty well. There was…
stokes:A little turbulence, which I think at this point is to be expected with testnuts.
stokes:Yeah, again, Perry A Barnabas, any updates, there?
stokes:Or anyone else want to add anything about Halushki?
stokes:Do we feel like it went successfully?
Parithosh Jayanthi:Yeah, so we had the DevNet fork yesterday, and we've been, keeping an eye on it. There was one incident halfway through the… so, sorry, so let me start from the beginning. As soon as the fork was done, we did notice a participation drop.
Parithosh Jayanthi:But all of the participation drop was associated with, missed updates, so once the updates were applied, we were able to hit back almost the same as, before the fall.
Parithosh Jayanthi:We're still tracking around the missing diff, but later in the day, we did notice one scenario where we're still figuring out what's necessarily going on.
Parithosh Jayanthi:But there was an unexplained drop in participation rates. We went below 66%, and then it came back up. Sam's posted a few theories, mainly to do with, either missing or late blocks, and also associated with,
Parithosh Jayanthi:spikes in CPU usage, likely related to spam or kind of spamming in relative, like, it has ticks to when it's spamming stuff.
Parithosh Jayanthi:It could just be a combination of all of these factors. Also, most people tend to have something like 10,000 validator keys per beacon node on Holzky, so it could just be a combination of everything, but we still don't have a…
Parithosh Jayanthi:Concrete answer for, why the participation rate went down, or how it recovered, either.
Parithosh Jayanthi:But since then, it's been… we haven't noticed any, any big issues. So, yeah, like Bohus says, there were a bunch of hiccups.
stokes:Yeah.
stokes:When you were saying updates, you mean, like, just people updating to new versions of the client?
Parithosh Jayanthi:Yeah, you're right. Yeah.
stokes:Okay.
stokes:And yeah, there could be a number of reasons for this.
stokes:Yeah. So…
stokes:it was good to see that, and yeah, it looks like it's pretty good so far. So, I guess we'll keep an eye on it.
stokes:The next thing there to call out is… the first VPO scheduled, which is…
stokes:Let me just double check, because I think I actually have the date wrong on the calendar. So yeah, that's, on…
stokes:Monday… Unless this is Tuesday UTC.
stokes:anyway, let me… let me not confuse people.
stokes:But there's one in a few days, yeah, again, check the blog post if you need the canonical time.
stokes:Or any of the client configuration.
stokes:So, have that on the radar.
stokes:And we'll see how that goes.
stokes:But yeah, I think all end, we're moving along pretty well.
stokes:So, anything else on Haleschi anyone wants to discuss today?
Ameziane Hamlat:Yep.
Parithosh Jayanthi:Go ahead.
Ameziane Hamlat:Yes, sorry, I was going to say,
Ameziane Hamlat:I have noticed a drop in the network activity on on peso validators, on HODI.
Ameziane Hamlat:And I guess that was expected, and I wonder if there are any other metrics. I think it is interesting to see, like, the drop in the network usage.
Ameziane Hamlat:Especially just before the next BPO.
Ameziane Hamlat:If we have other metrics related to that.
Parithosh Jayanthi:Is this for the whole Ski network, or the Houdini network?
Ameziane Hamlat:Sorry, holesky, holesky.
Ameziane Hamlat:Like, the… after the fork.
Parithosh Jayanthi:Okay, yeah, maybe we can just chat about that on, on our group, and then we'll try and see what we have associated to the bzov validators, and see where we can help.
Ameziane Hamlat:No, it is not an issue. It, it, it is, it is more, an observation,
Ameziane Hamlat:That, in my opinion, was expected, like the drop in activity, in network activity related to PERDAS.
Ameziane Hamlat:So that was something that I noticed on the…
Ameziane Hamlat:like, on the… on base validators, and I was just wondering if…
Ameziane Hamlat:If that was the case, and if we have, like, numbers, I thought it was interesting to check… to check that specific metric, just before
Ameziane Hamlat:The next BP rule?
stokes:You just mean, like, total bandwidth usage?
Ameziane Hamlat:Yes.
stokes:Yeah.
Barnabas:Did you notice the song on Super Notes, or also on full notes?
Ameziane Hamlat:Sorry, say it again?
Barnabas:Did you notice the bandwidth usage increase only on super nodes, or only on, full nodes?
Ameziane Hamlat:It's, it's a decrease, it's a decrease in the bandwidth.
Ameziane Hamlat:So we dropped, like, by more than 50%.
Barnabas:Yeah, but is it a validating node, or not?
Ameziane Hamlat:Yeah, yeah, validating notes.
pk910:Was that exactly at the fog boundary? Because we… shortly before the fog, we started spamming blobs to the network.
pk910:Before that, there were basically no blobs.
Ameziane Hamlat:Yeah, so that was exactly at the forked boundaries, just after the fork, actually.
Ameziane Hamlat:But do you, like, do you see the same on other clients, or not? Because I would expect to see the same.
Ameziane Hamlat:So, basically, a drop in the bandwidth usage.
Parithosh Jayanthi:We're still working on our bandwidth analysis, so we don't have… have that yet. But yeah, as soon as we do, we have it clustered per client, and then we'll have the report generated probably tomorrow.
stokes:Okay.
stokes:Anything else on Halashki?
stokes:Okay.
stokes:Then next up, I did want to call out this PR, so…
stokes:This came up from ACDT on Monday, and…
stokes:Essentially, I think it was a couple different things in here.
stokes:One of them, is just having, what we usually call, like, a readiness doc. So, you know, you could imagine there's, like, a pure DOS readiness doc, which just runs through, you know, these are the different checkpoints we need to see on the network before moving ahead, these are different tests we want to do, things like this.
stokes:There was one here…
stokes:from, you know, sort of across the whole lifespan of PureDOS development, and it kind of became…
stokes:well, let's just say it became a heavy working document. If you go to it now, it actually links to a Google Doc that also has a bunch of stuff.
stokes:That was one part. Another part, is actually just copying over some of the process stuff that we put in place with Pectra.
stokes:And most of this is relevant for mainnet, so I just started the PR and just kind of put down the skeleton here. We'll fill this in, you know, once we're closer to Fusaka Mainnet, but it's there.
stokes:And… Yeah, I should probably go and clean up this readiness document. It's…
stokes:I have a mess right now, but either way.
stokes:I'll keep working on that.
stokes:But just wanted to call this out, again, it'll probably be more relevant
stokes:As we get closer to mainnet, but that's underway.
stokes:And… Yeah, I think that's all we had on the agenda for Forsaka today.
stokes:Anything else?
stokes:I mean, in short, So far, Leshky's gone well enough, and we're gonna keep moving forward.
stokes:Okay.
stokes:So then, Glamsterdam.
stokes:I'm… curious what people think, you know, so we've kind of had this…
stokes:let's just say directive over the past couple ACDs of saying, hey, you know, we're focused on Fusaka, so let's, you know, kind of not think about Climstrom too much.
stokes:It seems to me, just kind of reading the room, that we're at a place now where I think we can start putting more attention back into Glensterium.
stokes:You know, obviously, if some of the FSACA changes, a testnet doesn't go over something, that will change.
stokes:But it seems like we can start focusing more on Amsterdam, so I would expect…
stokes:kind of starting today and moving forward, we'll have more emphasis on Glamsterdam back in the different ACD calls.
stokes:So, to that end,
stokes:we should probably start thinking about, you know, the whole process. So what does that mean? The process here is getting the specs hammered out for Amsterdam, it's getting to DevNets, and going from there.
stokes:So, one thing I could ask today is, how do we feel about, the DevNets for the various headliners?
stokes:I don't know if we want to touch on BLs today, but we can definitely touch on EPBS.
stokes:And again, everyone's been busy with Fisaka, so if the answer is not much has changed, that's fine.
stokes:But I would be curious, for an update there.
potuz:update on PBS or on… on… on block-level access lists?
stokes:Oh, sorry, on EPBS, yeah.
potuz:There's, nothing that has changed on the specs side. There's lately a discussion of, how to
potuz:Better enable,
potuz:trusted payments. We can have trusted payments just with the protocol as is right now, or there's a suggestion to add a field for off-protocol payments. That's the latest discussion on the spec, but the spec itself hasn't changed, we've been adding tests.
potuz:And since we are finding still bugs on Fusaka, we cannot.
potuz:start merging on develop. I think Teco is the only client that actually has, on their main branch, passing tests. Prism has a branch that has passing tests, but it's on a branch. It's still not on the main develop branch.
stokes:Gotcha, okay. So we're probably still quite a ways away from, EPF WebNet.
potuz:It's… probably not. As soon as we actually have a stable Fusaka branch, we can quickly merge all of Terence's work, and we will have some interrupt. And I… from the message that, Stefan posted on Discord.
potuz:Porteco, I mean, probably Stefan is here, that he can say, but it sounded like they are close to at least Cortosis.
Stefan Bratanov:Yeah.
Stefan Bratanov:From Deco perspective, I wouldn't say we're close, I think…
Stefan Bratanov:we want to focus a bit more on the design of… I mean, passing the reference test is a good first step, but there's a lot of things that,
Stefan Bratanov:Because the interop branch that we had before was very hockey.
Stefan Bratanov:So, I think I want to focus on, like, a proper design. So, I think there's, there's a why I want to…
Stefan Bratanov:We have DevNet, and since other clients, are also… Oh.
Stefan Bratanov:not, yet ready, I think we will wait a little bit and…
Stefan Bratanov:Be more careful when merging to master.
stokes:Yeah, I can see that. Yep, Harry and Barnabas are asking…
stokes:Or at least they're just pointing out we can run from our branch, but…
stokes:It sounds like what we don't want is to have, quote, a random branch that just becomes kind of unmanageable down the line.
stokes:So…
stokes:makes sense to be a little more mindful with that, because we kind of got into the situation with Pyrodos, as far as I understand, so…
stokes:Let's not avoid that.
potuz:Yeah, we don't want to repeat what happens with Fulu. We really want to start merging and develop right now.
stokes:Okay.
stokes:So then, yeah, we just need a little more time to get Fusaka
stokes:even more stable. Well, I guess, yeah, I guess that's the question, like…
stokes:how much is it we need to, like, think about more bugs coming down the line with Husaka versus…
stokes:it's just gonna take more time to get to, like, a stable EPBS branch, because we don't want to develop on the non-trunk.
potuz:I think we're gonna be very close. We just, like, had a release with a regression, and that's why we are delaying, but we were about to start merging this Monday.
potuz:So I suspect that next week we will be merging already on develop our gloss code.
stokes:No doubt.
stokes:And yeah, Pari has a comment here, are we happy with the design then? Unknown unknowns, and I believe you're referring to the spec, and that also tees us up for the next thing on the agenda.
stokes:As POTUS mentioned.
stokes:And some others have been discussing this week. There's a question around exactly how trustless payments work in EPVS. Lenoscope, if you're here…
stokes:Oh yeah, I don't know if you wanted to say anything.
Lin Oshitani | Nethermind:Yeah, can I… do I have time for a quick presentation?
stokes:If it's quick, yeah.
Lin Oshitani | Nethermind:C.
Lin Oshitani | Nethermind:Who… Can you see my screen?
stokes:Yep.
Lin Oshitani | Nethermind:Yeah, so, like, this is basically a call for discussion on trustless payments in EPBS.
Lin Oshitani | Nethermind:And quick context is that, EPBS, like, brings two critical changes to Ethereum. One is payload separation, is execution payload block separation.
Lin Oshitani | Nethermind:A lot of nice things, you separate the execution plate from the beacon block, you propagate and execute them separately for good pipelining, you get CL-side delayed execution.
Lin Oshitani | Nethermind:And process payments is another critical change that it introduces, where your builder becomes in protocol staked entities, commit to bids, propose or fetch bids, and payment is first in the CO.
Lin Oshitani | Nethermind:So, my proposal here is that we should either have a convincing argument on why trusted business payments cannot be separated from the current DIP,
Lin Oshitani | Nethermind:And that the complexity is worth it.
Lin Oshitani | Nethermind:Specifically, that there's no incentive to bypass it?
Lin Oshitani | Nethermind:Or we should have a separate EIP between the payload separation and the process payments.
Lin Oshitani | Nethermind:And discuss and decide them separately.
Lin Oshitani | Nethermind:Why? I see two reasons. One is, like, that these two features fundamentally have different stakeholders, so payload separation, it's about slot restructuring and scaling, so core devs are the experts here.
Lin Oshitani | Nethermind:They know all about scaling and can run benchmarks and all that. And ecosystems, they largely depend on CoreDevs for their expertise.
Lin Oshitani | Nethermind:On the other hand, for choices payments, it's about changing… fundamentally changing the block building pipeline, so I would say that the stakeholders are more the ecosystem players, like validators and builders.
Lin Oshitani | Nethermind:That are the experts, and end user of the feature too, and core devs, in my opinion, should take into account these activities, and
Lin Oshitani | Nethermind:My impression from the outside is that a lot of this discussion has been focusing on the payload separation.
Lin Oshitani | Nethermind:when Lamstrom was being discussed, like, what's the best pipelining solution and slot-restricting solution?
Lin Oshitani | Nethermind:I think there was fundamentally less discussion around the trustless payment part.
Lin Oshitani | Nethermind:And I think this is important in terms of governance, and one…
Lin Oshitani | Nethermind:I think, interesting case study is EOF.
Lin Oshitani | Nethermind:And I think I know that it's very, very different, but I also see a lot of parallel, and…
Lin Oshitani | Nethermind:Enough that it's interesting, and… I think EOF had different stakeholders.
Lin Oshitani | Nethermind:One is, like.
Lin Oshitani | Nethermind:with the core devs, and this was about removing tech tip and enabling easier upgrades of the EVM.
Lin Oshitani | Nethermind:And another was app and tooling developers, and they were, like, about the enabling better compiling tooling, and also at the cost of breaking changes.
Lin Oshitani | Nethermind:My impression from the outside was that the former was convinced, and the latter was not, and the end result was a loss for everyone, in my opinion.
Lin Oshitani | Nethermind:Well, the next reason I have is complexity and uncertainty. So, like, complexity of trustless payments, like, in terms of spec and CEO implementation, it's relatively simple.
Lin Oshitani | Nethermind:I would say is still, like, conceptually adds some complexity, because they're the new staked entity, but…
Lin Oshitani | Nethermind:I do see that it's, like, not the bulk of the complexity in each PBS.
Lin Oshitani | Nethermind:Well, in terms of ecosystem impact, I think it's far from simple. Like, it requires fundamental upgrades across the tool links, taking…
Lin Oshitani | Nethermind:And also, like, staking protocols, their accounting contracts and infrastructure.
Lin Oshitani | Nethermind:And it also had, like, a fundamental impact on the builder market that is very unclear.
Lin Oshitani | Nethermind:And, like, you can see, like, they send different, like, write-ups from different teams, like Lido saying that it adds a non-trivial increase in the protocol complexity, especially if they have to maintain both, like, the in-protocol payments and the off-protocol payments.
Lin Oshitani | Nethermind:And yet Aitan has pointing out that it will also negatively affect competition and increase concentration by raising barrier to entry, because you need to lock
Lin Oshitani | Nethermind:Like, liquidity up front, and also, like, you have… also always have the risk of losing it to everything if, like, your block doesn't land, and all that risk is up to the builder.
Lin Oshitani | Nethermind:So, like, complexity may be worth it if trustless payments are actually widely used, however, I think bypassability is an open question.
Lin Oshitani | Nethermind:Like, referring to the fact that proposers may be incentivized to bypass an improtocol justice payment.
Lin Oshitani | Nethermind:and instead use off-protocol options like MedBoost, And… If
Lin Oshitani | Nethermind:We have, like, bypassability, rational actors will bypass, hence we'll be introducing this complexity for nothing.
Lin Oshitani | Nethermind:And, yep.
Lin Oshitani | Nethermind:So… And, like, does justice payments re… like, one of the counterarguments here is that
Lin Oshitani | Nethermind:Business payments reduce latency, so that's why it's abused.
Lin Oshitani | Nethermind:Inc.
Lin Oshitani | Nethermind:that the card argument there is that current builders and relays co-locate, so ATC is mostly negligible.
Lin Oshitani | Nethermind:the point on, like, that we shouldn't… enforcing… like, we shouldn't be removing MedBoost supports from clients. I think this was another
Lin Oshitani | Nethermind:like, option that was raised by core devs, but to enforce trust payments, but I think that's a…
Lin Oshitani | Nethermind:Bad idea, because it will introduce, like, security risks.
Lin Oshitani | Nethermind:Here.
Lin Oshitani | Nethermind:So, if justice payment is clearly and uncurially accepted, maybe it's fine to just bundle it with payload separation.
Lin Oshitani | Nethermind:However, based on talking to ecosystem players, it is a fact that trustless payments is controversial.
Lin Oshitani | Nethermind:And so I believe these should be separated, and separately discussed with the ecosystem, unless we have a strong convincing argument to bundle them together, and…
Lin Oshitani | Nethermind:I think that's also a possibility, but it's just that the people are not convinced.
Lin Oshitani | Nethermind:And… I think if there's, like, even a single-digit percent risk of ending up like EOF,
Lin Oshitani | Nethermind:I think… I don't see a reason why we shouldn't separate. This is… Yeah, my personal opinion.
Lin Oshitani | Nethermind:Yeah, so this is my recap of the proposal.
Lin Oshitani | Nethermind:And… Yeah, that's it.
stokes:Cool, thank you.
stokes:Yeah, I think this is definitely a question we need to settle sooner rather than later, and like you point out, I do think there, yeah, are some arguments here to consider.
stokes:Ansaber?
Ansgar Dietrichs:Yeah, I mean, just in terms of progress by process, I would expect we wouldn't decide something like this just today, just because that's so short notice, and I would expect that many people are probably quite strongly opposed to separating the headliner AP out into two. I personally just wanted to briefly speak out in favor for such a split.
Ansgar Dietrichs:I've been… I've had some troubles in the past with specifically the aspect that EPBS, just for historic reason, nothing wrong with this, no fault of the champions or anything, but, like, it just morphed. It started out as something focused more on specifically, like, trustless payments and these things, and then it, over time, morphed more into being focused on scalability, because that's kind of where the trend overall went to, that we wanted to focus lump sum on scalability, but
Ansgar Dietrichs:I had to look back, and almost all the clients that had a post on their position on EPBS,
Ansgar Dietrichs:just before we made the headliner decision, specifically pointed out that they are supporting EPBS for scalability reasons, and so I do think that now puts it in this awkward position where there's this aspect of it, which might still be a good idea. I personally am somewhat skeptical, but the point is, it's kind of not…
Ansgar Dietrichs:that was not part of the core of, like, why this ERP was chosen as the headliner.
Ansgar Dietrichs:So I would really appreciate if we were to split out trustless payments and make the decision separately. It could still be…
Ansgar Dietrichs:included in Glamsterdam, but as a normal EIP, that then has to basically, like, have one more round of discussion around it, and then, yeah, I would have my arguments for why I might caution against it.
Ansgar Dietrichs:But yeah, I expect that there's a lot of people that are on the other side of this, so I feel like we should probably not make a decision, like, today.
Ansgar Dietrichs:But in two weeks, maybe.
stokes:Yeah, I mean, I think people will need time to dig into this, so I don't think we're gonna decide today.
stokes:But I did want to, have the discussion. Yeah, there are a lot of moving pieces here. There's…
stokes:you know, on, I guess, on one side, core devs here, you know, understanding some of these trade-offs, and just getting, you know, wrapping their heads around the spec and how it all works, and understanding that in context.
stokes:Then, you know, another part of it would just be reaching out to the different community members that have been listed.
stokes:I don't know, Greg here from Lido just had your hand up, so yeah, like, different sticking pools, different builders, and…
stokes:Yeah, getting their take on the feature as it is.
stokes:And that process will probably take some time to play out, just given how we can service input to ACD from the community.
stokes:And, yeah, sure, Greg?
Greg K | Lido:Yeah, hi guys, I'm Greg from, Lido. Yeah, I just want to say that, yeah, I pretty much, agree with the comments of, Lynn and, Anskar. Basically, yeah, on the conceptual level of it. So I think that, you know, as I said, we have this kind of two different PBAs. Basically, the one is the payload blocks operation, and the other, the…
Greg K | Lido:proposal builder separation.
Greg K | Lido:And, yeah, I think it would be a much more lean approach if we just have two separate things, because it's really conceptually separate, the one thing
Greg K | Lido:The main reason of this, like.
Greg K | Lido:It's the scaling part, and everyone agrees, and, like, we have a very good consensus on that, like, it's a scaling feature. The proposal builder separation has, like, other consequences. It goes beyond the scaling, it's about, you know, censorship resistance, it's about centralization, it's other stuff. So I think it also logically makes sense to separate those two things anyways.
Greg K | Lido:So, yeah, I think it's very good that, Lynn brought it in the discussion today. Yeah, I agree also with Anx that we cannot take a decision today, like, it makes sense. But yeah, I think also, like.
Greg K | Lido:research-wise and logic-wise, I think it makes sense to have those two things separately, like, like, to have a more gradual upgrade. That doesn't… it seems a bit complex to have two sorts at one ape.
stokes:Yeah, thanks for the thoughts, Ryan.
Lion dapplion:Yeah, I just went to boys that…
Lion dapplion:Since 2 or 3 months ago, I was…
Lion dapplion:I find it strange that we didn't have the chance as client teams to voice if we wanted to get payload separation and trustless payments, or just…
Lion dapplion:payment, payload separation. So, yeah, I would support to have this split as soon as possible, so different stakeholders can clearly voice their opinion.
stokes:Makes sense. Yeah, Produce?
potuz:Yeah, so…
potuz:I think this presentation and this point of view lacks understanding of how the implementation on the spec is.
potuz:Trustless payments.
potuz:is two different things. In fact, for that separation, just to have trusted payments, EPBS as is now is easier and safer and easier to implement than going trustless a la MapBoost.
potuz:The reason being is that
potuz:we want to have separation of broadcast, we need to have the payload being signed. I'm sorry that I'm going to be technical for a little bit.
potuz:But, to have that separation, if we keep
potuz:without all of the machinery that EPBS brings, and we keep the map boost.
potuz:sort of diab… the boost mechanism that we have today, then that incurs in a bunch of trade-offs of, like, going back and forth to share the payload and blind signing, and all of this machinery that we have today, just to prevent the builder from being unbundled.
potuz:If we have EPBS today, just as today, no changes.
potuz:Lido doesn't need to change their contract, Lido just needs to tell their node operators, hey, listen, only whitelist these builders. These builders are going to be paying you on the EL and are going to be bidding for one way on the protocol side.
potuz:EPBS does not prevent off-protocol payments. It does not prevent a node operator from trusting a builder and whitelisting it.
potuz:What EPBS brings, and now, having said so, that it's actually easier to have trusted payments on the EL with the current implementation and the specification of EPBS,
potuz:It's also better for a lot of other reasons, because even if the builder is paying on the EL of protocol, is still signing the payload, and we can actually detect on-chain, we can detect censorship, we can blacklist particular builders even without having been the ones that proposed the block, we can do a lot of things that we could not do without having a signature on the payload.
potuz:So those are just… those are already reasons to have the on-protocol mechanisms, and at the same time, it's very simple to go off-protocol for the payment itself, if the node operator just has. EPBS does not try to force an on-protocol payment. EPBS just gives you the option to have a trustless payment.
stokes:Okay.
potuz:And just in response to Francesco, it's exactly what I'm saying. So, the people that want to remove trustless payments, what they are saying is, remove everything, like, all of this withdrawal mechanism, the state builders on-chain, and all of these things. It's not what we're discussing now on Discord.
potuz:They really want to remove the whole… so they are calling trustless payment two different things. One is the stake builders, and the other one is the payment itself. And the claim is that the payment itself can be trusted on EPBS, just as, without any change. And Lido doesn't need to change their contracts at all.
Lin Oshitani | Nethermind:So you… Just to confirm, like, you're saying that you're… Fine with, like.
Lin Oshitani | Nethermind:In Prism, for example, like, you just keep the Memboost support.
potuz:No, we don't keep the MedBoot support at all. We don't have any MedBoot pipeline, but you can whitelist the builders that you're gonna take bids from, and those builders are going to bid, say, one way only on the actual on-protocol side, but they are promising me that they're gonna be paying me off-protocol.
potuz:And this way, Prism doesn't need to do any changes on the implementation, and you just only whitelist the builders that you're going to be dealing with.
Lin Oshitani | Nethermind:You see?
Lin Oshitani | Nethermind:But yeah, I mean, if you're… I think your point here is, like, that trustless payment is critical.
Lin Oshitani | Nethermind:For the scalability part.
Lin Oshitani | Nethermind:I think that's the part that a lot of us are not quite getting.
potuz:I am not claiming that at all. I haven't even mentioned scalability.
Lin Oshitani | Nethermind:But…
Lin Oshitani | Nethermind:the commit and review… okay, so the commit and reveal, like, difference, right? And you're saying that if we…
Lin Oshitani | Nethermind:that difference.
Lin Oshitani | Nethermind:Is tied to trust this payment, or…
Lin Oshitani | Nethermind:like… Or, or do you…
potuz:incometer reveal with assigned payload by the builder is easier than doing it
potuz:when the payload is signed by the proposer, because then we need to go the blind route, signing things that we haven't seen, and exchange the payload and fill it as we do now with MedBoost. Doing it as it is on EPBS is much easier.
potuz:Because the signature comes from the builder, and the builder can reveal whenever they want.
Lin Oshitani | Nethermind:Yo.
Lin Oshitani | Nethermind:I think…
Lin Oshitani | Nethermind:Yeah, I think there's still the question of, like, well, probably we maybe don't have time to go…
Lin Oshitani | Nethermind:too much, but I think there's still the question of, like, bypassibility, even if we… if it's, like, in-protocol cleaner, if they…
Lin Oshitani | Nethermind:you know.
Lin Oshitani | Nethermind:go through the trustless payment? Like, will they? I think that's still an open question, and if it's an open question, is it worth it?
Lin Oshitani | Nethermind:But, yeah, I do see your point, that…
Lin Oshitani | Nethermind:With the comment real time being, like, 4 seconds or 6 seconds away, like, trusted payment, Might have some.
Lin Oshitani | Nethermind:Advantage.
Lin Oshitani | Nethermind:Either way, I think, like, we need convincing.
Lin Oshitani | Nethermind:About these facts.
stokes:Okay, so, yeah, before we get too deep into the weeds here,
stokes:It does sound like we should look at all these different, you know, the different design decisions here.
stokes:have some written document, ideally, of the trade-offs, and I think that would help drive the conversation forward.
stokes:That's not gonna happen live right now.
stokes:So I would suggest that's something that we work on, is sync, and yeah, again, we'll see, timing-wise what that looks like. I don't know if anyone can guarantee that, you know, by the next call, we'll have this all together, but I do think we should keep this moving.
stokes:Yeah, Terrence has a good point here. There is an EPVS breakout.
stokes:It was next Friday, yeah, so…
stokes:That would be another good check-in. If anyone wants to get deeper into this conversation, that's probably the place to do it.
stokes:And in the meantime, yeah, I think we should…
stokes:I guess to Ansbar's point here, just around the process, like.
stokes:What we don't want to happen is, yeah, something…
stokes:like EOF with this EIP, so I think we should be flexible around the actual ultimate shape it takes in Amsterdam.
stokes:And that's a conversation that can play out in ACDC, over the coming weeks.
stokes:So… I think from there, I think things are pretty clear on next steps.
stokes:And… Unless there's a pressing comment on that point.
stokes:We can move on in the agenda today.
stokes:And in that case… so, I think the last thing here for Glamsterdam was, again, just this reminder, so…
stokes:We had the headliner selection process. We'll have a selection process for non-headliners, for EIPs.
stokes:And we had kind of said, okay, it'll be around Fusaka Mainnet. I wanted to propose a refinement here, just so it's, like, super clear exactly what we mean.
stokes:I think the call where we set the Fusaka mainnet date, you know, it would essentially be the next ACD call would be the deadline for non-Headliner EIPs.
stokes:So, again, that shouldn't be a surprise to anyone.
stokes:But, yeah, just a reminder there.
stokes:Okay.
stokes:Yeah, Osbury?
Ansgar Dietrichs:Wait, yeah, just can you… can you clarify this one more time? You're saying the call itself… so basically you're saying in two weeks, we would set the dates, and that would then already… the call where we set the dates is already the cutoff time, because it feels like I would have maybe expected, let's say.
Ansgar Dietrichs:on the call where we set the dates for the releases, we then also say, and that means that now we can set the exact cutoff time for ERP proposals, there's, like, one last week, or something. I feel like it's better to, on the day we make the decision, we make the decision not closing, but, like, saying, okay, on this day, basically, like, you only have, like, one last week. I feel like that's usually nicer than basically
Ansgar Dietrichs:Yeah.
stokes:That's what I meant. Maybe I didn't frame it well.
Ansgar Dietrichs:No, I probably.
stokes:And so.
Ansgar Dietrichs:Didn't understand correctly.
stokes:Yeah, so… yeah, like…
stokes:For example, say we decided mainnet today, then by next ACD, that would be the deadline for non-headliners.
stokes:Right, so you have that extra week.
stokes:Does that… okay, that makes sense.
stokes:Yeah, there will be time. The point will not be, oh, hey, by the way, surprise, this is, the deadline.
stokes:And it's passed. There'll be time, before that happens.
stokes:So… There's that.
stokes:Okay, otherwise, there were a few kind of miscellaneous things around, other concerns, either with the process of ACD itself.
stokes:Or some, yeah, various EIPs or names. Anything else on Glamsterdam before we move to that?
stokes:Okay, so then the first one… this is a follow-up from last week. There was this…
stokes:proposal here, from Lullivan, I think is how you say your handle here.
stokes:And it introduces this concept of a champion, that would essentially be point of contact for, getting an EIP into a specific fork.
stokes:There is a number of comments here going back and forth.
stokes:On some of the details.
stokes:And ultimately, I think the language has changed a little bit.
stokes:We had kind of wanted to get this merged in before today, so…
stokes:We haven't, and I wanted to try to get final comments today.
stokes:Yeah, well, then I see you're here, I don't know if you have anything to add.
wolovim:Yeah, hey, this should be very brief.
wolovim:The…
wolovim:The suggestion last week was to more formally define the champion title as the primary point of contact, and that a PFI'd EIP needs to have that primary point of contact.
wolovim:Or a soft requirement for one. There was some hesitation on the usage of the word champion, because it, potentially gets overloaded as the word champion is used in EIP1, sort of ambiguously, so I've just simplified the proposal
wolovim:Two… down from three sentences to one, basically, in order to get…
wolovim:PFI'd into, starting with Glamsterdam.
wolovim:you should specify the primary point of contact. That's the end of the story. So this is just a… meant to be a logistics,
wolovim:Improvement, like a… hopefully a… Communication friction reduction.
wolovim:So I hope that's, straightforward and agreeable.
stokes:Makes sense to me any final comments here?
stokes:With anyone at present.
stokes:Otherwise, I'll take a look at the PR.
stokes:But yeah, I think we're probably in a good place to merge.
stokes:So yeah, I guess then today…
stokes:If you have any final comments, take them to the PR, otherwise it'll be merged very likely within the next 24 hours, and we'll move that along.
stokes:Okay, next up, there was a comment here from Kev.
stokes:So, okay, I think this is actually just a very narrow process thing, but essentially.
stokes:With EIP7870, this was around the minimum hardware requirements, EIP…
stokes:So just to move it from…
stokes:Let's see, from interview to live. Okay, so it's just moving it through the EIP lifecycle process.
stokes:And I believe we just need to, like, agree on AACD that we're doing this, so it can be referenced. That's apparently what the editors requested.
stokes:So yeah.
stokes:Any… anyone have any issue with that? Otherwise, we'll just go ahead and move it forward.
stokes:Okay, that was easy.
stokes:It's just changing the lifecycle status, so it's not really a material change.
stokes:Next up, H-star. So, ABC caught up?
stokes:is calling out that H-star needs a name, which I agree.
stokes:And he proposes to have the name set by Passaka going live on Mainnet.
stokes:I don't think we'll have any issues there.
stokes:I will share this link.
stokes:So this link here, there's a sort of informal poll on different names.
stokes:And, yeah, I would… Personally think just use this for signaling and go ahead with the most popular option.
stokes:Which right now is called Etios.
stokes:So, yeah, if you have strong opinions on the name, I suppose take it to the ETHM Magician's thread.
stokes:And then from there, yeah, we'll get this sorted and a few ACD calls.
stokes:Just so there's a name and we can move forward with that.
stokes:Okay.
stokes:That was everything on the agenda today.
stokes:Anything else people would like to discuss? Otherwise, we will wrap up a bit early today.
stokes:Okay, that's great.
stokes:Then, yeah, in terms of immediate next steps, we have the Holeshky BP01 coming up in just a few days, so watch out for that.
stokes:And otherwise, we'll move forward on Glamsterdam, and yeah, I will see you all next time then. Thank you.
lightclient:Thanks.
Marius van der Wijden:Thanks, bud.
Fredrik:Thanks, bye.
Ansgar Dietrichs:Thanksgiving, bye.
Justin Traglia:Hi, everyone.
Pooja Ranjan:Thank you.
Chat Logs
00:03:16
Katya:fork
00:03:29
stokes:https://github.com/ethereum/pm/issues/1740
00:04:27
Barnabas:No
00:04:36
Fredrik:ga
00:05:16
potuz:we had a bunch of hickups
00:08:05
Parithosh Jayanthi:If clients want us to look at anything else, please ping us so we add it to our list!
00:11:24
Barnabas:https://grafana.observability.ethpandaops.io/d/MRfYwus7k/nodes?orgId=1&from=now-2d&to=now&timezone=browser&var-consensus_client=$__all&var-execution_client=$__all&var-network=holesky&var-supernode=$__all&var-filter=ingress_user%7C%21~%7Csynctest.%2A&viewPanel=panel-17
00:11:36
stokes:https://github.com/ethereum/pm/pull/1749
00:16:11
Barnabas:peerdas has been no a random branch for months lol
00:16:25
Justin Traglia:Just need one client for a devnet 😅
00:16:26
Parithosh Jayanthi:Why do we need changes merged for a devnet though?
00:16:33
Parithosh Jayanthi:We can run from a branch
00:16:39
Barnabas:yeah
00:17:05
Barnabas:Replying to "Just need one client..."
with one client we aren’t doing devnets 😄
00:17:11
potuz:yeah that's more or less what we have, we'd like to start merging production code instead of a hacky branch this time
00:17:15
Barnabas:Replying to "Just need one client..."
we gonna do devnets when we have at least 3 client implementation
00:17:52
Justin Traglia:Replying to "Just need one client..."
Maybe 2 is a better requirement.
00:17:56
Parithosh Jayanthi:I want to avoid the alt as well though, what if we spend time merging to develop and then change the design and need to redo the full cycle?
00:18:07
Parithosh Jayanthi:Are we happy with the design then? Are there unknown unknowns?
00:24:36
ethDreamer (Mark):Rational actors will bypass
Rational actors will use direct point to point connections to builders but there is no incentive to bypass the in protocol mechanism - it was carefully designed so there was no incentive to do this
00:25:22
Lorenzo:Replying to "Rational actors wi..."
There is an incentive if off-protocol bids are different than in protocol ones
00:25:24
Toni Wahrstätter:Replying to "Rational actors will..."
One incentive is getting the payment faster and another that you can have it call code (e.g. be automatically distributed)
00:26:34
ethDreamer (Mark):Replying to "Rational actors will..."
@Lorenzo
You need to be clear what you mean by “off-protocol” - hitting a builder directly and accepting a bid that wasn’t gossiped is NOT off-protocol - they still use the protocol to adjudicate the payment
00:27:21
Lorenzo:Replying to "Rational actors wi..."
By off protocol I mean a low unconditional payment, with the majority coming from the EL payment
00:28:23
ethDreamer (Mark):Replying to "Rational actors will..."
Ah so you mean if builders offer different bids for bypassing the protocol and using relays - I don’t see why they would do that fundamentally
00:29:16
Lorenzo:Replying to "Rational actors wi..."
Many reasons, two main ones: 1) it's expensive for the builder to keep capital staked, 2) if the slot is missed the builder misses the full payment for potentially little profit
00:29:52
Ansgar Dietrichs:one specific argument for why I would rather not have unconditional payments in Glamsterdam at all:
I think it adds significant complexity to ePBS and will delay fork readiness (this point is controversial, many EF researchers I talked to disagree).
And given we have limited room in Glamsterdam, I think there are higher urgency items like FOCIL. I think ePBS + unconditional payment + FOCIL is too much CL-side for Glamsterdam. And I think FOCIL is much more important and urgent than unconditional payments
00:30:00
Chris Haug:Replying to "Rational actors will..."
it’s more about having a 0-bid from “whitelisted builders” and the actual “off_protocol_bid” amount offchain through relays
00:30:08
Chris Haug:Replying to "Rational actors will..."
@ethDreamer (Mark)
00:30:19
Sophia Gold:If we split out trustless payments, there are still several variants of pipelining only ePBS (e.g. dual headline and parent header). I suggest we should try to not only decide this but also which flavor of pipelining by end of month in order to not delay development
00:31:32
Ansgar Dietrichs:but I also feel like this topic is being sprung onto the ePBS champions right now, so we should give room for that conversation to happen fully informed. We already accepted ePBS in full as headliner, so default would absolutely be to keep it that way.
00:32:23
Francesco:I don’t quite understand this point. We don’t need to keep using mev-boost and do any blind signing, like discussed on discord
00:33:04
Francesco:Having the builder sign the payload is different from trustless payment though (meaning the withdrawal mechanism, the need to be staked, the fork-choice things)
00:33:46
ethDreamer (Mark):Replying to "Rational actors will..."
@Chris Haug I understand what is meant but I wanted to be clear about terms in the discussion
@Lorenzo what do you mean by 2)?
00:35:11
Francesco:I think there’s 3 things:
Still use mev-boost (not sure what’s the point of that)
Current thing with trustless payments
Current thing but without withdrawal mechanism, counting weight, fork-choice changes etc…
00:35:13
Lorenzo:Replying to "Rational actors wi..."
the unconditional payment is paid by the builder regardless of whether the slot lands, so a missed slot is very risk for the builder, potentially bidding in many blocks become -EV
00:35:26
Ansgar Dietrichs:the on-the-merits conversation on unconditional payments should maybe happen offline? would be best to focus on “should it be part of the headliner or a separate EIP proposed for Glamsterdam”
00:35:54
Toni Wahrstätter:Trustless payments should have been separated out from the beginning and would have been a potentially nice feature by itself. Now that it's in, it's probably better to keep it as-is(?)
We should use it as a fallback and make it as smooth as possible for proposers to continue using relays if they want to. Keep it as fallback but not as default.
00:36:14
Greg K | Lido:I am pretty much in the same page with Ansgar.
PBS1 (Payload - Block separation): Good for scaling, widely accepted
FOCIL: Good for censorship resistance, widely accepted
Trustless payments: Not clear to everyone why needed, esp. benefit vs complexity.
00:36:35
terence:there's an epbs breakout next friday
00:36:49
ethDreamer (Mark):Replying to "Rational actors will..."
the unconditional payment is paid by the builder regardless of whether the slot lands
Again you need to be clear. If the proposer misses the slot, the unconditional payment is absolutely NOT paid. If the BUILDER misses the reveal, it is still paid. Of course because that would be the builder’s fault. But relays already enforce this with optimistic relay designs anyway?
00:36:51
Ansgar Dietrichs:Replying to "there's an epbs brea..."
in 8 days, right?
00:37:07
potuz:Replying to "there's an epbs brea..."
yes
00:37:23
Justin Traglia:Replying to "there's an epbs brea..."
Please comment on the agenda if there’s anything you want to bring up.
https://github.com/ethereum/pm/issues/1744
00:37:44
DA | Flashbots:Replying to "Rational actors will..."
Would like to see missed slot rates on a testnet before forming an opinion. Like unless they’re ~zero it will probably affect bids.
00:37:50
Ansgar Dietrichs:but we should make the headliner split decision in 2 weeks
00:38:03
Ansgar Dietrichs:Replying to "but we should make t..."
so if we split, it can be first EIP we then discuss for Glamsterdam
00:38:27
Sophia Gold:Replying to "but we should make..."
We should commit to that now so stakeholders who don't normally attend this call know to join
00:39:39
Ansgar Dietrichs:ah okay, makes sense
00:39:44
Ansgar Dietrichs:Replying to "ah okay, makes sense"
sorry about the confusion
00:39:45
Justin Florentine (Besu):iirc we close G* for proposals on the date that F* mainnet client code is due
00:39:48
Ansgar Dietrichs:Replying to "ah okay, makes sense"
seems reasonable to me
00:40:02
Maria Silva:What is the optimistic date for mainnet releases atm?
00:40:17
lightclient:early dec?
00:40:30
Ansgar Dietrichs:Replying to "iirc we close G* for..."
I think we don’t need to stick to very specific pre announcements we made on this, but can just pick a reasonable process now that we are close to that point
00:40:35
stokes:https://github.com/ethereum/EIPs/pull/10391
00:40:35
ethDreamer (Mark):Replying to "Rational actors will..."
If the proposer’s block is re-org’d then the payment is re-org’d.. why are we worried about missed slots from the proposer?
00:40:49
Ansgar Dietrichs:Replying to "iirc we close G* for..."
but that does sound like a sensible default
00:41:55
Lorenzo:Replying to "Rational actors wi..."
with relays, builders missed slots are extremely rare as usually demotions happen within the slot and avoid any missed slot
00:43:46
Justin Traglia:In support of marking the eip as “live"
00:44:15
stokes:https://ethereum-magicians.org/t/h-star-name-for-consensus-layer-upgrade-after-glamsterdam/24298
00:44:38
ethDreamer (Mark):I don’t see why builders would suddenly have infrastructure failure rates worse than relay failure rates - especially competitive builders - especially not to the extent that they would need to factor these failure rates into their bids
00:45:28
Ansgar Dietrichs:should enjoy being able to have short acds, before getting into Glamsterdam EIP discussion :-)
Summary
12 highlights
· 3 decisions · 2 action itemsExperimental
Summary
12 highlights · 3 decisions · 2 action itemsExperimentalfork status and schedule
epbs development
- ePBS specs stable; blocked on Fusaka stabilization before merging to develop branches00:16:11
- Prism expects to merge on develop next week post-Fusaka stability00:17:52
- Proposal raised: Split ePBS payload separation from trustless payments into separate EIPs00:21:41
- Ansgar supports split; most client support was for scalability, not trustless payments00:27:26