All Core Devs - Execution #217

Transcript

Tim Beiko: everyone. We'll get started in a minute or so.

Okay, Josh, you wanna move us over.

Justin Florentine: Happy birthday to us. Happy birthday to us! Happy birthday to my ether. Friends! Happy birthday! You're 10.

Josh Davis: And that was like.

Tim Beiko: Nice thanks, Justin. Happy birthday ethereum so officially kicking off the second decade of ethereum awkward Evs. So bunch of things on the agenda today, mostly some Fusaka clarifications and then talking through the rollout of the upgrade. And then we can continue the discussion around Glamsterdam headliners. But yes, to kick us off Harry or Barnabas. Do either of you want to give an Update on the Fusaka despots.

Barnabas Busa: Yeah, sure I can get started. So physical has been mostly stable. We have 2 sales that are a bit struggling North Star and Nimbus. so they seem to have different bugs. Loot Star is having a library. b 2 b bug, that they are debugging in the past few days or few weeks. Maybe someone from can give us an update if anyone is here. Otherwise. Nimbus had a Mev related. Bug that should be fixed now. And yeah, participation is up to 94%. So should be good to go. We're gonna be doing some perfect previous testing in the coming days, and hopefully that will also work for all the Cls.

Tim Beiko: Thank you. Any client theme, or anyone else want to add anything to the dead notes? Okay? If not, then there were 2 issues that came up this week that we should discuss the 1st is very much an El issue which has to do with the and which which has to do with the transaction size capping so duncan brought this up on ethereum magicians. Saying that if we cap at 16.8 million gas it would cause some problems for some of the applications. And hired a couple a couple of them on this thread. I don't know if he's on the call today, and otherwise I saw that Tony and Vitalik had responded to this. So

If Duncan is out here. Maybe Tony or Vitalik can give an update.

Toni Wahrstätter: Yes, I can do so. Yeah, I think. It's it's fair to acknowledge. Sorry.

Mark Mackey: I wanna say Duncan is on his way. I.

Toni Wahrstätter: Okay.

Mark Mackey: I gave him the link. He was just having trouble finding the link. But yeah, exactly.

Tim Beiko: Right.

Toni Wahrstätter: Yeah, I think that compatibility super important. I think backwards compatibility is super important. But we had. like a lot of discussions around exactly this topic. It feels like the 30 million were just a problem for many different edge cases like the extent contract or a lot of attack vectors that's just dependent on using everything for the for one purpose, and especially thinking of parallelization. We just get nothing from it. And then there were also concerns from Ckvms around 30 million. So this was this were the reasons why this was lowered. and it seemed like a good trade off between getting some more scalability, some more security without really affecting many users.

Tim Beiko: Okay, thanks. I see Duncan is here. Duncan, do you want to give more context on the actual issue? And then we can go to Ben.

Duncan Townsend: Yeah, thanks. Sorry about that. I had a trouble finding the the video link.

Tim Beiko: Almond.

Duncan Townsend: Yeah. The bottom line is that decreasing the transaction gas limit from 30 million to 16.8 million is a breaking change for application developers. And yeah, it's causing a lot of complexity in our application. I'm sure there are other ecosystem wide impacts. It's frustrating that this change appears so late breaking. I like to think that I do keep reasonably well appraised of the acde process. And so, you know, having this change be 3 weeks out does not grow my confidence that a thorough ecosystem impact review was performed.

Tim Beiko: Thanks Ben.

Ben Adams: I mean, I'm I'm sympathetic to the the issue. But one of the examples that uses given that uses over 16 million, and it probably uses more now. Was deployed in 2,021 when the block limit was 12 million, so it would have been possible. And that's sort of like a a a complete loop around every single attached contract to to a pool. So essentially, that would taken to his extreme that would need a transaction of infinite gas. based on yeah, how it's written, because people could keep adding pull pulls to the to the contract. One of one of the issues is supporting

these larger transactions reduces the overall gas that can be offered to the network. So there's like a a balance there. So if you wanna if you wanna do more transactions, then overall and have higher block gas, then we need to reduce how much any individual transaction can do.

Vitalik Buterin: Yeah, I mean, I could just elaborate a bit on some of the arguments I gave on magicians. Basically, I think like one is that we have had a yeah history of situations where, like we like, we historically have not followed a rule that if X is a breaking change, then X cannot be done right. And like, there have been things in the past that we have done like, for example, some of the gas limit increases are one and then some of the the removal of of self destruct is another one, and I think that one's pretty instructive because there is no case that it was secure security critical that one was very significant gain in client development simplicity. But like, if we had wanted to, we could have done without it. And I think, the yeah, like, the reason why I want to do these things is because if we don't, then effectively, we're suffering a permanent penalty in order to avoid a 1 time switching cost right? And generally. Yeah, like.

the thing with invariance is that the more invariance you can have, the more they often have positive benefits to simplicity or to security, or opening up new client design, choices that often we did not even realize right. And so like with the self-destruct removal. For example, like we gave ourselves an extra invariant that bounded the number of storage slots that can change in a simple block, and that allowed a bunch of things to actually, yeah, in things in client development and caching to become quite a bit simpler. Right? So. I, yeah, would argue that also the kinds of breaks that are here, like, they yeah will happen in the context of things that we want to do in the future, like multi dimensional gas, like per coach chunk gas, pricing like, very serious repricing of breaking piles. And so I do think that we need a procedure for being able to do to do things like this?

I, yeah, right? I think, is that. Yeah. See? Is, is that a breaking change or not? I mean from the arguments that I've right. The question is also like, is the way that we've looked at these things historically is like breaking for how many users right? And like what level of inconvenience? Right? Because, like, if there's an application that has no natural path for rewriting itself, that's 1 thing. But if on the other hand, we're just talking about like, for example. any of the like bot activity, like, I'm personally, yeah, totally fine. Making changes that force mev bots to read to rewrite their code. Right? So it's like, like, that's 1 of the balances. I mean, I do think we should.

How be more thoughtful to having a procedure having a a procedure for this? I mean, I am like perfectly happy deal delaying things like this. I'm also, I'm happy. Yeah, to like having having time delays and and explicit deprecations is, I think, something that's good. Having explo explicitly. Yeah, like, specified invariance is good having, you know. And we continuing to like, have lists of things that we keep in mind as we change gas per gas prices is or is good so right, wouldn't 30 million per transaction be enough? I think the one use case that I would worry about there is distributed proving right? Because, like, basically a yeah, distributed prover is going to be yeah.

