stokes:Okay, thank you. Everyone.
Transcript
stokes:Welcome to Acdc, number 1, 5, 8. The agenda is here. It's issue 1548. And the Pm Repo.
stokes:so yeah, today we'll cover some Fussaka things and also open the Glamsterdam conversation.
stokes:And yeah, let's go ahead and get into it. So
stokes:1st up with Posaka. We have Posaka devnet 0
stokes:Perry, would you be able to give an overview last time? I looked it looked a little little hectic.
Parithosh Jayanthi:Yeah, I think Barnabas might have the latest on that one.
stokes:Okay, great part of us. Would you mind updating us.
Barnabas:So we basically set up 0 with being activated in epoch 256, and then every single Bpo will be 256 epochs later. So that will give us one day to observe if the Bpo. Is working as expected. If any clients are causing an issue, and we decided to go up, down and
Barnabas:and so far, every everything seems okay. We had a few clients that that are still missing blocks and some clients that have issues appearing up. But we are actively looking into these issues.
Barnabas:But the concept of Bpo seems to be working.
Barnabas:Okay, okay.
stokes:Okay, that's good news.
stokes:Cool anything else on Devnet 0.
Barnabas:We had a bit of misconception regarding removing the block count in flow.
stokes:So.
Barnabas:There's a
Barnabas:a clarification that had to be done, and we had to add an additional block schedule for the full fork, basically on the side.
Barnabas:So this, this was just basically saying that, hey in full, we still gonna be using 6 and 9.
Barnabas:But yeah, as as I mentioned, this only touched the sales.
stokes:Alright makes sense, and that's already live on Demo 0.
Barnabas:Yeah, this this was done before the 1st before even full went live.
stokes:Gotcha.
stokes:Okay? Cool.
stokes:Okay.
stokes:Then, next up we have on our schedule today to get to a final Sfi set for Fusaka
stokes:and I wanted to go ahead and cover this now, because it might inform Devnet one scope.
stokes:So
stokes:yeah, essentially, the only question we have is Eip 7, 9, 1, 7. This was the one that gives us a proposal. Look ahead.
stokes:and it fixes kind of an edge case in the protocol where the proposal. Look ahead is dependent on the shuffling that mixes in the balances, and these can change an epoch boundary
stokes:this is not great if you need to rely on this proposal. Look ahead, use cases like Pre comps. Obviously come to mind for for this type of thing.
stokes:And yeah, right now, it's Cfi.
stokes:And the question then is, if we want to go ahead and sfi this, and if so, we could even think about scheduling onto a devnet.
stokes:Generally
stokes:the framing has been. Get a stable devnet with these Cfi things. Sorry, sfi things before thinking about.
Tomás Arjovsky | Lambda | Ethrex:Yeah.
stokes:Moving
stokes:to just shove more features in but yeah, wanted to open the conversation now, because I think we should finalize what we want to do here today.
stokes:So
stokes:yeah, maybe to kick us off. Then I see Lynn is here. I don't know if any of the Eip authors want to make a case for this.
stokes:I think something that would be super helpful is also hearing from the community here, which in this case would be users of Pre comps. Any Pre comp providers.
stokes:And yeah, trying to get a sense of the demand for this.
Lin Oshitani | Nethermind:Yeah, I can give a quick
Lin Oshitani | Nethermind:perspective from my side. So I think
Lin Oshitani | Nethermind:so. I think, like, if you look at the big picture like
Lin Oshitani | Nethermind:we have the rollic centric roadmap, right?
Lin Oshitani | Nethermind:And I think that was good like it. It makes sense to as a construction like you, post data to l. 1, but execute an L. 2.
Lin Oshitani | Nethermind:I think right now there's a lot of people who feel something wrong about the current roll ups
Lin Oshitani | Nethermind:like there.
Lin Oshitani | Nethermind:It doesn't feel like they're just scaling the old one, or they're just like an execution extension of the old one.
Lin Oshitani | Nethermind:I think this is one of the reasons why we have like so much pushback right now, for.
Lin Oshitani | Nethermind:like L twos.
Lin Oshitani | Nethermind:and like going back to like our own scaling. And I think a core part of this is that
Lin Oshitani | Nethermind:of why it feels wrong is that I think one thing is a centralized sequencer, basically like just having a single server somewhere that's like sequencing your transactions.
Lin Oshitani | Nethermind:It doesn't feel like a natural extension of the old one. And
Lin Oshitani | Nethermind:yeah, like, it seems to like
Lin Oshitani | Nethermind:hurts the credible neutrality of the whole thing.
Lin Oshitani | Nethermind:And so like, basically, this will locks enable.
Lin Oshitani | Nethermind:And I think peace roll-ups are like the way to solve this.
Lin Oshitani | Nethermind:it enemies will up centric roadmap, but like without the centralized sequencer, it's the only construction that's working right now in Mainnet, where you can actually remove the centralized sequencer.
Lin Oshitani | Nethermind:But, like the issue there is that we have very high latency, like we have to wait at least 12 seconds, or
Lin Oshitani | Nethermind:because visuals, they can't post every slot. So sometimes like
Lin Oshitani | Nethermind:close to a minute, if the demand is not high.
Lin Oshitani | Nethermind:So this is why we need pre confirmations, and to actually lower this time to actually have, like a competitive based roll up.
Lin Oshitani | Nethermind:And so I think in the end, what I
Lin Oshitani | Nethermind:thing is that, like ethereum scaling is very important.
Lin Oshitani | Nethermind:Velope is important for Athem scaling
Lin Oshitani | Nethermind:and paste roll-ups, I think, is important, for roll-ups
Lin Oshitani | Nethermind:and base pre confirmation is important, for base roll ups. So in the end, I think
Lin Oshitani | Nethermind:base and like for base pre confirmation, the cip will be like a very good
Lin Oshitani | Nethermind:Oh, it! It's very much needed, like at least to do it in a non hacky way.
stokes:Yeah, do you have a sense of how hacky it would be? I think that's a question. At least I have is like.
stokes:you know? I think so. Yeah, the cip aims to like patch kind of a edge case in the protocol
stokes:and then to go ahead and trigger it. It's like, yeah, it's not straightforward. So I wonder if there's a sense of
stokes:yeah, I guess how how important is it to fix this? Now.
Lin Oshitani | Nethermind:Yeah, I think Jason has been looking a lot right now. He's in the call from fabric.
Lin Oshitani | Nethermind:Yeah.
Jason Vranek:Yeah, sure, thanks, guys. So yeah, fabric.
Jason Vranek:we're working on 2 goals is one to like help existing. Roll ups become based. And 2 is help. New apps, launches based roll ups. So one of those initiatives was working on these inbox contracts for rollups. And
Jason Vranek:yeah, without this eip, it's it's pretty hacky, so like there's nice. I don't want to discount the importance of having look ahead. Stability. But for us, what really matters is allowing the look ahead to be accessible from the Beacon State.
Jason Vranek:Without this, like, the problem we're trying to solve is that we need roll ups to be aware and respect the schedule of pre confers, and to do this they need a view of the look ahead. So without this, there's kind of 3 proposals. One that Tyco is working on right now is optimistic. Look aheads. You have to
Jason Vranek:optimistically post your view of it and add these incentives, or trust like fault proofs after the fact like you can always use eip 4, 7, 8, 8 after the fact.
Jason Vranek:Another proposal is
Jason Vranek:to sacrifice real time settlement, and l. 1. Composability, and retroactively determine the canonical L. 2. Head by figuring out who the proposer was. This is simpler, but a lot of the value prop of based roll-ups is real time settlement, and l, 1. Composability, unlocking things.
Jason Vranek:and like a 3rd really hacky approach that might be the simplest on chain is just.
Jason Vranek:You have to import all of the logic to derive the look ahead into your roll up state transition function, which starts to feel kind of like the beam chain effort. So adding the look ahead to the Beacon State just trivializes all these problems and makes it safer and cheaper
Jason Vranek:to to run these ropes.
stokes:Yeah, that makes sense. Mark, you have your hand up.
ethDreamer (Mark):Yeah, I mean, I was just gonna say.
ethDreamer (Mark):I think a simple way of looking at the problem is is like.
ethDreamer (Mark):you know, these Pre. Comp. Protocols need to have the proposer on chain ideally ahead of time, and we know that there is an edge case where
ethDreamer (Mark):the proposer can change sort of last minute.
ethDreamer (Mark):And so I mean in terms of getting information on chain. You have a few options you can
ethDreamer (Mark):do.
ethDreamer (Mark):I mean ideally. You have proof that's with the cip, you can actually prove it.
ethDreamer (Mark):if you don't have that, you have crypto economic systems. But in this case, since there's an edge case where
ethDreamer (Mark):you know, people can stake on a certain proposer. But then it can change last minute.
ethDreamer (Mark):I mean, I think you you end up with a really complex crypto economic system, because people said the proposal was going to be one thing, and then it ended up being another. Even if that's a rare case. The fact that it's an edge case that could happen makes it like really hard to do that. And then you're you're left with, I guess like you said either implementing
ethDreamer (Mark):like large chunks of the the bacon chain protocol on chain, or just having trust. So
ethDreamer (Mark):it I mean, it just doesn't seem like there's a lot of good options
ethDreamer (Mark):here, if we don't just make it provable.
stokes:Yeah, thanks.
stokes:Okay, so yeah, a number of voices from people working in the space that would use this feature does seem like, there's some demand for it.
stokes:I'd like to get a sense from core devs like how much of a lift this is to go into Fusaka. So I think that's kind of the
stokes:big constraint here is, we have pure dos and Fussaka. I think we'd all like to ship that as soon as possible.
stokes:The question then, is like, is this the right time to include this Vip?
stokes:if we yeah risk Fusaka timelines at all, I think that's not great. At least, yeah, we should very intentionally make this make this trade off.
stokes:So yeah, I'm curious. If any client teams have had a chance to look at this, or even have a sense of implementation, lift.
ethDreamer (Mark):It's I mean, people may already know, but it's trivial in lighthouse.
ethDreamer (Mark):I think the so far, what it comes down to is
ethDreamer (Mark):basically, did your do? You already have a variant of the Fusaka Beacon State?
ethDreamer (Mark):Because I know some clients may not, since, as of yet the Fusaka Beacon State has not changed
ethDreamer (Mark):from Electra, so it's identical. And so some clients have just reused the Electra Beacon State.
ethDreamer (Mark):So if you already have a Fussaka Beacon State. It should be really fast. It really was quite easy in Lighthouse. If you don't, the question becomes, how much work is it for you to add a Fusaka beacon state.
ethDreamer (Mark):Just for for the devs that haven't looked into this that appears to be the main
ethDreamer (Mark):The main question.
stokes:Yeah, yeah. Onsgar has a helpful comment here lighthouse and lodestar said above in the chat, that it's a pretty small lift.
stokes:similar for Teku
stokes:and see as a point around testing. And yeah, I guess this is kind of the core thing, at least for me, is
stokes:without this. We don't touch the Beacon state in Fusaka, so we just don't have to think about it. If we do include this, then the Beacon state does change. And so it just increases sort of the scope here.
stokes:That being said, you know, our bread and butter is testing state transition changes. So
stokes:it's not anything. Super novel? Yeah.
stokes:Okay, Otis, do you want to speak to this a bit more? Your comments here.
potuz:Oh, I was just saying that, for prism is the same. It's just not as trivial as lighthouse that it's just one line change. But
potuz:I've been told that we have this very well documented, and it shouldn't be a change that would take weeks.
potuz:I think this discussion, however, is kind of irrelevant on the technical side. There's no argument on the technical merit of this cip, nor on the need of the eip, nor the difficulty of the eip. The only question here is, there are many easy changes
potuz:that are not scheduled for Fussaka.
potuz:The question here is, is this going to delay Fusaka testing. Is it going to delay the fork or not? If everyone agrees that there's no delay possible because of this.
potuz:then I think there's no complaint.
potuz:If there's a risk that this is going to delay Fusaka having, we all have agreed that we wouldn't delay Fussaka under no circumstances, and this was part of our choosing on the scoping.
potuz:Then I think it's that's the question that we need to ask.
stokes:Yeah, I agree.
stokes:Sorry if you've had your hand up for a minute.
saulius:Yeah. So in transfer it, or to to comment on portals ideas, I think I mean, any change
saulius:actually should affect the delay, or whatever. I mean, it's it's a it's in any case extra work, and in any case extra effort. So I think, whatever we add, even if it's small thing, this almost 100% delays things because it's it's extra stuff. So this is one comment, another comment. I was just thinking
saulius:theoretically, if we have a more predictable look ahead than we have now. There is a kind of theoretical, at least the way I think there is a theoretical
saulius:decrease in security in some sense. So I mean, likely it's a very minor or neglect, but but likely there is. So that's that's another point.
stokes:Yeah, thanks.
stokes:There's some good discussion in the chat here. So yeah, I think I'll start here. This is a question by pari, are there any unknown? Are there any unknown unknowns that could come up?
stokes:And yeah, given that, it seems like implementation is straightforward. This is mainly a question of testing.
stokes:There has been some testing already. I don't have the Pr handy, but there is one to the Fusaka specs from Lynn and Co.
stokes:With testing there.
stokes:So you know, it's not that. It's like, Oh, we need to go write the test. And maybe there's issues.
stokes:We have tests testing can be expanded. And again, this is pretty straightforward. All the client teams here know how to pull down the spec test and and run them. So
stokes:yeah, are there any other things anyone sees that we should consider?
stokes:Yeah, Mark.
ethDreamer (Mark):Yeah, just an angle that I don't think has been mentioned is sort of like what
ethDreamer (Mark):our main priorities are as a protocol.
ethDreamer (Mark):And
ethDreamer (Mark):I think there's pretty widespread agreement that like scaling blobs is one of our main priorities. And that's basically why we don't want to delay Osaka at all.
ethDreamer (Mark):yeah. But I would argue that, like Pre comps.
ethDreamer (Mark):and based rollups are also one of our main priorities for for layer 2 experience.
ethDreamer (Mark):and that that's sort of why this eip is being considered, even if there are other eips that are also trivial. I I do think it's closer to
ethDreamer (Mark):our our main priority is a protocol, I guess would be.
stokes:Yeah.
ethDreamer (Mark):Let's see.
stokes:Yeah, I mean one comment on the other eips thing like we've gone through the process. And this is the only other eip currently, like there are an infinite number of other eips we could be talking about. But this is the one on our plate today. So
stokes:let's let's just focus on this one, but that, all being said, no one has really
stokes:voiced any opposition, and people generally seem like it wouldn't be a huge lift.
stokes:So yeah, I think we go ahead and sfi it, unless anyone would like to dig into that more.
stokes:there is the option of boiling it if we absolutely had to
stokes:say for Amsterdam or some other fork
stokes:that also has a cost. But
stokes:yeah, that seems to be where consensus is at right now.
stokes:Yeah. I was reading Perry's comments here.
stokes:I feel like we were taking this the other way.
stokes:I don't know, Perry, do you want to argue for this your your proposal versus the other way.
Parithosh Jayanthi:Yeah, I think my proposal is just that. First, st we need to have stuff on the test net so that we are
Parithosh Jayanthi:make sure that there aren't any problems. But also just reading Tim's message that Sfi just basically means next devnet. So I guess there's a counter argument for what order we do stuff in.
potuz:What's the timeline parry for? To have this in for the next Devnet.
Parithosh Jayanthi:The next one's on June 9, th and Devnet 2. We don't have a date yet, but we would like to have it in June.
potuz:I think we can have this by June 9.th
Barnabas:Ideally. 2 weeks after June 9. We could have dinner, too. And that would be basically what would go to Sepulia and Minnet.
stokes:Okay, so does everyone feel comfortable with targeting devnet one for this? Or should we target Devnet 2,
stokes:yeah. Photos.
potuz:Not sure about other teams, but for us, I suspect that June 9 or 2 weeks after is probably the same, because many of us are going to be in Berlin.
stokes:Anyone else.
stokes:Any client teams want to speak to the timing.
ethDreamer (Mark):This.
ethDreamer (Mark):I'm just, I guess, relevant question.
ethDreamer (Mark):Do any of the other existing clients besides prison not already have a a
ethDreamer (Mark):a variant of the Beacon State
ethDreamer (Mark):for Fusaka, even though it hasn't changed yet, because I feel like
ethDreamer (Mark):those are the clients that would take longer
ethDreamer (Mark):and and like, I guess my intuition is, if it if prison is comfortable by June 9, th
ethDreamer (Mark):and they have to do the extra work that
ethDreamer (Mark):other clients would probably be able to do the same thing. But I guess that depends on the load of the client. But
ethDreamer (Mark):yeah.
stokes:Yeah, I think I would say, just to keep velocity high, just of the general process. We would go ahead and aim for devnet one. So we'd Sfi today.
stokes:this would be your chance to raise any concerns with that timeline.
stokes:Yeah, okay, like Barnabas is saying the chat. No one seems to have any issues. So let's do it.
stokes:We'll go ahead and sify this. Today
stokes:we'll target Devnet one. And yeah, we'll keep moving things forward.
stokes:Cool.
stokes:Let me pull up the agenda. Then for the next item.
stokes:Okay, yeah. I had a good. I had this next just to talk about pure dos
stokes:again, because I figured it might inform the dem not one timing.
stokes:There were some more details came up like more issues and or details of Bpo, and also without our custody around the period feature set
stokes:as people got into implementation.
stokes:I wanted to take some time today to resolve those.
stokes:So with Bpo.
stokes:There was, I think a question around this Pr that would like back port this Vpo idea, I believe that's been closed. So I think we're good there.
stokes:There was also a thread of conversation on discord around. How we want to handle Bpo and the context of networking. So
stokes:there is a proposal to
stokes:essentially mix in the Bpo schedule into the fork digest, so that this is legible in the networking layer, and this is good because you don't want to have to like necessarily appear with some other node who might be on a different Bpo than you. So it just keeps the networking layer much cleaner.
stokes:There is an also question at that point. If we should touch the fork version
stokes:at that point it kind of becomes a hard fork. And this is, I think, really the question here is like, how much of a fork is the Vpo change?
stokes:So
stokes:let's see, I know, Raul, you were here, and you were looking into this. I don't know if anyone else would like to speak to this issue.
Raúl Kripalani:Yeah, sure. So I can give some some extra context here. With regards to the port version.
Raúl Kripalani:the key question here is our vpo forks. Given that the change consensus rules are they treated? Should they be treated as protocol forks? That would mean changing the the fork version. The reason why we came. Why I particularly came to the solution was, at the Emr level. Here is our
Raúl Kripalani:indicating what the next fork version is, and this enables fork signaling, and it enables that appearing so. But they're not indicating what the next fork digest would be so kind of like. The natural solution would be to change the fork version. But then, as we kind of like unravel this, there were more and more deeper changes required specifically to make everything work and line up nicely. We would need to patch the recon state as well.
Raúl Kripalani:Which, like, there is, I think, a kind of like a version of the world where that is desirable, because otherwise would end up, I think creating a secondary path for deploying consensus, breaking views with the network without actually representing, representing them as protocol forks, and I don't know what downstream consequences this could have like potentially in libraries and other tools, and so on.
Raúl Kripalani:So that's kind of like the the top, the top node in the decision tree. But then, like downstream from that, there were a bunch of other proposals for the signaling. There was a proposal to signal the next fork, the next Bpa. Fork and the status Rpc.
Raúl Kripalani:Request response. In the response. But the issue with that is that you would need to establish a connection with a peer, to then learn whether they're gonna follow the work or not. So this is costly, so still, like the if we decide to not
Raúl Kripalani:represent them as fork versions and just keep them at the at the 4th digest level. Then what I would recommend is adding here to the enr to indicate what the next Vp of work that's gonna be followed is,
Raúl Kripalani:yeah, that's that's kind of like the the 2 different potential plots that we can go. We can go into either changing the 4th version or
Raúl Kripalani:the fork digest, mixing it with the Bpo's, the next Bpo. Schedule entry.
Raúl Kripalani:together with an enhancement of new E and R.
stokes:Cool. Thanks.
stokes:Yeah. My sense here. And I'm very curious. Your client teams take on this. But my sense here is that
stokes:if we make these deeper changes into like fork version. Then, yeah, it's essentially very close to our fork. And yeah, this could be fine, but it seems a little bit too invasive
stokes:fork digest, I think, makes sense for the pairing arguments. And then, yeah, I wonder if there's like some middle ground? I guess you're saying
stokes:you would. If we went with that approach we would do that, but then also add something to the Nr.
stokes:Which is not a big thing, but it is still a thing.
Raúl Kripalani:Yeah, it would be pretty complex.
stokes:Sorry. What was that? You're a little quiet.
Raúl Kripalani:Would be pretty compact, but at a byte level it would just be a few bytes, so.
stokes:Right? Yeah, I'm I'm thinking, more. Just end implementation and testing that and everything.
stokes:But yeah, any other client teams have any thoughts on how to handle this.
sean:So in in lighthouse like, yeah. Fork version, change is like a bigger deal causes more changes, fork, digest change is more manageable, doable.
stokes:Yeah, okay, Terrence says, same with prism. And that's my sense as well as
stokes:that's probably the right way to handle this is, make the change to the fork digest. So again, it's clear from the networking layer. What's going on with all your peers. And yeah, then having the enr, and maybe we'll maybe you could just reiterate like
stokes:that just helps you manage this at the discovery layer.
Raúl Kripalani:Yeah, exactly. The enr is necessary to know
Raúl Kripalani:to for 2 reasons for signaling and to discover the right peers that you're that are going to be following the next pork as you. The same next pork as you, so you can. You can continue connected to that one to 4 accommodities.
stokes:Right without having to connect and do the whole handshake and everything.
Raúl Kripalani:Exactly.
stokes:No.
stokes:Okay.
Raúl Kripalani:Cool. So what I'll do is, it seems like consensus is moving in this direction. So I'll do a second version in the second iteration of this Pr and hopefully later today for folks to review hopefully that will resolve the contention here.
stokes:Okay, great. And this was a Pr to the eip or the consensus specs. Or where did this look.
Raúl Kripalani:To the, to, the, to the eip, and from there we can take a to the consensus standard.
stokes:Alright, everyone on board with this.
stokes:because I think this was the last piece of vpos again. It sounds like we have them already, and like the core functionality, seems like it's working, which is really cool.
stokes:At least we'll know soon enough, and then we'll round this out.
stokes:Were there any other open questions with, Vpos.
stokes:okay, cool.
stokes:Yeah. Thanks for making this updates roll. And great.
stokes:The other thing that I think we should touch on today
stokes:under Pyrados is this notion of validator custody?
stokes:So we had the feature, and just like a quick summary, the idea is
stokes:you have additional custody requirements dependent on how much stake you have. So say there's so many validators on a node with this much stake, as there's more stake than you would custody more columns under periodos.
stokes:This helps with network stability and a bunch of nice things.
stokes:The complication, I think, as it is right now, is the way the spec is written currently is, it's a very dynamic process where you should basically follow every change to, you know,
stokes:any validators attached. And this is like a dynamic online process.
stokes:I think there have been some implementation issues here. And in that case we should decide if we want to do something simpler.
stokes:just to facilitate shipping.
stokes:With this in particular, you only change the custody set you need to reason about, I believe, every 32. Eth. Right? So like per validator.
stokes:And okay, thanks. Sanskar. Okay, we'll circle back to that.
stokes:But yeah, so the point being is, it would be fairly infrequent changes. And so then there's, I think, a pretty good argument to make that. If this is a more static process, it works well enough.
stokes:Yeah, I guess I'd be curious if anyone has run into implementation issues with the current spec, and if they'd like to. Yeah, essentially
stokes:propose, we go with the simpler option.
stokes:any others comment. It's possible the people who are closest to this are not on the call today.
stokes:so we can handle it. Async. But this is definitely something we should sort out in the next like week or 2,
stokes:cause it's been this like a long running thread.
Barnabas:Yeah, I think, yeah, I think we've been basically going back and forth on this or month.
stokes:Yeah.
stokes:yeah, it's not a bad suggestion. Osgar. Just take it to the testing call Monday. Cause. Yeah, it looks like we don't have the people here today. Okay.
stokes:I will try to follow up on this Async, just so we can get everything organized. And then, yeah, let's sort this out. Monday.
stokes:Okay, cool.
stokes:Sorry. I was just checking the agenda. So yeah.
stokes:okay, so with that all in place I did want to check in on Devnet one.
stokes:I can go grab a link to the specs. But yeah, essentially, just wanted to touch base. If there was anything we needed to resolve. Otherwise
stokes:it sounds like we've added 7, 9, 1, 7 to them, that one. So we can make that update.
stokes:Let's see, we can iron out these things with Bpo.
stokes:and we'll decide Valerie custody. But it's also framed as an optional thing. So I think if that doesn't make it until done that, too. That's acceptable, at least.
stokes:Are there any other things for Devnet? One specs people would like to discuss right now
stokes:we feel good about them.
stokes:Okay.
stokes:was there, do you want to just ask.
Ansgar Dietrichs:I mean, I'm just really just curious. Basically for just some sentiment check in terms of are we feeling kind of the focus getting nicely towards a conclusion here, or like, do we do? We? Are we secretly worried? And we might kind of need some extra time like, what's what's the kind of current state of things.
stokes:Yeah, maybe a different way to frame this is once we are now things with Devnet 0. Do we feel like Devnet? One will be at least, do we expect them that one to be pretty streamlined on top of that?
stokes:And then from there would that put us in a place where we feel period office is stable.
stokes:The next big thing after that, once we have something we feel like. A stable implementation of peer to us is then to think about scaling the bob count and ironing that out, which I expect will take over the summer.
stokes:But yeah, the way I've been thinking about it at least, is
stokes:get stable code. Then we essentially move to perf testing around the blog count. And that lines us up for Osaka.
stokes:You know, Terrence says here, after done that one just testing, testing, testing, testing.
stokes:Okay.
stokes:cool. So I think that was all we had for Fusaka. And yeah, thanks everyone I feel like that was pretty streamlined. I think we're making good progress there.
stokes:So okay.
stokes:the other thing today was Glamsterdam. And yeah, so some of this might be a little different or new, just given this new proposal we have to think around
stokes:or how we think about, you know.
stokes:scheduling hard forks, pacing them. And all this stuff.
stokes:So we said we'd move to this sort of regime. Now, where this call is essentially focused on fork plus one, we'd have a lot of the core current fork stuff. Go to the testing call.
stokes:So what that means, then, is, we can now open the thread of Glamsterdam, which is the next work for this call.
stokes:There's a couple of things here. And I mean, yeah, maybe just to get ahead of this.
stokes:I don't think we should make any decisions today around Glamsterdam, but I did want to start to open the conversation
stokes:the framing that Tim had in his proposal, which I thought was pretty nice, is to start by discussing the the focus of the fork. So essentially, you know.
stokes:she lets me and focus on scaling should focus on ux. There's like a number of high level categories we could frame works around
stokes:for what it's worth. I think most people would say that we should focus on scaling for Amsterdam.
stokes:But I do want to leave some room for that conversation again, just to get things started.
stokes:After that there were 2 headliners on the Cl. Side. So far that have been proposed for Glamsterdam.
stokes:I invited the authors of those vips to give a short review today.
stokes:And again, the point is not to decide anything. But just to start the conversation.
stokes:And then, yeah, a key bit, I think. Given all that context is for us to start to discuss today.
stokes:What what community input do we need? I think this is something that came up with our scoping of Petra is not being as in sync with the community. And how to think about that.
stokes:And so yeah, the the thinking is essentially to
stokes:open the conversation today. And then highlight different input, we feel like we're lacking. And then we can move forward on that for future calls.
stokes:So with that context, yeah, Onzgar, you have your hand up so I'll let you speak.
Ansgar Dietrichs:Yeah, I just wanted to say that I think it obviously makes sense to kind of talk here, mostly about the Cl side focus and on on acde more about the El side focus. And I think in some ways the Cl side is a bit easier, I think, kind of across the general priorities that I think right now we we seem to want to to have, and of course we can discuss those as well, but I think mostly it's around
Ansgar Dietrichs:well, scaling the l 1 scaling the blobs, making sure that also Ux and things like sensor resistance are in a good place. And so for Glamsterdam. That seems to just very naturally mean we will have to find some ways to continue the blob scaling that probably will already take up a meaningful portion of the attention on the Cl. Side there might be some El side scaling opportunities that will
Ansgar Dietrichs:require Cl. Help. So, for example, epbs, or some sort of delayed execution. Some variants of that would also be Cl side. So basically, Cl might also be able to help with that one thing that I think explicitly, because I think otherwise. Priorities don't make sense. If you don't say what they do not include, I personally think that on the Cl. Side, we've actually been a bit much on the side of
Ansgar Dietrichs:focusing around just like features, for the users of the Cl. Users of the Cl. Are mostly stakers. I think over the last 2, 3 years. We've very much focused on delivering kind of just quality of life. Nice to have
Ansgar Dietrichs:features there, I would say we should deprioritize that for a while. I think we're in a good place there now, after Max Cb. There are some proposals right around, like reducing the the withdrawal, time and whatnot. I think
Ansgar Dietrichs:these should very much be in the nice to have category like if we end up having room for that in Amsterdam great, but I think that should not be front and center, and the last thing I would also say is because fossil is already one of the proposed ones, and of course you'll hear arguments for that. I think we all agree. Fossil will have to be shipped soon, I would personally say right now, in the moment we're in time I would prioritize scaling, meaning that there are some arguments that fossil is also very crucial for scaling, because it reduces our reliance on
Ansgar Dietrichs:solar building for sensory resistance. And so basically making building a bit more heavy is easier to do after we have fossils. So in that sense, fossil is also helping with the scaling. But I think we should basically, for the short term, be pragmatic about. Does it already constitute a bottleneck that we need to address now, otherwise I would personally wait with fossil, for like one or 2 more hard fogs. But yeah, so that's kind of my general mindset for what Glamsterdam should focus on delivering.
stokes:Okay, thanks
stokes:any general comments on focus. Otherwise I think it might be helpful just to get into these headliner proposals to help ground the conversation.
stokes:Okay?
stokes:So then, I just went in order of proposal here. So the 1st one was 7, 7, 3 2 epbs.
stokes:Put us if you'd like to give a short overview, and I guess, frame it. Then in the context of scaling ux these types of fork focuses that
stokes:I think we want.
potuz:Sure. Let me just share the couple of slides that I used for the protocol call.
potuz:Let me see if I can
potuz:do I do this? Here? It is.
potuz:Alright. This is just a couple of slides. Most people here already know the mechanism. So I'm not gonna go over that again.
potuz:I just want to mention quickly what are the scaling properties of epbs?
potuz:it's simple. The Pbs gives you the following, it removes all of the broadcast of the payload and the blobs from the hot path.
potuz:Instead of like having 2 seconds to broadcast the block, the complete block consensus, execution and blobs. You will have now between 8 and 11 seconds.
potuz:and you will have now between 8 and 11 seconds, with the current slot times to broadcast blobs. The whole thing
potuz:bottleneck today for scaling blobs and for scaling in general. The bottleneck today is bandwidth. There's no other bottleneck that gets even close to bandwidth. So these numbers are just huge changes.
potuz:and this is the only eip that achieves this thing of like completely decoupling the payload from the block and completely decoupling the broadcast of the blobs from the validation of the block.
potuz:So that's the major change that the cip gives in terms of scaling. Of course there are other known scaling benefits which move around the trust assumptions on, on, off protocol
potuz:players. But I've been told not to focus on this today. They are written in this slide.
potuz:Let me just go to the next one
potuz:and other features that Dps has.
potuz:It's absolutely, trivially composable with other proposals for scaling both on the El and the Cl. And it's easy, because of the mechanism of separating the consensus from execution. Logic.
potuz:once you have different consensus and execution logic, then you can just tackle both sides independently. So compare, what's the complication of including fossil with other proposals for delayed execution? Of course Cpbs gives you delayed execution
potuz:and compare it with the proposal on how to include this, for epbs for epbs, including fossil, is just trivial. It's just a single bit list that needs to go in the bid, including a block access list, is absolutely trivial. It doesn't even affect epbs at all.
potuz:So there's no changes that are needed. Whenever you want to make changes, either purely on the consensus side or purely on the execution side, because the logic is completely coupled. So that's what Dpbs does. It separates the payload from the block, and it makes it simpler to argue about changes on either side
potuz:as it stands today. It only involves Cl changes, it does not touch the El at all. It doesn't even touch the execution engine. If you do this correctly, in the sense that when this execution, when the consensus layer gets the block, it doesn't even talk to the El to validate it
potuz:at all. There's no even a single message to the local El. It can be tested in isolation because of this change because of this property. So whatever the El is doing in a fork, we can just test epbs separated at that time.
potuz:It's already been. It's already implemented almost completely. But there are some simplifications that aren't included yet, but it's fully implemented in Taek. One prism.
potuz:And well, that's it.
potuz:Let me just have this last slide with some questions that people typically complain about. There are many others. But these 3 I like.
potuz:This is one that I get very common. It enshrines a particular type of auction, and it would just like, Give us this tech debt forever. No, there's no auction in epbs, not at all. The proposer can do whatever he wants. 99% of the pip is separating the block from the payload the auction part. It doesn't exist.
potuz:What happens is that the payload has to be signed by someone that's just for simplicity, and that can be changed at any time in the future. In fact, all of the proposals that we have for Aps is execution tickets, and so forth. Rely on the separation of the payload from the block. So they rely already on the feature that epbs produces minimally.
potuz:It is not compatible with existing off protocol mechanism. That's that's just purely false epbs is compatible with anything that happens now, because you can continue doing whatever you're doing. Now, if you wish to.
potuz:Epbs just allows you to do in a different way, but you can just still sign your blocks and your payload yourself and trust whomever external builder is going to produce you a payload if you just signed it blindly.
potuz:it increases protocol complexity. No, I think I already argued that it doesn't. It's true that it's not a simple eap to implement. It takes time to implement on the consensus side, but it actually simplifies the protocol itself. It simplifies it because it separates the concerns of the consensus and the execution.
potuz:If you want to read more, these are resources. The 1st 2 are just non-technical, exactly in the same tense that I talked today, and the last one has more than what you wish to to look for on the technical side.
stokes:Cool. Yeah, thanks for the review. So yeah, I think in summary, like, if the framing of Amsterdam in terms of fork focus is scaling.
stokes:Yeah, the argument here is like Pps gives us these pipelining benefits.
lightclient:That's.
stokes:Directly helps us scale.
stokes:I don't know if there are other questions from that.
stokes:I did have one question. I believe there's given the way we separate the execution payload from the consensus block.
stokes:There is some impact on how transaction inclusion, latency would be perceived effectively adding a delay.
stokes:Could you speak to that a little bit.
potuz:I'm sorry. Oh, oh, the delay of including execution is including transactions.
stokes:Right.
potuz:Yes. So this is definitely an issue. So the issue here is, the following is, if you're sending a transaction today, the builder can produce can include it right at the moment that you're that you're sending it
potuz:with the Pbs. There is a delay between what the proposal the proposer has committed to a blog.
potuz:and that block is not revealed yet. However, this delay we're looking into like making the slot shorter, and we believe that we can push this delay to about like one second 1.5 seconds. We have been doing experiments with 6 MB blocks, and they show that we can actually squeeze the time in which the builder has to reveal their payload.
stokes:Okay. Thank you.
potuz:Party.
stokes:How's it going.
potuz:Question about 4 choice. I don't know if you wanted to mention there he is.
stokes:Rolling. Yeah.
potuz:There is. And this is something that people typically ask about. And it's scary, because.
potuz:frankly, because most people don't know what 4 choice is on ethereum.
potuz:and there are a few that actually do know. And they have this concern. And I agree any touch on 4 choice is important, but most of our bugs have not been on 4 choice. Most of the bugs that we have seen, and the important security concerns that we've had had been around the execution engine, and actually the non separation of the consensus and the execution. However, there is a minimal change to 4 choice. The change to 4 choice is that now
potuz:today you have a node in 4 choice means that you've seen a block, a consensus block and an execution block, and with the Pbs. A node in 4 choice would mean 3 different things. Either you've seen the consensus and the execution block, or you've seen only the consensus block, or you haven't seen anything.
potuz:So there's this one new feature that you need to account for that a consensus block might have come without a payload that was revealed. But that's the only change. We still rely on proposal boost in the same way as today to
potuz:to enforce the security of the builder and of the proposer. And there's a little mechanism of merge view that I don't want to get into details today. But that's just very minor, which is just counting attestations from the Btc.
stokes:Right and just to clarify. There would be then like 2 proposer boost.
stokes:because you'd have one for the 1st round, and then.
potuz:No, there's only no, there's only one. There's no changes to fortress today except the node mechanism that I said
potuz:so. There's only one proposal boost that enforces that the consensus block was there.
potuz:and the builder can actually overload the existence of that boost to not to not produce his own block
potuz:his own payload. There's no changes to 4 choice except this fact that attestations that are tested for a block that did not support the payload then don't count for the full node that has the consensus block and the payload in it.
stokes:Got it.
stokes:Okay?
stokes:And yeah, in terms of process, I will elevate this comment from Onsgar. That essentially, I think now, the framing is to just have an intro to these different proposals we will get, I think, much deeper into the weeds later on in the process.
stokes:So we'd probably then, at that point, want to get deeply into like pros and cons and start, you know, weighing different eips against each other
stokes:today, I just wanted to open the conversation. So yeah, let's just keep that in mind.
stokes:You did mention Potus. There are 2 cl clients who have implemented it. I would assume prism. And what was the other one.
potuz:Teku.
potuz:We had finalizing, and that that accelerated the process quite a bit. Once you have more than one client is very simple to start testing.
stokes:Alright cool.
stokes:Yeah. Thanks for the overview.
stokes:Unless there are other questions for that, I think we'll then turn to the next proposal we have on the Cl side, which is fossil.
stokes:let's see, is tomorrow on a call.
soispoke:Yup down here.
stokes:Okay, yeah, take it away.
soispoke:Thank you.
soispoke:Can you guys see the presentation.
stokes:Yep.
soispoke:Yeah, Hi, everyone. So yeah, I'm and I'm actually very happy to make the case for 8. 0, 5
soispoke:as a headliner for for Amsterdam.
soispoke:So yeah, I thought I would just start by the explained 5 sort of prompt fossil. What fossil does is basically improving ethereum's censorship resistance? And it does so by enabling multiple validators to ensure that any transaction valid according to the protocol rules is included in ethereum blocks.
soispoke:so it does this by having multiple validators that build inclusion lists and impose constraints on the sophisticated builders that we have today.
soispoke:I am going to go through the mechanism real fast, just in case there are like 3 very simple steps that are important to keep in mind. The 1st step is about building and broadcasting the inclusion lists. So it's like you have 16 validators that are randomly selected to become Il committee members or includers.
soispoke:and each of them basically monitors, the main pool, and includes like transactions that are comp pending in the public main pool. In their inclusion list up to 8 kB, which is like around 40 transactions per inclusion list. If if you take the median transaction size.
soispoke:and then you the broadcast broadcast, their inclusion list over the shared between network.
soispoke:And what validators do is they monitor the P. 2 P. Network, and they store the inclusion lists that are broadcast until a deadline. That's the view. Freeze deadline that, and that's 9 seconds into the start.
soispoke:And so at this point they keep forwarding like inclusion lists, but they stop storing new ones.
soispoke:Then the second step that's very important is about the builder, that is, including Inclusion List transactions in its block.
soispoke:And so what the builder does is it also collects and store the inclusion lists, but it actually has additional time after the view. Freeze deadline
soispoke:just to make sure, like there is enough time for the builder to see all the available inclusion lists that were broadcast by the committee members.
soispoke:and so 11 seconds into the slot. The builder, just like, takes the union of transactions across all its stored inclusion lists and then include them in the execution payload before the full block is just like proposed to the rest of the network by the proposal.
soispoke:And in the last step that's like the enforcement step. Attesters also take the union of transactions from Inclusion list they sold according to like their local view, until the view freeze deadline, and they check whether all these transactions were actually included in the block execution payload by the builder.
soispoke:This is where the folk choice enforced comes from. It's like
soispoke:a testers will basically only vote for the block if it satisfies inclusionist conditions according to their local view. So that's the mechanism.
soispoke:I want to briefly talk about some fossil properties the 1st one is that inclusion list, and the payload can be built in parallel, like during the same slot, which is sort of nice and they only need to be merged towards the end of the slot. And that provides real time, censorship, resistance, which is one thing we like. The second part is like we actually have multiple
soispoke:inclusion is proposals like, that's a very cool and central design consideration, and that allows to
soispoke:be quite robust to commitment tax. But it also gets us like a very nice one out of N honesty assumption.
soispoke:and what it means like, we only need one Il committee member to build its inclusion list honestly and include transactions from the main pool without censoring for the whole mechanism to work properly.
soispoke:And the conditional property means that the builder must include all the I transactions until the block is, unless the block is full sorry
soispoke:and the builder is also not constrained on where inclusionist transaction transactions are included in the block or their order.
soispoke:And these 2, like last properties, are like, quite important, just to like prevent inclusion list from being crowded out by Mev transactions
soispoke:like, imagine if there is like dedicated additional block space, that is for Il transactions, and that will have to be included like I don't know. At the top of the block, or at the end of the block, we might, we will probably see, like some something like an il boost sort of thing emerge where like, you try to sort of like, include your valuable transactions but using il block space. And so
soispoke:in fossil right now, we avoid this, because the Inclusion List transactions have no ordering guarantees, and they must be created before the builder actually builds the block. They are broadcast publicly. So there is really no point in trying to include your transactions with the fossil.
soispoke:Why, it matters well, I I think it's kind of a useful like. Censorship. Resistance is sort of like a core ethereum value. And today we have
soispoke:more than 80% of all blocks that are produced by like just 2 builders.
soispoke:And yeah, it's important to keep in mind that these 2 visitors can arbitrarily decide whether to include or exclude transactions from like most of ethereum blocks.
soispoke:And just by looking at the data you can see like these huge fluctuations in builder censorship. And that's just caused by like one or 2 builders that just suddenly decided to censor more or less based on like the fluctuations of their policies.
soispoke:So what fossil does is like? It actually fixes this by giving power, sort of like back to the more decentralized set of validators to enforce inclusion constraints on builders, basically, and that restores fairness and ensures that theorems remain pretty neutral
soispoke:who it benefits, or I I think it's sort of like clear that it benefits, like all users, by ensuring, like their transactions are just included on chain in a timely manner as long as the network is that congested and without having to rely on like those 2 centralized entities, to not censor them. So I think it's like a big ux thing.
soispoke:and the primary benefits. I think the 1st one is obvious. The second one is actually sort of very interesting, because
soispoke:it allows to scale ethereum without having to impose the constraints on the local blockbuilders.
soispoke:The idea there is like, if you allow validators with fossil to independently enforce transaction inclusion. Then it's a major step towards scaling ethereum throughput because it removes the dependency you have on local builders to preserve censorship resistance at the cost of performance and incentive, and I linked it there. But there is a really good article by Barnaby that goes into more details on this.
soispoke:But there are all these like the improved yeah. Ux that I talked about.
soispoke:I think when your transaction is sent for today, you have to
soispoke:wait for quite a long time like 7 to 8 bucks, I think. And enforce. You know that that actually drastically reduces the the time to inclusion for transactions that might be sensible. So it is an a improvement.
soispoke:Yeah. So I I think it does like fit quite well with the the ethereum priorities. in terms of I mean it. It. Both are all scaling, and it improves ux so. But that's my perspective. I'm obviously a bit biased.
soispoke:It doesn't scale blobs, so it doesn't like do 3 out of 3. But you know 2 is quite good and a a secondary benefit. That was also brought to me recently. And it's kind of enable. It's nice, like it might actually allow some optimistic roll-ups to shorten the challenge period from 7 days to 2, 3 days. If their Tbs is not too big, but like it's, it's still like a an interesting
soispoke:benefit, I guess.
soispoke:Yeah, I'll just go on. Why, now?
soispoke:I think. Yeah, we've been talking about having is, and like better solutions for censorship resistance. For a while. The builder market is inherently centralized just because of like the Mev and the private order flow dynamics. So
soispoke:I don't think that will change like anytime soon. And, on the contrary. Basically, we've observed, like increasing vertical integration across builders and relays and socials over time. So it's not like looking like it's going into in a super nice direction to be. To be honest, I think, observing how fossil behaves on Mainnet is actually also important to us to make decisions on future local changes. We might want to make
soispoke:for example, like this new idea of like delayed execution with Dkvms. I will. I forgot the link, but I will put it to it is like depending on, like the same view merge mechanism we use for fossil. So it would be nice to see it live on Mainnet and that will inform us on how to to deal with other proposals that are important for future upgrades. We need also fossil to
soispoke:to to ship a case, in in my opinion.
soispoke:And then a very important for why, now I think it, and it's always like understated. But like we are like quite lucky that there is not that much censorship going on on the network right now at the protocol level?
soispoke:and if we wait and things change, and and they can like it could actually make protocol level changes to improve censorship, resistance a lot more difficult to coordinate and adapt. And I think that's a point that needs to be taken into consideration in like the sort of urgency in shipping fossil.
soispoke:And then I'll just finish by the technical readiness. Yeah, so 1st of all, 1st of all, is like the result of like multiple years of research on inclusion list, multiple proposals, new merge mechanism, and and so on.
soispoke:It's now working and like, implemented on, on different clients. 5 clients have worked on it. And it's actually successfully runs on a local with prism loadstar teku and get interoperability.
soispoke:We are now working on the spec test for both the Cl. And the El. We've had 11 possible breakout sessions that have been like, at least for me, like very, very nice and useful and we address like sort of like security concerns around il equivocation. And so there was actually a problem in like a previous eip that was about inclusion lists. We've made sure it's also compatible with account, abstraction, delayed execution, epbs, blocks.
soispoke:access blockable access lists, and and other like proposals
soispoke:on the El and Cl. Side
soispoke:and you can go on Meetforcil dot e dot limo. It's a censorship resistance web website that's using Ens and Ipfs, and there you can find, like an actual update
soispoke:on progress on the implementation side of things, but also like all the resources that are like useful for Fosso, both for, like the current proposal, but also like research directions and everything.
soispoke:Thanks. That's it for me. Thanks. Yeah, thanks a lot to all the co-authors, and but also, like all the client devs and contributors that have worked on this so far. It's been super nice to work with all of you, and that's it for me.
stokes:Great thanks for the review.
stokes:Yeah. So you know, going with this focus or this framing of the focus of Amsterdam as some combination of scaling and ux, then, yeah, we have fossil that
stokes:fits into that category. So, okay.
stokes:any questions, I guess, to close out the segment on fossil.
stokes:Okay, I think your hand was up for a split second.
stokes:Well, that was.
Ansgar Dietrichs:Just for comment. I just wanted to say that, like, in a way, it's almost like
Ansgar Dietrichs:we should also not over focus on these
Ansgar Dietrichs:these focus areas, right? Like, I think the reason like, I think some people in chat were a bit amused that basically, like fossil, is now being presented as a ux and a scaling benefit. I think it is both, but it is much more crucially also delivering to one of like delivering one of ethereum's core values. And I think it's much more justified through that, like sensitive resistance is at the very core of what ethereum is all about. And one of the core things that also
Ansgar Dietrichs:delivers for L. 2 s. And for everything right? And I think it doesn't need justification through these shorter term focus areas. I think the only the main reason why it is useful to have that conversation. How much does it also help with Ux? How much does it also help with scaling is
Ansgar Dietrichs:to ask the question.
Ansgar Dietrichs:do we need to have that in the next fork? Or is it more? Something that we need to like slot in at the next convenient time. So I still think that conversation we should have once we kind of actually determine the scope of Amsterdam in a month or so. But I just wanted to mention right? Just like this is crucial to the future of ethereum. Definitely, I think we all agree on that.
stokes:Right? Yeah. And you know.
stokes:it's, I think, perfectly fine to say that Cr is a focus of a fork, at least as a general statement.
stokes:So we don't need to like gradually stick to just scaling or just ux, as like these, only options for the glen focus.
stokes:Yeah, tomorrow.
soispoke:Yeah, yeah, I I just want to agree fully, like the I don't want to like make it seem like, it's as important for like scaling and and ux, or like, just like going through these lenses as it is for some social resistance. It's it's mostly definitely like a proposal force and social resistance.
soispoke:and I think it's like also interesting, because it can lead to these like pretty big improvements, in my opinion, in the future, and like in in scaling, which is interesting to think about. But yeah, I I didn't mean to like sell it as like a scaling eip. I don't think I want to do that, and I don't think it's it's fair. It's like it is a sensorship resistance, eip, and the argument. I think the the more convincing argument for me of why it should be included rather
soispoke:like sooner than later is more about like the we don't know how censorship is gonna evolve on the network. And that's the part that worries me the most not like. Oh, we need to get fossil in because it's gonna unlock like a ton of skating. That's not what the where the urgency is, at least for me personally.
stokes:Makes sense. Thanks.
stokes:Okay. Then, I think the other thing for today, I did want to try to start building the muscle memory of thinking about getting input from different parts of the community.
stokes:So yeah, I assume this is a conversation that will probably also be informed by the execution layer. But assuming, then, we have this focus on scaling, possibly ux.
stokes:maybe cr for Glamsterdam. Then, yeah, I think either of these headliners could make sense in that framing.
stokes:One thing that we've historically, I think, lacked quite a bit is again input from the broader community. So
stokes:I wanted to take some time to discuss and to make it concrete. We can focus on these 2 eips today.
stokes:And just yeah.
stokes:start to start to highlight who you'd want to get input from to help inform the scoping discussion.
stokes:So off the top of my head right now, I think we could pretty easily say that with Upps.
stokes:There are a number of comments here that we're speaking to different people in the Mev ecosystem. So I think we should try to incorporate their input.
stokes:And then, yeah, fossil.
stokes:it's kind of a pretty broad set, simply just because it's all users of ethereum. But yeah, we mentioned roll ups. And yeah, I think there are a number of people we could incorporate there.
stokes:And
stokes:let's see, I was just looking at Tim's comment. Here, I think we should assume there will be more. I I don't know.
Tim Beiko:More candidates. Cl, head headliners.
Tim Beiko:Yeah. Barnabas was asking the question.
stokes:Okay.
stokes:right? So yeah, this is again, I just wanted to start the conversation. Today. I assume there'll be more and we'll cover them in future calls
stokes:but yeah, okay, Nixo has a nice cloud here to solo state grocery Pbs.
chanderprakash sharma:Can I ask one question?
stokes:Sure!
chanderprakash sharma:Yeah.
chanderprakash sharma:so like, as we are implementing thinking about implementing epbs for the ethereum cl. So if we think at the privacy level in because the future roadmap of ethereum is going to be the privacy level. So what are the impacts? It can like to the core protocol have any idea about it?
stokes:The question was, core impacts
stokes:or impact to the core protocol from apbs.
chanderprakash sharma:No question was that like epbs is just like another way of the sensors of resistance compared to other mechanism. So my question is that like, if we, if we encrypt the for example, we are encrypting the blocks and transaction end to end.
potuz:I can probably take. I'm not.
potuz:I can probably take this. Justin here might be probably a better person, but I think that all of these primitives for encrypted mempoles already rely on some sort of separation, on some sort of delayed execution.
potuz:An epbs gives you this, so it's tangential. But I think all of the private mempool mechanisms get only stronger when you have delayed execution.
chanderprakash sharma:Okay. Thank you.
stokes:Okay, thanks.
stokes:Onsgar has an interesting take here that essentially the strive for community input should be more of an El focus than a Cl focus. I think we can debate that.
stokes:I don't know if you had something to add to that, Anzar.
Ansgar Dietrichs:No, I mean, of course. Also, we should try it everywhere. I'm just saying I think it's more important on the Yale side, or more of a liking thing on the Yale side.
stokes:Gotcha? Oh, yeah. Potus.
potuz:I think the I mean we have this this idea, that scaling the El means scaling the protocol, and then this the separation of the El and the Cl. But
potuz:we see that one of our biggest bottleneck is networking and scaling. The Cl. Does affect this. So it's very hard to separate this. And we can actually talk about scaling vips on the Cl call.
stokes:Yeah. And I guess the general comment, there is as we get closer to a final Glamsterdam scope.
stokes:you know. I think we will need to
stokes:take these things together. We can't just say, Oh, the sales over here, the else over there, and they just are working off in a vacuum.
stokes:especially given the nature of. Yeah, I think all of these vips we've discussed today have at least some impact on both layers. So
stokes:we will eventually need to take them in consideration. At the same time.
chanderprakash sharma:Stocks. I have one request to you. I already mailed to Tim also, and you about like I like, recently joined the core protocol meetings because I was working on layer 2 protocols. Our paper is coming very soon
chanderprakash sharma:so I have one to guess like where the meetings of the all rank. It's fine, because I also discovered the project management repo. But I did not find then I lately find in the discord. So there is a so many channels for it.
chanderprakash sharma:so could you please approve like I got the meeting link in.
stokes:Yeah, I couldn't quite hear you. I think you're asking where you could find information about the Acd meetings.
chanderprakash sharma:Yeah, actually like
chanderprakash sharma:I mail regarding it like as I read the report, like, I have to mail either the team or you stop about like to join the meeting. But actually I did not find any meeting link there, it only showing like there is the meeting in the calendar.
chanderprakash sharma:But there is a no end meeting link, but fortunately I find through the discord. But many of the time I forgot to join, because the. There is the meeting link in your present in the my Google Calendar. So could you share the calendar or provide me permission to join that.
stokes:Yeah, well, it sounds like you've discovered the process. So yeah, we have agendas in the Pm repo that you've mentioned. And then also, yeah, the meeting information share on discord.
stokes:So yeah, my email is in the agenda. So if you would like to follow up.
stokes:let's just take this offline.
stokes:Oh, yeah, I'm in fang.
Mingfei Zhang:Is there some time left for me to present my vip like 12 min.
Mingfei Zhang:so I want to make it in a headline in the next folk hard, hard folk.
stokes:Yeah. So I replied, on the agenda about this the way we're thinking about this now is having this process for headliner proposals. So I think ideally, you would have
stokes:I post on these magicians that proposes the headliner. If that fits the scope, and then we could cover in a future call.
Mingfei Zhang:Okay, okay, that's cool.
stokes:Okay, thanks.
stokes:Okay, let's skip back on topic. So
stokes:I did want to highlight different parts of the community that I think we should try to get input from, as we inform the scope discussion.
stokes:And let's see. So we have different map ecosystem people, free Pbs, solo stakers there.
stokes:Probably generally validators across the board.
stokes:And yeah, anything anyone wants to call out for fossil.
stokes:I think that would generally just be everyone.
stokes:so that might be a harder set to get a concrete representation of
stokes:okay?
stokes:Yeah, I'll think about how we can get again concrete input from these different parties and incorporate them into future calls, as we continue the Glamsterdam scoping conversation.
stokes:And with that let me just double check.
stokes:Oh, there was a okay, I guess I'll just call this out there's a poll here for the H. Star name
stokes:for the upgrade after Glamsterdam.
stokes:Let me just grab a link here.
stokes:There's this post on Ethan magicians. So yeah, if you would like to chime in, you can do so there.
stokes:And okay, yeah, I mean, okay, I see your comments here. I'll follow up with you after this.
stokes:But yeah, otherwise, I think that was essentially everything on the agenda today.
stokes:And yeah, unless there are any other comments? Then I will go ahead and say, we can wrap up early.
stokes:yeah, I guess. Generally, just yeah. Be thinking about the different points made today around Glamsterdam, continue thinking about the the framing of the fork, and like, what are the sort of core properties we want to focus on. And yeah, I think, well, maybe I won't speak to next week. But
stokes:yeah, point being is, we will continue the conversation. And yeah, get to a Glamsterdam.
stokes:Okay? Unless there's anything else. Let's go ahead and wrap up today.
ethDreamer (Mark):Thanks guys.
soispoke:Thanks.
soispoke:Okay. Thanks. Everyone.
stokes:See you next time.
Ansgar Dietrichs:Thanks. Ron bye.
chanderprakash sharma:Thank you, everyone. Bye-bye.
potuz:Bye-bye.
Chat Logs
00:00:16
stokes:https://github.com/ethereum/pm/issues/1548
00:00:20
Ansgar Dietrichs:Replying to "gm gm"
last may acd
00:00:28
Ansgar Dietrichs:Replying to "gm gm"
(hopefully only for this year)
00:03:03
Parithosh Jayanthi:I had a peerdas-7 update on sync testing if we have time for it later
00:03:32
Justin Traglia:Regarding blob schedule confusion, we made this spec change: https://github.com/ethereum/consensus-specs/pull/4341
00:04:13
Ansgar Dietrichs:what’s the clients’ take on how much of a lift this is?
00:04:35
Ansgar Dietrichs:Replying to "what’s the clients’ ..."
preconfs seem like important for UX medium term, so if it is small, I’d include it
00:04:41
ethDreamer (Mark):Replying to "what’s the clients’ ..."
Seems highly dependent on the client
00:04:45
ethDreamer (Mark):Replying to "what’s the clients’ ..."
It’s easy in lighthouse
00:04:46
Ansgar Dietrichs:Replying to "what’s the clients’ ..."
of course less clear if it adds significant load to fusaka
00:04:54
ethDreamer (Mark):Replying to "what’s the clients’ ..."
Prysm may be different
00:04:57
NC:Replying to "what’s the clients’ ..."
For lodestar, it’s not hard
00:05:03
Ansgar Dietrichs:Replying to "what’s the clients’ ..."
@ethDreamer (Mark) oh interesting, any client that knows it would be a headache?
00:05:13
stokes:Replying to "what’s the clients’ ..."
Big thing imo is that it touches the beacon state, whereas today we don’t do that in fusaka
00:05:41
lightclient:but you can do base rollups today?
00:05:41
ethDreamer (Mark):Replying to "what’s the clients’ ..."
So some clients may not have a new object for the fusaka beacon state since it’s the same
00:05:46
Gustavo Gonzalez:At OZ we are very supportive of including EIP-7917 in Fusaka. It will help building based rollups and preconfs easier. It would certainly help our work in the minimal-rollup stack.
00:05:57
ethDreamer (Mark):Replying to "what’s the clients’ ..."
In lighthouse, adding a new variant is a 1 line change. It might not be in other clients
00:06:13
Storm Slivkoff:Even if all L2 sequencers were decentralized, the L1+L2 doesn’t feel like a single unified chain. Centralization is different than the UX problem
00:06:25
Ahmad Bitar | Nethermind:centralized sequencers today have 200ms confirmation time. Based rollups cant compete with that now
00:06:40
Ansgar Dietrichs:but preconfs seem like a UX win, no?
00:06:58
Stefan Bratanov:Replying to "what’s the clients’ ..."
for Teku, it's not hard on first look, but have to check with the team member who is looking at it
00:07:33
Lean F | Lambda:You can still do based but having this will improve the UX and enable preconfs very easily
00:07:35
Storm Slivkoff:Replying to "Even if all L2 seque..."
Definitely!
00:08:18
Ansgar Dietrichs:so overall it seems like it is a relatively small change in most (all?) CL clients, and our users really seem to want this.
Maybe we can use this as an exercise in shipping things people actually want?
00:08:52
Ansgar Dietrichs:Replying to "so overall it seems ..."
(some nuance around “our users” with this L2 context, but if we zoom out, still holds)
00:09:11
Gustavo Gonzalez:Not having this introduces the need for some trust assumptions or central actors as Jason is mentioning. It also increases risks for proposers to be slashed since the lookahead might change
00:09:51
Jason Vranek:prepped this in case butchered it!
Prior to EIP-7917, the space has arrived at three potential solutions, each with negative tradeoffs:
1. Optimistic Lookaheads (https://github.com/taikoxyz/taiko-mono/blob/b7ecfcfc80a82412d7beb960e40a4fd2c8004f8a/packages/protocol/contracts/layer1/preconf/iface/ILookaheadStore.sol#L43): Optimistically post the lookahead and slash with EIP-4788 after the fact if incorrect, *requiring complex incentives or trust*
2. Raid (https://eth-fabric.github.io/website/research/raid): use EIP-4788 to derive the canonical L2 head ≥ 1 slot after the blob publication, *sacrificing real-time settlement and L1 composability*
3. Dido (https://eth-fabric.github.io/website/research/dido): import the logic to derive the lookahead from the beacon state *into your rollup’s state transition function*
EIP-7917 trivializes this problem making based rollups simpler to implement and cheaper to use with the added bonus of increased L1 stability. Please consider it for inclusion!
00:10:10
Marc:Replying to "At OZ we are very su…"
who are OZ, do you guys make based rollups?
00:11:01
Ahmad Bitar | Nethermind:Replying to "At OZ we are very su..."
OpenZipplin, and yes. they are working on minimal based rollup implemmentation
00:11:18
Ahmad Bitar | Nethermind:Replying to "At OZ we are very su..."
https://github.com/OpenZeppelin/minimal-rollup/
00:11:22
Gustavo Gonzalez:Replying to "At OZ we are very su..."
OpenZeppelin. We are working on this reference stack for people to extend
https://github.com/OpenZeppelin/minimal-rollup
00:11:23
kasey:Healthy to talk about:
Benefits
Scope
But we should also talk about what our criteria is for adding last minute EIPs, and whether this proposal satisfies that criteria.
00:11:25
Ansgar Dietrichs:if we include it, would it be for devnet-1 or devnet-2?
00:11:39
Gustavo Gonzalez:Replying to "At OZ we are very su..."
we’ve been working with taiko and nethermind
00:11:41
Jason Vranek:Replying to "Even if all L2 seque..."
based rollups are the most obvious way to get L1<>L2 synchronous composability to make the chains feel unified. But without preconfs their UX is terrible and will prevent this goal from happening!
00:11:45
Marc:Replying to "At OZ we are very su…"
ah ofc, didn’t recognise from the abbreviation
00:11:46
Ansgar Dietrichs:lighthouse and loadstar said it’s small lift
00:12:23
Stefan Bratanov:Replying to "lighthouse and loads..."
similar for Teku, just some boilerplate code
00:12:31
NC:Replying to "lighthouse and loads..."
Implementing it is a small lift. But not sure from the testing perspective
00:13:17
potuz:Replying to "lighthouse and loads..."
For Prysm is also not a big lift, a lot of boilerplate and then testing the hashing paths and Trie cache
00:13:32
Ansgar Dietrichs:maybe we could ask - any people strongly opposed to including this?
00:13:33
Parithosh Jayanthi:Are there any unknown unknowns that could bite us? (Estimated ones atleast)
00:13:49
saulius:Replying to "lighthouse and loads..."
for grandine should not be a big change too.
00:14:05
Ansgar Dietrichs:Replying to "maybe we could ask -..."
(not saying that should be the bar for inclusion, but the absence of such a voice would still be a good data point)
00:14:52
Ansgar Dietrichs:we also added a few EL EIPs that have *some* risk of causing minor delays, because they are worth it
00:15:25
Ansgar Dietrichs:Replying to "we also added a few ..."
the point is to avoid multi-week delays for nice-to-have features
00:15:30
Phil Ngo:Replying to "Are there any unknow..."
I believe things can still be DFI’ed if we run into these, but because the lift is not huge on the code implementation, the burden then becomes if we find testing it to not actually be trivial, we could remove it if encountered or issues are discovered?
00:15:31
DA | Flashbots:Is not having this going to hold back based rollups in the next 12 months? Like what is holding them back today?
00:15:54
Barnabas:We plan to launch devnet 1 on 9th of June. Lets just keep this in mind. And by the 13th of June we want to absolutely freeze all spec changes.
00:16:02
Gustavo Gonzalez:Replying to "Is not having this g..."
yes IMO. It makes it harder to implement preconfs and riskier for proposers to opt in
00:16:10
chanderprakash sharma:HI GM GM everyone
00:16:29
Ansgar Dietrichs:agree we can be trigger happy with pushing it to Glamsterdam if there are issues
00:16:46
Parithosh Jayanthi:Replying to "Are there any unknow..."
Adding and removing also delays Fusaka
00:16:47
df:I think security is a very remote concern here
00:16:51
DA | Flashbots:Replying to "Is not having this g..."
Okay. Pro inclusion then.
00:16:54
Parithosh Jayanthi:Replying to "Are there any unknow..."
So we have to be ready to pay this cost
00:17:05
Ansgar Dietrichs:Replying to "Are there any unknow..."
agreed! just saying, that limits the downside
00:17:09
stokes:Replying to "We plan to launch de..."
I would lean towards devnet-2 for this if we include it
00:17:10
Ansgar Dietrichs:Replying to "Are there any unknow..."
seems like overall people want this
00:17:54
Will Corcoran:Improve UX
00:18:14
Ansgar Dietrichs:Replying to "Improve UX"
let’s keep the 7702 streak going
00:18:19
Roman:when did preconfs become our priority?
00:18:27
kasey:Since this is small, what if we get everything else done and tested, and then if we have a successful devent where everything else is working, add this at the end?
00:18:35
Parithosh Jayanthi:Isn’t the process that we CFI -> deploy on testnet and then SFI?
00:18:36
Ahmad Bitar | Nethermind:For devnet-2
00:18:38
Marc:Replying to "when did preconfs be…"
preconfs come under good UX
00:18:40
potuz:Replying to "when did preconfs be..."
God only knows
00:18:41
Roman:Replying to "when did preconfs be..."
not talking about the end goal, but the mechanism itself
00:18:42
Parithosh Jayanthi:Not SFI first and then deploy on testnet
00:18:46
ethDreamer (Mark):Replying to "Since this is small,..."
We have devnet-0
00:18:49
kasey:Replying to "Since this is small,..."
The idea of CFI is we should be able to add it at any point if there is no downside to doing so.
00:18:51
ethDreamer (Mark):Replying to "Since this is small,..."
That was the original thinking
00:19:09
Tim Beiko:SFI should be “next devnet"
00:19:16
Gustavo Gonzalez:Replying to "Since this is small,..."
I believe it would be helpful for projects building based rollups and preconfs to have predictability that this will be included soon
00:19:24
Ansgar Dietrichs:Replying to "when did preconfs be..."
point is that this is not something we are the best people to be opinionated about
clearly people are asking for this to help UX
00:19:37
Tim Beiko:So if this is going to be devnet-1, we should SFI. If we want to wait until devnet-2, can just leave SFI for now
00:21:46
Ansgar Dietrichs:Replying to "So if this is going ..."
is there no value in “this is included, start working on it now”?
00:22:00
Barnabas:Lets do june 9 then
00:22:04
Barnabas:nobody opposing it
00:22:08
Ansgar Dietrichs:Replying to "So if this is going ..."
because clearly before today, it was not yet time to start working on it
00:22:11
Phil Ngo:🚢
00:22:12
Ansgar Dietrichs:Replying to "So if this is going ..."
seems like an important status change
00:27:43
terence:same with prysm
00:30:44
Ansgar Dietrichs:Francesco is OOO today, seems tricky to decide without him
00:31:52
Ansgar Dietrichs:testing call monday might be good place to discuss?
00:32:09
Ansgar Dietrichs:Replying to "testing call monday ..."
confirmed Francesco will be joining :-)
00:33:21
Ansgar Dietrichs:curious, what’s the general feeling from CL side around fork readiness?
mostly still some work until peerdas stability?
00:34:29
terence:Replying to "curious, what’s the ..."
I think after devnet1, its just testing test testing
00:34:53
Ansgar Dietrichs:Replying to "curious, what’s the ..."
makes sense. sorry for the open ended question
00:35:53
Ansgar Dietrichs:what are the timelines again for headliner proposals?
00:36:34
Barnabas:Are we ok with not shipping any forks in 2026?
00:36:37
soispoke:[May 26 - June 20] Fork Focus Discussion & Headliner Proposals
[June 23 - July 17] Headliner Discussion & Finalization
[July 21 - Aug 21] Non-Headliner EIP Proposals
[Sep 4 & 11] Non-Headliner EIP CFI Decisions
00:36:40
Ansgar Dietrichs:Replying to "Are we ok with not s..."
??
00:37:03
df:Replying to "Are we ok with not s..."
Hopefully not, why?
00:38:13
df:IMO focus Glamsterdam on scaling+UX
- shorter block times
- delayed execution
- anything else that is ready and deemed highest priority for EL scaling (e.g. block level access list or an alternative like tx state diffs)
00:38:19
potuz:ePBS does not need EL at all
00:40:07
Ansgar Dietrichs:ah I though we wanted to have general discussion first, then headliners
00:40:07
soispoke:Will talk about it during the presentation but FOCIL helps with both scaling and UX (which are two priorities)
00:40:13
Ansgar Dietrichs:Replying to "ah I though we wante..."
sorry about that
00:40:29
Ansgar Dietrichs:Replying to "ePBS does not need E..."
but it does help EL scaling
00:40:51
stokes:Replying to "ah I though we wante..."
Mix of both
00:40:54
Ansgar Dietrichs:Replying to "IMO focus Glamsterda..."
ah right I forgot shorter slot times, +1 to that
00:40:56
stokes:Replying to "ah I though we wante..."
I think your comment was a good intro
00:41:02
NC:Is censorship resistance not one of the focuses? Rather than frame it as UX
00:41:03
Ansgar Dietrichs:Replying to "IMO focus Glamsterda..."
to me that's "scaling" in a broad sense
00:42:14
df:Replying to "Is censorship resist..."
CR is important but do you mean specific things to increase CR like FOCIL?
00:42:22
Anders Elowsson:Replying to "IMO focus Glamsterda..."
BALs are cool
00:42:35
mpaulucci | ethrex:Anywhere I can read opinions against ePBS? I’ve heard it’s controversial but it seems like a no brainer for me
00:42:48
NC:Replying to "Is censorship resist..."
Yea I meant to say focil
00:42:52
soispoke:Replying to "Is censorship resist..."
FOCIL’s focus is definitely CR, but it does have an impact on UX
00:43:09
Carl Beekhuizen:Replying to "IMO focus Glamsterda..."
BALs are indeed cool, but imo might not be worth the bandwidth cost
00:43:10
df:Replying to "Is censorship resist..."
shorter slot times also halve the time to censorship resistance :)
00:43:35
soispoke:Replying to "Is censorship resist..."
But you still rely on the same 2 centralized builders so not really
00:43:52
Carl Beekhuizen:Replying to "IMO focus Glamsterda..."
That said, if we’re going stateless then it doesn’t add much overhead
00:44:29
Ansgar Dietrichs:just a general word of caution: we should be somewhat careful with champion-led proposals, because people usually end up personally invested, which makes it harder to get neutral assessments.
This has been causing issues on the EL several times (e.g. Verkle)
00:44:30
Toni Wahrstätter:Replying to "IMO focus Glamsterda..."
I think they are. This is off-topic here but having full state diffs is also nice for other purposes other than just speeding up execution such as partially stateless nodes or full nodes under zkEVMs
00:44:32
Justin Florentine (Besu):Replying to "IMO focus Glamsterda..."
also fan of BAL, also concerned about bandwidth increase
00:44:35
df:Replying to "IMO focus Glamsterda..."
feeling is that tx state diffs might be the best tradeoff in terms of:
- parallel execution
- getting "almost" perfect prefetching via parallel execution
- syncing
- at more moderate bandwidth cost
00:44:52
Tomasz Stańczak:It sounds like an advertisement.
00:45:45
Barnabas:Replying to "It sounds like an ad..."
is that a good or a bad thing?
00:46:05
df:Replying to "Is censorship resist..."
not really. If you assume any percentage of non-censoring proposers, then halving slot times halve the time until you get a non-censoring proposer
00:46:28
Barnabas:Would be really good to get the cons of epbs too now.
00:46:37
Tomasz Stańczak:Replying to "It sounds like an ad..."
Not sure. If it is encouraging people to look into it more then good.
00:46:52
Tomasz Stańczak:Replying to "It sounds like an ad..."
If encourages people to just include it because it is great and solves all the problems then not.
00:47:05
Parithosh Jayanthi:Are there any fork choice implications? That tends to be a security sensitive layer and we should make sure there are no dragons there
00:47:09
df:Replying to "Anywhere I can read ..."
It is quite a complex proposal and delayed execution gives even better pipelining (scaling) properties
00:47:30
Storm Slivkoff:Replying to "Is censorship resist..."
the effect of slot times on CR is very underrated
00:47:37
Ansgar Dietrichs:process clarification question: I assume the next 4 weeks are for headliner proposals, then we would get into evaluating / discussing them afterwards, right?
I assume the people critical of ePBS would then prepare arguments to present for such a discussion
00:47:41
Tomasz Stańczak:Replying to "Would be really good..."
Last time I was looking at it, the main concern was that there was no incentive for anyone to use it and that it would be dead on arrival but now it seems it has changed significantly since then.
00:47:46
Marc:how does it compare to other APS proposals?
00:47:47
Justin Florentine (Besu):Replying to "Anywhere I can read ..."
delayed execution in general is a big pre-cursor for encrypted mempool designs
00:47:48
terence:I think it’s much less complex than delayed execution. epbs doesnt have any EL change
00:48:02
soispoke:Replying to "Is censorship resist..."
non censoring proposers that happen to be local block builders then, that’s very limited (6%)?
00:48:14
kasey:I think an undersold benefit of epbs is that it could be extended to allow the builder to show what blobs it would include (via eg commitment root), enabling L2-aligned proposers to pick blocks that include blobs they need to get on-chain. Keeping builders aligned with blob inclusion is going to get harder as we crank the blob limit and fragment the EL mempool.
00:48:19
stokes:Replying to "process clarificatio..."
Roughly yes
00:48:26
Ahmad Bitar | Nethermind:Replying to "Would be really good..."
This argument was discussed and debunked in a breakout room in thailand
00:48:27
terence:Replying to "Anywhere I can read ..."
but I agree epbs has fork choice change, which is the biggest part
00:48:30
Tomasz Stańczak:Replying to "Would be really good..."
Also staking related teams believe it would require significant amount of time for them to integrate it while they are still implementing MaxEB
00:48:31
stokes:Replying to "process clarificatio..."
Just wanted to prime the pump today
00:48:44
Ansgar Dietrichs:Replying to "process clarificatio..."
yes it makes sense
00:48:48
Barnabé Monnot:Replying to "how does it compare ..."
It does not remove the responsibility of assigning the builder of the execution payload from the validator
00:48:53
Barnabas:Replying to "Would be really good..."
that shouldn’t be a blocker tho...
00:49:11
Tomasz Stańczak:Replying to "Would be really good..."
@Ahmad Bitar | Nethermind - would love to learn more
00:49:11
Marc:Replying to "how does it compare …"
could that be done on top of ePBS?
00:49:19
Ansgar Dietrichs:Replying to "process clarificatio..."
just would want to clarify that the next 4 weeks are more about champion presentations and ad hoc q&a, so people should reserve judgement
00:49:37
Tomasz Stańczak:Replying to "Would be really good..."
Barnabas, I think that taking into account all the apps on the protocol should rather be an important aspect of planning forks.
00:49:41
Ahmad Bitar | Nethermind:Replying to "Would be really good..."
For sure @potuz and @terence can say it way better than I.
00:49:55
Barnabas:which cl are ready? Prysm I assume and?
00:49:56
Barnabé Monnot:Replying to "how does it compare ..."
if you added something like mev-burn to it, it would look more like it (JIT APS)
00:50:10
Justin Traglia:Replying to "which cl are ready? ..."
Prysm & teku, I believe.
00:50:22
terence:Replying to "how does it compare ..."
we believe eip7732 is fully extensible to APS
00:50:35
Stefan Bratanov:Replying to "which cl are ready? ..."
Teku yes
00:50:37
Parithosh Jayanthi:Replying to "Would be really good..."
@Tomasz Stańczak what do you mean staking teams need to implement things? Afaik epbs doesn’t require them to partake in some change right? Or is it just that it is more load for them to keep up with?
00:51:00
Tomasz Stańczak:Replying to "Would be really good..."
@Ahmad Bitar | Nethermind - around mid year last year the general feeling was that many researchers on the MEV side just pointed out that it had broken incentive (at that time) and were ignored and stopped participating so you may have them activating much more if it gets closer to inclusion. Similar to what happened around EOF.
00:51:26
Barnabé Monnot:Replying to "Anywhere I can read ..."
It is also not perfectly clear that separating the beacon block from the execution payload is what we want to do, if other things are desired such as short slot times (in some limit)
00:51:29
soispoke:FOCIL for Glamsterdam presentation: https://docs.google.com/presentation/d/1BYZQOmNkv-nLe25NmPOowhBLPVa76kDDibR_nR0-RGU/edit?usp=sharing
00:51:38
Tomasz Stańczak:Replying to "Would be really good..."
But I was not tracking the updates since last April so definitely looking forward to reading much more on all the latest updates.
00:51:59
NC:Replying to "Would be really good..."
I am more interested in what doors are shut if we adopt ePBS. Like what other potential eips cannot be adopted because of ePBS
00:52:18
potuz:Replying to "Would be really good..."
I can speak volumes to the bipasseability argument if you want Tomasz, it's abosuletly bogus
00:52:26
potuz:Replying to "Would be really good..."
but not in this chat
00:52:40
Barnabas:Replying to "Would be really good..."
I’m not suggesting that we shouldn’t consider the aspect of staking teams, I’m just saying that I don’t think just because a team hasn’t yet implemented maxEB we shouldn’t be considering new updates that touches staking pools. Just because some dev teams work slower, it shouldn’t slow down protocol changes.
00:52:42
Barnabé Monnot:Replying to "Would be really good..."
To ePBS credit, even if MEV people decide not to use it, it still offers the pipelining of delivering the execution payload later
00:53:30
potuz:Replying to "Would be really good..."
@NC no doors get closed, it' s the exact same opposite, 7886 would close doors by interwining the consensus from the execution. By separating their logic you allow for much more flexible protocol
00:55:03
Ansgar Dietrichs:just want to say, I think the team working on this (especially Thomas and Julian) have done a phenomenal job, and it’s because of their work we finally have a concrete feature ready for getting to a principled solution for CR on mainnet.
I feel like a bit of a bad guy for always saying we should be pragmatic about waiting to ship this if it’s not yet necessary for scaling. To be clear, I think this is absolutely crucial for Ethereum in the medium term!
00:55:25
potuz:Replying to "Would be really good..."
@Tomasz Stańczak Staking teams were generally very favorable to ePBS: it removes the problem of MEV stealing for them. I mostly got feedback from Lido but for them it was a very good UX benefit
00:55:36
terence:Replying to "Anywhere I can read ..."
I dont think epbs contradicts much short slot time: https://hackmd.io/@potuz/B1pWLb0-ll
00:55:49
df:Replying to "Is censorship resist..."
Currently that give you an expected 200s to censorship resistance, with 6s slots it would be 100s
00:56:01
Ahmad Bitar | Nethermind:btw, @Drew Van der Werff i think it is very important to start looking into the ePBS spec and its impact on Preconfirmations. I do still think the benefits of ePBS (especially on L1 scaling for both blobs and execution) outweighs the benefits of preconfs
00:56:02
Marc:I think FOCIL in glamsterdam would be great, just important to consider how it will interact with other things like ePBS / delayed execution and block access lists
00:56:24
potuz:Replying to "how does it compare ..."
I tried to prepare an actual implementation of APS on top of 7732 but I can't solve some problems of incentives on how to choose the builder 32 slots in advance.
00:56:42
potuz:Replying to "how does it compare ..."
but that problem is completely independent of 7732, any mechanism for APS will have to deal with this
00:57:05
Barnabé Monnot:Replying to "how does it compare ..."
@potuz you could do it not 32 slots in advance, using mev-burn for instance
00:57:29
Barnabé Monnot:Replying to "how does it compare ..."
but this is not the preferred APS mechanism atm aiui
00:57:46
Toni Wahrstätter:Replying to "Would be really good..."
My main argument against ePBS is complexity and potential incompatibility with other features we might want in the future (shorter slots and SSF).
We'd enshrine two new entities (PTC and builders) and radically change the fork-choice function. The latter is the real issue because it touches such a sentitive part of the protocol and changes the inputs to fork choice for the proposers (PTC vote becomes input to fork choice, which is something entirely new).
Also, the simulations done claiming block propagation of 1s are just optimistic benchmarks but far away from propagation times on mainnet today. Assuming attestations propagate in 1s but one can see them arriving at the 0.5 quantile of the network at second 6.5 in the slot for missed slots, so after 2.5s.
00:57:47
Marc:Replying to "how does it compare …"
makes sense, does this close the design space somewhat for what kind of APS we could do on top though?
00:57:50
potuz:Replying to "Anywhere I can read ..."
@df what you say about delayed execution givin gbetter pipelining is just false. Broadcast is the biggest benefit and delayed execution does not change that at all
00:58:05
Drew Van der Werff:Replying to "btw, @Drew Van der W..."
Noted! We still will need faster transaction confirmation than likely can be offered even in ePBS / L1. But faster block times are critical.
00:58:17
potuz:Replying to "Anywhere I can read ..."
@Justin Florentine (Besu) ePBS gives you better delayed execution than delayed execution
00:58:44
df:I don't think FOCIL should be considered a UX benefit. That stretches UX too far!
00:59:05
Barnabé Monnot:Replying to "btw, @Drew Van der W..."
afaict there is no direct impact of ePBS on preconfs, ePBS is only a secure line to make the remote call to builders, but you can still make the call and the builders/their relays can still offer you preconfs?
00:59:10
stokes:Replying to "I don't think FOCIL ..."
Would you say it is a scaling benefit?
00:59:15
Ben Edgington:Replying to "I don't think FOCIL ..."
Better UX for people who are getting censored.
00:59:16
Ansgar Dietrichs:Replying to "I don't think FOCIL ..."
also almost trivializes FOCIL. Censorship resistance is one of the key values of Ethereum!
00:59:20
stokes:Replying to "I don't think FOCIL ..."
Or just CR as a category separate from UX?
00:59:45
terence:Replying to "btw, @Drew Van der W..."
in the current eip7732 spec, builder is staked, its validator index is on the beacon state, this enables pre conf to do more things like trustless slashing
00:59:57
Toni Wahrstätter:Replying to "Is censorship resist..."
We should note that even if there are 99% builders censoring, only non-censoring builder get the prio fees from censored tx and thus, from time to time, accumlate enough to win the block. This is why it was so easy to get censored transactions on chain = non-censoring builders are ready to win the block auction using censored transaction. If a big app gets censored, only non-censoring builders would win and censorship would be at ~0.
01:00:38
Barnabé Monnot:Replying to "how does it compare ..."
there is a large design space, i am not sure if all of it looks like an iteration from ePBS, some of it looks more fundamentally different. best resource atm https://docs.google.com/presentation/d/1WVVcHsFcg92zB77vgzG4fsdpCR2Jxzx8XfuTCbCqWjM/edit?slide=id.p#slide=id.p
01:00:52
Toni Wahrstätter:I don't fully buy the scaling argument: As long as we need local builders as a fallback for mevboost, we cannot just scale both gas limit and the IL size since at somepoint you would need to include more txs than you can.
01:02:03
DA | Flashbots:Replying to "Would be really good..."
Personally neutral epbs, but suspect that it encourages the builder market to collapse towards one single builder. Still looking into it.
01:02:11
Marc:Replying to "how does it compare …"
I guess if we ship ePBS soon then we can still do something different for beam chain
01:02:32
Storm Slivkoff:Replying to "I don't fully buy th..."
Can you explain more about why the fallback is needed post FOCIL
01:02:33
potuz:Replying to "how does it compare ..."
@Barnabé Monnot I do not know how to do it, I tried to actually fully specify it and I couldn't. Neither with mev-burn type mechanisms where the protocol runs the auction, or assigning an auctioneer (for example the CL proposer). I can't plug all holes. I think people tend to think at a higher level without actually sitting down to specify the full thing.
01:03:08
Toni Wahrstätter:Replying to "Would be really good..."
to compete for large blocks you need large stakes, so yeah, might further increase centralization on the builder front
01:03:40
potuz:Replying to "btw, @Drew Van der W..."
I already argued in a few places that ePBS enables easier mechanisms for preconfirmations
01:03:46
Ahmad Bitar | Nethermind:Replying to "Would be really good..."
@Toni Wahrstätter can you elaborate on this
01:03:50
terence:Replying to "Would be really good..."
how does epbs change the builder market?
01:04:10
Barnabé Monnot:Replying to "I don't fully buy th..."
discussed this question in bullet point #5 of this section https://ethresear.ch/t/decoupling-throughput-from-local-building/22004#p-53517-block-production-liveness-7
01:04:26
Toni Wahrstätter:Replying to "Would be really good..."
you need to stake right? and if I want to compete for a block with 10 ETH mev, I'd need to stake at least 10 ETH?
01:04:29
potuz:I think it's a nobrainer that FOCIL should be included in the protocol
01:04:50
DA | Flashbots:Replying to "Would be really good..."
Either relays become more powerful or you see a giant shift in order flow dynamics that strongly benefit a single builder.
01:04:56
Drew Van der Werff:Replying to "btw, @Drew Van der W..."
Links we can read / learn more? Can dm you if easier.
01:05:36
Toni Wahrstätter:Replying to "I don't fully buy th..."
The proposal is great for other reasons but I won't say it's scaling, at least not as long as it cannot scale with the gas limit while relying on builders to be online.
01:06:16
potuz:Replying to "btw, @Drew Van der W..."
The only written thing I can find is this old thing where I propose to use staked builders as preconfers. https://ethresear.ch/t/the-contention-between-preconfs-and-epbs/19770
01:06:18
Toni Wahrstätter:Replying to "I don't fully buy th..."
imagine you're forced to include tx of 30m gas but you thought you could always rely on builders and won't ever have to fall-back from mevboost (bc of a bug) and build blocks locally again.
01:07:02
Drew Van der Werff:Replying to "btw, @Drew Van der W..."
Think a lot has changed since then, but we’ll take a close look and be back!
01:07:03
Storm Slivkoff:Replying to "I don't fully buy th..."
It seems like this only becomes an issue if the IL length is too long
Otherwise FOCIL helps scaling by allowing for higher validator hw req’s without sacrificing CR
01:07:44
NC:Replying to "Would be really good..."
@DA | Flashbots how will epbs affect flashbot’s builder net?
01:08:23
Barnabas:Are there any other CL headliners that could make it into glamsterdam?
01:08:34
Tim Beiko:I think we should assume there will be more
01:08:44
DA | Flashbots:Replying to "Would be really good..."
Unsure. Would say neutral.
01:08:47
nixo:+ solo stakers for ePBS
01:08:50
Francesco:Replying to "Are there any other ..."
There’s a lot of work to do on networking
01:09:05
Barnabas:Replying to "Are there any other ..."
are networking changes going to be headliners?
01:09:06
Francesco:Replying to "Are there any other ..."
Possibly big changes to how peerdas works
01:09:21
Francesco:Replying to "Are there any other ..."
Don’t see why they couldn’t be
01:09:24
Barnabé Monnot:Replying to "I don't fully buy th..."
@Toni Wahrstätter you're describing a liveness failure and assuming that there is no other way to make a block other than from your local node, imo this is a strong assumption and maybe too strong to justify FOCIL not replacing local building
01:09:46
Storm Slivkoff:Replying to "I think we should as..."
delayed execution 💪
01:10:35
Toni Wahrstätter:Replying to "I don't fully buy th..."
but this is how it works today. mevboost breaks, everyone falls back. If we'd get into such a situation today, we'd see many reorgs, I'm sure
01:10:39
Ansgar Dietrichs:Somewhat contrarian take:
I think being more user / stakeholder centric should be more of a focus for EL than CL.
CL is more about high level properties of the protocol, EL is the direct interface to users.
Exception is DA (we need to talk to blob consumers about what they need!), and to some extent staking (but as I said before, I think we overly focused on this in the past)
01:10:58
Toni Wahrstätter:Replying to "I don't fully buy th..."
what would be the other way that is not mevboost or locally?
01:11:00
nixo:are these “official proposals” for headliners? or better put - what’s the threshold for the proposed rule that declined headliners can’t be added in as non-headlining features?
01:11:09
DA | Flashbots:Replying to "I don't fully buy th..."
Can we just cap the gas used by a IL transaction? And add a proposer flag for max gas in a block so that local builders can keep liveness?
01:11:36
Justin Florentine (Besu):I FEEL TARGETED
01:11:54
Storm Slivkoff:Replying to "Somewhat contrarian ..."
Another exception is slot time
01:11:58
Toni Wahrstätter:Replying to "are these “official ..."
I think those are the one "officially" proposed on ethmag under #glamsterdam
01:12:25
Barnabas:+1 potuz, by far the biggest problem is always going to be networking. We can always buy a faster CPU/ more ram. But realistically we can’t always buy faster internet.
01:12:38
Ansgar Dietrichs:agreed the CL can help with scaling, but that’s still more high level. we already know we want to scale. EL needs to go talk to people about how the EVM should evolve. Much more direct user interface
01:13:00
potuz:that' s my point: and that' s why I want to scale that @Barnabas
01:13:15
Ansgar Dietrichs:Replying to "agreed the CL can he..."
also with EVM equivalence, EL changes affect all EVM chains, not just L1.
CL changes only affect L1.
01:13:25
Tim Beiko:Can you post your question on the chat?
01:13:31
Tim Beiko:Ahh audio is better now
01:13:37
Tim Beiko:The meeting link is in the Discord
01:13:54
Ansgar Dietrichs:Replying to "agreed the CL can he..."
so overall I do think there is a pretty strong asymmetry between EL and CL here
01:13:56
Barnabas:@chanderprakash sharma this is all on Eth R&D
01:14:04
potuz:Replying to "agreed the CL can he..."
I do not think these are high level changes. Changing the way blocks are distributed for example is definitely not high level
01:14:07
Pooja Ranjan:https://calendar.google.com/calendar/u/0?cid=Y191cGFvZm9uZzhtZ3JtcmtlZ243aWM3aGs1c0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t
01:14:10
Francesco:Can you please ask something like offline? It’s a call with 70 people, don’t really have time for this (no offence)
01:14:11
Tim Beiko:I don’t think we should put the zoom link in the cal invite, because it’s too suceptible to spam
01:14:11
Roman:can u ask about it separately pls?
01:14:33
Ansgar Dietrichs:Replying to "agreed the CL can he..."
but the number of stakeholders to talk to about this is still small
01:14:33
potuz:Replying to "agreed the CL can he..."
and if I were to proposose an RLNC broadcast mechanism, it would be here, not in the ACDE.
01:14:49
Ansgar Dietrichs:Replying to "agreed the CL can he..."
of course! but the discussion was about bringing in more external stakeholders
01:15:13
Ansgar Dietrichs:Replying to "agreed the CL can he..."
and I think these are still much more internal topics. there will be some people to invite, but at much lower scale than for many EL topics
01:15:17
potuz:Replying to "agreed the CL can he..."
ah yeah, but that can get into either call fine, for ePBS we should bring builders, Lido, homestakers etces
01:15:22
potuz:Replying to "agreed the CL can he..."
and those can come anyone
01:16:02
Ansgar Dietrichs:Replying to "agreed the CL can he..."
but these are the people helping us make the changes happen, not the people the changes are for
01:16:09
potuz:LIDO, RocketPool, homestakers, Builders, etc should be input for ePBS. But I also would want client devs to actually look into the impl so that they get an actual feeling on complexity
01:16:17
Ansgar Dietrichs:Replying to "agreed the CL can he..."
I think we need to start focusing more on the actual users, not the infrastructure layer
01:16:22
potuz:I urge people that work on both sides to look into it
01:16:29
stokes:https://ethereum-magicians.org/t/h-star-name-for-consensus-layer-upgrade-after-glamsterdam/24298
01:16:37
Ansgar Dietrichs:Replying to "agreed the CL can he..."
of course always important to go talk to infra layer about what is feasible
01:17:09
Storm Slivkoff:Replying to "LIDO, RocketPool, ho..."
There are impacts throughout the protocol. Stakes are not the only relevant audience
01:17:11
potuz:Replying to "agreed the CL can he..."
yeah, but actual users won't really be much affected by ePBS. FOCIL is more nuanced
01:17:21
potuz:Replying to "agreed the CL can he..."
except the scaling properties I guess
01:17:24
terence:Replying to "LIDO, RocketPool, ho..."
Pref conf gateway as well
01:17:39
potuz:Replying to "LIDO, RocketPool, ho..."
I barely mentioned stakers
01:17:40
Sam Jernigan:bye