stokes:Okay, thanks. Everyone.
Transcript
stokes:Welcome to Acdc. This is call number 1, 6, 1.
stokes:It is issue 1614, and the consensus as well. Sorry. The Pm repo.
stokes:So
stokes:let's go ahead and get started today we'll cover Fusaka some glam things. And then there was a spec question that we can get to at the end of the call. So
stokes:1st up with Fusaka.
stokes:I think. Devnet 2 is pretty much done at this point. Are there any open points there that we need to discuss. We've pretty much moved on to Devnet 3.
Barnabas:Yeah, maybe 1 point to mention that we are running different kind of think test scenarios. And we saw that load star is having issues syncing up and never mind to have some issues syncing up
Barnabas:multiple times multiple different days when we tested, never mind, was always struggling to sync up in like 2 h.
Barnabas:The head of the chain and loads are seem to get rate limited.
stokes:Okay, interesting. And you suspect this is because of the higher block. Count.
Barnabas:I think lots are is already aware of the issue of getting really limited.
Barnabas:because they don't do backfilling. I don't see that this would be an issue.
Barnabas:I'm not really sure what the issues on the domain side.
Barnabas:I would have to investigate that further.
stokes:Right.
stokes:Thanks.
stokes:Cool then. If that's it for Devnet 2, we'll move to Devnet 3 which had Genesis yesterday about 24 h ago.
stokes:and let me see.
stokes:we haven't quite worked to full yet. But yeah, it says here in just under 4 h.
stokes:So yeah, anything to report on Devnet 3. Then
stokes:I think the fun will begin. Once we've worked with Hulu.
Barnabas:Right in interrupt. I have basically the quick update the Cgc value seem to be all right now on this side and on the side
Barnabas:basically, the only thing we could check is the did config
Barnabas:the new vip that we have decided to add. And there are some issues there. But I've pinged everyone regarding that.
stokes:Okay, thanks.
stokes:So yeah. Then, Devnet 3 will fork to furloo soon. And yeah, I expect. Then by next Monday, with acdt, we'll have plenty to discuss
stokes:anything else on Devnet 3 for the moment, or any Osaka things generally.
Barnabas:Now we are working on the Mev workflow. Hopefully.
Barnabas:either today or tomorrow, we can figure it out.
stokes:And that's just using.
stokes:You wouldn't know if that's using this new V 2 endpoint. Do you.
Barnabas:Good.
stokes:There is a spec change in Devnet 3. To have this v. 2. Endpoint.
Barnabas:Yeah, yeah, so that that is there already.
stokes:Alright, cool.
Barnabas:Also, I'm not sure which. Cl, we support that on 3, right after the phone.
stokes:Yeah, it might take some time.
stokes:Yeah, I'm not sure implemented.
Barnabas:Right now. We are still trying to test the lecture with the latest trenches, and that seems to be breaking at this point also.
stokes:Oh, interesting. Okay, well, that's that's exciting.
stokes:Cool. Okay.
stokes:then, yeah, there's nothing else. Simply soccer, then. So I did want to kind of just reassert this
stokes:We had looked a bit at timelines on Acde last week, and you know, one way to think about this is
stokes:having Devnet 3 up this week.
stokes:Hopefully, things are stable and good assuming they are, we can then turn to hardening everything.
stokes:There was a timeline that basically gave us end of August to do all of that work, and then we could start having release candidates out by the end of August. To then think about moving, to test nuts and then ultimately, Mainnet.
stokes:So
stokes:I kind of just wanted to bring this up again. Just, you know, the more time is repeated, I think the better. So it's on every in everyone's mind.
stokes:And I believe the outcome of this last week was, yeah. People thought this was perhaps an ambitious timeline, but generally, you know, it wasn't impossible. So
stokes:let's I'll try to work under that framework.
stokes:And
stokes:okay, if that's it on Fusaka, I guess we're just kind of waiting on that 3 at this point.
stokes:Yeah. Barnabas.
Barnabas:Yeah, just one more thing that
Barnabas:In the next few hours I will enable a rate limiter on all the full nodes. And we gonna have, basically a hundred megabits down and 50 megabits up on every single full node.
Barnabas:We have about 70%
Barnabas:full nodes and 30% super nodes. Super nodes will not have any rate limiting.
stokes:Okay.
Barnabas:And this will not have 10 gig connection. So maybe we can
Barnabas:really limited to one gig to be a bit more realistic.
stokes:Okay, interesting.
stokes:And this is the new profile from previous sorry devnets.
Barnabas:Yeah, previous devots didn't have any rate limiting.
stokes:Okay, we'll see what that does to things. Hopefully, it doesn't break anything.
stokes:Okay?
stokes:So
stokes:yeah, just to touch on post this comment here in the chat. Yeah. So when I said, release candidates, I mean, more like things we go for test nuts.
stokes:Mainnet, would. Yeah, you know, assuming there's like minor things we see in the test nets, you know. Obviously, we'd fix those in those releases
stokes:hopefully, we can get to, you know, one test nut fork, where nothing needs to change. That then becomes the main net
stokes:release. And yeah, per, the security sort of procedure that we had. Ultimately, yeah, we want 30 days in between
stokes:that and the actual main net date. So
stokes:that is the rubric we're working under. And again, timelines will be tight but let's try to make it happen.
stokes:and maybe just to reiterate, if we do this according to this sketch of a plan, then you know we can hit Usaka Mainnet before death connect, which would be very good.
stokes:So I think that's all I have to say about that.
stokes:And if that's the case. Then, yeah, I think that wraps up Fusaka. Then. So again, just everyone be watching Devnet 3. And I'm sure once the fork happens, there'll be more to discuss
stokes:in that case.
stokes:We'll turn to Glamsterdam. And yeah, it might be a short call today, we'll see. So the main thing here is talking about headliners.
stokes:So what we had said is essentially, you know, picking one eip per layer that is the headliner for the fork
stokes:we've moved ahead with the scoping discussions now, so that we can kind of paralyze things.
stokes:Yes, we're working on Pisaka. But also, you know, we can work on Glenstream in parallel, and this should give us a faster sort of shipping velocity overall.
stokes:So
stokes:in that case, we're currently in the phase of Glamster, Glamsterdam, scoping where we need to select a headliner. So
stokes:we touched on someone in the last call. You know, there are some obvious
stokes:candidates here again, I think Eps is essentially a crowd favorite, at least among core developers.
stokes:So before we get into that, there were a few updates that people wanted to give on different eips. So let's look at those, and then we can turn to discussing selection
stokes:so to kick off that first, st I think, Maria, I wanted to give a quick update on shorter slot times.
stokes:I think, yeah, you're here, Maria.
Maria:Yes, I'm here, so I will just quickly share my screen. Then we can start.
stokes:Okay.
Maria:Be sorry.
Maria:Okay.
Maria:okay, so I'll try to quickly go through this. So we have some time for comments and discussions. So this is just some initial results on slot timings.
Maria:And I need to highlight that. There's no report yet. So this is just early results and early plots, and we do still have a lot to look into, but I think it's already valuable to to share on this venue.
Maria:and just so we know what we are talking about. I just want to highlight exactly what we are measuring here. So the 1st thing is, one of the metrics we are looking at is lock arrivals
Maria:minus the publishing time from relays. So here we are essentially trying to estimate the block propagation excluding timing games, so we don't assume from 0 seconds, because then again, we would be exposing or taking into consideration the timing games. But we are trying to kind of exclude that part by looking at the difference between. And when the block arrived and the publish time by the relay.
Maria:the second thing we are looking at. Is the attestation arrival minus the same relay publishing time. And so here this will include both the block propagation, block execution and validation, and then the attestation propagation. Okay?
Maria:again excluding the the timing games, and then, just for the attestation propagation, we will be looking at the attestation arrivals for me slots, because for those we know that they only start propagation at second 4, and so we can do the times in second 4. And so we can have a sense of just the
Maria:attestation propagation. So excluding the block propagation and execution and validation.
Maria:Okay, so in terms of data sources, we are using data from Chatu which is a data set maintained by the and the Ops team. And they did a recent update on their data set where they did a fork on the on the prize client. And this allows us to collect data from the P. 2 P. Layer.
Maria:and they deployed 3 nodes per location. So we have San Francisco, Amsterdam, Bangalo, Bangalore, and Chile and these nodes are only subscribed to 2 subnets or 2 committees. And the reason for this is that we noticed that when we were
Maria:seeing the data from the older notes that were subscribed to all committees, and their timings were actually much slower than just the ones that were subscribed to just 2 committees. And so this is a much more realistic view on what the normal validator would observe.
Maria:We also look at block events. And so for the attestations, we only have the sleep data set. But for the block events, we also look into. An additional data set that chateau has that is contributed by the community. So this allows us to get a much wider view on different locations and also different.
Maria:And also we got the block publishing times by ultrasound relay. So our data is only looking at the blocks that were provided by ultrasound which is already a sort of a
Maria:you can say that is a sort of biased sample. But we are working also to get more information from other relays.
Maria:Okay, so very quickly showing some initial plots. So this is the block propagation for the Li. P, 2 P data set, though. So it's those 3 nodes per location that are maintained by the Ops team.
Maria:And here, I'm showing the distribution for the different locations and also the 95 percentiles. And so we can see that they are all under one second. The I mean the 95 percentiles. And Australia is the the slowest location.
Maria:I need to highlight here that
Maria:these are nodes that have high bandwidth. And so we should
Maria:most likely seen other nodes that they have a lower bandwidth. The timings might be different, and and also this is just that that sample from blocks that were distributed by the ultrasound relay. So there will be already some skew there.
Maria:and this is the the same metric. So block propagation. Since the publishing by the relay. But now using the community notes.
Maria:So here you see much more wider selection of locations, and this we do see some variation between different locations. Some of them are really big outliers, so this could be some issues in the data and we can see that the 95 percentile is is significantly higher. So this is something that we want to investigate more and understand what, what.
Maria:why we have or what is leading to these slower numbers. But again, I should highlight that this is just a data set that is contributed by the community. We are not collecting any data on who the validators are, nor if this data is collective with high feasibility. So
Maria:it's more prone to errors than the previous data set.
Maria:And now we are moving to the attestation. So again, this is the So
Maria:here. What I'm what I'm what I'm showing is for each committee. Okay? So for each subnet I'm looking at when the attestation arrive.
Maria:So we are receiving at stations. Right? We are observing the at stations arriving from that subcommittee.
Maria:And I, I'm recording the percentile of at station. So on the 1st plot. I'm showing the percentile 65. So you could think of this as like a super majority within the within the committee. And then the 95 percentile. So 95% of the attestations that would be shared within that committee
Maria:within that community. Arrived at that time. And here we see the full distribution across the various slots and the various
Maria:committees and notes.
Maria:And I'm also showing here the percentiles.
Maria:So this is the 95 percentiles of the 2 metrics, which is the metric for the p. 65, which is the 65 percentile within the committee and the 95 percentile within the committee.
Maria:And an interesting thing here is that the for the 95 percentile. This is right below what? The
Maria:what the new proposal for shorter slot times would require.
Maria:And this is already you could say, like an extreme metric, because we are taking
Maria:the 95%. I love the 95%.
Maria:So yeah, it's, I think it's. It's interesting. Also, we can see sort of like 2 modes in the distribution where we see some at stations kind of arriving much earlier, and then you have a second sale of of the stations arriving a bit later.
Maria:Again, I should highlight. This has the same issues that as the as the data sets from the blocks that I showed before, so we do are seeing these from high bandwidth nodes. And also this is already blocks that are distributed by a relay. So there there will be some some bias there.
Maria:Then, for the pure attestation propagation. So this is the the the metric where we are looking at just missed slots.
Maria:Here. I'm showing the full attestation. Cdf function. So this is for each nose when they are seeing each level, each percentage of attestations. Within their committee.
Maria:And here I'm also highlighting the point where the.
Caleb:Where we.
Maria:Can see sort of a shift in the in the distribution. So we do see that some
Maria:until second 1.5 we see a big majority of attestations coming in. And then after that, the last 10% is actually taking a bit longer. And this is also another point that we want to investigate next and understand what is causing these arrivals.
Maria:And again, I should highlight. This is still a small sample. And we might see. So the fact that we are using Miss Slots may actually lead to these numbers looking a bit worse than a normal
Maria:slot, let's say because all that stations are coming at second, or we do have a a sort of a bigger pressure on the bandwidth side than if there was a normal slot, where at the stations would come a bit slower throughout the the 4 second mark and so there there might be here some delays related to concentration of of the
Maria:at the stations.
Maria:And so just to give you an overview. So going back to that image of the slot that I was showing you. So we do see that for the block propagation, for the for the nodes that are maintained by Pendops. We do see a good a good 95 percentile which would if
Maria:time
Maria:to implement this, this change for the communities nodes, we are seeing larger percentiles. But I think this is something we also want to investigate more. Understand? Why is that and also is something we can tweak because we can this block propagation is something we can control with the with the block size
Maria:and then for the full time that connects propagation execution and at station we do see that the the 95 percentile of the 95 percentile within the committee is perfectly within the the proposal. So this is already
Maria:let's say, like a a positive sign. And for just the attestation is
Maria:I I think it's still something we need to analyze a bit further. So first, st because we are using the Miss Slots. There, there will be some some noise there. And also we want to understand what is happening to those last 10% that are coming a bit slower.
Maria:In terms of next steps. So we will collect more data again, this is just preliminary results. So we want to collect more data from other relays. it's been, the Ops team is also working on collecting community data for attestation. So we can have a sense of the difference between analyzing their nodes that are
Maria:well connected to a more varied sample of notes and also gathering bigger samples in terms of additional analysis. We will look also at Blobs because we haven't. We were just focusing on on block arrivals. Also, we want to look at aggregations.
Maria:and then investigate arrivals for locally built blocks. And also investigate arrivals for small blocks. So the idea here is to understand how block size and gas use affect both the block propagation and execution times, and finally also investigate the late arrivals and understand what factors are. Con are contributing to that. Maybe it's something that we can fix or is something that is
Maria:that depends on on the network itself. And it's not something we can change. So it's it's 1 thing that we we want to look at.
Maria:So I know this was very fast, so I was trying to to keep within time. But if there are any questions or comments I'm happy to
Maria:to go through them.
Maria:I'm not sure if we have time. But thank you.
stokes:Cool. Thanks. Maria Terrence has had his hand up.
terence:Yeah, I just had a comment. And the question, I guess the comment I had was like something I zoom from Zato or just from personal experience is that like when we, I can speak for prison when we send data to Zato, those data are already validated on the Ptp layer, even though, like
terence:there is an inherent like a small delay there. So you'll be worth to measure what that delay is when we verify something, and then send to Zato, and also the latency. How much like it? By what like? Basically, what is the delay for the, for the, for the, for the transmission? As well, for the data is, send it to Zato. I think those 2 have a small delay there. You'll be good to
terence:have those numbers, I guess. And then the question I had is on the the decision slide.
terence:We have p. 95, and there was something about like 4 seconds, and that is when the block is arrived. Right? Versus. So so, yeah, so for this slide.
terence:The 4, yeah, the 4. So the 4 seconds. So that is calculated. When the block is arrived versus the star of the slot, right.
Maria:Right? Right? So it's not when the block arrives is mostly on. So let let me just get get back to that image which is so, we are getting the time from when the block is published by the relay. Okay, and this is the time that we are discounting. So we essentially are considering the yellow, the pink, and the blue in those 4 seconds.
Maria:So it is like, you are sort of excluding the timing games. But you are still including the block, propagation, execution, and validation, and then the attestation, propagation.
terence:And that is, and that, and that is not a steep slot, and that is the slot that has a block of of the current slot right.
Maria:Exactly so. The for for the Miss Slots is this plot here, for these distributions is just all this, like the sample of slots we had that were relay, ultrasound relay
Maria:blocks.
terence:Okay, that's something that's interesting is in prison in the next release will actually attest timely by default, meaning that we will not wait for the 4 second to set up the station, so the number may be slightly better using the prison for the next release. So something to monitor again. Maybe in the next few weeks. Yeah.
Maria:Yeah, yeah, 100%. That's that's a good point.
stokes:Cool
Toni Wahrstätter:Maybe even then, even then we would rely on on notes updating. So I think from next time we should
Toni Wahrstätter:stick to getting data from relays might be more reliable than
Toni Wahrstätter:assuming everyone. Updates and people are testing in time.
stokes:Mark, you have your hand up.
ethDreamer (Mark):Oh, sorry I was unmuted. Yeah. So based on the I, someone correct me. If I'm wrong, it's just
ethDreamer (Mark):based on the numbers you had here. It doesn't
ethDreamer (Mark):feel like there's a lot of slack left in the slot. Honestly, you've got. It looks like over 6 seconds is just being used for attestation, propagation aggregation and propagating the aggregates so
ethDreamer (Mark):like, I don't know this to me, would suggest that we
ethDreamer (Mark):we couldn't get the slot time down to 6 seconds without some kind of pipelining. But am I interpreting these numbers wrong like? How would we do this?
Maria:Doesn't
Maria:doesn't seem to me that is not possible. So we we so in the new proposal, the deadline for the aggregations would be 4.5 seconds.
Maria:And, as I was saying, like this is already a sort of ex extreme metric, because it's a 95 percentile of a 95 percentile. So probably you don't need like the 95,
Maria:you don't need 95% of the notes within your committee to see
Maria:95% of authorizations. Maybe you just need like
Maria:for aggregators to see it. And so
Maria:yeah, so I, this to me is actually like a
Maria:something that seems exciting is like even in an extreme metric. This already seems really nice. I think now, is a is A is a point of collecting more data, making sure that these numbers are correct.
Maria:And yeah, then look also at the at the station aggregation part that we haven't looked into to make sure that it fits and also to understand the factors that may be causing delays because there are some things that we could change. So, for instance, if we
Maria:reduce slot times by half. Maybe it makes sense to also reduce the the gas limit by half, and then this means that the ex, both execution and propagation might also reduce a little bit.
Maria:so yeah, does this make sense or or or not?
ethDreamer (Mark):Well, are you saying that maybe we could cut? Okay. So let's say, we cut propagation execution both in half. And then you're saying we we might be able to cut down
ethDreamer (Mark):the attestation aggregation by maybe. How much like it it seems like a
ethDreamer (Mark):and then you have. You still have at statistic propagation it which I can't see being any faster. Really, I don't know how you'd make that faster, but.
Maria:Yeah. So what I'm saying is like for the at the station aggregation, we still need to look into it. So I'm I don't know the timings yet, but for the 1st part, which is the part that should fit within the 4.5 seconds, it seems to be pretty.
Maria:seems to be looking in a good way. We just need to dig a bit deeper there and and make sure that the that the numbers make sense.
ethDreamer (Mark):Okay. So you are still hopeful that we could get it down to 6 seconds. Then.
Maria:From the daytime scene. Yes, we might discover
Maria:new things down the line, but so far yes.
Maria:again I I think to
Maria:to me. The most compelling thing is like this, p. 95, of the p. 95, below the 4.5 seconds. I think it's pretty compelling.
Maria:and then again, we need to look at the aggregation part that we haven't yet. But yeah, I'm I think I'm optimistic.
stokes:Barnaba, you've had your hand up.
Barnabé Monnot:Yeah, I guess this is more my interpretation, and possibly different from Maya's own. But looking at these numbers, I don't think it proves that we can't do 6 seconds. But it
Barnabé Monnot:maybe says that. Yeah, it's first, st we need better ways to measure all these things like to increase our confidence on these numbers. And, second, we should also be looking into optimizations as they are available, and I will also say that if we buy the story of
Barnabé Monnot:restructuring the slot first, st and then we can easily do 6 seconds. I actually don't think it's still easy, like, even if we do epbs putting the attestation deadline. I think the number I saw was 1.5 seconds means we have 4.5 seconds to do attestation and aggregation. It's a bit better than 6 seconds with the current slot architecture. But it's still yeah, probably challenging.
Barnabé Monnot:I share with my optimism that I think the numbers are are not like ruling out that it's possible. But I do think we need to do more work on validating them 1st and then figuring out optimizations to increase our confidence.
stokes:Okay.
stokes:Any other questions or comments?
stokes:If not, thank you, Maria.
stokes:and we can go to the next bit here. So that was shorter slot times. Which was one of the headliner proposals.
stokes:and another one that we're all familiar with is egps
stokes:on this Christoph and Bruno from flashbots wanted to give an update on their work. They're calling this particular part of the design the free option problem in epbs.
stokes:I assume one of them is on the call.
Christoph Schlegel:Most of them. Yeah.
stokes:Oh! Hey!
Christoph Schlegel:Okay?
Christoph Schlegel:right? So epbs, free option problems. So what is a free option problem? And why should you care?
Christoph Schlegel:has to do with basically this?
Christoph Schlegel:this optionality of of a winning builder in
Christoph Schlegel:in block building, auction to invalidate their block if they're not happy
Christoph Schlegel:with sort of how the world evolved in the meantime, and there is a difference between difference in time between when they commit to a block. And
Christoph Schlegel:so you have a time window after that to invalidate
Christoph Schlegel:the block if if they wish to do so, and they would forego sort of the gains that's in the bit that they made and the
Christoph Schlegel:maybe also option. But otherwise they would. Yeah.
Christoph Schlegel:post. Basically, it's equivalent to posting an empty block.
Christoph Schlegel:So how how is this
Christoph Schlegel:turning out in reality. So epbs has 2 payload timeliness committee deadlines
Christoph Schlegel:which you could put use both actually to to invalidate the block. So you have, you could fail to
Christoph Schlegel:send the payload in time as as a builder.
Christoph Schlegel:or, what is actually the more valuable option is to you, could fail to to send some blob.
Christoph Schlegel:and that is the second deadline, and since the entire design is sort of meant as a pipelining
Christoph Schlegel:sort of architecture where we postpone blobs to the end of the slot. Right? That gives you
Christoph Schlegel:a bunch of time to actually wait for this last deadline for the blobs.
Christoph Schlegel:Wait whether something happens that is informative to you, and that usually is about trading financial information. And then you could sort of choose to to not send a blob.
Christoph Schlegel:it's about 8 seconds. And so if you want to take away one thing from from this presentation, 8 seconds is a lot.
Christoph Schlegel:8 seconds is a lot, and that gives you possibly a lot of value to this option.
Christoph Schlegel:Aside, as I think, or Spurtus made this point to me, and I now agree with him philosophically. So it's a problem, not not about it's a problem of epbs, but it's more like the feature of pipelining right? So that the fact that you give ample room for propagation of blobs and see if there's a different timelines, so that the fact that you can basically trigger invalidation of the block
Christoph Schlegel:by failing to to submit a blob right, and that would probably be true for sort of other other designs that would have this pipeline feature.
Christoph Schlegel:So what we did in this thing, and that is ongoing research. But so we want to do more on that. But we tried to figure out how valuable. This option is
Christoph Schlegel:so, and sort of the Tldr is okay, probably very valuable in some some sense. And it creates a bad form of Mev, right? So you basically create the form of Mev, where, if you exploit the Mev, in some cases you produce empty blocks, and that has a negative externality on everybody else wanted to put the transactions in in the block.
Christoph Schlegel:so it's potentially substantial. It is also the value of the option is increasing in volatility and increasing in liquidity on chain. So what does it mean? In plain English, so increasing in volatility means that sort of the option is triggered asymmetrically so. There might be some days where a lot of things happen in the world. And then, basically, you have a lot of empty blocks suddenly in these days, because there's a lot of volatility. Some some days nothing.
Christoph Schlegel:Nothing important happens. And so he was observed less frequently.
Christoph Schlegel:and increasing in liquidity means, if
Christoph Schlegel:ethereum is able to attract a lot of, you know, financial activity more so than the current. It currently does. Actually, the problem becomes worse, right? So it becomes worse with with scaling financial activity.
Christoph Schlegel:And yeah, volatility is increasing in in the time window as well. And that is sort of the reason why the longer you have the pre auction window, the worse it becomes. And well, as I said, the punchline is 8 seconds is probably bad.
Christoph Schlegel:And actually bad. Why? Because it's sort of
Christoph Schlegel:the mental model that you could have is sort of this length of this free option value relative to the slot length that matters right. If if sort of the free option window is sort of as here, it's 3 quarters of the slot length. That is a lot right. It would be less of a problem, it would be one half, it would be less of a problem. It would be 1 3.rd The point is sort of it doesn't disappear when you mix
Christoph Schlegel:slots shorter if sort of the relative fractions remain the same.
Christoph Schlegel:Okay, so that's that's the thing. We try to
Christoph Schlegel:bit. Do a bit of like mix of theoretical analysis and empirical analysis. That is sort of very preliminary. We want to do it
Christoph Schlegel:because empirical analysis is mostly on on binance data. So because on chain trading data is messy, we want to extend it to that. But I can tell you what is is going on with that.
Christoph Schlegel:We also have some potential mitigations that I think Bruno wants to tell you about. One other sort of interesting punchline is, so I think for me, at least, it's an interesting punchline. So the problem also becomes worse if we make on-chain trading better in some sense, right? If we reduce the Mev.
Christoph Schlegel:On, on chain per unit of liquidity deployed on chain. So if sort of it makes the trading leak less mev right, we solve sandwiching, or we we solve.
Christoph Schlegel:So this this problem of basically stale liquidity being or liquidity being placed at stale prices right to better Amm design. So if he makes the on-chain trading experience. Better sort of weirdly, the option becomes more attractive. That is basically because you give up. If you exercise the option you give up on mev right in in a time. Window
Christoph Schlegel:in order to, you know, exercise the option right? So you give up sort of the block values that that you would otherwise have captured or part of the block value. That's 1 of the way of thinking about it.
Christoph Schlegel:Okay.
Christoph Schlegel:that's a deal. Yeah. I want to explain. It was a mental model of poker that was taken, or this is from Eccan. So there was a casino which was conveniently located next to the Con convention center for Ecc.
Christoph Schlegel:So here's 1 mental model that you could have. So suppose you would play roulette right? Usually, that's not a good idea because you lose. But now you have the options that you can sort of
Christoph Schlegel:revert the spin of the roulette wheel if you don't like the outcome. Right? So that's that's that's the option the kind of option that you would have right. So you spin the roulette wheel, and then it's black, and you bet on red, then
Christoph Schlegel:you revert it. Suppose you have that option? Right? So what is the value of that option? And basically it depends on the maximal bet you can take in the Casino. So whatever allows you, the the Casino allows you to bet on this roulette wheel that is sort of the value of the option. Right? Half of that is the value of the option. Okay? So you can take
Christoph Schlegel:and that bounce, bounce, bounce the value of that option. That
Christoph Schlegel:sort of the interesting thing is, if you translate it into finance is basically the option scales with liquidity. Right? So the more liquidity you can place in the market there is in the market, so that you can place larger bets in the market. So where the option problem becomes.
Christoph Schlegel:And we looked into binance data as a. As I said, so we looked into what happens. For example, if you trade 1 1 million notional on on binance in 8 seconds intervals, and you would would have the
Christoph Schlegel:It's the option to reverse a trade if you don't don't like the outcome. So that is the return distribution. So you get somewhere between
Christoph Schlegel:a thousand and a minus 1,000 on those on those
Christoph Schlegel:on those bets right? Betting 1 million on ethereum going up or down.
Christoph Schlegel:So it's much much lower AV per unit of of of liquidity than in the Casino. Right there. It's coin flip, basically. So you get 50% in the Casino. But here in binance, because the price of East does move
Christoph Schlegel:that much, it moves maybe one basis point per 8 8 seconds approximately. So you get on 1 million bed size. You get about. We have between a thousand and minus 1,000. And on average, you get
Christoph Schlegel:what was it?
Christoph Schlegel:200 300, something like this?
Christoph Schlegel:But the interesting thing is with the option, you can basically eliminate the bad cases right? So you don't get the minus 1,000. You don't get the minus 500. You don't get the minus 250. You only get everything to the right of 0, or if you want to bet on East going down, it's sort of almost symmetric. You can also get the left hand side and then multiply by minus one.
Christoph Schlegel:So that's that's sort of
Christoph Schlegel:binance is a casino, just with a lower, you know. Return on each each spin. But
Christoph Schlegel:and the amount of liquidity that you can bet is basically
Christoph Schlegel:how much you should value the option. Okay? Then we looked into how? How would that look like if we would have binance level liquidity on ecusdc pair.
Christoph Schlegel:and then you get something like this. So you get upward sloping curve. So the longest sort of this option window is the more value that you can make. So the right hand side curve, I think, is more interesting. So that's the absolute.
Christoph Schlegel:absolute value of the return. So you get half of that right. If if it's a coin flip, whether it goes up or down
Christoph Schlegel:right, and then you see, with 8 seconds. For example, a bit above
Christoph Schlegel:200. You get half of that. So you get 118 Us. Dollar per spin on average.
Christoph Schlegel:on on binance. That's 1.2 million per day, approximately 1.3 million. Okay, so that's that's the order of magnitude. If you would have binance size, liquidity on ethereum. l. 1 which you don't have right? I think it's off by a factor, 10 or whatever.
Christoph Schlegel:But then also that is only 1 1 pair. Right? So you can also, I mean, if you have this option, you can trade many roulette wheels at the same time. Right? You can bet on on ease. You can bet on on Bitcoin. You can bet on everything. You have many correlated bets, right? So you can pump it up so the mental model that you should have is right.
Christoph Schlegel:Everything that you can trade, basically with good liquidity. Where you have very low slippage.
Christoph Schlegel:put put a bet, put a bet in there and then. Yeah.
Christoph Schlegel:takes a chance. And if you lose out on on the value, if this is the other way, then you can revert it right right, and that gives you the sort of magnitude of of gains which I think is substantial.
Christoph Schlegel:And so in theory, value is higher. If there's more liquidity. Right? I think that is clear. So if I can trade not only 1 million notional on binance with almost 0 slippage, but 2 million notional, with almost 0 slippage. Then I just double my gains right in ethereum world. If you could.
Christoph Schlegel:we attract twice as much liquidity. You make this problem.
Christoph Schlegel:Maybe
Christoph Schlegel:so the value of the option you make double, but then you also maybe increase the cost of exercising the option. Right? So that's that's
Christoph Schlegel:it's a mixed bag. But I would say, if you increase liquidity directionally, it would increase a problem.
Christoph Schlegel:and it's a function of volatility, right? So if you can trade meme coins. Maybe you get lower liquidity on those, but get per spin. You get more right. You can bet less on the roulette wheel, but you get get more per spin right? And that that scales it as well.
Christoph Schlegel:And one sort of very crude way of approximating how bad the problem is. You could say, okay, this free option gives you about half of the arbitrage that a builder could make
Christoph Schlegel:if he would be able to
Christoph Schlegel:place the bed top of block the the order top of block
Christoph Schlegel:over 8 second slot time blocks in this kind of actual world, so you can get about half half of the value, not quite half of the value, but approximately half of that value.
Christoph Schlegel:And then
Christoph Schlegel:then that gives you a sort of a very crude way of approximate approximating it would look like, don't, don't you know? Don't take the takeaway of this slide is not. Don't take those probabilities literally. But I mean,
Christoph Schlegel:philosophically, those are the kind of effects that you should expect. Right? So you you have increasing probability of option exercise, and if you have increasing
Christoph Schlegel:exercise window, right?
Christoph Schlegel:And that is basically, if you have it.
Christoph Schlegel:do it with this heuristic that you say, okay.
Christoph Schlegel:you can capture approximately half of the arbitrage gains that you could capture. In the conventional Mev way you can capture with the option. Then you get this kind of competitive settings. On the other hand, this is normal, normally distributed returns. So if they're fat tails, actually, this becomes more extreme, right? So you get high probabilities. And then the 2 curves tell you. Okay, it makes a difference whether
Christoph Schlegel:actually sort of the Mev scales linearly with time, probably less than linearly with slot time. Or
Christoph Schlegel:it probably scales a bit more than square root
Christoph Schlegel:block time. But you get substantial probabilities with this napkin map
Christoph Schlegel:model right? And sort of the other other thing to highlight. This is, of course, a very stupid. It's very straightforward and stupid strategy. Right? You just
Christoph Schlegel:take a bet, and then if the bet doesn't turn out well, you you
Christoph Schlegel:where you basically exercise the option. So you could run more sophisticated strategies probably make more. But sort of you you get these numbers. Right? So you get anywhere between 5 and 10%
Christoph Schlegel:exercise probability on these things.
Christoph Schlegel:Right? So we need would need to calibrate this more with actual data. Another data point, which is more like anecdotal. So we we also ask a searcher from from scp. I mean how he would think about this option, he says, Okay, that's very valuable. You could expect at least 10% of blocks where where this option is exercised. Assuming right? All of these, you know.
Christoph Schlegel:and assuming away. All of
Christoph Schlegel:builders, want or builders, of course, want to be well behaved right. They might not exercise that option because of social slash, slashing reason, or because they are
Christoph Schlegel:block listed by by validators if they do that so often. But assuming away all of those things north of 10%
Christoph Schlegel:probability of exercising option when we have this
Christoph Schlegel:this kind of 8 8 seconds option time window. So it's substantial. And we should be aware of that. And it scales very badly. Right? If ethereum becomes more successful, the problem gets worse.
Christoph Schlegel:Okay, Brunan, do you want to talk a bit about potential solutions.
Bruno Mazorra:Yeah, sure. So, okay, potential solutions. I'm.
stokes:Sorry. Just one sort of orchestration point. Let's try to move through these slides faster rather than slower.
Bruno Mazorra:Sorry, what.
stokes:Let's just try to get to these slides so we can get to other things on the agenda today.
Bruno Mazorra:Okay, essentially, yeah, we have
Bruno Mazorra:3 sets of solutions. So slashing. Shortening the free option window and block listing.
Bruno Mazorra:I think the most reasonable one is shorting free option window. But that could have other effects that we don't know of. Additional slashing, of course.
Bruno Mazorra:essentially like can increase the barriers of entries. And so that's not good, but also like, will decrease
Bruno Mazorra:the optional value, and of course, also the the probability of exercising it.
Bruno Mazorra:Also, we think, like block listing is not the right solution. Because, yeah, we want a permissionless
Bruno Mazorra:boulder market. And either we will have civils or we will make it permission it when we are block listing, because we think these opportunities will be exercised more by
Bruno Mazorra:solo searchers, building blocks and actually like blog builders that try to acquire order, flow.
Bruno Mazorra:And then there is like a potential 4th solution that I am.
Bruno Mazorra:We should be thinking more about. It is essentially making blobs totally separated objects from transactions.
Bruno Mazorra:and essentially having completely independent inclusion and
Bruno Mazorra:free markets process so that could be some ideas.
Bruno Mazorra:I don't know if we have more time.
stokes:Were there more slides?
stokes:Yeah, it seems like it stopped.
stokes:Yeah. In that case, I guess, are there? Maybe one or 2 follow up questions. There are a lot of conversations in the chat. It's gonna be hard to summarize them all.
stokes:Yeah, Mark.
ethDreamer (Mark):Yeah, I would say, with regard to
ethDreamer (Mark):the like increasing the penalty like the only that that seems like a fine solution. But the the worry that we would have here is that people go and they try to do this with solo staking and off train relays, and if that was ha happened. Then we would have to impose this on
ethDreamer (Mark):solo stakers, and that would only impact like solo staking self building validators. But we could even they would only get that penalty in like an unfair way, if basically, their node dies between publishing the beacon block and the execution payload, and we could presumably mitigate that by allowing them to publish the execution payload first.st They don't have to worry about the blob since they're self building, and they're already building publicly available blobs, anyway. So
ethDreamer (Mark):yeah, that was just a nuance. I wanted to point out that
ethDreamer (Mark):we could increase this penalty, and we could do things to try to make it so that no
ethDreamer (Mark):self-building solo staker would suffer this. That was honest.
ethDreamer (Mark):Yeah.
stokes:Okay, thanks. So yeah, maybe just summarize. There's this notion of the free option problem.
stokes:There are some solutions. It sounds like it might take a little more work to figure out the right way to frame 7, 7, 3, 2, which is the Pps IP. To mitigate them.
stokes:but it seems like there are some potential paths there.
stokes:Cool. Let's see one other point on this eap dap. Lion had a post that was relevant. Let's see, is he on the call.
stokes:I think? Oh, yeah, there you are. I don't know if you'd like to say anything definitely. If not, I can just grab a link to your post.
Lion dapplion:Yeah, I just, I agree with the slot restructuring part for the sake of scaling. And I was just
Lion dapplion:questioning the need to do the trust and trustless payment.
Lion dapplion:So at least I wanted to add the option
Lion dapplion:to the fore planning and to everyone that if we want to, we can do.
Lion dapplion:Eip. 7, 7, 3, 2, without the trustless payment, and I haven't found any obstacle to that path.
stokes:Okay, cool.
stokes:Sorry. I just responded in the chat. Just around like potential paths for mitigation. 3 option problem. I mean, it sounds like. There's, you know, for example, you could penalize the builder.
stokes:for not revealing something like this.
stokes:Yeah, rather than going further into that. Let's just leave that alone for now.
stokes:Okay.
stokes:So
stokes:if there were no other questions about that for the moment one other thing that came up so Christine Kim
stokes:had a community space yesterday, and she had some input from different community members.
stokes:I also am not sure if she's on the call. But let me grab a link to
stokes:her message. It was on the awkward as channel, so you probably saw it.
stokes:But, in short, why don't I just give a summary.
stokes:So sorry I lost the top. Okay?
stokes:Yeah. Support for some sort of pipeline in you know, Epbs could be a solution here.
stokes:Another support for 6 second slots just to improve ux.
stokes:and otherwise. Yeah, those are the main things there. So just consider that as plus ones for these proposals from the community.
stokes:There are some shout outs to forecast. And yeah, Christine will continue this process just to get input from different community members.
stokes:So I did want to bring that up. And from there. Okay, so
stokes:I think the way to proceed here.
stokes:yeah. And maybe we'll need to have a conversation about this. However, my read is given, yeah, different community inputs that we've gotten both core developer sentiment and also the relative progress of R&D on these different proposals.
stokes:It seems like Epbs is sort of the leading headliner candidates right now.
stokes:the way I propose to proceed is that we essentially like conditionally acknowledge this on today's call.
stokes:That, then, can be an input to acde next week.
stokes:And the reason we want to do that is because the headliners we pick here might also impact the of the headliners they pick on the Yale side. So we kind of have this
stokes:circular dependency, and seems like this is the right path forward.
stokes:Does that sound okay to everyone?
stokes:And maybe then, just to like round out the timing, say, we do this now, you know, given sort of another conditional act from Acd next week. Then we can go ahead and make the headliner decision
stokes:on the next Acdc. In 2 weeks.
stokes:Alright. Just ask, what do we sfy epbs? Let's see.
stokes:I'd want to think if we want to. Cfi versus Sfi just process wise. But essentially, yeah, like, we would say
stokes:that this would be the headliner selection for Glensterham on the Cl. Side.
stokes:Osgar asked a question. Would we explore Bill builder penalties. So yeah, at least, the way I see this shaping up is that
stokes:the selection for this process today and say over next call
stokes:would just be saying, this is what we intend to do.
stokes:I think, then, that lets people focus very precisely on just 7, 7, 3, 2. And there's a number of open questions there around. Yeah, things we want to improve or fix.
stokes:I think the IP can still evolve. But this is just again narrowing the scope rather than having this entire set of vips. We can then move to focus on just this one
stokes:mark.
ethDreamer (Mark):I'll let us go first.st Actually.
stokes:Okay.
Potuz:I just want to make a comment because I wrote it like 3 times on the chat. If you go on the computations of the free option problem lowering the size relative to the slot actually minimizes this issue. Like what it was like, it appears in a percentage of slots that this searcher builder would actually find it beneficial to exercise the option
Potuz:reduces that dramatically. If you make this this size window minimal.
Potuz:and it's not a feature of the commit reveal process of of
Potuz:of epbs. But it is a feature of the difference between the payload
Potuz:deadline and the blob deadline. If you make those too early, very early enough, so that the builder only has time to just reveal immediately the block. This problem disappears from Epbs, of course, at the cost of scaling, which is, which is the essential trade-off here.
Potuz:The deadline for blobs being late, is as late as we want is what we want on anything. This, this will happen on Aps. This will happen on any system that has a different deadline for execution and data.
Potuz:And we want these different deadlines for execution and data, because we need the end of the slot to execute the block or to prove the block in Zk, and we don't need this for broadcasting the data.
Potuz:So so that's that's what I meant. I mean, there's a way of making this disappear according to the computations themselves of Christops and company, which is just put those 2 deadlines together, and put them as immediately after the at station deadline. This makes the problem disappear, but then it also makes the scaling disappear. And this is the kind of things that we need to think about.
ethDreamer (Mark):Yeah, well, I guess I was next yeah. And
ethDreamer (Mark):I would say, like, maybe more precisely, it doesn't make the scaling disappear because you still have the ability to execute after the things are propagated? But it that we can't scale as much as we could, and wanted to point out that we are intending to shorten slots as soon as we can as well. And so
ethDreamer (Mark):if you actually shorten the slot, then if you're I mean.
ethDreamer (Mark):it sounds like the problem gets not less
ethDreamer (Mark):or harder to pull off or or not as bad. If you should. If you have a a smaller deadline, so like.
ethDreamer (Mark):If we if we are shortening the slots later, then we're gonna make this attack harder. But, as
ethDreamer (Mark):was pointed out, like, if things like liquidity and ethereum go up. This could be an issue. But
ethDreamer (Mark):yeah, I guess I just wanted to to point out that
ethDreamer (Mark):we are naturally going to lower these deadlines, and if if this is such a problem in Glamsterdam, we could set the Ptc. Deadline quite early to mitigate it. And then, later, when we shorten the slots, you know it won't have. We'll we'll still get a lot of these scaling
ethDreamer (Mark):benefits.
stokes:Thank God!
Dankrad Feist:Yeah, I wanted to quickly check that. You mentioned that both from community and core devs like, you see, the most support for epbs.
Dankrad Feist:I mean, I definitely see the core devs part. But I don't see the community part, I think, like in most
Dankrad Feist:most of what I've seen from the community clearly has 6 second slots ahead of Epbs. Can you clarify that where this impression comes from.
stokes:Yeah. So this is where it's kind of tricky mainly just different conversations, even on like Twitter that I've seen. So something that would help here is having like, yeah, more like.
stokes:I don't know if official is the right word. But having, like more written records that are easier to like index would be useful.
Dankrad Feist:Yeah, I mean, we we do have that right like, I mean, there was. They were the I don't know who made this like the headliner tier list, and I think, like I saw in the majority slot time slot times being at the top.
stokes:I saw something different. So
stokes:yeah, I think the way to proceed then would just be to again conditionally say, Pbs, looks like the favorite today.
stokes:We can take more time, even, you know, as of next Acd or or even the next Acdc call, we can revisit that and make another assessment.
Dankrad Feist:Okay, I mean, I would object to that based on like saying that this is the community opinion. This is not what I see.
stokes:Okay.
stokes:Hmm, okay, I will take a look. Try to compile some stuff. And yeah, if
stokes:if that's not the case, then definitely, I'll bring this up and we will incorporate that.
stokes:Okay, there's a lot of commentary in the chat. I don't know if anyone wants to speak up.
stokes:but essentially, I think, the next point. Then, there was a process suggestion here from Tim. So
stokes:I was trying to basically say, like, you know, give some positive signal of narrowing the scope, which again in my assessment, is Epps right now
stokes:one way we could do that is actually cfi it today and then move to Sfi on the next call.
stokes:I mean one thing with that is, you know, I think the Cfi gives people more confidence to be more fine grained with the different issues we see, there could be some problem where it's like, oh, actually, this is a bigger problem than we thought.
stokes:For example, more work on this reoption problem.
stokes:then it would be kind of weird, I think, to see if I or like essentially undo the sfi. So
stokes:again. If people want to do one or the other, we can.
stokes:It feels like we're a bit early to make that exact call today.
stokes:I don't know if you had more thoughts on that, Tim.
Tim Beiko:Yeah, I was literally just typing in the chat.
Tim Beiko:one other option today is like, it seems pretty apparent that the 3 main cl headliners that are like being considered, or epbs, 6 second slot times and fossil. So we could also just like, say that we cfi these 3. And then, yeah, on the next call, we're sort of making a decision. And if we went down that path it might be worth spending some time today getting some
Tim Beiko:some insight from Cordez on, like what they would like to see from these other proposals, especially given that like, there's a strong bias, at least on the court upside towards moving forward with epbs, like.
Tim Beiko:are there things that would change their mind? And what are those? So we get basically 2 weeks. Yeah.
Tim Beiko:yeah, 2 weeks to to address those things.
stokes:That's fair.
stokes:I mean, I guess a couple of things so Eps is, I think, relatively large in scope. Then from there I personally would have concerns about also doing fossil. But I think that's a conversation we should have.
stokes:6 second slots. Yeah, is interesting. And again, I'd love to hear any opinions from people here today.
stokes:My read is that you know, it's a compelling proposal. But the research and developments like, actually pretty early. But then, yeah, to Tim's point, you know, if any core dev would like to chime in here and say, what would help change your mind. That would be really useful, because then
stokes:we can go and do that work and bring it back to the next. You know, set of calls.
stokes:So does anyone have, like a concrete
stokes:set of data or analysis they like to see on 6 second slots
stokes:Grotus.
Potuz:Preston, I don't think he's here. I think he's busy, so I'll speak for him. I asked him how he's doing. Hopefully, he's gonna correct me if I said something wrong here. But Preston already has a proof of concept of a prison node that actually changes in a fork, and it manages to run even in cortosis up to one seconds block, of course, locally.
Potuz:So the the hard part of
Potuz:changing the slot duration is done.
Potuz:But of course it's not. I mean, it's a lot of work, but it's doable. He did it in a couple of months, I think.
Potuz:and still a lot of things are missing. A lot of things are broken like reorgan late blocks, a bunch of things that are like tied to the engine. Api are broken, or he has still some to do's in the list. But I think the major blocker for that Pr. Is the fact that it's not not even specified we are going to need to touch issuance, and that it I mean, he hasn't even looked into how hard that part would even be.
Potuz:We need to touch like at least the base reward. Make sure that just scaling the base reward is enough, and it's not really clear how invasive that change would be on top of the already working branch from Preston.
Potuz:but prison is has a prototype, and I think we can. We can easily add it later on on a later fork.
stokes:Ben.
Ben Adams:And so the the vibe I get is that both slot restructuring and
Ben Adams:shorter slots are desirable. And it's it's more of a sequencing question which goes first.st
Ben Adams:So my question for Epbf is, if that goes first, st
Ben Adams:what would be the slot? Time target as in? If we can do 6, if
Ben Adams:it's possible to do 6 seconds. Now.
Potuz:The numbers we got today of attestations are the bottleneck. I think it's probably not have to do with the Pbs itself. We need to figure out what to do with attestations and aggregation. I was counting with one second
Potuz:to get most attestations, and today we heard 4 seconds, so that changes dramatically my view of what the slot the shortest slot can be.
Potuz:I mean, I feel like, get those numbers.
Dankrad Feist:1st of all.
Potuz:Correct. It's strange.
Dankrad Feist:4 4 seconds is block propagation, execution plus attestation.
Dankrad Feist:Just so that you don't like misunderstand that.
Potuz:I thought it was A. P. 95, to get attestations from from Committee 0 and one. And it was p. 90.
Dankrad Feist:9, 1 9.
Potuz:4,100!
Potuz:Maria!
Maria:It is.
Potuz:You've.
Maria:Yeah, yeah, it is counted since the block was published by the relay. So it does include block propagation, execution, and validation. And then the at the stations itself.
Maria:So it's it's like.
Potuz:I see.
Maria:Were to do the 6 second slot, you would have.
Potuz:Okay, so I need to add.
Maria:For that.
Potuz:Yeah, so I need to
Potuz:kind of hard. Yeah. So then, it's kind of hard to measure. So in epbs, we were hoping to do this
Potuz:because the block propagation will become much shorter, so that number kind of is irrelevant for epbs, because the block in Epbs would be very, very small. It's only the consensus block and not the payload.
Ben Adams:Yeah. So would epbs. Would the slot time target
Ben Adams:be even shorter after Epps is my question, or would it be the same? The 6th
Ben Adams:doesn't, doesn't get us anything other than safety.
Potuz:I don't. I think the answer to that question is very simple. Whatever we do.
Potuz:we want to be in a situation in which the full slot is used, entire slot is used.
Potuz:and the minimum size of the slot that we can actually use is determined by broadcast and not by how you pipeline it.
Potuz:So I would suspect that any system more or less, arrives to about the same kind of minimal slot time.
Dankrad Feist:But and I think, like my argument would be that
Dankrad Feist:Currently, a lot of things are not very well optimized because we did have so much slack in the slot. We had to just allow 4 seconds for propagation.
Dankrad Feist:and we will learn a lot from doing the work on reducing slot times, and it will also improve our like. How informed our choices will be on pipelining.
Dankrad Feist:and it's better to do it when fully understanding what like the hardest constraints are rather than doing it now with like, yeah, like, not even knowing exactly.
Potuz:No, no, we we do know what are the Chinese bandwidth.
Dankrad Feist:Well, I mean right now, there's something else. Right? For example, we see that 10% of the attestations somehow arrive very slowly. I mean, I think, like, this is like something that we really need to investigate what is happening there. There's something strange there when like 90% arrive very quickly. And then there's like a slow, long tail like what's happening there
Dankrad Feist:like stuff like that is really important to analyze and like, is it the art constraint is this because some validators are in the middle of nowhere and really slow? And we really want to allow that time, like all these things, are important questions, I think.
Dankrad Feist:or is it just random? And it's like a some something we can improve by having some improvement in the Pops ups like, I don't know, like this is, yeah.
Dankrad Feist:this is really important to investigate. And I feel like it's also
Dankrad Feist:it helps like actually working on reducing the slow time to actually get there, because otherwise we will never have the actual full pressure to like, optimize these things as much as we can. And I think it will allow us to make better choices on pipelining.
stokes:Yeah, put us.
Potuz:I think it's actually the opposite. I mean this the attestation. So for the current slot, time.
Potuz:attestation, propagation, aggregation, all of these things are completely relevant for epbs. They happen in the background while you're doing useful stuff like propagating the block and executing it.
Potuz:So how long, how many attestations are coming late or not doesn't change at all the pipelining benefits of epbs while they do change. How short the slot we can actually make. So that's more of a reason to actually choose some pipelining. Now deliver pipelining, and then adjust the timing so that they are actually possible.
stokes:Okay, are there a number of comments in the chat around? Yeah, supporting these investigations? I would highlight that. This will take time.
stokes:And if we want to make a call in Amsterdam and say the next couple of weeks, it might be hard to get that data.
stokes:which again, is just another input to consider.
stokes:So okay, I think to move forward. Then.
stokes:probably what's best today. Tim's suggestion here was to Cfi 6 second slots, epbs and fossil, and essentially, then just take this to the next call.
stokes:This helps reduce the scope of what you know the Cl. Is thinking about in terms of Amsterdam headliners
stokes:that will then help refine the El headliners, and presumably then it'd be nice to make a call on the actual headliner on the next? Acdc.
stokes:so that's how I would propose to move forward.
stokes:In the meantime, yeah, there are some comments around like, yeah, what does it actually mean to get community input.
stokes:I think, trying to have like a canonical source of truth, would be good. And I'd propose each magicians for this.
stokes:There have been comments around Twitter and these forecast polls and everything, you know. I think if eip champions would like to even just copying that, you know, into the conditions post, just to put it in one place would be useful.
stokes:Because, yeah, I think some of what we're seeing right now is different. People are seeing different data, and it leads to split views which is tricky to navigate. So
stokes:I think we do that today. Cfi, those 3 eips with the idea being that one of them will be the seal headliner.
stokes:Then do what we can to. Then, you know, we're again really refine this notion of community input to help
stokes:make the decision on the next call.
stokes:So the 3 Aps, 7, 7, 3, 2 with epbs.
stokes:I think it's 7, 8, 8, 6 for the 6 second slots, and I forget the fossil. Number
stokes:7, 8. 0, 5. Thank you.
stokes:I might have the number off on 6 second slots as well.
stokes:right. 7, 8, 8, 6 was still in execution.
stokes:Okay, sorry. I'm getting them mixed up. I can go find the 6 second slots number unless someone has it
stokes:is this 7, 7, 8, 2. That's what came up.
stokes:Yeah, okay, thanks. Part of it. So yeah, either way. I'll get that sorted in the summary and make that clear.
stokes:and from there I think we're good on the Amsterdam conversation, for right now.
stokes:in that case we will turn to the last agenda item here.
stokes:There was a spec question from Etan again. I'm not sure if he's on the call, but I think.
Etan (Nimbus):Anyhow.
stokes:Context. Oh, yeah, would you like to ask this question? You had.
Etan (Nimbus):Yeah, right now.
Etan (Nimbus):I have a problem when I wanna get my specs for pure into the consensus specs repo, because I need a couple extra Ssc types, namely, that's like the lists and
Etan (Nimbus):progressive containers. The problem is because the Ssc specs are part of consensus specs repo. But
Etan (Nimbus):There is no way to make like a fork specific type there, because there is only like a master spec there, like the other infrastructure where it's like, where you can make like a features folder and create your own folder there, and put all the pre-release stuff there. It doesn't work for the Ssc. Specs.
Etan (Nimbus):There is a precedent with the Union, which is also a type that is not used by ethereum itself. It's only used by a portal network, and that one is also there. So
Etan (Nimbus):I made a Pr to make it like similar, where I add my type and just put like a comment, hey, this is from this eip. It's currently unused just to get it in there at the tests to unblock me. And I was wondering if that's fine. Justin just pasted the Pr. There in the chat.
stokes:Yeah, I mean one comment here we do have a precedent here with other SSD features from a long time ago, like unions is one?
stokes:So yeah, this wouldn't be anything super new.
stokes:I guess. The question then is, would anyone have problems with this being in the spec? Again, it would be clearly labeled that it's
stokes:essentially a placeholder.
Etan (Nimbus):Yeah. And it adds extra test folders to consensus backtests that can be ignored because it's unused. Right?
stokes:Right.
stokes:So if no one disagrees sort of at a high level I think we can take this from we can take the conversation to the Pr, and yeah, there might be ways to
stokes:restructure things that make more sense. Barnabas has this comment here about handling feature forks better. And yeah, I agree.
stokes:it would be nice to have a clear way to handle this in the actual artifact. But I think that's something we can sort out on the Pr.
stokes:okay, yeah, seems like, no disagreements in principle. So yeah, Etang will. Justin. And I can work with you on that. Pr.
stokes:okay, let me do one more check. But I think that's all we had on the agenda today.
stokes:And yep, so yeah, we can wrap up a little bit early
stokes:unless someone else has any closing comments.
stokes:Okay.
stokes:well, then, I'll see you all next week on Acd. We'll continue the Glamsterdam discussion there, and hopefully by then we'll also have more data on how Devnet 3 is going with Osaka, so we can keep that moving as well.
stokes:Thanks everyone. I'll see you next time.
Potuz:Bye.
Dankrad Feist:I'm.
ethDreamer (Mark):See you guys.
Pooja Ranjan:And.
Marius van der Wijden:Bye-bye.
Chat Logs
00:03:08
stokes:https://github.com/ethereum/pm/issues/1614
00:06:01
Justin Traglia:When we decide to shutdown devnet-2, we should try to kill it first.
00:06:28
Potuz:Replying to "When we decide to sh..."
Could we try disabling tx3 txs from the mempool?
00:08:18
Parithosh Jayanthi:This is per: https://eips.ethereum.org/EIPS/eip-7870
00:08:27
Potuz:I think it’s doable, with the caveat that mainnet releases shouldn’t be expected by end of August but rather 1month before mainnet right?
00:10:13
Barnabas:Replying to "This is per: https:/..."
I think we should also update 7870 to require gigabit for supernodes
00:10:42
Ben Adams:🍿
00:10:50
Potuz:Replying to "This is per: https:/..."
Goodbye home CSM and RP operators
00:11:25
Potuz:Replying to "This is per: https:/..."
I would advocate then to raise the limit of keys that are needed to become a supernode
00:15:09
ethDreamer (Mark):FOUR SECONDS for attestation propagation and aggregation - this is what the PTC enables you to parallelize with block and blob broadcast and execution
00:16:26
Potuz:From the charts I gather US may be very much skewed since they tighten maximally for timing games https://discord.com/channels/595666850260713488/874767108809031740/1394340226238775337
What’s 0.4 seconds for US is 1.6 seconds for Titan
00:16:54
Raúl Kripalani:do we know how connected relays are to the mesh? we assume they're hyperconnected
00:16:56
Radek:go Poland
00:17:01
Barnabé Monnot:Replying to "FOUR SECONDS for att..."
on a 6s slot time?
00:17:16
ethDreamer (Mark):Replying to "FOUR SECONDS for att..."
That’s independent of slot time
00:17:22
Francesco:Replying to "FOUR SECONDS for att..."
The PTC votes also need to propagate, so that’s not entirely true
00:18:38
Potuz:This are strictly single attestations?
00:18:48
Dustin:p95 isn't enough
00:19:00
Potuz:From just 0 and 1 committees right?
00:19:08
Dustin:p95 means risking a block every epoch
00:19:24
Dankrad Feist:no
00:19:46
Dankrad Feist:Replying to "p95 means risking a ..."
it's 95% of attestations. so no
00:19:54
Potuz:Wait I didn’t understand how 4413ms supports the 6 slot times here?
00:19:59
Barnabé Monnot:Replying to "p95 means risking a ..."
not sure that’s true, but could argue p95 is not enough on different grounds
00:20:02
Dustin:Replying to "p95 means risking ..."
it's als for blocks
00:20:05
stokes:Replying to "p95 means risking a ..."
I assume he means if we try to fit to p95 for blocks
00:20:08
Potuz:Aren’t we moving the attestation deadline to 3 seconds?
00:20:08
Dustin:Replying to "p95 means risking ..."
yes
00:20:16
Dankrad Feist:Replying to "p95 means risking a ..."
yes but we are not doing that
00:20:22
Dustin:Replying to "p95 means risking ..."
yes the presentation does
00:20:27
Dustin:Replying to "p95 means risking ..."
I don't know what "we" are doing
00:20:31
Dankrad Feist:Replying to "p95 means risking a ..."
it just measures
00:20:33
Barnabas:could someone mute caleb please?
00:20:51
Dustin:Replying to "p95 means risking ..."
ok, well, the slides are about p95 for block distribution aleady being 3s
00:21:00
Dustin:Replying to "p95 means risking ..."
(one dataset)
00:21:34
Dankrad Feist:Replying to "p95 means risking a ..."
but this is not stake weighted
00:21:41
Mingfei Zhang:How many validators are in a committee in the test
00:21:57
Potuz:Yeah also another bias is that nodes tend to be more stressed at the beginning of the epoch where you should have a higher bias to these missed blocks
00:22:03
Trent:@Tuyen please stay muted =)
00:22:04
Dankrad Feist:Replying to "p95 means risking a ..."
so it definitely does not mean risking 5% of all slots as you are suggesting
00:22:10
Dustin:Replying to "p95 means risking ..."
ok
00:22:17
Potuz:Replying to "How many validators ..."
Active / 32 / 128
00:22:51
Dustin:Replying to "p95 means risking ..."
it's sampling by nodes-with-valiators only?
00:22:55
Potuz:Can anyone please tell me how the 4.1 seconds is within the proposal?
00:22:59
Potuz:This is pre aggregation too
00:23:01
ethDreamer (Mark):Replying to "FOUR SECONDS for att..."
Wait this isn’t true because I didn’t include aggregate propagation
00:23:02
Potuz:I am completely lost
00:23:04
Ben Edgington:Replying to "How many validators ..."
*Active / 32 / 64 (I think)
00:23:13
ethDreamer (Mark):Replying to "FOUR SECONDS for att..."
@Francesco
00:23:15
Barnabé Monnot:Replying to "Wait I didn’t unders..."
showing preliminary measurements, wouldn’t say it supports or does not support 6s. also 4413ms is based on current partition and means some clients fire off their attestations at 4s only
00:23:24
Barnabas:fusaka-devnet-3 bandwidth rate limiters are now active.
supernodes: 1000Mbps/1000Mbps
fullnodes: 100Mpbs/50Mbps
00:23:42
Barnabé Monnot:Replying to "Can anyone please te..."
answered above
00:24:23
Potuz:Replying to "Wait I didn’t unders..."
Concentration is not a bias for shorter slot times though
00:24:26
Barnabas:Do we have a working prototype of any clients of shorter slot times?
00:24:27
Potuz:Replying to "Wait I didn’t unders..."
It will be concentrated
00:24:44
Barnabé Monnot:Replying to "Wait I didn’t unders..."
what do you mean by concentration?
00:25:03
stokes:Replying to "Do we have a working..."
I think there was a PoC in lighthouse
00:25:06
Toni Wahrstätter:Replying to "FOUR SECONDS for att..."
Attestations are not aggregated neither here. It's looking into attestations in subnets
00:25:09
Potuz:Replying to "Wait I didn’t unders..."
Concentration of all attestations being at the same time (because that’s a bias in this test by looking at missed blocks)
00:25:13
stokes:Replying to "Do we have a working..."
Also feel like I saw a tweet about a shorter slot testnet
00:25:20
Potuz:Replying to "Wait I didn’t unders..."
But on shorter slot times, attestations will be more concentrated than today
00:25:28
Parithosh Jayanthi:The prysm fork doesn’t add the delays now 😄
00:25:36
Parithosh Jayanthi:But yes the community data would have it indeed
00:26:14
Potuz:Replying to "Do we have a working..."
Preston may not be here but he has a working Poc now
00:26:28
Toni Wahrstätter:Replying to "FOUR SECONDS for att..."
If a bls verify takes ~1ms, then ptc validation will add some more additional latency
00:26:29
Potuz:Replying to "Do we have a working..."
Of course without any of the changes that aren’t specified
00:26:54
terence:Replying to "The prysm fork doesn..."
ahh i see, can you show me the fork, will love to study that
00:27:10
Barnabé Monnot:Replying to "Wait I didn’t unders..."
well they have less room to spread around, so we want them to be more concentrated. shorter slots without any other intervention don’t just concentrate attestations by themselves
00:27:32
Francesco:Replying to "How many validators ..."
In other words it’s about ~500
00:27:38
Parithosh Jayanthi:Replying to "The prysm fork doesn..."
You gotta ask sam 😄
00:30:21
Potuz:Propagation of blocks should not affect attestation propagation
00:30:43
Potuz:They should be independent since they should be latency bound not bandwidth bound
00:30:54
Mikhail Kalinin:+1 to Mark. We need pipelining and potentially BAL (to speed up the execution) in G* and then introduce block latency reduction in H* with more confidence in it
00:30:56
Raúl Kripalani:libp2p attestation propagation timing from Xatu was incorrect the last time we looked at it
00:31:07
Raúl Kripalani:due to Hermes backlog / misconfiguration
00:31:23
Potuz:@Raúl Kripalani do you think there could be p2p changes to improve single attestation propagation?
00:31:24
Raúl Kripalani:so i'd like to dig deeper into the data / methodology
00:31:49
Trent:This was mentioned on a call yesterday as well - if the 6s slot proposal also includes halving the gas limit to keep throughput stable - this was new to me (though I may be in the minority) and worth surfacing as a key part of the proposal
00:31:50
Potuz:These numbers are horrible and don’t match up with the ones I had from Terence in my head for the last few months already
00:32:12
Potuz:Replying to "This was mentioned o..."
It is assumed, same with issuance
00:32:12
Raúl Kripalani:Replying to "@Raúl Kripalani do y..."
yeah, i think there's quite a bit of headroom here
00:32:16
Potuz:Replying to "This was mentioned o..."
Which hasn’t been spaced yet
00:32:27
Potuz:Replying to "This was mentioned o..."
Speced, Hate autocorrection
00:32:48
Marius van der Wijden:Replying to "This was mentioned..."
(but gas limit increases would put it at roughly the current time again)
00:33:13
Toni Wahrstätter:Replying to "These numbers are ho..."
Note that it's a long range: beginning of block propagation -> 95% attestations seen. There's much latency in between and not that much happening afterwards.
00:33:14
DA | Flashbots:Replying to "This was mentioned o..."
Part of the issue is that there are fixed things in a slot, like the commit-reveal scheme. So it’s not clear to me how linear cuts of different sections are to me with gas limit
00:33:18
Potuz:Replying to "This was mentioned o..."
Yeah… these numbers presented here are horrible, I’m hoping it’s a measurement issue and not that reality is this
00:33:26
Ahmad Bitar | Nethermind:Dont we already know that home staker s are probably the ones with the worst internet. Doesn't this mean that most likely, those are the validators most likely will be affected?
00:33:36
DA | Flashbots:Replying to "This was mentioned o..."
Like this analysis just ignores the first 1.5 seconds on commit-reveal in PBS
00:34:23
Marius van der Wijden:Hey we get something for free, thats great!
00:34:43
DA | Flashbots:Replying to "Hey we get something..."
Actually you’re giving it away for free to us :p
00:34:44
Francesco:Replying to "Hey we get something..."
Bad name, you actually pay for it
00:34:58
Barnabé Monnot:Replying to "This was mentioned o..."
you can extrapolate some results for the ePBS world, after 1.5s you’d have both the exec payload propagating + blobs and the attestations etc. mixed effects then, attestations are not in the “hot path” but they may compete for bandwidth more than today
00:35:01
Bruno Mazorra:Replying to "Hey we get something..."
Is a sunk cost
00:35:03
Trent:@Gary Schulte please stay muted =) (im only sending these after I mute someone)
00:35:17
Bruno Mazorra:Replying to "Hey we get something..."
So the option is free
00:36:01
DA | Flashbots:Replying to "This was mentioned o..."
Agreed. I just think there’s a lot of layers of nuance. Even like separating ultrasoun-us v.s. ultrasound-eu in the data.
00:36:45
Raúl Kripalani:ranging from gossipsub parameter fine-tuning per-topic, transport optimizations, dedicated topology / routing policies for attestations, etc. to more drastic changes
00:37:08
Sophia Gold:EL only DE is pipelining and doesn't have this problem, right?
00:37:20
Ansgar Dietrichs:This is a fundamental problem with the propagation window, even today: between winning the auction and propagation finishing, you can always abort propagation (but still pay the proposer).
So the thing is just that we now want to use a larger portion of the slot for propagation, so the problem gets worse.
also means best solution is shorter slot times
00:37:24
Potuz:Replying to "@Raúl Kripalani do y..."
I think this is becoming a bottleneck soon if these numbers are right
00:37:27
ethDreamer (Mark):Any proposal where there is a time delta between transaction selection and the deadline for all components of the block must be available will be vulnerable to this option problem
00:38:15
Raúl Kripalani:the network load placed by attestations is radically different to everything else (many tiny fragments in a bursty way), so i'm sure we're incurring more overhead than we should (e.g. we could even batch attestations to amortize validation time and MTU utilization)
00:38:15
Toni Wahrstätter:Replying to "Any proposal where t..."
It's more every proposal that allows post-attestation payload invalidation
00:38:35
Potuz:Replying to "This is a fundamenta..."
The particular problem though according to the computation by Christoph et. al. is proportional to MEV and therefore to the slot time so making the slot shorter doesn’t substantially help
00:38:38
Francesco:Replying to "@Raúl Kripalani do y..."
Another dumb thing is, I don’t think the current number of committees is optimal (more committees => each single attestation topic is smaller but the global aggregates topic has more messages)
00:38:42
Potuz:Replying to "This is a fundamenta..."
Ahh what he is saying now
00:39:00
Raúl Kripalani:i.e. if we decouple "unit of work" from "message/attestation", i think several clever optimizations open up
00:39:15
ethDreamer (Mark):Replying to "Any proposal where t..."
Wait what? That does’t make sense. You can’t retroactively invalidate a payload if it was valid from the start and all components are available
00:39:29
Ansgar Dietrichs:Replying to "This is a fundamenta..."
ah, hm right
00:39:32
ethDreamer (Mark):Replying to "Any proposal where t..."
If it was invalid from the start, you have no option
00:39:42
Hasu:btw the post for reading along https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115
00:39:53
Barnabé Monnot:Replying to "This is a fundamenta..."
right but all else equal shorter slot times help no? you’d have half the MEV per slot, but twice the slots?
00:39:58
Toni Wahrstätter:Replying to "Any proposal where t..."
Here you "invalidate" your payload by not publishing >50% of the blobs
00:40:11
Potuz:Replying to "This is a fundamenta..."
No, this is explicitly the statement they make
00:40:19
Potuz:Replying to "This is a fundamenta..."
It’s the time relative to the slot
00:40:28
ethDreamer (Mark):Replying to "Any proposal where t..."
I said “deadline where all components are available”
00:40:29
Marius van der Wijden:So we need to make the penalties for builders more severe?
00:40:33
Francesco:Replying to "EL only DE is pipeli..."
Yes but fwiw this not a CL-DE problem either, it’s specifically a commit/reveal problem. It is in principle possible to do CL-DE with full pipelining (including PTC) but no commit/reveal, but what has to be given up for that is trustless payments (not clear how to do them without commit/reveal)
00:41:07
Toni Wahrstätter:Replying to "Any proposal where t..."
So, you publish your valid el payload early and the whole el payload turns "invalid" at the ptc deadline if the blobs are not revealed
00:41:13
Raúl Kripalani:do we think having a confident answer here is blocking us from choosing the headliner? (ie. what priority should we (p2p) give to this?)
00:41:37
Ansgar Dietrichs:Replying to "This is a fundamenta..."
right, at least with perfect slot usage, shorter slot times would no longer help.
currently they would help, because we can’t use full slot for propagation, so ratio gets better
00:41:52
Potuz:Replying to "EL only DE is pipeli..."
Not a commit reveal for the payload but for blobs is the main issue. ePBS with a single short PTC deadline doesn’t have this problem as per these guys computations
00:42:00
Raúl Kripalani:Replying to "These numbers are ho..."
they're probably affected by the same Hermes issue as my attestation CDF chart from Berlinterop
00:42:04
Potuz:Replying to "EL only DE is pipeli..."
And it’s still commit-reveal
00:42:10
Ansgar Dietrichs:Replying to "This is a fundamenta..."
which also means that this effect is directly proportional to throughput - we can make it better by artificially throttling throughput
00:42:12
Potuz:Replying to "EL only DE is pipeli..."
But loses blob propagation scaling
00:42:13
Francesco:Replying to "This is a fundamenta..."
I think there’s a fundamental difference between having commit/reveal and not having it, because having commit/reveal means that the entire allocated propagation window fuels the option’s value, whereas without commit/reveal the end of the auction is close to the latest time when you can propagate the data
00:42:24
ethDreamer (Mark):Replying to "Any proposal where t..."
I guess if you include publishing early.. but why would you do that?
00:42:30
Potuz:Replying to "This is a fundamenta..."
I’m replying to this in a different thread so I’ll copy there
00:43:00
ethDreamer (Mark):Replying to "Any proposal where t..."
You created an option you already had by publishing on time. It’s more expensive publish early and waste the block rather than just publishing on time
00:43:11
Potuz:Replying to "This is a fundamenta..."
Not a commit reveal for the payload but for blobs is the main issue. ePBS with a single short PTC deadline doesn’t have this problem as per these guys computations
And it’s still commit-reveal
But loses blob propagation scaling
00:44:05
NC:If this option is valuable, wouldn’t it be reflected in the bid price? ie. builders are willing to pay a premium for it and they will lose more when they decide to withhold
00:44:09
soispoke:Replying to "So we need to make t..."
It’s not clear yet we would need to do that I think it all depends on results from empirical data. If what builders bid (and always lose) is a lot greater than their profits then the dominant strategy is already to reveal and not withhold the block: https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115/9?u=soispoke
00:44:32
ethDreamer (Mark):Replying to "So we need to make t..."
Yes a penalty for not revealing is a trivial way to negate this attack
00:44:52
DA | Flashbots:Replying to "If this option is va..."
Yes. But that also makes their bids more competitive and creates this vicious circle where proposer blacklisting will never make sense.
00:44:54
ethDreamer (Mark):Replying to "So we need to make t..."
But the real problem is if solo stakers build off-chain infrastructure
00:44:55
Sophia Gold:Replying to "EL only DE is pipe..."
Tbh I don't think trustless payments give us much. The benefits of ePBS are pipelining
00:44:56
stokes:Replying to "So we need to make t..."
Couldn’t the PTC collude to grief the builder then?
00:45:11
ethDreamer (Mark):Replying to "So we need to make t..."
Good luck getting the PTC to collude
00:45:17
stokes:Replying to "So we need to make t..."
fair
00:45:17
Ansgar Dietrichs:PTC can already grief builder in existing design, the effect with a penalty would just get worse
00:45:42
Barnabé Monnot:Replying to "@Raúl Kripalani do y..."
depends what your other priorities are of course 🙂 but even if we assume we want 6s asap, before or after restructuring, then imo we should be paying attention to these things asap too
00:46:19
DA | Flashbots:Replying to "EL only DE is pipeli..."
Saying trustless payments doesn’t give you much just means that you aren’t paying attention to the trends in the MEV ecosystem.
00:46:45
stokes:Replying to "EL only DE is pipeli..."
You mean re: relay centralization?
00:46:54
Francesco:Replying to "So we need to make t..."
It also just means that any network failure can become very costly. Would you build locally if you can lose 1 ETH?
00:47:13
Francesco:Replying to "So we need to make t..."
(And there’s obviously no way for the network to distinguish between local building and professional building)
00:47:18
Sophia Gold:Replying to "So we need to make..."
Iiuc the point is that the option is so valuable given high liquidity that the capital requirements to penalize builders for exercising it would not be feasible
00:47:55
Barnabé Monnot:Replying to "So we need to make t..."
Yeah usually people were not comfortable with missed slot penalties because of local building
00:47:58
DA | Flashbots:Replying to "EL only DE is pipeli..."
death of minority relays, relays trying to monetize, moving towards sealed bid, vertical integration, etc.
00:48:29
Francesco:Replying to "EL only DE is pipeli..."
In the post you’re saying that a sealed bid auction is a good thing. Why are you listing it here as a bad trend?
00:48:53
DA | Flashbots:Replying to "EL only DE is pipeli..."
It’s a bad thing if there’s a relay in the middle. Because you can’t monitor it.
00:49:16
soispoke:Replying to "So we need to make t..."
Fwiw FOCIL helps relying less on local builders and would be useful if we want to have missed slot penalties
00:49:27
DA | Flashbots:Replying to "EL only DE is pipeli..."
+ encourages vertical integration
00:50:53
ethDreamer (Mark):Shortening the window just reduces propagation time
00:51:02
ethDreamer (Mark):So negative impact on scaling
00:51:10
Ansgar Dietrichs:without new innovations, the free option time window is directly proportional to throughput, no?
so that is a very important downside
00:51:47
Ansgar Dietrichs:Replying to "without new innovati..."
both blob and calldata throughput
00:51:57
Toni Wahrstätter:Shortening the window takes pipelining and at some point we are back at attestation deadline = payload availability deadline = blob deadline. Then, we took the pipelining from ePBS.
00:52:07
Potuz:Yes, the point that this is mostly interesting to searcher-builders without serving other searchers is important to understand perhaps or modeling.
00:52:20
Potuz:No need for that
00:52:28
Potuz:You can do a refund to the builder
00:52:31
Potuz:Instead of a penalty
00:52:34
DA | Flashbots:Replying to "Yes, the point that ..."
Or only serving searchers bidding the same direction as them.
00:52:50
Toni Wahrstätter:Replying to "without new innovati..."
Yesh, agree, later deadlines that impact what was attested on impacts how we think about pipelining.
00:52:52
Potuz:Replying to "Yes, the point that ..."
Exactly, but then searchers would stop sending txs to them
00:53:04
Ben Adams:Can't do a penality high enough to (that anyone would pay) to cover trading gains?
00:53:10
Potuz:Replying to "Yes, the point that ..."
The PoF point of view I think it’s important
00:53:10
soispoke:Replying to "Yes, the point that ..."
I think there is an incentive for non integrated builders to reveal to searchers generally speaking no? If they don’t searchers would shade their bids and builders profit less
00:53:27
Toni Wahrstätter:Replying to "Can't do a penality ..."
They are uncapped
00:53:37
Ansgar Dietrichs:“seems like there are potential paths” - which ones?
00:53:57
stokes:https://blog.sigmaprime.io/glamsterdam-eip7732.html
00:54:03
Christoph Schlegel:Replying to "“seems like there ar..."
Left as exercise to you Ansgar
00:54:03
Ben Adams:Replying to "Can't do a penality ..."
then "that anyone would pay"?
00:54:11
Ansgar Dietrichs:Replying to "“seems like there ar..."
or was that just some optimistic placeholder?
like I am sure we will eventually find solutions, but I didn’t hear any mentioned
00:54:18
DA | Flashbots:Replying to "Can't do a penality ..."
I’m curious to how much other builders would stop wanting to include private (mostly based rollup) blobs. Since they’re already hardly paying for liveness
00:54:24
Ben Adams:Replying to "Can't do a penality ..."
why would you propose a block if risk is so high?
00:54:33
ethDreamer (Mark):I just think that proposal is strictly worse
00:54:34
Potuz:Replying to "“seems like there ar..."
I don’t see any solution really it’s fundamental to have the blob deadline late
00:54:45
stokes:Replying to "“seems like there ar..."
Penalty for builder not revealing
00:54:47
ethDreamer (Mark):Replying to "I just think that pr..."
It still suffers free option problem
00:54:47
Potuz:Replying to "“seems like there ar..."
This affects APS, mev boost anything
00:54:58
Ansgar Dietrichs:Replying to "“seems like there ar..."
ah, right, penalties are an option.
00:55:05
soispoke:Replying to "“seems like there ar..."
@stokes missed slot penalties hurt local builders
00:55:25
stokes:https://discord.com/channels/595666850260713488/745077610685661265/1397620790798581834
00:55:30
Potuz:Replying to "“seems like there ar..."
Instead of penalties (that are hard to do) I think it’s trivial to return a percentage of the bid to the builder when the payload is processed
00:55:33
Francesco:Replying to "“seems like there ar..."
Seems to me that the realistic choices are:
Accept this problem and move on with 7732 (with current knowledge of the free option problem I find this really uncomfortable)
Remove trustless payments and commit/reveal for now, do everything else that epbs does to keep maximal compatibility with it (maybe we change how things work with blobs later/gain new insights and can revisit)
Go back to some other delayed execution proposal (not sure why)
00:55:50
Lion dapplion:I think it’s deceiving to force ePBS on the slot restructuring effort. Core devs should be able to signal support to both or either
00:55:59
nixo:Lido, Flashbots, Snowbridge, & QuickNode also left feedback here: https://ethereum-magicians.org/t/soliciting-stakeholder-feedback-on-glamsterdam-headliners/24885
00:56:00
ethDreamer (Mark):Replying to "“seems like there ar..."
Wait potuz
00:56:09
ethDreamer (Mark):Replying to "“seems like there ar..."
What you mean by refund Is what I mean by penalty
00:56:14
Potuz:Replying to "“seems like there ar..."
Removing trustless payments does not solve this at all
00:56:19
ethDreamer (Mark):Replying to "“seems like there ar..."
Of course the penalty isn’t applied when they reveal
00:56:29
Ansgar Dietrichs:Replying to "I think it’s deceivi..."
can you clarify?
00:56:35
ethDreamer (Mark):Replying to "“seems like there ar..."
Only applied when they don’t reveal
00:56:35
Potuz:Replying to "“seems like there ar..."
Yes I understand, I’m only talking about implementation details
00:57:16
Francesco:Replying to "“seems like there ar..."
@Potuz removing commit/reveal does solve the problem afaiu
00:57:17
Potuz:Replying to "“seems like there ar..."
When we schedule the withdrawal we schedule for less than the total amount
00:57:26
Ansgar Dietrichs:would we then explore having e.g. builder penalties already in the initial ePBS version in Glamsterdam? seems like we could still add that
00:57:26
Barnabas:so we SFI epbs?
00:57:31
wolovim:Replying to "Lido, Flashbots, S..."
+ client team perspectives aggregated here: https://forkcast.org/upgrade/glamsterdam#client-team-perspectives
00:57:43
Ansgar Dietrichs:Replying to "so we SFI epbs?"
well not today though
00:57:44
nixo:CFI seems more appropriate
00:57:44
Potuz:Replying to "“seems like there ar..."
No, the problem is the difference between payload reveal and blob reveal
00:57:54
Toni Wahrstätter:Nothing on the EL SFI'd yet
00:57:54
Francesco:How can we SFI something where we have such a big unresolved question?
00:58:04
Potuz:Replying to "“seems like there ar..."
If you do ePBS as is, with since PTC early it does not have this problem
00:58:19
Parithosh Jayanthi:Can we DFI anything?
00:58:30
Francesco:Replying to "“seems like there ar..."
If you have a single deadline, it can be late
00:58:39
Lion dapplion:Replying to "I think it’s deceivi..."
The slot restructuring contained on its own can be implemented without rustless payments, let’s call that feature EIP-7732A. Now let’s call the trustless payment feature EIP-7732B which depends on EIP-7732A. Now you can signal support to either EIP-7732A or EIP-7732B.
I wonder if the majority want as headliner EIP-7732A or EIP-7732B
00:58:48
stokes:Replying to "Can we DFI anything?"
I think we DFI other headliners on the next call
00:58:53
Barnabas:Replying to "Can we DFI anything?"
dfi - 7942
00:59:03
stokes:Replying to "How can we SFI somet..."
Yeah, CFI feels better
00:59:25
Tim Beiko:Maybe we CFI EPBS today, SFI on next call if we still think it’s the right headliner?
00:59:35
Toni Wahrstätter:If we cannot agree on any specific slot restructuring (and do shorter slots instead), we shouldn't SFI it. There's great progress happening around slot restructuring right now and we still need more community input.
00:59:39
Ansgar Dietrichs:I think basically any CL Glamsterdam headliner choice would have the same free option problem, right? It’s not specific to ePBS at all.
So say even with 6s slots, we would want to increase the propagation portion of the slot, so same problem
01:00:06
Barnabas:what do we wanna do about FOCIL for glamsterdam?
01:00:26
soispoke:Replying to "what do we wanna do ..."
Thanks for asking 🙂
01:00:30
Francesco:Replying to "I think basically an..."
I don’t see how it’s the same problem with or without commit/reveal (e.g. a single deadline for payload and blobs late in the slot)
01:00:32
stokes:Replying to "Maybe we CFI EPBS to..."
Yeah I was going to invent a “headliner CFI” as a “conditional acknowledgment” today, but if everyone agrees CFI seems fine
01:00:34
Toni Wahrstätter:Replying to "I think basically an..."
Right but we could still have execution being done after the attestation deadline. But yeah, it limits propagation.
01:00:43
Ansgar Dietrichs:Replying to "what do we wanna do ..."
I am not yet convinced that combining it with ePBS wouldn’t be insane scope wise
01:00:56
Potuz:Correctly, it removes bandwidth scaling which is the main thng
01:00:56
stokes:Replying to "what do we wanna do ..."
Yeah I think its a lot in terms of scope
01:00:58
Francesco:Replying to "I think basically an..."
With commit/reveal you always have the worst case amount of “free option time”
01:01:12
stokes:Replying to "what do we wanna do ..."
But also why I don’t want to DFI anything today
01:01:26
stokes:Replying to "what do we wanna do ..."
I think we should have the convo to have FOCIL in glamsterdam
01:01:37
Ansgar Dietrichs:Replying to "what do we wanna do ..."
as in, timing needs to be we have the final glamsterdam devnet in february, if we want to ship glamsterdam 6 months after fusaka
01:01:46
Mingfei Zhang:How about improving the security of the protocol in the headline
01:01:56
Christoph Schlegel:Yes having PTC deadlines earlier makes it much better
01:01:58
terence:Replying to "what do we wanna do ..."
why cant we do epbs + focil together?
01:02:24
Potuz:Replying to "what do we wanna do ..."
Officially I do not want to DFI FOCIL at all
01:02:51
Potuz:forkcast?
01:03:03
nixo:Lido favored 7886 (delayed exec) first then ePBS. Flashbots BALs, then ePBS
01:03:12
Barnabas:How do you ask community about something like epbs?
Asking about 6s slot time is super easy, because everyone can super easily grasp the idea of halving the slot time. While if you know what epbs is, then you are probably a core dev, or should be one.
01:03:13
soispoke:Replying to "what do we wanna do ..."
Would be good to have client’s perspective on this tbh, most clients have indicated they would want FOCIL as a stretch goal
Maybe it’s a discussion to have after making a decision about ePBS
01:03:26
Mikhail Kalinin:Replying to "Lido favored 7886 (d..."
BAL is on EL side
01:03:30
soispoke:I think tier lists on twitter is also biased
01:03:31
Ansgar Dietrichs:Replying to "Lido favored 7886 (d..."
important to note that these are infrastructure providers, so the opposite of users :-)
01:03:41
soispoke:I’ve seen a lot of FOCIL as top tier on my timeline 😃
01:03:47
Lion dapplion:Authors of EIP-7732 can I create a new EIP that deletes the trustless payment and add you as authors?
01:03:52
nixo:Replying to "Lido favored 7886 (d..."
ah right, just ePBS then
01:03:52
Ansgar Dietrichs:Replying to "Lido favored 7886 (d..."
still useful to note, but I think we are trying to make Ethereum listen more to users
01:04:00
Barnabas:Replying to "I think tier lists o..."
maybe twitter itself is biased? 😄
01:04:08
soispoke:Replying to "I think tier lists o..."
Yeah exactly
01:04:14
terence:I dont think we can take it seriously, I've seen ppl put DE and EPBS on the same tier. (S tier)
01:04:28
spencer-tb:Replying to "I think tier lists o..."
“Prepares bots to vote for epbs”
01:04:29
Ansgar Dietrichs:Replying to "How do you ask commu..."
simplest:
shorter slots = latency
ePBS = throughput
01:04:36
Potuz:Replying to "what do we wanna do ..."
Yes, and I think as soon as we manage to get rid of the problem here of deciding the easier will be how to rebase FOCIL
01:04:54
Tim Beiko:We could also CFI a handful of Headliners: EPBS, 6SS, FOCIL?
01:05:07
bbuchbauer:X is infested with bots. I don' think relying on it for community input is a good idea
01:05:08
Potuz:Replying to "How do you ask commu..."
My twitter poll with this exact 2 options had more return than forkcast
01:05:14
Potuz:Replying to "How do you ask commu..."
🤣
01:05:24
Dustin:Replying to "I think tier lists..."
terence: I'd view that as "slot restructuring"/pipelining/etc generically as being grouped
01:05:34
Dustin:Replying to "I think tier lists..."
not that they think they'd both happen
01:05:44
Barnabas:Wasn’t one of the pre-requisites of having something CFI-ed is to have at least 1 working prototype implementation?
01:05:45
saen:gonna be honest I think both proposals made me think we should do both in glamsterdam 😏
01:06:03
Ansgar Dietrichs:ePBS improves throughput
6s slots improve latency
Glamsterdam will already have other throughput increases, so to me latency would be more valuable.
01:06:08
Barnabé Monnot:Replying to "How do you ask commu..."
ePBS obviously has value to the community, imo it should be a prompt to find out good ways to communicate it, rather than bemoan other proposals are easier to communicate
01:06:09
Tim Beiko:Replying to "Wasn’t one of the pr…"
Yeah it’s a bit weird but it’s the tool we have
01:06:21
terence:DE and Epbs are competing proposals though. I'd understand if Epbs + reduce slot time together
01:06:26
Tim Beiko:To be clear, I’m saying we should do only one of those 3 😄
01:06:28
Ansgar Dietrichs:Replying to "Wasn’t one of the pr..."
I assume headliners have different rules
01:06:50
Tim Beiko:Replying to "Wasn’t one of the pr…"
First time doing this, so yes, we need to figure out the kinks
01:06:52
Barnabas:Replying to "Wasn’t one of the pr..."
I don’t think 6s slot time has any prototypes yet?
01:07:19
ethDreamer (Mark):Replying to "gonna be honest I th..."
I’d be fine SFI ePBS and CFI FOCIL if we can.. or CFI both
01:07:26
Trent:Replying to "Wasn’t one of the pr..."
Did nethermind do some experiments on ePBS + lower slot times
01:07:41
Lion dapplion:6SS conflicts with three slot finality? Sounds like it will further reduce the max count of signers per slot we can support
01:07:51
Parithosh Jayanthi:Replying to "Wasn’t one of the pr..."
Yes but they did a fresh network, the hard part is not a new network with lower slot time. Its an existing network that reduces slot time at a fork epoch
01:07:52
Caleb:Replying to "How do you ask commu..."
Exactly
01:08:53
Dustin:Replying to "I think tier lists..."
right, it's IMO a way of expressing a desire for either of them to happen, not having a strong preference
01:08:53
ethDreamer (Mark):There’s also just the fact that the data we saw today indicated that 6 second slots without pipelining is gonna be a heavy lift - maybe doable but not certain
01:09:26
nixo:Replying to "I think tier lists o..."
yea i don’t think we should tally these one to one at all
01:09:48
Dustin:Replying to "I’ve seen a lot o..."
it's almost like everyone's timelines are different
01:10:20
Barnabé Monnot:Replying to "6SS conflicts with t..."
not clear what we do with it today is indicative of what will constrain 3SF
01:10:36
James He:It would be very sad if the majority of core devs voiced opinion on the fork headliners, and community overrules based on some arbitrary metric of collection of handpicked twitter posts
01:10:44
bbuchbauer:Replying to "I’ve seen a lot of F..."
yea, twitter shouldn't be taken too serious
01:11:01
ethDreamer (Mark):Replying to "I’ve seen a lot of F..."
I saw this one.. because I just made it.. but I also saw it
01:11:13
stokes:I’d suggest eth-magicians as a “record of truth"
01:11:30
stokes:So champions should try to get written data there
01:11:39
stokes:e.g. from various community members
01:12:27
Barnabas:we have nodes in 3rd world countries
01:12:32
Barnabas:with lots of hops
01:12:43
Raúl Kripalani:agree with @Dankrad Feist, we need to dig into the data
01:12:48
soispoke:Replying to "I’d suggest eth-magi..."
I think making one venue the “record of truth” is a bit tricky to start with tbh
01:12:48
Potuz:Fully support investigating these numbers
01:12:53
Toni Wahrstätter:Right, but more likely it's slow remote signers and similar
01:13:11
ethDreamer (Mark):I don’t see how we can argue we shouldn’t do pipelining without better understood data - and not also argue that we shouldn’t do slot shortening without better data
01:13:51
Ansgar Dietrichs:I think we should get better at making decisions that have immediate impacts.
ePBS is mostly a long term feature. Short term it gives more throughput, but we get that anyway from Glamsterdam.
shorter slots would be a much more noticeable immediate feature for users.
01:13:52
Mikhail Kalinin:+1 (to Potuz)
01:13:55
Barnabas:Question is, can we do deep investigation of this data in the next few weeks, in order to have 6s slot time still deliver in reasonable amount of time? Or will it take months of investigation?
01:14:23
Barnabé Monnot:my view:
obviously would be best if we had 100% confidence that 6s is a no-brainer technically
numbers today don’t prove unequivocally that it’s impossible however
if we committed to doing 6s for glamsterdam, I believe we’d likely be able to pull it off
ePBS doesn’t give us much more room either, so anyways P1 to understand the data and think about optimisations
01:14:34
Phil Ngo:Replying to "I’d suggest eth-magi..."
It’s hard to aggregate so many different venues. Even eth magicians doesn’t have a canonical thread for this AFAIK, there’s a few related to Glamsterdam topic
01:14:40
Potuz:Replying to "I think we should ge..."
This is false: ePBS makes Fusaka possible right now
01:14:44
Sophia Gold:Replying to "I think we should ..."
If we don't ship any form of pipelining in Glamsterdam it will set back zkEVMs by a year
01:14:47
Potuz:Replying to "I think we should ge..."
Without it Fusaka is useless
01:15:05
Josh Davis:Replying to "I’d suggest eth-magi..."
@Phil Ngo https://ethereum-magicians.org/t/soliciting-stakeholder-feedback-on-glamsterdam-headliners/24885
01:15:47
Potuz:What are the three EIPs?
01:16:01
Katya Riazantseva:7805
01:16:02
soispoke:7805
01:16:09
nixo:again pushing here for community input: https://ethereum-magicians.org/t/soliciting-stakeholder-feedback-on-glamsterdam-headliners/24885
also redirects from http://forkcast.org/feedback
01:16:14
Potuz:7886 is not 6 seconds slots right?
01:16:19
Dustin:thats DE
01:16:22
soispoke:Replying to "7886 is not 6 second..."
That’s DE
01:16:26
Phil Ngo:Replying to "I’d suggest eth-magi..."
So not the meta thread anymore
01:16:30
Barnabé Monnot:7782
01:16:35
Ansgar Dietrichs:Replying to "I think we should ge..."
wait what’s the fusaka argument?
01:17:00
nixo:Replying to "I’d suggest eth-magi..."
that thread is highly discussed based, looking to standardize opinions in some format
01:17:02
Potuz:Replying to "I think we should ge..."
Fusaka sets the ground to increase blob count substantially, but it can’t achieve much with 2 seconds to broadcast
01:17:15
Potuz:Replying to "I think we should ge..."
With ePBS you multiply this by 4-5
01:17:25
nixo:Replying to "I’d suggest eth-magi..."
it just makes it clearer to sort through
01:17:35
Potuz:Replying to "I think we should ge..."
Actually scaling immediately giving infinite gas to rollups (and also allowing late execution)
01:17:41
Potuz:Replying to "I think we should ge..."
This impacts users immediately
01:17:59
Justin Traglia:Etan’s PR: https://github.com/ethereum/consensus-specs/pull/4445
01:18:04
Ansgar Dietrichs:Replying to "I think we should ge..."
any version of Glamsterdam would increase the propagation ratio of the slot
01:18:06
Francesco:Replying to "I think we should ge..."
Not with the second deadline shortly after the attestation deadline 😄
01:18:06
Lion dapplion:Replying to "I think we should ge..."
*with payload decoupling
01:18:24
Potuz:Replying to "I think we should ge..."
Sure, I am advocating for the scaling version
01:18:39
Lion dapplion:Replying to "I think we should ge..."
Such version doesn’t exist yet right?
01:18:45
Potuz:Replying to "I think we should ge..."
what?
01:18:46
Ansgar Dietrichs:Replying to "I think we should ge..."
ePBS does add delayed execution over pure slot restructuring, but that only helps to further scale execution, not propagation
01:19:06
Potuz:Replying to "I think we should ge..."
Yes it scales propagation more than execution!
01:19:16
Potuz:Replying to "I think we should ge..."
The deadlines are about 4 seconds for the payload and 10 for the blobs
01:19:20
Barnabas:I think we need to find a better way to handle feature forks
01:19:40
Trent:Replying to "I’d suggest eth-magi..."
FWIW I don’t see the problem with pushing people to collect responses in a single venue
01:19:44
Potuz:Replying to "I think we should ge..."
This was the whole point of the early discussion on free options