constrained by yeah, like, basically like the way that it parallelizes is it paralyzes across different participants? Right? And the way Ckvms work is that, like basically, all of them, they parallelize between transactions. They don't parallelize within transactions because parallelizing within transactions is like 10 times harder. Right? And so we yeah, the like. The value is basically that the more we can like right now, probably. Yeah, there, we're not going to be in a position even with like a 10 x improvement in proof of time to be able to say, Well, let's have a distributed prover that would actually be able to handle a worst case block which involves a single prover keyword transaction. That's across 30 million gas, right? Yes. And even when non-distributed, these kinds of things are an issue, right? So I think, in terms of right, also paralyzable execution. I mentioned that right? So just like in terms of worst case mitigations.

There's a huge number of these like weird edge cases that exist within transaction boundaries that just don't exist at all between transaction boundaries, because between transaction boundaries, like basically all over the State gets flushed. I mean, except for obviously in the state tree itself. So that's kind of how I yeah. I would argue the case for doing things like this. In principle. I mean, I definitely don't have a strong opinion personally about timing. And like, I'm actually yeah, like, I think it's reasonable to be conservative on timing for for things that break things.

Tim Beiko: Thank you. There were a couple of comments in the chat. I don't know if anyone wants to speak up about them.

Duncan Townsend: Yeah, I I was asked to explain the use case. yeah. So you know, to be clear. I'm not arguing for no limit. I think having a limit is a really really good idea, especially in as much as it means It unlocks scalability, parallelism, and also constrains the design space for dap developers and makes it easier to reason about the system. Really, all I'm arguing is that the limit of 16.8 million is too low. Specifically my use case. You know, I can't speak to the was it 100 and something 1 million gas that the contract I link to consumes today, but I can talk about the transactions that I develop, which on chains with oh, I suppose I should back up and say I represent 0 XA dex aggregator. So we're building Erc 20 swaps that will touch a whole bunch of different pools to achieve best price.

And when gas is cheap and liquidity is highly fragmented, as we see on many. Evm. L. 2 s. 16.8 million. You can blow past that in a $100 $1,000 swap fairly easily, and if we scale l. 1 and bring execution costs down on l 1, we would likely see similar gas consumption for low notional swaps. And so the problem is that the problem of optimal Dex aggregation routing under a low gas limit is Np-hard which we've developed approximations for and can solve this problem in production, but it significantly increases the problem, and I think is one of the reasons why you don't see a thriving competitive Dex aggregation ecosystem on chains like Solana, because that constraint is so low and the problem is so difficult.

So, for reasons of competitiveness, I think increasing the limit to the historical block gas limit of 30 million is a very good idea.

Tim Beiko: Let's do, Ben. And then Tony.

Ben Adams: How much is the gas on on the aggregation from storage versus calculations? So would, for instance, repricing non storage opcodes down which is planned. Help resolve that.

Duncan Townsend: Most of the time. and you know this depends very heavily on a lot of specifics, but most of the time you are storage. Limited exceptions would be things like Pendle finance curve finance. Really anything that has to do Newton-raphson approximation of a constant function. The reason why you couldn't do 2 transactions is atomicity. Slipper checking has to be performed at the end of a swap, and so you need to be able to roll back the entire swap from the moment the user's tokens are moved in order to achieve that atomicity and avoid some really bad impacts of Mev. And so you know, again, with Solana, making the comparison. not being able to achieve that atomicity in protocol causes people to seek out of protocol solutions which are typically centralized because you're making a promise for multi transaction atomicity that you can only guarantee based on some sort of handshake agreement rather than you know, actual crypto economic security.

Tim Beiko: And Tony.

Toni Wahrstätter: Yeah, I think the the concerns here are totally valid. And I and I want to stress that I definitely acknowledge them. And also, I hope this you had that feeling during my the magician's replies, but I think in the end it's just a trade off, and we have to take a decision on where we put that point. Now, we are at 45 million. So 30 million, we can be like, okay, hopefully, there was no use case in the meantime. That needs those additional 50 million guests. I think that's a fair assumption. But I still think I'm going to 60 million, which is currently the default on the defnets. Is, is there a better choice? Just because we get those additional benefits from parallelization?

And of course we affect slightly more users. but if this is exactly the trade-off here, we will always affect some users. but other users will benefit from us, being able to scale. And yeah, so totally valid. But I still think we should stick to the limit that we have.

Tim Beiko: Yeah, I I guess, like, yeah, the define. The actual limit is maybe part of the question is, you know, we originally had 30 sets, because it was, I think, the gas limit when the eip was drafted. And obviously the gas that gets gone up since then. And then it got lowered at the the 16.8 or something. But is there a number like, yeah, if we did it, the 20? Or is there some number today that we feel would actually allow most. You know, large use cases that have been used in productions that are like somewhat reasonable. and yeah, we're still asked about it, and.

Toni Wahrstätter: Just from the numbers we know that around. So in I did a 6 6 month analysis and the 3 years analysis. And it's around 0 point 0 3 8. So 0 point 0 4% of the transactions that were affected. And it's even lower for the users, because it's mostly people that use certain contracts. So I think the vast majority of them was Xen. So different accounts using the Xen contracts. This accounted for like the majority of it. I don't remember how much, but I think like 30, 40, 50%. And then there were a lot of batch use cases like batch ens registrations and batch payouts, and all that kind of stuff that.

Tim Beiko: Do you have a link to this.

Toni Wahrstätter: Edged. Yes, I have a link. Let me. I post it into the. I will post it into the Acd discord right now, because I am on a different device than mine. like, let me check here. Okay. I posted it right now.

Tim Beiko: Okay, thank you. I'll cross post it in the chat here just for people referencing. Oh, thanks. Josh, yeah. And I guess. Yeah. So there's a trade off here. 1 1 approach we could take is, you know, we set a relatively high limit with the expectation it might go down in the future. The problem is, then, as soon as we set the limits, people will rely on it for something. So there's a risk that if we say, Hey, we do 30 million in this fork, and we want to take it down in the next fork. you know, like there, by the time the next fork happens we by the time the next project happens we we can't lower it.

but yeah, we could also commit the same like. we put a hard limit today at 30 million. And then we deprecate these yeah. So it's actually pass some amount on the next fork, and it gives time for people to migrate. and I guess on the like, yeah, on the 0 X use case, like, what would happen if this cap existed today, and someone was trying to do a transaction that you know touched a bunch of routes. is it just that the transaction would fail. Would the 0 X, I assume the ui, or you know, the front end is able to catch this in the wallet to some way that like? Yeah, well, what? Like.

