All Core Devs - Consensus #161

Transcript

Alex Stokes: Hello, everybody. Let's see, let's give people a few more minutes to join, and we'll kick things off.

Okay, let's see, Josh, are you helping with the stream? You can go ahead and get started.

Josh Davis: Cool, you're live.

Alex Stokes: Okay, thanks. Everyone. Welcome to Acdc. This is call number 1, 6, 1. It is issue 1614, and the consensus as well. Sorry. The Pm repo. So 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 1st up with Fusaka. 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 Busa: 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 multiple times multiple different days when we tested, never mind, was always struggling to sync up in like 2 h. The head of the chain and loads are seem to get rate limited.

Alex Stokes: Okay, interesting. And you suspect this is because of the higher block. Count.

Barnabas Busa: I think lots are is already aware of the issue of getting really limited. because they don't do backfilling. I don't see that this would be an issue. I'm not really sure what the issues on the domain side. I would have to investigate that further.

Alex Stokes: Right. Thanks. Cool then. If that's it for Devnet 2, we'll move to Devnet 3 which had Genesis yesterday about 24 h ago. and let me see. we haven't quite worked to full yet. But yeah, it says here in just under 4 h. So yeah, anything to report on Devnet 3. Then I think the fun will begin. Once we've worked with Hulu.

Barnabas Busa: 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 basically, the only thing we could check is the did config the new vip that we have decided to add. And there are some issues there. But I've pinged everyone regarding that.

Alex Stokes: Okay, thanks. 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 anything else on Devnet 3 for the moment, or any Osaka things generally.

Barnabas Busa: Now we are working on the Mev workflow. Hopefully. either today or tomorrow, we can figure it out.

Alex Stokes: And that's just using. You wouldn't know if that's using this new V 2 endpoint. Do you.

Barnabas Busa: Good.

Alex Stokes: There is a spec change in Devnet 3. To have this v. 2. Endpoint.

Barnabas Busa: Yeah, yeah, so that that is there already.

Alex Stokes: Alright, cool.

Barnabas Busa: Also, I'm not sure which. Cl, we support that on 3, right after the phone.

Alex Stokes: Yeah, it might take some time. Yeah, I'm not sure implemented.

Barnabas Busa: Right now. We are still trying to test the lecture with the latest trenches, and that seems to be breaking at this point also.

Alex Stokes: Oh, interesting. Okay, well, that's that's exciting. Cool. Okay. then, yeah, there's nothing else. Simply soccer, then. So I did want to kind of just reassert this We had looked a bit at timelines on Acde last week, and you know, one way to think about this is having Devnet 3 up this week. Hopefully, things are stable and good assuming they are, we can then turn to hardening everything. 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. So 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.

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 let's I'll try to work under that framework. And okay, if that's it on Fusaka, I guess we're just kind of waiting on that 3 at this point. Yeah. Barnabas.

Barnabas Busa: Yeah, just one more thing that 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. We have about 70% full nodes and 30% super nodes. Super nodes will not have any rate limiting.

Alex Stokes: Okay.

Barnabas Busa: And this will not have 10 gig connection. So maybe we can really limited to one gig to be a bit more realistic.

Alex Stokes: Okay, interesting. And this is the new profile from previous sorry devnets.

Barnabas Busa: Yeah, previous devots didn't have any rate limiting.

Alex Stokes: Okay, we'll see what that does to things. Hopefully, it doesn't break anything. Okay? So 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. 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 hopefully, we can get to, you know, one test nut fork, where nothing needs to change. That then becomes the main net release. And yeah, per, the security sort of procedure that we had. Ultimately, yeah, we want 30 days in between that and the actual main net date. So that is the rubric we're working under. And again, timelines will be tight but let's try to make it happen.

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. So I think that's all I have to say about that. 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 in that case. 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. So what we had said is essentially, you know, picking one eip per layer that is the headliner for the fork

we've moved ahead with the scoping discussions now, so that we can kind of paralyze things. 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. So in that case, we're currently in the phase of Glamster, Glamsterdam, scoping where we need to select a headliner. So we touched on someone in the last call. You know, there are some obvious candidates here again, I think Eps is essentially a crowd favorite, at least among core developers. 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

so to kick off that first, st I think, Maria, I wanted to give a quick update on shorter slot times. I think, yeah, you're here, Maria.

Maria: Yes, I'm here, so I will just quickly share my screen. Then we can start.

Alex Stokes: Okay.

Maria: Be sorry. Okay. 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. 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. 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 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.

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? 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 attestation propagation. So excluding the block propagation and execution and validation. 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.

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

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 you can say that is a sort of biased sample. But we are working also to get more information from other relays. 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. 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.