Duncan Townsend: Yeah, I mean.

Tim Beiko: User like, what what would the experience be if, like you. you try to exceed this limit today?

Duncan Townsend: Well, so today, it's a non-issue for Xerox, because we've developed the technique for handling this and producing optimal routes under the limit. And it's actually probably better for us because it cements our position in the ecosystem. What I'm saying is that the problem is, if you want there to be more competition in the solver searcher, aggregator ecosystem. Then you are raising the minimum level of technical skill required in order to produce valid routes by requiring that they also solve for the transaction gas limit. because right now the problem is largely limited by profitability due to the relatively higher gas prices on l. 1 compared to L. 2.

Tim Beiko: And so the gas, the transaction gas limit is very rarely a problem.

Duncan Townsend: Right. If if a potential Dex aggregator were to produce a route that's above the limit, the front end would catch it immediately. Because you can't. You obviously can't submit a transaction with that high of a limit.

Tim Beiko: Got it. Thanks. And I guess. is there a future where we would imagine going even below the 16 million? Because, yeah, I I maybe don't have an intuition, for what's the lowest we would actually consider if is that 16 million, or is that yeah? Is there an argument to say should be, you know, 10 million or 8 million

Ben Adams: I mean 6 at 16 million. That's 16 million, for, like 45 million gas, you're looking at 3 transactions that can be run in parallel. And then, you know, when we go to a hundred 1 million, yeah, it's it's a lot more. And we're specifying that you need 8 cores. I'm run a validator. So essentially saying, Well, you can't use it. This entirely single threaded is. you know, wasteful because we have the capacity to increase using parallelism, but setting the the limit higher causes of the worst case to get worse. But setting the limit lower in the situation where the block gas is getting higher. I don't think necessarily gains much.

Tim Beiko: Vitalik, you're gonna say something.

Vitalik Buterin: Yeah, I mean, I've like, thought about this. And even talked through some defi people. And like, there is a case to be made that a kind of theoretically spherical cow better ethereum would be if you push the gas, the transaction gas cap all the way down potentially to low millions, but with some specific carve outs for contract for contract creation. Obviously as but like, the reality is that the benefits of doing that are low. So like one. Basically, in all of the cases where there are benefits of doing that, you could do specific stuff like, say, only low gas transactions are eligible for fossil or only low gas transactions are eligible for account. Some account abstraction, feature, or something similar. So it's

like, the balance is basically, yeah, getting like, how much you you would get in terms of some of these nice separate, nice properties in terms of like client side paralyzability and dealing with quadratic attacks, and so on. I mean, like, what's what this brings to mind. Right is back in 2,016. When we had our most serious dos attacks, we pushed to the gas limit all the way down 500 k. And that actually like, let the chain run while while those bugs were unresolved. So. But it's like once you. you go lower the yeah. Like. Benefits do get accrue. Keep accruing. But the returns start marginally down like start decreasing quite a bit, and also the costs start increasing increasing quite a bit. Right? So like once you go into

single digit below single digit millions then I think, starks start start becoming impossible. And then potentially. They're like just the number of people that have to rewrite keeps going up so like, I like, I, personally would like, don't feel a strong need to start pushing into like lower, single digit millions or anything like that. And like. I, I feel like, Oh, there we go! That's a good dash. a good chart from from Tony. There, that just shows how the portion of stuff that breaks is like base, basically exponential.

Tim Beiko: Thanks. And, Daniel, yeah, thanks for putting the sorry to go, Tony. And then Daniel said that you know if we remove the contract size limits, then the transaction gas limit also becomes in a way, the the contract size limit. my proposal to move this forward would be to consider having the limit be 20 million instead of 16. It seems like it addresses some of the cases that were that were raised. I also think 20 million is maybe a nice number, because the gas limit is 40 or 36 million. Now we expect, or sorry 45 million. We expect to probably go to 60 ish around Fusaka. And so 20 million gives us the ability to actually run. In the worst case, you know, 2 transactions, 3 transactions in parallel. If we're if we're doing parallel execution, whereas if we're at 30,

it's like until we raise the gas limit to 60 million, there's still cases where maybe we're not able to to to paralyze. So I yeah, I don't. That would be my proposal, and that you know, this this 16 million number was basically just the power of 2. So if 20 is slightly better, yeah, I think we could make that change. And.

Toni Wahrstätter: Yeah, I think it us into one direction of the trade-off. We should be aware of that.

Tim Beiko: Yeah. And I think the feedback we've gotten is we're a bit too far in the other direction. But yeah, that's good.

Duncan Townsend: Yeah, yeah, I just put out a call to some of our data guys at Xerox to do some analysis for like gas consumption by notional trade size on low gas. L, 2 s. So I can also provide you guys some some hard numbers specifically for Dex aggregation on the impact of this eip. But that'll be later today.

Vitalik Buterin: Yeah, perfect. And would you mind like also finding some transaction hashes? I think, like specifically of some of these like, create, like massively multi atomic arbitrage, things.

Duncan Townsend: Yeah, we're not in the business of arbitrage. But but yeah, right? Right? I know. Yeah, it is.

Vitalik Buterin: Oh, sure! Me too.

Tim Beiko: Okay? And so I guess there's 2 things you can do, either. We like soft agreed to go to 20 million dollar 20 million gas now, and if we if we find something that disproves that being a good number, we change it again, or do we prefer to wait? a week or 2 to make the final call. This kind of ties into the fork deployment cycle like if we need to write some tests and update the clients. I I imagine this is fairly simple. But yeah, the clients have a preference between coming to a decision now and potentially reversing that or waiting a week or 2. and and yeah, having it be more final. Maru.

Mario Vega: Yeah, I would like for us to make the least amount of changes possible, because it has not been easy to go through all the static legacy tests and finding out which ones break because of these transaction gas limits, has been extremely hard to put it like softly, and so the least amount of changes that we do. The transaction that has limit cap the better in the testing.

Tim Beiko: And right.

Mario Vega: Okay.

Tim Beiko: And right now the testing team is assuming we're doing 16.8, not 30. Is that correct?

Mario Vega: Exactly 60 million is the is the one that we.

Tim Beiko: Okay, then, in that case let's leave it at that, for now. Get the numbers, and if we are to change it, we make that decision on the next call 2 weeks from now. And this gives us 2 weeks. And I, if if we were to change it in 2 weeks, Mario, like I'll big of a change. Would it be 10 like once you've identified all these tests? Is it easy to go back? And you know.

Mario Vega: Yeah. So the approach is that we have to analyze what exactly test is doing to be able to not break it. And still, like, provide test coverage for these legacy tests. We have the the procedure now. We didn't have. We had not done this before. So we now have the procedure, it should be easier, but I I still would like lean towards changing it least less frequently as possible. In my opinion.

Tim Beiko: So less frequently and later, is better for you than more frequently and sooner.

Mario Vega: That that's correct. Yeah.

Tim Beiko: Okay? So in that case, okay, let's leave it as is now make a final call in 2 weeks. If we are to change it. And yeah, just give us some time to discuss it. And yeah, look into the details and the edge cases. So anything else on this. See if we can make the final call on Monday instead of 2 weeks from now. I don't know how quickly we can get the numbers and get through them.

Duncan Townsend: I can probably have numbers, at least for 0 X. By tomorrow morning.

Tim Beiko: Okay, so let's right. Okay, if you have that, let's discuss it again. On Monday's testing call. And yeah, if we feel like we have all the information to make a decision. Then then great and at the very least, if it's leaning towards, we think we're gonna change it. Then we'll know on Monday that we we need to set up a new definite. And we can also figure out the exact right value. okay, anything else on this. Okay, well, thanks everyone. Thanks, Duncan, for writing this and coming on. okay, next up is another spec issue. This one is more of a cl one. Oh, it's actually just a cl one about pure. Das it's come up in the thread that basically the increased requirements on cl nodes can affect can affect some of these community staking module like Lido and Rocket will have.

and and I know that this is the El call, but it's a pretty significant change. So I wanted to leave some room for people to discuss it today, and at the very latest. It feels like we should resolve this on next week. Cl, call. So if we, if there's anything we can move forward today on this topic, it would be good. and I don't know if either Dimitri who raised the issue, or anyone who's engaged on the Pr. Send the call or.

Dima Gusakov: Yeah, I'm I'm here. Thank you. Team. So the quick context about the thing and why we are discussing that in pure das, there is a constant that determines how many samples of this new blob samples, which is 128. Right now Cl Node is obligated to custody, depending on the number or the eth amount attached to the validators to the node. So there is a feeling that the current number, which is 128 or 4,01896. Eth. Attached to the node being the top requirement for the node to be a super node might have a like, possibly a negative effect on homestakers. Specifically, home stakers in the fractional staking protocols like rocket pool or Lido Csm or stater, or whatever else protocol where people only provide a fraction of the capital to custody a full 32 e. For validator, or

in the future, maybe Oxo to validators as well. So the the proposal from my side, from my aside from Csm side is to increase this limit from like 4 times from the current value, so that the obligation to be a super node, and to custody all of the segments will appear. Once there are 512 validators attached to the node, or 16,000. Eth. I personally think that this wouldn't make a significant change regarding professional operators and large notes that we already have in the network, because, from my experience, negotiating with the professional operators almost all of them have at least 500 validators, and then balance validators attached to the node right now. so it means that their nodes would still be mandatory super nodes, while it will make a curve less stiff, and would ensure that both storage and bandwidth requirements would not go crazy high, for homestakers like myself, for example, who are running validators from home, using a very common hardware like Dap Node, for example.

and who are limited by a household Internet connection which might be not super perfect and given that the requirement would result in not just storing or custody more segments, but also downloading them in a limited 4 second period. Oh, I believe that this limit can be raised, especially given the initial rationale behind selecting the initial value which was 1st of all compiled, I believe, either a year or year and a half ago, when functional staking was not such a big thing, and the second is that I believe the rational was just one segment per validator. Maybe it is not a very robust thing, and there is a chance that we can increase the value, so that we will allow homestakers to still maintain relatively low requirements both to their hardware and to their bandwidth.

Tim Beiko: Thank you. See, Asgar has his hand up.

Ansgar Dietrichs: Yeah, I just wanted to say that I would argue, for we should just be very aware that this is not primarily a technical question, but more kind of philosophical question of sorts, and I personally am pretty strongly opposed to this change, because I think in principle, what we're trying to achieve is trying to basically have as few economies of scale as possible in staking right? Because that those always push against solo stakers and send this specific concern is not about solar stakes. But that's kind of the point, right? Because in principle, staking 32 Eth and staking 64 Eth already like should basically be twice the effort, because you also get twice the payoff. Right? So of course, you need twice the capital. But ideally, you should also run basically 2 nodes in 2 locations with twice the bandwidth and twice the everything

in practice. Of course, we can't actually fully get there, but that is actively bad. And so like. The more we are leaning into economies of scale, the more we are making life harder for solar stakers, especially now that the staking ratio is increasing more and more, and the kind of the yield comes down quite a bit. And so the margins get slimmer and slimmer. So I personally think at least we should be very, very careful with this kind of change. And if you look at numbers right like so for people that actually fully stake their own. Eth, we're basically talking about this change like from you could already, you know, like you could now stake, I don't know. Up to 4 million dollars of capital before before you'd even start having to like classity more than the very minimum of of columns.

I personally think that's excessive. I understand that this is specifically to enable these use cases where you have, like a very high multiplier between your own capital and the underlying capital. But in that case, there's just a lot of fees that should then just go into making sure you can actually and still do that. I am sympathetic to this in the sense that I think we should look at this into solutions like someone like that being able to just run nodes in multiple locations that then communicate with each other to basically like, so that no one location just has to custody all the columns or something like this. So I do think we should try to facilitate this, but I personally think that the easing the requirements and leaning more into economies of scale is the wrong approach. But I do think people can have different opinions here.

Dima Gusakov: I'm not quite sure that the proposed change is leaning towards the economies of scale. Maybe like is either my misunderstanding of how the protocol works or my bad English. But I'm not quite sure that we are talking here about leaning towards economies of scale. I believe we are talking more here about? How many nodes would be affected by that, and raising the limit, like anything in between one validator and 500 validator is. can barely be considered an economy of scale. And again, as I mentioned, from my experience with professional operators, like all of them, they're trying to maximize what they, what they are earning. So they're trying to minimize hardware costs. And that's why they all already run more than 500 validators. And the question is, how much do we affect those running? Not like a 500 validators, but

say, I don't know 50 validators, for example, in Csm. Or in light of simple Dvt, or just in Dvt clusters. So imagine you have 7 Homestakers who are now building a cluster of 7 nodes. It means that they will need to have each 7 times less capital. But they will all have to run the same number of validators just because of the fact how Dvt technology works. And in this case, if they're say running to, I don't know 30 validators or 40 validators altogether, the steeper the curve would be, the more they will be affected, and from my personal experience right now, like any change that makes it harder to become homestaker, makes it less profitable, less convenient, less comfortable, is