I need to highlight here that these are nodes that have high bandwidth. And so we should 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. and this is the the same metric. So block propagation. Since the publishing by the relay. But now using the community notes. 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.

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 it's more prone to errors than the previous data set. And now we are moving to the attestation. So again, this is the So 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. So we are receiving at stations. Right? We are observing the at stations arriving from that subcommittee. 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

within that community. Arrived at that time. And here we see the full distribution across the various slots and the various committees and notes. And I'm also showing here the percentiles. 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. And an interesting thing here is that the for the 95 percentile. This is right below what? The what the new proposal for shorter slot times would require. And this is already you could say, like an extreme metric, because we are taking the 95%. I love the 95%. 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.

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. Then, for the pure attestation propagation. So this is the the the metric where we are looking at just missed slots. 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. 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 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. 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 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

at the stations. 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 time 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 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

let's say, like a a positive sign. And for just the attestation is 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. 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 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.

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 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. 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 to go through them.

I'm not sure if we have time. But thank you.

Alex Stokes: Cool. Thanks. Maria Terrence has had his hand up.

Terence Tsao: 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 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

have those numbers, I guess. And then the question I had is on the the decision slide. 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. 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. 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 Tsao: 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 blocks.

Terence Tsao: 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.

Alex 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 stick to getting data from relays might be more reliable than assuming everyone. Updates and people are testing in time.

Alex Stokes: Mark, you have your hand up.

Mark Mackey: Oh, sorry I was unmuted. Yeah. So based on the I, someone correct me. If I'm wrong, it's just based on the numbers you had here. It doesn't 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 like, I don't know this to me, would suggest that we 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 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. 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, you don't need 95% of the notes within your committee to see 95% of authorizations. Maybe you just need like for aggregators to see it. And so yeah, so I, this to me is actually like a 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.

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 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. so yeah, does this make sense or or or not?

Mark Mackey: 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 the attestation aggregation by maybe. How much like it it seems like a 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. 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.

Mark Mackey: 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 new things down the line, but so far yes. again I I think to 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. 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.

Alex Stokes: Barnaba, you've had your hand up.

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

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.

Alex Stokes: Okay. Any other questions or comments? If not, thank you, Maria. and we can go to the next bit here. So that was shorter slot times. Which was one of the headliner proposals. and another one that we're all familiar with is egps 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. I assume one of them is on the call.

Christoph Schlegel: Most of them. Yeah.

Alex Stokes: Oh! Hey!

Christoph Schlegel: Okay? right? So epbs, free option problems. So what is a free option problem? And why should you care? has to do with basically this? this optionality of of a winning builder in in block building, auction to invalidate their block if they're not happy 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 so you have a time window after that to invalidate 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 maybe also option. But otherwise they would. Yeah. post. Basically, it's equivalent to posting an empty block.

So how how is this turning out in reality. So epbs has 2 payload timeliness committee deadlines which you could put use both actually to to invalidate the block. So you have, you could fail to send the payload in time as as a builder. or, what is actually the more valuable option is to you, could fail to to send some blob. and that is the second deadline, and since the entire design is sort of meant as a pipelining sort of architecture where we postpone blobs to the end of the slot. Right? That gives you a bunch of time to actually wait for this last deadline for the blobs. 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.

it's about 8 seconds. And so if you want to take away one thing from from this presentation, 8 seconds is a lot. 8 seconds is a lot, and that gives you possibly a lot of value to this option. 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 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.

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

Nothing important happens. And so he was observed less frequently. and increasing in liquidity means, if 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. 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. And actually bad. Why? Because it's sort of 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

slots shorter if sort of the relative fractions remain the same. Okay, so that's that's the thing. We try to bit. Do a bit of like mix of theoretical analysis and empirical analysis. That is sort of very preliminary. We want to do it 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. 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.

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

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

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 and that bounce, bounce, bounce the value of that option. That 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.

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 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 a thousand and a minus 1,000 on those on those on those bets right? Betting 1 million on ethereum going up or down. 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

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 what was it? 200 300, something like this? 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. So that's that's sort of

binance is a casino, just with a lower, you know. Return on each each spin. But and the amount of liquidity that you can bet is basically 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. 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. 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

right, and then you see, with 8 seconds. For example, a bit above 200. You get half of that. So you get 118 Us. Dollar per spin on average. 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. 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.

Everything that you can trade, basically with good liquidity. Where you have very low slippage. put put a bet, put a bet in there and then. Yeah. 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. 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.

we attract twice as much liquidity. You make this problem. Maybe 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 it's a mixed bag. But I would say, if you increase liquidity directionally, it would increase a problem. 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. 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