essentially net negative, because even with the current conditions that ethereum has to offer, that protocols on top of ethereum has to offer, it is still extremely hard to get like additional 100 operators on ethereum network. So for me personally, there is a chance to make a curve less steep, so that we will still be able to allow for, like a semi professional node operators to be not, or it's like large homestakers. Let's call them this way, not to get affected that much by this team.

Tim Beiko: Yeah. Bonus.

Potuz: I want to mention that there is an actual technical side to this. I want you guys to go and look into that thread on discord on R. And D. Francesco, for example, brought up that it might be beneficial to have a distribution of nodes where we have more nodes. That custody, the minimal number of columns. And then this bimodal distribution in which we have these nodes. And then suddenly we have nodes that are super nodes that have everything these nodes like they do different kind of things. For p. 2. P. The super nodes allow to like, reconstruct the blob, reconstruct the blob, and serve the other nodes, and having a bunch of nodes in the middle ground, might be detrimental because it increases the number of subnets, and it just degrades blob propagation. So it might be worth, just from that perspective, to increase the number of validators that you run while still keeping the minimum number of columns

according to numbers. I mean, of course, this would affect depending on what sort of like the leverage that the staking pool mechanism allows. I believe, with rocket pool. I think Nixo just pointed that this would be like 4 million or something like this. with Csm. The numbers, as far as I can see in the from the Pr. You would need about 36, Eth. Not more than this to hit this this limit in which you start having more columns to to to keep. So I think that's not so so large of a number. I think we do have home stakers that do stake for about 36 East. I mean, many of them would actually like split their own validator and try to take many keys from from a protocol like Lido, because they just earn more. And I think we do want to incentivize this kind of staking, because this kind of staking is what's taking out stakers from institutions. So I don't think that this is

this is something something dramatic, I think, in that Pr. Many client devs supported it. and it seems to me that research also supports it, and it seems that it's not dangerous. It might actually even help on p. 2. P. Propagation. So I don't see why to be opposed to this.

Tim Beiko: Thanks. Thanks.

Alex Stokes: Yeah, so I think there is this general conversation to have. And yeah, you know, having another look at how this custody works and how it scales, you know, that seems to make sense. Given all the above arguments. there's a separate question, though, of like, when is the right time to do this, I think. given where we are in the R&D process. Also, a key factor is we don't expect to like, scale the blob significantly immediately after Socca. I think we'll have time to get to a place where this would even start to be an issue. So I propose we kind of table this change, for now keep looking into it, and you know, as we need to do something about it down the line, we can pretty easily.

Tim Beiko: And you mean table. This change from Fusaka completely like.

Alex Stokes: Yeah, yeah.

Tim Beiko: Do people feel about this? yeah, you know, we can make a final decision of this on Monday as well. Like, I think it's important that we at least discuss it now, and people have time to review. But yeah, I I'm fine making the change, making the decision on Monday or at the latest on the Cl call next week. go ahead. Yeah, let's try to. I I guess. Actually, yeah, is it better to do this on the scale call, or on Monday, like, I know that there's a lot of.

Alex Stokes: I think, as quickly as possible. I would have liked to make a decision today. Let's aim for Acd. Then I think we might sort of nominally have more cl participation there. So.

Tim Beiko: Yeah. And we can at least yeah. ping the cl and try to get them to. If they can't show up. Articulate their reasoning. Async. Ahead of the call. Okay, let's do that, then and then there's obviously the Pr people can engage on. I think anything else on this before we move on. Yeah, but there is Frank, I think. it would be good for all of the Cl teams to either share their opinion before act or on the call and I guess the question is, if the Cl teams are mostly gonna look at it from an implementation perspective? Or do we expect them to look at it from a process or philosophical perspective, as well.

Parithosh Jayanthi: Cause. I think that was the reason it was brought up in Acd.

Tim Beiko: That. Okay, yeah. Barnabas.

Barnabas Busa: Yeah. So I've tested the change on, and all the different Cls can adjust it as expected. So it's a complete change. There's no technical question about it.

Tim Beiko: Then I think I would be inclined to make to give people some more time to voice like their views on it at that level and make the call next week on this Pl. Call rather than Hdt, even if it's a bit further out and.

Alex Stokes: Yeah, I mean, so it is like a 1 line change. Literally, it's just then this implies probably more devnets, more testing like it. Just.

Tim Beiko: Yeah, do we want to actually do it? Yeah, I mean.

Alex Stokes: Yeah, I mean, my take is, we want to do something here at some point. I just don't think it's right now.

Tim Beiko: Okay, on. Skype.

Ansgar Dietrichs: Yeah, I mean, I would just also say, for process reasons, this is a big change, not not technically. I understand this technically, it's pretty trivial, even though it would imply no devnet and everything. But it is conceptually like a very big change. and also, I mean, as was even brought up when describing it. It's not something that was only said a couple of weeks ago like this, specific value has been in the spec for like over a year. So people had a lot of time to look at it to potentially propose changes. I just think it's too late into the process to now discuss like a very meaningful change with basically not giving people a lot of time to like to form opinions, to not have this debate. I really think it's a meaningful enough topic that would require a lot of debate. And I think, just rushing to a decision.

I think it's just not appropriate. Given the kind of fog process.

Tim Beiko: Right. But I guess yeah, to be clear. we will still be rushing to a decision. The decision would just be maintained. The spec, as is right. So if there's if there's anything that we would learn in the next week that we think could help shape the decision. I think it's worth trying to do that. If we don't think so, then yeah, I would also bias towards not making changes at this point. what sorry subway is not just blob parameter.

Barnabas Busa: Basically, he wants to change the value in the Bpo.

Csaba Kiraly: Yeah, Vto is is a interesting concept. But we will be more more running into Ppo, not just being a parameter. Only change and.

Tim Beiko: I mean I don't. I guess.

Csaba Kiraly: Sure.

Tim Beiko: An option is, we could not have this launch with Fusaka. And then, to the extent it becomes. Yeah, more urgent to address. We can overload the vpo to also have this

Csaba Kiraly: Yeah, exactly.

Barnabas Busa: Yeah, we also assume that the Cgc value doesn't go down. By the way. So once we introduce this technically, you're not gonna go down in your Cgc value unless you yeah. Neutral. dB, but.

Tim Beiko: Right? Okay? Then I guess I would lean towards not making this change. And yeah, just because we're selecting the process trying to minimize, minimize the amount of changes to the specs. we should still have the discussion and think through kind of the the design principle implications. Further. But if we find that there's something so important that needs to be addressed, we can do that in one of the Vpos but for Fusaka. We can admit this change. Does that make sense.

Alex Stokes: It makes sense to me. But I guess just clarifying. Are we making? Are we starting this today? Or we're just stating it as a summary, and then we'll take this to Acdt or C next week.

Tim Beiko: I'm fine not discussing it on acbt if people here okay with it. But.

Alex Stokes: Okay? So yeah, let's just say, this is like the the preference right now and then. Yeah, we can finalize on next week's Acdc.

Barnabas Busa: Well, on Monday we're gonna find out if we're gonna need a new that, anyway, regarding Max transaction. So I think it. If if we can make a decision about that. Then. On that call, I think we can also make a decision about this.

Tim Beiko: Yeah. Like, if we don't need a new definite, then I think that would lead us much more heavily towards not including this change. And yep.

Alex Stokes: Agree.

Tim Beiko: Okay. okay, anything else on this one before we move on. Yes, we are discussing the transaction gas limit gap on Monday, Mario. Okay? And then the the last 2 second thing I want to discuss is just continuing your timeline discussion. We had last time. So Alex had proposed a timeline which would mean that around September. 1st we get the fine releases for test nets, and then for test nets through September, October, and potentially main net early mid November and then, you know, some concerns about working during dev connect but

I think any of the proposed schedules that get us a fork before on disconnect, assume that we have the client test net releases out around September first, st which is a month from now. The people think this is realistic, are there things we should be doing to make sure we can get there? yeah. are things we should not be doing like. For example, you know, if we do change this transaction limit cap. The client teams feel like it makes a difference between whether they can have a test and release in 4 weeks or not. Yeah, Sean.

Sean Anderson: So for lighthouse. We were talking about this yesterday for us. Yeah, the 4 weeks for the release is like aggressive. But we think doable. We're a little concerned about like there's some adversarial testing that we're trying to start doing right now, and if that were to reveal some bad stuff that might push back the timeline a little bit, but so maybe like an extra week or 2, padding would be good for the 1st release. But we still want to hit the Dev connect timeline. So, yeah, that was our thought process.

Tim Beiko: Thanks anyone else. Okay? Then, if there's no other major comments, then I think, yeah, we should basically plan everything as though we're releasing the 1st testnet on September first.st Obviously, if we find a major bug, you know, we should always fix that, and that might delay things. Then, in terms of the test nets? Did people have preferences between forking sepulia first? st Hudi first, st and whether or not we should fork Holeski

Alex Stokes: Doing husky. The upside is. It's just another sort of strong goal, so to speak, Downside is. It's just another attention sync.

Parithosh Jayanthi: Yeah, I think the only benefit of 14 is that we do have enough public nodes. So we will collect some p 2 p data. But yeah, the downside is extra time.

Tim Beiko: There's a comment by still saying that. You know, we talked about doing some non finality testing with the releases. Should we use Holesky for that.

Parithosh Jayanthi: Yeah, we can use Host Key for that. We also wanted to spin up a different network for non finality. We're just waiting for like a proper final spec freeze, and all the other bugs to be sorted out before we spend the money on non finality test.

Tim Beiko: Because then, you know, one schedule could be something like we release. you know, on the week of September 1st we fork Helesky on the week of yeah, if we have 2, basically, if we if we have 2 weeks between every test net and we fork all 3 that brings us to October 15, and that means, if we want to wait a month after the last test, that we would be forking during that connect which feels feels not ideal. So if we do want to fork Holeski, then we probably should do something where maybe we have like. and a 1 week between the release and Helesky, and then, you know, a week or 2 between Holeski or between between Sepulia.

Parithosh Jayanthi: We could use the same release for wholeski as well as sepulia, and one of the benefits of having non finality testing on hold key as well is that it shows people explicitly that we want to deprecate the network, and it'll avoid the scenario where my infra has worked well. So I forgot to migrate.

Tim Beiko: Right? So yeah, 1 1 option could be that, like. you know, week of September. 1st we put out the releases for Heleski and sepulia week of September 8th Forks. Because I assume we're controlling most, if not all, of the nodes on this. So we can. We could clearly like update in time, and then week of the 7, the 15, th the polio forks. We we put out another release after that, and then we Fork, who d. On the week of October 29.th Assuming all of this goes well. It means we could fork Sorry, like, yeah. Sorry. On the week of September. September 29, th and this means, if everything goes well, it means we can fork Mainnet on the week of

October 27, th or or November 3, rd which are yeah, which are right before death connect? yeah. So I guess my, yeah, my schedule is basically with Barnabas posted, but then potentially shifted one week earlier on everything so that we can do wholeski one week after the client releases. Given that, we're gonna do non finality testing and and that we control most of the of the nodes. And and yeah, we don't have to like 100% finalize this today. But it would be good. it it would be good to do so in the next week or 2. especially if, like, yeah, we are needing to set these blocks for for September first.st

I guess I don't. Yeah. Maybe it a good way to move this forward is that if all the teams like Pen Ops posted their preferences, but I think it might be good to hear from all the different teams by next call, and we can kind of finalize the happy path dates by next call based on the feedback from teams. Does that make sense? Did you want to see how part next week. Okay, I have a plus one. But I think, like, yeah, by this point, everyone knows kind of what the constraints are, and you know how we can approach them. So yeah, let's let's let's try to get a final set of dates on on next week's call. And obviously, if we find a bug and things. You know things are problematic. We should always like revisit that. But at least, having, like our happy path, set of support, blocks would be good.

Okay, anything else on the rollout? If not, then yeah, we can use the rest of the call to discuss Amsterdam. We discussed it. A bunch in the past couple of weeks. On last week's cl call. It seemed like there was strong support by the Cl teams about epbs. Still some open questions around potentially some other headliners. So we cfi the Epbs delayed execution, and fossil, I believe, as candidate headliners and then on the Cl. Call. We didn't want to discuss block access list too much, but it It is kind of the main thing that's come up on the El side. And so I guess. yeah, how do people feel about making block access lists? Kind of the El headliner?

are there any objections to this? At this point? It seems like the kind of okay. least controversial, and also somewhat smallest of the headliners. And so, yeah, I feel we may be able to lock this one in on the El side today and then finalize the discussion about epbs, shorter slot times than possible next week. Okay, so bae su guest, like bals Francis.