if he would be able to place the bed top of block the the order top of block 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. And then 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, 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 exercise window, right?

And that is basically, if you have it. do it with this heuristic that you say, okay. 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 actually sort of the Mev scales linearly with time, probably less than linearly with slot time. Or it probably scales a bit more than square root block time. But you get substantial probabilities with this napkin map

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 take a bet, and then if the bet doesn't turn out well, you you 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% exercise probability on these things. 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.

and assuming away. All of 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 block listed by by validators if they do that so often. But assuming away all of those things north of 10% probability of exercising option when we have this 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. Okay, Brunan, do you want to talk a bit about potential solutions.

Bruno Mazorra: Yeah, sure. So, okay, potential solutions. I'm.

Alex Stokes: Sorry. Just one sort of orchestration point. Let's try to move through these slides faster rather than slower.

Bruno Mazorra: Sorry, what.

Alex 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 3 sets of solutions. So slashing. Shortening the free option window and block listing. 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. essentially like can increase the barriers of entries. And so that's not good, but also like, will decrease the optional value, and of course, also the the probability of exercising it. Also, we think, like block listing is not the right solution. Because, yeah, we want a permissionless 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

solo searchers, building blocks and actually like blog builders that try to acquire order, flow. And then there is like a potential 4th solution that I am. We should be thinking more about. It is essentially making blobs totally separated objects from transactions. and essentially having completely independent inclusion and free markets process so that could be some ideas. I don't know if we have more time.

Alex Stokes: Were there more slides? Yeah, it seems like it stopped. 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. Yeah, Mark.

Mark Mackey: Yeah, I would say, with regard to 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 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

yeah, that was just a nuance. I wanted to point out that we could increase this penalty, and we could do things to try to make it so that no self-building solo staker would suffer this. That was honest. Yeah.

Alex Stokes: Okay, thanks. So yeah, maybe just summarize. There's this notion of the free option problem. 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. but it seems like there are some potential paths there. 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. 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 questioning the need to do the trust and trustless payment. So at least I wanted to add the option to the fore planning and to everyone that if we want to, we can do. Eip. 7, 7, 3, 2, without the trustless payment, and I haven't found any obstacle to that path.

Alex Stokes: Okay, cool. 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. for not revealing something like this. Yeah, rather than going further into that. Let's just leave that alone for now. Okay. So if there were no other questions about that for the moment one other thing that came up so Christine Kim had a community space yesterday, and she had some input from different community members. I also am not sure if she's on the call. But let me grab a link to her message. It was on the awkward as channel, so you probably saw it.

But, in short, why don't I just give a summary. So sorry I lost the top. Okay? Yeah. Support for some sort of pipeline in you know, Epbs could be a solution here. Another support for 6 second slots just to improve ux. and otherwise. Yeah, those are the main things there. So just consider that as plus ones for these proposals from the community. There are some shout outs to forecast. And yeah, Christine will continue this process just to get input from different community members. So I did want to bring that up. And from there. Okay, so I think the way to proceed here. 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.

It seems like Epbs is sort of the leading headliner candidates right now. the way I propose to proceed is that we essentially like conditionally acknowledge this on today's call. That, then, can be an input to acde next week. 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 circular dependency, and seems like this is the right path forward. Does that sound okay to everyone? 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

on the next Acdc. In 2 weeks. Alright. Just ask, what do we sfy epbs? Let's see. I'd want to think if we want to. Cfi versus Sfi just process wise. But essentially, yeah, like, we would say that this would be the headliner selection for Glensterham on the Cl. Side. Osgar asked a question. Would we explore Bill builder penalties. So yeah, at least, the way I see this shaping up is that the selection for this process today and say over next call would just be saying, this is what we intend to do. 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.

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

Mark Mackey: I'll let us go first.st Actually.

Alex 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 reduces that dramatically. If you make this this size window minimal. and it's not a feature of the commit reveal process of of of epbs. But it is a feature of the difference between the payload 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.

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

Mark Mackey: Yeah, well, I guess I was next yeah. And 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 if you actually shorten the slot, then if you're I mean. it sounds like the problem gets not less or harder to pull off or or not as bad. If you should. If you have a a smaller deadline, so like. If we if we are shortening the slots later, then we're gonna make this attack harder. But, as

was pointed out, like, if things like liquidity and ethereum go up. This could be an issue. But yeah, I guess I just wanted to to point out that 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 benefits.

Alex 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. I mean, I definitely see the core devs part. But I don't see the community part, I think, like in most 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.

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

Alex Stokes: I saw something different. So yeah, I think the way to proceed then would just be to again conditionally say, Pbs, looks like the favorite today. 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.