Francis: Hi, just to kind of like express basis opinion on this a little bit or preference. For the el sides. We kind of like prefer delayed execution to bals, and we like. I think we like both, and the reason we prefer, like delayed execution is that we think delayed execution can provide benefit to both the l. 1 scaling and l. 2. Scaling, and also provide benefit to faster confirmations. It moves the actual execution to the next blocks, which I think it's a very good property to have. And it has, I think, from other analysis, has 80% of the benefits, for as opposed to for of Pbs without the the Ptc, the new folk choice rules and the other stuff. So yeah, that's just like our opinion, just want to express it. But if everybody is like already aligned on that

I guess that's okay, too.

Tim Beiko: Yeah, I guess. Yeah. 1 1 question. I just posted in the chat as well. But from what I've heard of people supporting delayed execution. It seems like they would also want to do block access list. But I'd be curious to hear from fine teams like M. Yeah. Like, if we do delayed execution. Do we think that this is This is somehow blocking for for block access list? Okay. Beizu says yes, and.

Justin Florentine: I wouldn't simplify it down to a yes, Tim, it does change our math a little bit.

Tim Beiko: Yeah. yeah. And I guess this is kind of weird, because you know, the late execution is mostly an El thing. Epbs is mostly a Cl thing, but they're kind of competing because they're both about those slots, restructuring. And and yeah, it seemed like all of the Cl teams, relatively strongly supported epbs, so I yeah, it's either we 1st make it an ebbs versus delayed execution decision. And that's gonna kind of go through another awkward cycle, or we make the call around around block access lists. And you know, commit to that, and then see whether or not we also do the execution. Yeah, on the bar.

Ansgar Dietrichs: Yeah, I mean, I agree with you that the kind of decision process is a bit weird here because of the elcl interactions. I mean, I think, in principle, we probably just all agree that if we do ups, then the El headliner should be block level access lists. I do think that in a way, maybe I don't know. It's weird to make that conditional decision. But like, I do think, and I also think, that the Cl. Will choose epbs. But I do think in a way we should not preempt like it is weird to just lock in bls now and then. If the Cl. After all, says no! Actually, we want to push Epbs to H. Star, and we're doing 6 second slots in Glamsterdam. Then, of course, I do think we should revisit. And actually I would prefer delayed execution for us to do, or at least consider that over blocks list.

So I don't know, like I think the really the main decision for Grumpstem is this. Ebbs was delayed execution, and I think that is more a Cl. Question. I mean, I do think at this point it is becoming pretty obvious that we are going to go with epbs. But I still feel like, in a way, maybe we should just like only conditionally lock in block lab access lists to saying, like, okay, we assume it's going to be epbs, so we say, block level access. But we revisit this. If the Cl surprises us, basically.

Tim Beiko: Yeah, I agree. So I kind of feel like I'm passing the buck here. But like, I think we can probably Cfi block access list like it seemed at least as there's as at least as strong of a content consensus on this than the 3 other ones we have. Cfi. We could make that like the 4 candidate headliners, and then we can make the call next week about the Pps, which is delayed execution, and then, assuming we do delayed execution or sorry assuming we do, I think, assuming we do epbs, then it would make sense to just also include block access lists. If we don't end up doing the Pbs, then I think we'll need some more discussion.

and it is a bit weird in terms of conditionals. But that's also not that crazy? So yeah, I would move to Cfi Block access list. Make a call on Evds. Make a call on Egbs, which is delayed. Execution. And then yeah, it a a line on the on the El side, based on on the result of that. But default to doing block access list. If it's Pbs, yeah. A MoD.

Ahmad Bitar: Hey? So I wanted to like express a different opinion from Francis on a delayed execution being beneficial to L twos. Because unless you're doing like block building and doing the execution and and like, even if you're doing block building, you're executing as you're building. But if you are just grabbing batches of transactions from from the mempo and sequencing them, whatever the highest priority fee, or whatever like delayed execution, will not actually provide you with that much benefit. that's my personal opinion. But maybe there is other considerations that I'm not. That I'm not seeing. But there is another consideration also about delayed execution versus Apbs here, which, as far as I'm concerned, Apbs delayed execution does not bring the same scaling benefits as Apbs when it comes to blobs. Because the

and blobs are important for L twos. So this is another consideration that if we want to actually scale blobs higher, we should probably consider apbs over delayed execution. But yeah, I'm also I would like to hear feedback from others on this.

Francis: To answer your questions. for delay. Execution does have a tangible benefits for pre-confs, at least in l. 2. For example, for flash blocks that the Ob stack is kind of like getting on right. Now we have to reserve 500 ms of time at the end of the slot to just do insertion of the block of the preconfer blocks into the actual sequencer. and if we can do delayed execution, that 500 ms can become, can move to the next slot, which becomes a total 2 seconds for the execution, and it makes the precons like much more smoother and like truly like like pre-confs in the time slots that we we are building. So that's the 1st thing. The second thing about the Epps has better benefits for the broad scaling definitely. Yes, our thinking currently, maybe it's not entirely accurate is that based on what we've seen seems like delayed execution can provide 80% of the benefit. And the other thing that into the consideration is that

I kind of like, maybe like, it's just me. But I feel like the Epbs testing could be a very tricky thing to get to. I understand it's more stable. It's more mature at its current state right now, but I kind of fear. With all the introduced changes, the testing can be very hard to get right, and can like delay the timelines. And finally, regarding the blob throughput. my current thought is that with peer that's going out, that we can potentially theoretically get to 48 blocks, and the 80% of the benefits from delayed execution seems good enough for the foreseeable future. For like block scaling. So yeah, that's that's my overall thinking.

Tim Beiko: Thanks. And okay, Mark, yeah, do you have that as well.

Mark Mackey: Yeah, I mean, I just wanted to make explicit that that line of reasoning is their prerogative. But it's sort of like. you know we're advocating for delayed execution on l. 1, because it makes it puts code that can best be reused on L. 2, not necessarily because it's the best option for l 1 and like that's obviously their prerogative, and and so on. But I mean, I think we also have a line of clients. Don't. We have like an implementation of like. I mean, I think we're committed to maintaining a version of guest for L. 2 s. That has these kinds of features. and it doesn't necessarily mean that if we have a better option, not that he's saying that it is a better or worse option, but if we do have a better option for l 1 that we can, we can take that

and then yeah, I mean, I think for me the one of the biggest reasons to do. Epbs over delayed execution is the block payload. Separation is the the synergies with fossil and just like better. what is it like the types of low car, like proposer equivocation, low car, Crusader type attacks become better. Yeah, like, there's a lot of reasons to still do, Epps. And yeah, I guess that debate is probably going to happen next next call. But yeah, so I would. I guess my my counter to that would be like. Could we not do something like delayed execution for the layer? 2 fork of yes.