Alex Stokes: Okay. Hmm, okay, I will take a look. Try to compile some stuff. And yeah, if if that's not the case, then definitely, I'll bring this up and we will incorporate that. Okay, there's a lot of commentary in the chat. I don't know if anyone wants to speak up. but essentially, I think, the next point. Then, there was a process suggestion here from Tim. So 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 one way we could do that is actually cfi it today and then move to Sfi on the next call. 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.

For example, more work on this reoption problem. then it would be kind of weird, I think, to see if I or like essentially undo the sfi. So again. If people want to do one or the other, we can. It feels like we're a bit early to make that exact call today. I don't know if you had more thoughts on that, Tim.

Tim Beiko: Yeah, I was literally just typing in the chat. 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 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. are there things that would change their mind? And what are those? So we get basically 2 weeks. Yeah.

yeah, 2 weeks to to address those things.

Alex Stokes: That's fair. 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. 6 second slots. Yeah, is interesting. And again, I'd love to hear any opinions from people here today. 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 we can go and do that work and bring it back to the next. You know, set of calls.

So does anyone have, like a concrete set of data or analysis they like to see on 6 second slots 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. So the the hard part of changing the slot duration is done. 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. 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.

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. but prison is has a prototype, and I think we can. We can easily add it later on on a later fork.

Alex Stokes: Ben.

Ben Adams: And so the the vibe I get is that both slot restructuring and shorter slots are desirable. And it's it's more of a sequencing question which goes first.st So my question for Epbf is, if that goes first, st what would be the slot? Time target as in? If we can do 6, if 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 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. 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. 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! 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. 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 kind of hard. Yeah. So then, it's kind of hard to measure. So in epbs, we were hoping to do this 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 be even shorter after Epps is my question, or would it be the same? The 6th 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. we want to be in a situation in which the full slot is used, entire slot is used. and the minimum size of the slot that we can actually use is determined by broadcast and not by how you pipeline it. 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 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. 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. 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 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. 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.

this is really important to investigate. And I feel like it's also 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.

Alex Stokes: Yeah, put us.

Potuz: I think it's actually the opposite. I mean this the attestation. So for the current slot, time. 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. 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.

Alex Stokes: Okay, are there a number of comments in the chat around? Yeah, supporting these investigations? I would highlight that. This will take time. 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. which again, is just another input to consider. So okay, I think to move forward. Then. 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. This helps reduce the scope of what you know the Cl. Is thinking about in terms of Amsterdam headliners 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.

so that's how I would propose to move forward. In the meantime, yeah, there are some comments around like, yeah, what does it actually mean to get community input. I think, trying to have like a canonical source of truth, would be good. And I'd propose each magicians for this. 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. 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

I think we do that today. Cfi, those 3 eips with the idea being that one of them will be the seal headliner. Then do what we can to. Then, you know, we're again really refine this notion of community input to help make the decision on the next call. So the 3 Aps, 7, 7, 3, 2 with epbs. I think it's 7, 8, 8, 6 for the 6 second slots, and I forget the fossil. Number 7, 8. 0, 5. Thank you. I might have the number off on 6 second slots as well. right. 7, 8, 8, 6 was still in execution. Okay, sorry. I'm getting them mixed up. I can go find the 6 second slots number unless someone has it

is this 7, 7, 8, 2. That's what came up. Yeah, okay, thanks. Part of it. So yeah, either way. I'll get that sorted in the summary and make that clear. and from there I think we're good on the Amsterdam conversation, for right now. in that case we will turn to the last agenda item here. There was a spec question from Etan again. I'm not sure if he's on the call, but I think.

Etan Kissling: Anyhow.

Alex Stokes: Context. Oh, yeah, would you like to ask this question? You had.

Etan Kissling: Yeah, right now. 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 progressive containers. The problem is because the Ssc specs are part of consensus specs repo. But 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. 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

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.

Alex 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? So yeah, this wouldn't be anything super new. 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 essentially a placeholder.

Etan Kissling: Yeah. And it adds extra test folders to consensus backtests that can be ignored because it's unused. Right?

Alex Stokes: Right. 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 restructure things that make more sense. Barnabas has this comment here about handling feature forks better. And yeah, I agree. 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. okay, yeah, seems like, no disagreements in principle. So yeah, Etang will. Justin. And I can work with you on that. Pr. okay, let me do one more check. But I think that's all we had on the agenda today.

And yep, so yeah, we can wrap up a little bit early unless someone else has any closing comments. Okay. 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. Thanks everyone. I'll see you next time.

Potuz: Bye.

Dankrad Feist: I'm.

Mark Mackey: See you guys.

Pooja Ranjan: And.

Marius van der Wijden: Bye-bye.

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