Tim Beiko: I mean, we've struggled to do more basic things on L. Two's and get them like adopted. So I I'm personally quite bearish on the idea that L. Twos would adopt like a pretty big minor size feature without a 1 supporting it. yeah, Francis, I don't know if you want to add more. There.

Francis: The adopting that is definitely a concern. But it's, I think, as Mark mentioned, it's not absolutely not doable like, I guess my question is that my understanding for delayed execution is that it still has benefits for l. 1 s. As well. Just because, like moving execution to the maybe the latest, the later block can free up to the preconsistence to be able to kind of truly like using the entire slot. So please correct me if I'm wrong. There.

Tim Beiko: Yeah. So data execution would be helpful on l. 1 as well. Yes, and.

Francis: Okay, then, in that case. I think our kind of like previous argument is still valid. It's both good for l, 1 and L, 2. And yeah.

Tim Beiko: Alright, thanks see Felix and Tony.

Felix Lange: Yeah. So I can just quickly go because you mentioned explicitly like implementation of this in Geth. So as far as I know, there's no active implementation of this change in Gath. Ultimately, the current strategies of on our side is that we do now, since the beginning of the year, care a lot more about basically trying to keep the upstream friendly, for, like any changes that are made in support of the downstream L 2 forks of Geth. So I would actually love to discuss, like the implications of implementing delayed execution for the use by L. 2 s. In Geth. But I also think it's maybe not entirely worth discussing it on this call. And also, I think it's like there's no

like the timeline, for it is also a bit different, like we can definitely discuss it. But it's not like in the context of the Glamsterdam l. 1 fork.

Tim Beiko: Thanks. I'm Tony.

Toni Wahrstätter: Yeah, I think one thing that would be very helpful to have and to help us. To guide the decision would be having some numbers on the final deadlines within the slot. because there was this free option problem that everyone heard of, and it would be super interesting to know what the actual difference between delayed execution and epbs is, finally, because initially, the delayed execution couldn't give you as much pipelining than Epbs, because the Ptc. Is just a smaller committee that you can put at the very end of the slot. This is essentially the trick, and it's a very nice one, but it also led to this free option problem. And then it's also worth discussing. How much does this actually impact epbs?

Right now, I think it hasn't impacted the specs yet, but this is also like published end of last week, or something, so it would be interesting to know, like what it eventually does.

Tim Beiko: Okay? So I guess, yeah, this plus the comment around the free option. Yeah, like, the free option right up. make meaning towards finalizing this discussion on next week's call. We should see a 5 block accesses today. And again, I think, if if we move forward with Epbs next week. We can also make it clear. We we move forward with block access lists. but yes, that's your downstream of that decision that makes sense people. And one thing sorry I forgot to mention as well. This came up in the chat, but we've collected on each magicians feedback from the community on which headliners they would like, and next so posted the link as well, and evbs or sorry not Evbs block accesses came up like quite frequently in that thread, too. So I think, even beyond just the core. That's group. It seems like there's strong support for for block accesses.

yep. so we'll move forward with Cfi and block accesses. We'll make a final call on the headliners next week at least on the Cl. Side. If that headliners is Eps, then we'll also have block accesses alongside it. Anything else people want to discuss about slabsurgon before we wrap up. Okay? Then we can. Yeah, we can call it a day. Again, the main 3 things as figuring out next steps on the transaction size limit on the testing call next week, and then the the headliner Discussion and Timeline discussion, The Glamsterdam Headliner Discussion and Fusaka Timeline discussion on the Cl. Call next Thursday. Anskar, do you want to add anything before we wrap up.

Ansgar Dietrichs: Yeah, just very quickly. I wanted to double check, because I do remember that block level access lists had some variants. Now, I think, already at interop. We looked into those right and like we, I think there was this general feeling that the current variant of the IP which basically includes just the read locations and then the right locations and values. That is basically the best version of block level access lists. But given that that was a bit of a design space and basically different options at some point were all thrown around. I just wanted to double check like, are we at this point now that we're cfiing it already, confident that, like the version as is in the Mp. Today, it seems to be my favorite version. But I just want to get a temperature check.

Are we basically cfiing blocks list and saying, Oh, we're still going to like iterate on like, what exact version of it? Or is this already kind of a vote of confidence for that specific flavor of it?

Toni Wahrstätter: I think right now we are kind of early in the process, because none of no one from the clients has a complete implementation except Gaff. So I think Jared. is, as we are talking, collecting some 1st numbers there, so we should have them very soon. and if we're talking about the size of the object. Then the reads wouldn't matter that much. So I think 30% of the block level 30 kB is from storage changes and only 10% from storage locations. So from the size perspective, it wouldn't matter that much if clients say we don't need the read locations to do parallel. I/O, then we can still exclude them. We have spec both versions. There are also tests for both versions. It should be a quite easy change to move from, including the storage locations, to excluding them.

Jared Wasinger: Wait. Just to be clear. Are you saying that, including the read locations, bumps the size by 30%? Did I understand that correctly?

Toni Wahrstätter: No, yeah, I actually, yeah, exactly 30%. So.

Jared Wasinger: So I guess I would say like right now, and I plan to grab some benchmarks related to the read locations. But intuitively it just doesn't I? I don't understand why they're needed, because, it seem it would seem like they would be important for being able to prefetch reads ahead of time. So like when you start the transaction execution. And you're right now you're doing the transactions serially. If you had some pre knowledge of read locations, you could fetch them ahead of time. But if we're executing transactions in parallel, that doesn't really leave time to do that. So I yeah, right now I I guess I just don't see what including them brings to the table.

But I mean we can certainly get numbers.

Ben Adams: I mean it does bring additionally, because you know you're not. If you've got 8 cpus, and you're executing 8 transactions in parallel. You can do the reads for the transactions further down the pipeline already. But just like, say, it sort of depends on whether epbs is the choice, because that gives more time for larger blocks. And yeah, I'm not sure load execution does. So. The the size of the block level access list would change propagation.

Tim Beiko: Okay? So I guess, like, yes, clearly, there will be some exploration to do on this specific variant. okay, anything else before we wrap up great? Well, yeah, thanks everyone. I'll post a summary later today. But again remain. Things are transaction limit. Susaka timelines and scale headliners to sort out next week. That's gusting.

Pooja Ranjan: Thank you.

Alex Stokes: Thank you.

Fredrik Svantes: Thank you.

Ansgar Dietrichs: Thanks. Everyone.

Potuz: Bye-bye.

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