Justin Florentine (Besu):Happy birthday to us.
Transcript
Justin Florentine (Besu):Happy birthday to us!
Justin Florentine (Besu):Happy birthday to my ether. Friends! Happy birthday! You're 10.
Josh Davis:And that was like.
Tim Beiko:Nice thanks, Justin.
Tim Beiko:Happy birthday ethereum so officially kicking off the second decade of ethereum awkward Evs. So
Tim Beiko: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.
Tim Beiko:But yes, to kick us off
Tim Beiko:Harry or Barnabas. Do either of you want to give an Update on the Fusaka despots.
Barnabas: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.
Barnabas:so they seem to have different bugs.
Barnabas:Loot Star is having a library. b 2 b bug, that they are debugging in the past few days or few weeks.
Barnabas:Maybe someone from can give us an update if anyone is here. Otherwise.
Barnabas:Nimbus had a Mev related. Bug that should be fixed now. And
Barnabas:yeah, participation is up to 94%. So should be good to go.
Barnabas:We're gonna be doing some
Barnabas:perfect previous testing in the coming days, and hopefully that will also work for all the Cls.
Tim Beiko:Thank you.
Tim Beiko:Any client theme, or anyone else want to add anything to the dead notes?
Tim Beiko: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
Tim Beiko:which has to do with the and
Tim Beiko:which which has to do with the transaction
Tim Beiko: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.
Tim Beiko:I don't know if he's on the call today, and
Tim Beiko:otherwise I saw that Tony and Vitalik had responded to this. So
Tim Beiko:If Duncan is out here. Maybe Tony or Vitalik can give an update.
Toni Wahrstätter:Yes, I can do so.
Toni Wahrstätter:Yeah, I think. It's it's fair to acknowledge.
Toni Wahrstätter:Sorry.
ethDreamer (Mark):I wanna say Duncan is on his way. I.
Toni Wahrstätter:Okay.
ethDreamer (Mark):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.
Toni Wahrstätter:I think backwards compatibility is super important. But we had.
Toni Wahrstätter:like a lot of discussions around exactly this topic.
Toni Wahrstätter: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
Toni Wahrstätter: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.
Toni Wahrstätter:So this was this were the reasons why this was lowered.
Toni Wahrstätter:and it seemed like a good trade off between getting some more scalability, some more security without really affecting
Toni Wahrstätter: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 (0x):Yeah, thanks. Sorry about that. I had a trouble finding the the video link.
Tim Beiko:Almond.
Duncan Townsend (0x):Yeah. The bottom line is that
Duncan Townsend (0x):decreasing the transaction gas limit from 30 million to 16.8 million is a breaking change for application developers.
Duncan Townsend (0x):And
Duncan Townsend (0x):yeah, it's causing a lot of complexity in our application. I'm sure there are other ecosystem wide impacts.
Duncan Townsend (0x):It's frustrating
Duncan Townsend (0x):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
Duncan Townsend (0x):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.
Ben Adams:But one of the examples that uses
Ben Adams:given that uses over 16 million, and it probably uses more now.
Ben Adams:Was deployed in 2,021 when
Ben Adams:the block limit was 12 million, so
Ben Adams:it would have been possible. And that's sort of like a
Ben Adams:a a complete loop around every single attached contract to to a pool.
Ben Adams:So essentially, that would taken to his extreme that would need a transaction of infinite gas.
Ben Adams:based on yeah, how it's written, because people could keep adding
Ben Adams:pull pulls to the to the contract.
Ben Adams:One of one of the issues is supporting
Ben Adams:these larger transactions reduces the overall
Ben Adams:gas that can be offered to the network.
Ben Adams: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
Vitalik Buterin:just elaborate a bit on some of the arguments I gave on magicians. Basically, I think like one is that
Vitalik Buterin: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
Vitalik Buterin:and then
Vitalik Buterin: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
Vitalik Buterin: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.
Vitalik Buterin: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
Vitalik Buterin:allowed a bunch of things to actually, yeah, in things in client development and caching to become quite a bit simpler. Right? So.
Vitalik Buterin:I, yeah, would argue that also the kinds of breaks that are
Vitalik Buterin: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?
Vitalik Buterin:I, yeah, right? I think, is that. Yeah. See? Is, is that a breaking change or not? I mean from the
Vitalik Buterin: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.
Vitalik Buterin: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
Vitalik Buterin:it's like, like, that's 1 of the balances. I mean, I do think we should.
Vitalik Buterin:How be more thoughtful to having a procedure having a a procedure for this? I mean, I am like perfectly happy
Vitalik Buterin:deal delaying things like this. I'm also, I'm happy. Yeah, to
Vitalik Buterin:like having having time delays and and explicit deprecations is, I think, something that's good. Having explo explicitly. Yeah, like, specified invariance is
Vitalik Buterin:good having,
Vitalik Buterin: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
Vitalik Buterin: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.
Vitalik Buterin: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
Vitalik Buterin: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
Vitalik Buterin: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.
Vitalik Buterin: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
Vitalik Buterin:that's kind of how I yeah.
Vitalik Buterin: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
Tim Beiko:wants to speak up about them.
Duncan Townsend (0x):Yeah, I I was asked to explain the use case.
Duncan Townsend (0x):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
Duncan Townsend (0x):It
Duncan Townsend (0x):unlocks scalability, parallelism, and also constrains the design space for dap developers and makes it easier to reason about the system.
Duncan Townsend (0x):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
Duncan Townsend (0x):contract I link to consumes today, but I can talk about the transactions that I develop, which
Duncan Townsend (0x):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.
Duncan Townsend (0x):And
Duncan Townsend (0x):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
Duncan Townsend (0x):$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
Duncan Townsend (0x):which
Duncan Townsend (0x):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.
Duncan Townsend (0x):So, for reasons of competitiveness, I think increasing the limit
Duncan Townsend (0x):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
Ben Adams:calculations? So would, for instance, repricing
Ben Adams:non storage opcodes down which is planned.
Ben Adams:Help resolve that.
Duncan Townsend (0x):Most of the time.
Duncan Townsend (0x):and you know this depends very heavily on a lot of specifics, but most of the time you are storage. Limited
Duncan Townsend (0x):exceptions would be things like Pendle finance curve finance. Really anything that has to do Newton-raphson approximation of a constant function.
Duncan Townsend (0x):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.
Duncan Townsend (0x):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
Toni Wahrstätter:additional 50 million guests. I think that's a fair assumption.
Toni Wahrstätter:But I still think I'm going to 60 million, which is currently the default on the defnets.
Toni Wahrstätter:Is, is there a better choice? Just because we get those additional benefits from parallelization?
Toni Wahrstätter:And of course we affect slightly more users.
Toni Wahrstätter:but if this is exactly the trade-off here, we will always affect some users.
Toni Wahrstätter:but other users will benefit from us, being able to scale.
Toni Wahrstätter: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.
Tim Beiko:And then it got lowered at the the 16.8 or something. But is there a number
Tim Beiko:like, yeah, if we did it, the 20? Or is there some number today that we feel would
Tim Beiko:actually allow most. You know, large use cases that have been used in productions that are like somewhat reasonable.
Tim Beiko:and yeah, we're still asked about it, and.
Toni Wahrstätter:Just from the numbers we know that around. So in
Toni Wahrstätter: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
Toni Wahrstätter:transactions that were affected. And
Toni Wahrstätter: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
Toni Wahrstätter: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.
Toni Wahrstätter:Yes, I have a link.
Toni Wahrstätter: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.
Toni Wahrstätter:like, let me check here.
Toni Wahrstätter:Okay. I posted it right now.
Tim Beiko:Okay, thank you.
Tim Beiko:I'll cross post it in the chat here just for people referencing. Oh, thanks. Josh,
Tim Beiko: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.
Tim Beiko:you know, like there, by the time the next fork happens we
Tim Beiko:by the time the next project happens we we can't lower it.
Tim Beiko:but yeah, we could also commit the same like.
Tim Beiko:we put a hard limit today at 30 million. And then we deprecate these yeah.
Tim Beiko:So it's actually pass some amount on the next fork, and it gives time for people to migrate.
Tim Beiko:and I guess on the like, yeah, on the 0 X use case, like, what would happen
Tim Beiko:if this cap existed today, and someone was trying to do a transaction that you know touched a bunch of routes.
Tim Beiko:is it just that the transaction would fail. Would the 0 X,
Tim Beiko:I assume the ui, or you know, the front end is able to catch this in the wallet to some way that like?
Tim Beiko:Yeah, well, what? Like.
Duncan Townsend (0x):Yeah, I mean.
Tim Beiko:User like, what what would the experience be if, like you.
Tim Beiko:you try to exceed this limit today?
Duncan Townsend (0x):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.
Duncan Townsend (0x):And it's actually probably better for us because it cements our position in the ecosystem.
Duncan Townsend (0x):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.
Duncan Townsend (0x):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 (0x):Right.
Duncan Townsend (0x):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.
Tim Beiko:is there a future where we would imagine going even below the 16 million? Because,
Tim Beiko: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
Tim Beiko:yeah?
Tim Beiko:Is there an argument to say should be, you know, 10 million or 8 million
Ben Adams:I mean 6
Ben Adams:at 16 million. That's 16 million, for, like 45 million gas, you're looking at 3 transactions that can be run
Ben Adams:in parallel. And then, you know, when we go to a hundred 1 million,
Ben Adams:yeah, it's it's a lot more. And we're specifying that you need 8 cores.
Ben Adams:I'm run a validator. So essentially saying, Well, you can't use it. This entirely single threaded is.
Ben Adams:you know, wasteful because we have the capacity to increase using parallelism, but setting the
Ben Adams:the limit higher causes of the worst case to get worse. But setting the limit lower
Ben Adams: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
Vitalik Buterin: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.
Vitalik Buterin: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
Vitalik Buterin:account. Some account abstraction, feature, or something similar. So it's
Vitalik Buterin: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
Vitalik Buterin: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
Vitalik Buterin:unresolved. So. But it's like once you.
Vitalik Buterin: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
Vitalik Buterin: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
Vitalik Buterin:lower, single digit millions or anything like that. And like.
Vitalik Buterin:I, I feel like, Oh, there we go! That's a good dash.
Vitalik Buterin: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.
Tim Beiko: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.
Tim Beiko: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,
Tim Beiko:it's like until we raise the gas limit to 60 million, there's still cases where maybe we're not able to
Tim Beiko:to to paralyze. So I
Tim Beiko:yeah, I don't. That would be my proposal, and that you know, this this 16 million number was
Tim Beiko:basically just the power of 2. So if 20 is slightly better,
Tim Beiko:yeah, I think we could make that change. And.
Toni Wahrstätter:Yeah, I think it us into one direction of the trade-off.
Toni Wahrstätter: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 (0x):Yeah, yeah, I just put out a call to some of our data guys at Xerox to do some analysis for like
Duncan Townsend (0x):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.
Duncan Townsend (0x):But that'll be later today.
Vitalik Buterin:Yeah, perfect. And would you mind like also finding some
Vitalik Buterin:transaction hashes? I think, like specifically of some of these like, create, like massively multi atomic arbitrage, things.
Duncan Townsend (0x):Yeah, we're not in the business of arbitrage. But but yeah, right? Right? I know.
Duncan Townsend (0x):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
Tim Beiko:like soft agreed to go to 20 million dollar 20 million gas now, and if we
Tim Beiko:if we find something that disproves that being a good number, we change it again, or do we prefer to wait?
Tim Beiko: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.
Tim Beiko:and and yeah, having it be more final.
Tim Beiko: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
Tim Beiko: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,
Tim Beiko:if if we were to change it in 2 weeks, Mario, like I'll
Tim Beiko:big of a change. Would it be 10 like once you've identified all these tests? Is it easy to go back? And
Tim Beiko: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
Tim Beiko:yeah, just give us some time to discuss it. And yeah, look into the details and the edge cases.
Tim Beiko:So anything else on this.
Tim Beiko:See if we can make the final call on Monday instead of 2 weeks from now.
Tim Beiko:I don't know how quickly we can get the numbers and get through them.
Duncan Townsend (0x):I can probably have numbers, at least for 0 X.
Duncan Townsend (0x):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
Tim Beiko: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.
Tim Beiko:okay, anything else on this.
Tim Beiko:Okay, well, thanks everyone. Thanks, Duncan, for writing this and coming on.
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:and
Tim Beiko:and I know that this is the El call, but it's a pretty significant change. So I wanted to
Tim Beiko: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.
Tim Beiko:and I don't know if either Dimitri who raised the issue, or anyone who's engaged on the Pr.
Tim Beiko:Send the call or.
Dmitry Gusakov:Yeah, I'm I'm here. Thank you. Team.
Dmitry Gusakov: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
Dmitry Gusakov:128. Right now Cl Node is obligated to custody, depending on the number or the eth amount attached to the validators to the node.
Dmitry Gusakov: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
Dmitry Gusakov:might have a
Dmitry Gusakov: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
Dmitry Gusakov: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
Dmitry Gusakov:validators attached to the node, or 16,000. Eth.
Dmitry Gusakov: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
Dmitry Gusakov:have at least 500 validators, and then balance validators attached to the node right now.
Dmitry Gusakov: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.
Dmitry Gusakov:and who are limited by a household Internet connection which might be not super perfect and given that the requirement
Dmitry Gusakov:would result in not just storing or custody more segments, but also downloading them in a limited 4 second period.
Dmitry Gusakov:Oh, I believe that this limit can be raised, especially given the initial rationale behind selecting the initial value which was 1st of all
Dmitry Gusakov: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Dmitry 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.
Dmitry Gusakov:I believe we are talking more here about?
Dmitry Gusakov:How many nodes would be affected by that, and raising the limit, like anything in between
Dmitry Gusakov:one validator and 500 validator is.
Dmitry Gusakov: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
Dmitry Gusakov: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
Dmitry Gusakov:building a cluster of 7 nodes. It means that they will need to have each
Dmitry Gusakov: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
Dmitry Gusakov:right now, like any change that makes it harder to become homestaker, makes it less profitable, less convenient, less comfortable, is
Dmitry Gusakov: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.
Dmitry Gusakov: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.
potuz: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
potuz: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
potuz:according to numbers. I mean, of course, this would affect depending on what sort of like the leverage
potuz: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.
potuz:with Csm. The numbers, as far as I can see in the from the Pr.
potuz:You would need about 36, Eth. Not more than this to hit this this limit in which you start
potuz:having more columns to to to keep.
potuz: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.
potuz: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
potuz:this is something something dramatic, I think, in that Pr. Many client devs supported it.
potuz: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.
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.
stokes:there's a separate question, though, of like, when is the right time to do this, I think.
stokes: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.
stokes:I think we'll have time to get to a place where this would even start to be an issue.
stokes:So I propose we kind of table this change, for now
stokes: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.
stokes:Yeah, yeah.
Tim Beiko:Do people feel about this?
Tim Beiko: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
Tim Beiko:yeah, I
Tim Beiko:I'm fine
Tim Beiko:making the change, making the decision on Monday or at the latest on the Cl call next week.
Tim Beiko:go ahead.
Tim Beiko:Yeah, let's try to.
Tim Beiko: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.
stokes:I think, as quickly as possible. I would have liked to make a decision today. Let's aim for Acd. Then
stokes:I think we might sort of nominally have more cl participation there. So.
Tim Beiko:Yeah. And we can at least yeah.
Tim Beiko:ping the cl and try to get them to. If they can't show up. Articulate their reasoning. Async. Ahead of the call.
Tim Beiko:Okay, let's do that, then and then there's obviously the Pr people can engage on. I think
Tim Beiko:anything else on this before we move on.
Tim Beiko:Yeah, but there is Frank, I think.
Tim Beiko:it would be good for all of the Cl teams to either share their opinion before act or
Tim Beiko:on the call and
Tim Beiko: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.
Tim Beiko:Okay, yeah. Barnabas.
Barnabas: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
Tim Beiko:to give people some more time to voice like
Tim Beiko: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
Tim Beiko:and.
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?
Tim Beiko:Yeah, I mean.
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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:I think it's just not appropriate. Given the kind of fog process.
Tim Beiko:Right. But I guess yeah, to be clear.
Tim Beiko:we will still be rushing to a decision. The decision would just be maintained. The spec, as is right.
Tim Beiko:So if there's if there's anything that we would learn in the next week that we think could
Tim Beiko:help shape the decision.
Tim Beiko: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.
Tim Beiko:what sorry subway is not just blob parameter.
Barnabas:Basically, he wants to change the value in the Bpo.
Csaba:Yeah, Vto is is a interesting concept. But we will be more more running into
Csaba:Ppo, not just being a parameter. Only change and.
Tim Beiko:I mean I don't.
Tim Beiko:I guess.
Csaba:Sure.
Tim Beiko:An option is, we could not have this launch with Fusaka. And then, to the extent it becomes.
Tim Beiko:Yeah, more urgent to address. We can overload the vpo to also have this
Csaba:Yeah, exactly.
Barnabas:Yeah, we also assume that the Cgc value doesn't go down. By the way.
Barnabas:So once we introduce this technically, you're not gonna go down in your Cgc value
Barnabas:unless you yeah. Neutral. dB, but.
Tim Beiko:Right?
Tim Beiko:Okay? Then I guess I would lean towards not making this change.
Tim Beiko:And yeah, just because we're selecting the process trying to minimize, minimize
Tim Beiko:the amount of changes to the specs.
Tim Beiko: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.
Tim Beiko:Does that make sense.
stokes:It makes sense to me. But I guess just clarifying. Are we making? Are we starting this today? Or we're just
stokes: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.
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:Well, on Monday we're gonna find out if we're gonna need a new that, anyway, regarding Max transaction. So I think it.
Barnabas: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.
Tim Beiko:And yep.
stokes:Agree.
Tim Beiko:Okay.
Tim Beiko:okay, anything else on this one before we move on.
Tim Beiko:Yes, we are discussing the transaction gas limit gap on Monday, Mario.
Tim Beiko:Okay? And then the the last 2 second thing I want to discuss is just
Tim Beiko:continuing your timeline discussion. We had last time. So Alex had proposed
Tim Beiko: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
Tim Beiko:and then, you know, some concerns about working during dev connect but
Tim Beiko: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
Tim Beiko:around September first, st which is a month from now.
Tim Beiko:The people think this is realistic, are there things we should be doing to make sure we can get there?
Tim Beiko:yeah.
Tim Beiko:are things we should not be doing like. For example, you know, if we do change this transaction limit cap.
Tim Beiko:The client teams feel like it makes a difference between whether they can have a test and release in 4 weeks or not.
Tim Beiko:Yeah, Sean.
sean: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
sean: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
sean: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.
Tim Beiko: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.
Tim Beiko: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
stokes:Doing husky.
stokes:The upside is. It's just another sort of strong goal, so to speak, Downside is. It's just another
stokes: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.
Parithosh Jayanthi: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.
Tim Beiko: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
Tim Beiko:feels not ideal. So if we do want to fork Holeski, then
Tim Beiko:we probably should do something where maybe we have like.
Tim Beiko: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?
Tim Beiko:So yeah, 1 1 option could be that, like.
Tim Beiko:you know, week of September. 1st we put out the releases for Heleski and sepulia week of September 8th
Tim Beiko:Forks. Because I assume we're controlling most, if not all, of the nodes on this. So we can. We could clearly like
Tim Beiko:update in time, and then week of the 7, the 15, th the polio forks.
Tim Beiko: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
Tim Beiko:Sorry, like, yeah. Sorry. On the week of September.
Tim Beiko:September 29, th and this means, if everything goes well, it means we can fork Mainnet on the week of
Tim Beiko:October 27, th or or November 3, rd which are yeah, which are right before death connect?
Tim Beiko: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
Tim Beiko:wholeski one week after the client releases. Given that, we're gonna do non finality testing and
Tim Beiko:and that we control most of the of the nodes.
Tim Beiko:And and yeah, we don't have to like 100% finalize this today. But it would be good.
Tim Beiko:it it would be good to do so in the next week or 2.
Tim Beiko:especially if, like, yeah, we are needing to set these blocks for for September first.st
Tim Beiko:I guess I don't. Yeah. Maybe it
Tim Beiko: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
Tim Beiko:we can kind of finalize the happy path dates by next call based on the feedback from teams.
Tim Beiko:Does that make sense? Did you want to see how part next week.
Tim Beiko:Okay, I have a plus one.
Tim Beiko:But I think, like, yeah, by this point, everyone knows kind of what the constraints are, and you know
Tim Beiko:how we can approach them. So
Tim Beiko: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.
Tim Beiko:Okay, anything else on the rollout?
Tim Beiko:If not, then yeah, we can use the rest of the call to discuss Amsterdam.
Tim Beiko: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
Tim Beiko:and then on the Cl. Call. We didn't want to discuss block access list too much, but it
Tim Beiko:It is kind of the main thing that's come up on the El side. And so I guess.
Tim Beiko:yeah, how do people feel about making block access lists? Kind of the El headliner?
Tim Beiko:are there any objections to this? At this point?
Tim Beiko:It seems like the kind of okay.
Tim Beiko:least controversial, and also somewhat smallest of the headliners. And
Tim Beiko:so, yeah, I feel we may be able to lock this one in on the El side today and then
Tim Beiko:finalize the discussion about epbs, shorter slot times than possible next week.
Tim Beiko: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.
Francis: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
Francis:I think it's a very good property to have.
Francis: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
Francis:I guess that's okay, too.
Tim Beiko:Yeah, I guess. Yeah. 1 1 question. I just posted in the chat as well. But
Tim Beiko: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
Tim Beiko:M.
Tim Beiko:Yeah. Like, if we do delayed execution. Do we think that this is
Tim Beiko:This is somehow blocking for for block access list?
Tim Beiko:Okay. Beizu says yes, and.
Justin Florentine (Besu):I wouldn't simplify it down to a yes, Tim, it does change our math a little bit.
Tim Beiko:Yeah.
Tim Beiko: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.
Tim Beiko:And and yeah, it seemed like all of the Cl teams, relatively strongly supported epbs, so I
Tim Beiko: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
Tim Beiko:we make
Tim Beiko:the call around around block access lists. And you know, commit to that, and then see whether or not we also do the execution.
Tim Beiko: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Tim Beiko:we can probably Cfi block access list like it seemed at least as
Tim Beiko: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
Tim Beiko:execution or sorry assuming we do, I think, assuming we do epbs, then
Tim Beiko: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.
Tim Beiko:and it is a bit weird in terms of conditionals. But that's also not that crazy? So
Tim Beiko:yeah, I would move to Cfi Block access list. Make a call on Evds.
Tim Beiko:Make a call on Egbs, which is delayed. Execution. And then yeah, it
Tim Beiko: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 | Nethermind:Hey? So I wanted to
Ahmad Bitar | Nethermind:like express a different opinion from Francis on a delayed execution being beneficial to L twos. Because
Ahmad Bitar | Nethermind: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
Ahmad Bitar | Nethermind:like delayed execution, will not actually provide you with that much benefit.
Ahmad Bitar | Nethermind:that's my personal opinion. But maybe there is other considerations that I'm not. That I'm not seeing.
Ahmad Bitar | Nethermind: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
Ahmad Bitar | Nethermind: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.
Ahmad Bitar | Nethermind:But yeah, I'm also I would like to hear feedback from others on this.
Francis:To answer your questions.
Francis: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.
Francis: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
Francis: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
Francis: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.
Francis: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.
Tim Beiko:And okay, Mark, yeah, do you have that as well.
ethDreamer (Mark):Yeah, I mean, I just wanted to
ethDreamer (Mark):make explicit that that line of reasoning is their prerogative. But it's sort of like.
ethDreamer (Mark):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
ethDreamer (Mark):and like that's obviously their prerogative, and
ethDreamer (Mark):and so on. But I mean, I think we also have a line of clients. Don't. We have like an implementation of like.
ethDreamer (Mark):I mean, I think we're committed to maintaining a version of guest for L. 2 s. That has these kinds of features.
ethDreamer (Mark):and it doesn't necessarily mean that if we have a better
ethDreamer (Mark):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
ethDreamer (Mark):and then yeah, I mean, I think
ethDreamer (Mark):for me the one of the biggest reasons to do.
ethDreamer (Mark):Epbs over delayed execution is the block payload. Separation is the the synergies with fossil and just like
ethDreamer (Mark):better.
ethDreamer (Mark):what is it like the types of low car, like proposer equivocation, low car, Crusader type attacks become better.
ethDreamer (Mark):Yeah, like, there's a lot of reasons to still do, Epps.
ethDreamer (Mark):And yeah, I guess that debate is probably going to happen next next call. But
ethDreamer (Mark):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
Tim Beiko:I'm personally quite bearish on the idea that L. Twos would adopt like a pretty big minor size feature
Tim Beiko:without a 1 supporting it.
Tim Beiko: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
Francis: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.
Francis: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.
Francis: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 (Geth):Yeah. So I can just quickly go because you mentioned explicitly like implementation of this in Geth.
Felix (Geth):So as far as I know, there's no active implementation of this change in Gath.
Felix (Geth):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
Felix (Geth):worth discussing it on this call.
Felix (Geth):And also, I think it's like there's no
Felix (Geth):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
Felix (Geth):the Glamsterdam l. 1 fork.
Tim Beiko:Thanks.
Tim Beiko: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.
Toni Wahrstätter: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
Toni Wahrstätter: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?
Toni Wahrstätter:Right now, I think it hasn't impacted the specs yet, but this is also like published
Toni Wahrstätter:end of last week, or something, so it would be interesting to know, like what it eventually does.
Tim Beiko:Okay?
Tim Beiko:So I guess, yeah, this plus the comment around the free option. Yeah, like, the free option right up.
Tim Beiko: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.
Tim Beiko:but yes, that's your downstream of that decision
Tim Beiko:that makes sense people.
Tim Beiko: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.
Tim Beiko:yep.
Tim Beiko: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.
Tim Beiko:Anything else people want to discuss about slabsurgon before we wrap up.
Tim Beiko: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.
Tim Beiko: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Toni Wahrstätter:is, as we are talking, collecting some 1st numbers there, so we should have them very soon.
Toni Wahrstätter: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
Toni Wahrstätter: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
Jared Wasinger:I? I don't understand why they're needed, because, it seem it would seem like they would be important for being able to
Jared Wasinger:prefetch reads ahead of time. So like when you start the transaction execution. And you're right now
Jared Wasinger:you're doing the transactions serially. If you had some pre knowledge of read locations, you could fetch them ahead of time.
Jared Wasinger:But if we're executing transactions in parallel, that doesn't really leave time to do that. So I
Jared Wasinger:yeah, right now I I guess I just don't see what including them brings to the table.
Jared Wasinger:But I mean we can certainly get numbers.
Ben Adams:I mean it does bring additionally, because you know you're not.
Ben Adams: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.
Ben Adams:But just like, say, it sort of depends on
Ben Adams:whether epbs is the choice, because that gives more time for larger blocks. And yeah, I'm not sure
Ben Adams:load execution does.
Ben Adams: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.
Tim Beiko:okay, anything else before we wrap up
Tim Beiko: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.
Tim Beiko:That's gusting.
Pooja Ranjan:Thank you.
stokes:Thank you.
Fredrik:Thank you.
Ansgar Dietrichs:Thanks. Everyone.
potuz:Bye-bye.
Chat Logs
00:02:49
Ansgar Dietrichs:happy 10yr!
00:02:59
Orest Tarasiuk (t1):Yay :)
00:02:59
Trent:lmao
00:03:01
Louis:HBD
00:03:08
Barnabas:Thanks Justin!!!
00:03:09
Trent:Dulcet tones
00:03:11
nixo:🥳
00:03:11
Enrico Del Fante (tbenr):LOOL!
00:03:12
Gary Schulte:epic
00:03:12
Parithosh Jayanthi:<3
00:03:13
potuz:Lol
00:03:33
Parithosh Jayanthi:Can’t wait for how angsty eth gets in its teenage years
00:03:51
Ansgar Dietrichs:this might beat Hudson-Ameen as my new favorite acd moment :-)
00:03:53
Justin Florentine (Besu):all angsty teens have an embarrassing dad
00:05:15
Manu:Prysm currently does not support MEV, but should be fixed today
00:05:22
Manu:(On peerdas-devnet-3)
00:05:26
Tim Beiko:https://github.com/ethereum/pm/issues/1629#issuecomment-3129387862
00:05:40
Barnabas:we currently have some mev related bugs on devnet 3 that I didn’t mention, as its not client related bug.
00:06:01
Barnabas:basically txs are not being passed from reth to rbuilder, which is the root cause of the issue
00:06:12
Tim Beiko:https://ethereum-magicians.org/t/eip-7987-transaction-gas-limit-cap-at-2-24/24746
00:06:18
Barnabas:random restarts of rbuilder fixes this issue, its intermittent
00:09:54
Barnabas:Duncan, what is your personal use case that would break if this EIP would hit mainnet?
You mentioned that your personal use case would be affected by this change.
00:10:57
potuz:https://eips.ethereum.org/EIPS/eip-2929
00:11:37
Ansgar Dietrichs:I don’t have a strong opinion on the specific best per-tx gas limit, but I do think we need to get significantly more comfortable with (careful, thoughtful) breaking changes going forward
00:12:11
Ansgar Dietrichs:Replying to "I don’t have a stron..."
repricing is a major example
00:12:18
Justin Florentine (Besu):i'm not even sure i would frame this one as a breaking change
00:12:52
Ansgar Dietrichs:Replying to "i'm not even sure i ..."
right, agree
00:12:57
Duncan Townsend (0x):I'm not trying to argue for no limit, just that the limit in this EIP is too low
00:13:17
Duncan Townsend (0x):I'll explain my use case in a moment
00:13:18
Justin Florentine (Besu):breaking: undoing/changing existing, specified behavior.
closing an unknown/uspecified case? something else, but not sure it is "breaking"
00:13:50
Tim Beiko:Would it make things better if we did 30M gas cap this fork and then 16.8 next fork?
00:13:52
Luis Pinto | Besu:If we want to scale the throughput quickly wouldn’t 30MGas per transaction be enough? When we get to 240MGas we can already use the 8CPUs that’s in the recommend hardware requirements mentioned in an EIP by Kev
00:14:59
Sophia Gold:Parallelizing tx is crucial for realtime proving even non-distributed
00:15:10
Ben Adams:Replying to "Parallelizing tx is ..."
Also for BALs
00:15:16
Justin Florentine (Besu):Replying to "i'm not even sure i ..."
the more i think about it, if it's unspecified, it cannot be breaking. to cordon off the design space like that for us would be a disaster
00:15:20
Luis Pinto | Besu:Replying to "If we want to scale ..."
It seems a short time improvement that would be irrelevant in the long term at the cost of breaking dApps
00:15:27
Toni Wahrstätter:~ halve it is better and if you look at the cdf over gas used per txs, then this only affected very rare usecases, xen, batch ens registration, poisoning spam etc.
00:15:37
Ansgar Dietrichs:Replying to "If we want to scale ..."
once we reprice, the specific per-tx limit is a bit arbitrary anyway, because we can basically either make the cheap operations 5x more expensive, or the expensive ones 5x cheaper
00:15:57
Ansgar Dietrichs:Replying to "If we want to scale ..."
so it’s not quite clear what exactly 240M even means
00:17:44
Luis Pinto | Besu:Is it deployed already?
00:18:57
Barnabas:is there any reason you couldn’t just have 2x16M transaction instead of one 20-25M gas transaction?
00:19:18
Gary Schulte:Replying to "is there any reason ..."
atomicity for one
00:19:38
Justin Florentine (Besu):Replying to "is there any reason ..."
mev avoidance
00:19:44
Vitalik Buterin:Is the primary argument about breaking dapps or about breaking offchain code that can be rewritten (but less conveniently)?
I think it's important to disaggregate the two
00:20:13
Vitalik Buterin:I checked the tx in the magicians post ( 0xadc4e06a7a4c9442c14d1cf90c384d175e7e39f49f713924461c368253cb2697 ) and it's 19m gas for a contract deployment
00:20:53
Charles (vyper):once we increase contract size limit, it will affect how large contract you can deploy :)
00:20:57
Charles (vyper):140kb vs 70kb
00:20:58
Duncan Townsend (0x):Yes. That tx can definitely be broken up with offchain cleverness
00:21:23
Vitalik Buterin:So if not breaking dapps is the use case, we could compromise and make the limit 20m and be done with it
00:22:11
Vitalik Buterin:If the use case is enabling massively-large-scale atomicity, then I would want to see an actual example of a multi-atomicity-dependent tx that goes that high
00:22:17
Duncan Townsend (0x):Another point I'm trying to make is that we don't know what we don't know about might break because we haven't had the time to solicit feedback and analyze
00:22:59
Luis Pinto | Besu:Replying to "If we want to scale ..."
Yes but the point is at the current price make sure we don’t break anything. What happens after is fine, Dapps will adapt
00:23:20
Duncan Townsend (0x):So I think a good, conservative approach would be to set the limit to 30M and then solicit feedback and analysis for setting the limit lower in the next hard fork
00:23:24
Marc:it’s always easier to raise the limit in future than lower it, so going with 16M or maybe 20M makes sense to me
00:23:26
Josh Davis:https://github.com/nerolation/EIPs/blob/17a90c395dd48099d5bcb740be1a76249cdad996/assets/eip-7825/analysis.md
00:23:45
Justin Florentine (Besu):if we concede a tx limit of 36M (block size) we can't ever lower it
00:23:56
Vitalik Buterin:we can explicitly deprecate txs with gas >= 2**24
00:24:00
Vitalik Buterin:like we deprecated selfdestrucy
00:24:05
Vitalik Buterin:a fork before killing it
00:24:08
Justin Florentine (Besu):so 100mgas blocks limited to 3tx
00:24:15
Alexey:Can be solved by further addition of some kind of glued transactions?
00:24:37
Ben Adams:Issue is full block txs, kill any prewarming or paralelliam as they happen at tx level; which then causes difficulties on increasing blockgas limits
00:25:16
Charles (vyper):Replying to "Issue is full bloc..."
can they just get more expensive?
00:26:20
Charles (vyper):Replying to "Issue is full bloc..."
like a penalty for non-parallelizable txns
00:26:32
Toni Wahrstätter:I'm not sure if routes that take 16M gas are preferrable over the benefits of smaller transactions. It's a fair use case but should consume less gas.
00:26:39
Luis Pinto | Besu:I like this idea, pay higher for pinning a CPU more than others. But ultimately would not prevent it though :/
00:27:13
CPerezz:Replying to "Issue is full block ..."
Even if more expensive, they put a hard limit on the performance and specific worst case we have to cover. So scalability via gas_limit upgrades or ZKEVM proving suffer a lot wit it
00:27:35
Justin Florentine (Besu):BALs utility goes down a bit
00:27:45
Tim Beiko:@Toni Wahrstätter how hard is it to re-run your analysis with different limits?
00:27:55
Alexey:Like you can send a tx containing 3 txs and can't execute it partially. Still you can prepare witness for every one of 3, which enables parallelism
00:28:16
Tim Beiko:Replying to "@Toni Wahrstätter ho..."
If easy, it could be good to see the impact of a cap at 2**24, 20M and 30M
00:28:35
Toni Wahrstätter:Replying to "BALs utility goes do..."
Yeah, execution parallelism would go down by almost 2x (in the worst case). Other benefits such as parallel state root or parallel IO are unaffected.
00:29:15
Toni Wahrstätter:Replying to "@Toni Wahrstätter ho..."
Not hard
00:29:31
Duncan Townsend (0x):Replying to "Can be solved by fur..."
That would be a good solution, but quite complex
00:29:58
Danno Ferrin:If we uncap the contract size then transaction gas limit becomes the new contract size limit. 24k is ~6 Million, so 16M gas would be in the neighborhood of 64k -72k contracts once code deposit is paid. So there is some pressure to not reduce it
00:31:33
Luis Pinto | Besu:Replying to "BALs utility goes do..."
But I’m failing to get why it would have any impact? No ones is going to redeploy contracts to have txs up to 30M or 20M whatever we decide
00:31:42
Alexey:Replying to "Can be solved by fur..."
Reminds of based rollups a bit btw
00:32:12
Vitalik Buterin:One final argument: I also think doing these reductions is better earlier rather than later
So if we do 20m soon, then when we have to reorg limits again for the sake of multidim, we become able to do it mostly through increases rather than decreases
00:33:02
Charles (vyper):can there be like a formula which is quadratic in the tx gas used
00:33:32
Toni Wahrstätter:Let's keep 16M and see if there's something where 20M helps anf is worth the trade off
00:33:36
Vitalik Buterin:> can there be like a formula which is quadratic in the tx gas used
I used to be in favor of things like this (see the quadratic evm memory cost :D:D) but I think in practice the gains of hard bounds are better
00:34:07
Charles (vyper):can be both -- hard limit of 30mm, but the gas price increases as you approach 30mm
00:34:08
Carl Beekhuizen:And to be clear, we can only use parallelism to scale if we can guarantee a TX limit. The average case doesn’t help us, worst case is all that matters for allowing us to push things
00:34:37
felix (eest):Replying to "can be both -- har..."
imo we should prefer simple solutions to reduce complexity
00:34:48
Nicolas Consigny:Replying to "Let's keep 16M and s..."
+1 on this I will reach out to DeFi people @Duncan Townsend (0x) I'd be happy to connect to discuss the contract you identified that were not in Toni's analysis
00:35:22
Barnabas:can we make final call on monday instead of 2w?
00:35:24
Toni Wahrstätter:Replying to "And to be clear, we ..."
Right, and this is almost a 2x for tx execution parallelism. It's a trade off in the end.
00:35:33
Barnabas:we really short on timeline if we wanna ship fusaka this year
00:35:38
Barnabas:and this change would require a new devnet
00:36:38
Vitalik Buterin:BTW I think we should also do another serious analysis of worst-cases for (i) per-chunk code access pricing, and (ii) multidim.
00:36:53
Tim Beiko:https://github.com/ethereum/consensus-specs/pull/4477
00:37:14
Vitalik Buterin:As those will both have a significant set of applications that get adversely affected, and it's better to know that 2 years before it happens than 1 year than 6 months
00:37:56
Ben Adams:Example from other ecosystems; a Solana tx can use at max 2% of the block computation
00:38:41
Luis Pinto | Besu:Replying to "Example from other e..."
But they prob don’t have the Ethereum baggage
00:40:14
Ben Adams:Replying to "Example from other e..."
Tx can only be max of 1232 bytes of data including signitures also 😅
00:40:24
nixo:this affects a very small class of home stakers, right? for CSM stakers, anyone with >$634k locked up from home
00:40:53
Parithosh Jayanthi:^ yes this is not for home stakers, it is for home validators who opt into CSM. Which is not the same as home stakers.
00:41:01
nixo:for rocket pool stakers, anyone with >$3.9M locked up from home
00:41:23
Vitalik Buterin:Another fun one: a major argument used to argue against bitcoin block size increases was due to a quadratic vuln (transactions with N signatures have to compute N size-N sighashes). I remember the stats were that at 1 MB, a worst-case tx takes 30s to eveluate, at 4 MB it would of course have become a network-breaking 8 min
00:41:27
potuz:Replying to "this affects a very ..."
These numbers are expected to pick up quite a bit this year
00:41:39
Barnabé Monnot:Replying to "^ yes this is not fo..."
nit but home operators are partially home stakers too, since they use some of their own capital as bond
00:43:46
nixo:Replying to "^ yes this is not fo..."
yea, so those running $634k of their own stake with CSM, running $14.9M delegated to them
00:44:02
Tim Beiko:https://github.com/ethereum/consensus-specs/pull/4477
00:44:07
Tim Beiko:This is the proposed change ^
00:44:32
nixo:Replying to "this affects a very ..."
wdym pick up? more CSM stakers or specifically CSM stakers with >$634k of their own bond?
00:44:47
Vitalik Buterin:I can see the economies of scale argument going both ways
00:45:09
Vitalik Buterin:The proposed change increases econ of scale between 32 eth and 4096 eth, but decreases econ of scale between 4096 eth and 16384 eth
00:45:19
Barnabas:if a node operator wants to reduce costs, the easiest by far is by consolidation.
00:45:40
Barnabé Monnot:Replying to "if a node operator w..."
does this affect custody requirements?
00:45:45
Manu:Replying to "if a node operator w..."
no
00:45:47
Vitalik Buterin:There is an argument that "lazy millionaire enthusiasts" are a significant solo staker demographic, and making it easier for them to solo stake will significantly move the needle in terms of increasing our nakamoto coefficient
00:45:57
Manu:Replying to "if a node operator w..."
Custody requirements are ETH based, not “validators count based"
00:45:59
nixo:Replying to "if a node operator w..."
is it 4096 ETH or 128 validators?
00:46:21
Manu:Replying to "if a node operator w..."
3 validators with 32 ETH = 1 validator with 96 ETH
00:46:25
Barnabas:Right, but you could techincally run 500/5000 validators of each 2000 ETH on a single machine
00:46:27
Justin Traglia:Currently, a node with ~$16m worth of ETH would be a supernode. With this change it would be 4x this, so $64m worth of ETH on a single node. I feel the original value is more than enough.
00:46:28
Barnabé Monnot:Replying to "if a node operator w..."
@Manu my intuition is that the cost reduction from consolidation is pretty minimal compared to the cost of custody at some scale
00:46:45
Carl Beekhuizen:But that is a fundamental limitation of DVT. The cost of DVT is paid via hardware-inefficiencies in contrast to rocket-pool etc that incurs economic inefficiencies.
00:47:41
nixo:re: “lazy millionaire enthusiasts"
00:47:45
Barnabas:Replying to "if a node operator w..."
we estimate that at 70 blobs we require 300Mbps internet connection with the current setup.
Is it really that bad to assume that someone running $4M at home, wouldn’t have access to 300Mbps internet? And a $200 nvme drive?
00:47:47
Ansgar Dietrichs:Replying to "There is an argument..."
right, but that would be a case for increasing the min stake amount to me then
00:48:17
Ansgar Dietrichs:Replying to "ef2b4cf2a45de063101759fd6a1c0cd3.webp"
risky clicking on this
00:48:26
nixo:Replying to "ef2b4cf2a45de063101759fd6a1c0cd3.webp"
sorry 😅
00:49:02
Ansgar Dietrichs:right, there is no technical reason to be opposed to this change
00:49:25
Ansgar Dietrichs:Replying to "right, there is no t..."
that’s why I was saying though, treating it as a technical change is hiding the broader question about staking incentives
00:49:51
Barnabas:we could make final decision on monday
00:49:53
Enrico Del Fante (tbenr):But columns do not scale based on blobs number
00:50:02
stokes:Replying to "But columns do not s..."
The size of them do
00:50:05
Ansgar Dietrichs:also side point, it seems way too late into the fork to make such a big change (conceptually big, not technically)
00:50:06
Dmitry Gusakov:I don’t feel there is arisen to park it
00:50:13
Ansgar Dietrichs:Replying to "also side point, its..."
very bad process
00:50:25
potuz:I personally think that we will see some home nodes being kicked out at Fusaka because of this... at the very least my own node
00:51:07
stokes:Replying to "But columns do not s..."
And also cols you care about scale w/ your eth staked
00:51:16
Parithosh Jayanthi:So the ask is that every CL team has an async opinion by ACDT?
00:51:17
Enrico Del Fante (tbenr):Replying to "But columns do not s..."
Ye but size is not the only thing
00:51:18
Dmitry Gusakov:I think CLs are for the change. At least looking at the PR likes
00:51:25
Barnabas:I don’t think this is a CL / EL question , its a lot more philosophical
00:51:41
Enrico Del Fante (tbenr):Replying to "But columns do not s..."
There is a significant impact at fulu activation
00:51:43
stokes:Replying to "I personally think t..."
This is kind of the question though, re these “lazy millionaire home validators”
00:51:55
Barnabas:from CL point of view, its a pretty much a no-op, we just set a config value.
00:52:02
stokes:Replying to "I personally think t..."
If anything I like Francesco’s suggestion of some kind of bimodal chart for assessing custody
00:52:11
stokes:Replying to "I personally think t..."
But that’s too big a change to do now IMO
00:52:44
nixo:also - i assume, potuz, that you’ll still be able to run your own validators? it’s just less incentive to take on delegated stake? how much does it affect the smaller nodes, you said it begins at 36 ETH(?)
00:52:59
Justin Traglia:Personally, I’m against this change.
00:53:08
Francesco:Does having to have another devnet delay things or not really? For me that’s more important than the change itself
00:53:10
potuz:Replying to "I personally think t..."
I am not sure what's meant by the "lazy millionaire home validators" but in my case I run the limit of 12 Lido keys and that's only an investment of about 15ETH on my part... those keys will definitely need to be gone
00:53:22
potuz:Replying to "I personally think t..."
The problem is that those keys will move to some other centralized way of staking
00:53:29
Barnabé Monnot:Replying to "I personally think t..."
if the custody requirements increase more gradually, doesn’t it make it easier for you @potuz ?
00:53:30
Tim Beiko:Replying to "Does having to have ..."
We may already have a devnet if we change the txn limit cap
00:53:31
stokes:Replying to "Does having to have ..."
Even just rolling a new devnet takes a day
00:53:41
Francesco:Replying to "I personally think t..."
Why would they need to be gone? 12 keys means 12 columns instead of 8
00:53:47
stokes:Replying to "Does having to have ..."
Will it make e.g. Nov timelines impossible, likely no
00:53:50
potuz:Replying to "I personally think t..."
this is precisely what @Ansgar Dietrichs is pointing towards the philosofical change, and I think we should be on the side of this change, not the other
00:53:53
stokes:Replying to "Does having to have ..."
But it will add stress 🙂
00:54:26
Parithosh Jayanthi:Replying to "I personally think t..."
^ yeah would 12 keys actually kick you out potuz? It isn’t that many more columns than the default 8...
00:54:31
potuz:Replying to "I personally think t..."
@Francesco yes, I'm exagerating now with the 12 keys, I do expect these numbers to increase dramatically this year as soon as the limits are lifted
00:54:36
Ansgar Dietrichs:“maintain the spec as is” is not a decision, it’s the default
00:54:49
Csaba:I think it is better to do a NotJustBlobParameter than a rushed changed now
00:54:58
potuz:Replying to "I personally think t..."
CSM just started, RP also just lowered limits not long ago
00:55:13
stokes:Replying to "I personally think t..."
And my point is that we can adjust this feature then, after we have had more time to find a best solution and at the same time not delay fusaka rollout
00:55:19
Justin Florentine (Besu):Replying to "“maintain the spec a..."
agree, but "maintain in light of new information" may be a decision 🤔
00:55:20
Francesco:Replying to "I personally think t..."
I think most likely your bandwidth consumption will go down for a while 😄
00:57:51
potuz:Yeah I think it's better to make these decisions in ACDE/C rather than /T. What Alex mentioned seems the right course of action to me at least
00:57:56
Barnabas:its buy one get 2 change 😂
00:58:00
Mario Vega:Are we discussing tx gas limit cap on monday?
00:58:06
stokes:Replying to "its buy one get 2 ch..."
The best kind /s
00:58:30
Parithosh Jayanthi:Replying to "its buy one get 2 ch..."
last_call_eip_changes_final_v2.pdf
00:58:47
Barnabas:Replying to "its buy one get 2 ch..."
the spec has melted
00:59:12
Ben Adams:Replying to "its buy one get 2 ch..."
last_call_eip_changes_final_v2_final_final_4.pdf
00:59:30
Justin Florentine (Besu):Replying to "its buy one get 2 ch..."
who turned off track changes?!?!?!?!
00:59:32
Toni Wahrstätter:Replying to "Are we discussing tx..."
If there are reason to re-evaluate 20m over 16.8m
01:00:22
Barnabas:I think we should aim for 1st of Sep releases. With a possible delay to sep 15. (if something major found)
01:00:54
Barnabas:Holesky -> Sepolia -> Hoodi -> Mainnet
01:01:08
Dmitry Gusakov:Holesky is dead, right?
01:01:10
nixo:i thought we made a definitive decision after pectra to do sepolia before hoodi?
01:01:12
Phil Ngo:I would like to see if it’s possible to get some sort of non-finality testing going post releases
01:01:19
Phil Ngo:Maybe use Holesky?
01:01:19
Barnabas:its at 85% perticipation
01:01:26
Dmitry Gusakov:Replying to "Holesky is dead, rig..."
Wow
01:01:41
Barnabas:Replying to "Holesky is dead, rig..."
https://light-holesky.beaconcha.in
01:02:48
potuz:Can we just fork Holesky even pre-release with the devnet branches? It should be fine if it goes through turmoil
01:03:17
Barnabas:Pandas take on dates:
Would prefer to do holesky on week sep 15-18
Would prefer to do sepolia on week sep 22-25
Would prefer to do hoodi on week oct 13-16
Would prefer to do mainnet week nov 3-6
01:04:25
stokes:Replying to "Pandas take on dates..."
Can we comfortably do sepolia then if there is an issue w/ Holesky?
01:04:33
Chris:Replying to "Can we just fork H..."
Doing this without formal releases will make it more difficult to rollout clients and get participation from node operators.
This isn't necessarily a blocker, but leads more and more likely we have a worthless fork.
01:04:44
Barnabas:Personal dates posted as parts of our team is OOO, and wouldn’t wanna fall into the same trap as pectra
01:04:45
Justin Florentine (Besu):Replying to "Pandas take on dates..."
i assume all dates are "happy path"
01:04:49
stokes:Replying to "Pandas take on dates..."
Unironically could consider a time box for holesky debugging
01:05:29
Gabriel Trintinalia | Besu:👍
01:05:31
potuz:Replying to "Can we just fork Hol..."
it will need a release anyway since it needs the fork data
01:05:55
potuz:Replying to "Can we just fork Hol..."
point is that it doesn't need to be production ready code, the current devnet one should be good enough perhaps
01:06:52
Chris:Replying to "Can we just fork H..."
If client teams are comfortable releasing betas or something similar that's fine. Expecting node operators to build from source or other non-standard release path will likely limit participation.
01:06:55
potuz:ePBS, shorterr slot times and Focil
01:07:05
nixo:https://ethereum-magicians.org/t/soliciting-stakeholder-feedback-on-glamsterdam-headliners/24885
01:07:35
Justin Florentine (Besu):Besu likes BALs
01:07:40
Jared Wasinger:Geth supports BALs as the EL headliner
01:07:50
Ansgar Dietrichs:I would just mention that repricings are the same importance level to me to BALs. they make less of a sexy headliner, so I am fine with BALs, but important to keep in mind
01:08:03
Ansgar Dietrichs:Replying to "I would just mention..."
ofc we should do both in Glamsterdam
01:08:04
Andrew Ashikhmin:Erigon supports BALs
01:08:05
Barnabas:balls-devnet-0 end of Aug?
01:08:21
Roman:yesssss
01:08:50
Ahmad Bitar | Nethermind:Delayed execution do not provide benefits to l2s or preconfirmations
01:08:51
Tim Beiko:Assuming we did do DE over EPBS, would we still want to do BAL alongside it?
01:09:07
terence:DE is a EL headliner, not a CL headliner
01:09:16
Ansgar Dietrichs:@Francis can you clarify, do you actively prefer delayed execution over ePBS? I understand you think it is less complex, but you still get the same benefits
01:09:23
Justin Florentine (Besu):that changes our math
01:09:26
Francis:yes
01:09:28
stokes:Replying to "DE is a EL headliner..."
We likely don’t want to do DE and ePBS in the same fork though
01:09:35
stokes:Replying to "DE is a EL headliner..."
So it becomes a xor choice
01:09:40
terence:Replying to "DE is a EL headliner..."
exactly
01:09:51
Barnabé Monnot:Replying to "DE is a EL headliner..."
it’s a bit strange that they can be independently decided by different forums tho
01:09:56
stokes:Replying to "DE is a EL headliner..."
It is
01:09:58
potuz:Replying to "@Francis can you cla..."
to use the code on L2
01:10:07
potuz:Replying to "@Francis can you cla..."
for L1 they are the same
01:10:12
potuz:Replying to "@Francis can you cla..."
in terms of preconfs
01:10:14
Francis:if we could get both de and bal in, that'll be awesome
01:10:30
Francis:but not sure if it's possible
01:11:05
Tim Beiko:At the very least we can CFI BALs alongside the 3 other headliners?
01:11:07
Dmitry Gusakov:Replying to "this affects a very ..."
Second
01:11:23
Dmitry Gusakov:Replying to "this affects a very ..."
Cause CSM is currently limited by the share
01:12:00
Dmitry Gusakov:Replying to "this affects a very ..."
Once the share is 10% of lido or more, and the bonds go down, we can see an increase in the number of big Home Stakers
01:12:07
stokes:Each layer could do this “cond. ack” indefinitely though
01:12:10
stokes:Someone has to move first
01:12:13
Justin Florentine (Besu):this early in planning, i think conditional CFI'ds are fine
01:12:18
Ansgar Dietrichs:Replying to "@Francis can you cla..."
ah, I see
01:12:23
Francis:Replying to "@Francis can you cla…"
It's also good for L1? moving execution out of current block gives preconfs headroom and time to be more stable? I don't see the diff of benefits between L1 and L2
01:12:33
potuz:I think we should have weekly ACD and stop this thing of the two week latency which is artificial
01:12:35
Dmitry Gusakov:Pls do ePBS
01:12:51
Francis:Replying to "@Francis can you cla…"
if you have to do execution at the same block, wouldn't that eat into preconfs time budget?
01:12:53
Ansgar Dietrichs:Replying to "@Francis can you cla..."
@Francis this is the same for delayed execution and ePBS though (from L1 perspective)
01:12:54
stokes:Replying to "I think we should ha..."
For some things it is better, for some it is worse
01:13:09
Tim Beiko:Anyone against CFI’ing BALs?
01:13:10
Ansgar Dietrichs:Replying to "@Francis can you cla..."
or am I missing something?
01:13:16
stokes:Replying to "Anyone against CFI’i..."
no
01:13:23
stokes:Replying to "Anyone against CFI’i..."
Seems like the move today
01:13:31
potuz:Replying to "I think we should ha..."
yeah for this we should just do weekly and just focus more on one or the other side
01:13:40
Tim Beiko:Replying to "I think we should ha..."
That’s what we do lol
01:13:48
nixo:Replying to "https://ethereum-mag..."
tl;dr for EL:
Snowbridge: 6-sec slots
LidoDAO: BAL
Flashbots: BAL
Cometh: EOF
Sigil L2(?): BAL
Wallet dev: BAL
L2: BAL
Home stakers: BAL
Base: DE, BAL
0x: 6-sec slots
Researcher: BAL
01:13:55
stokes:Replying to "I think we should ha..."
Yeah, only diff would be making it clear we should have both layer attendees weekly
01:14:05
stokes:Replying to "I think we should ha..."
Which we already do have in part
01:14:23
Tim Beiko:Replying to "I think we should ha..."
Yes, all teams should ideally have someone at each call. Is there anyone missing today?
01:15:02
potuz:Replying to "https://ethereum-mag..."
that
01:15:06
potuz:Replying to "https://ethereum-mag..."
is the whole topic now
01:15:40
nixo:Replying to "https://ethereum-mag..."
where’s the table from?
01:16:07
Toni Wahrstätter:How does ePBS address the free option problem that was raised recently?
01:16:08
Francesco:Replying to "I think we should ha..."
Even if there is an expectation that all teams have someone at each call, seems to me that we often prefer not to make a decision on the “wrong” call even if it would be useful to decide more quickly
01:16:21
potuz:Replying to "I think we should ha..."
> That’s what we do lol
We always delay decisions based on the breaking
01:16:53
Ben Adams:Replying to "I think we should ha..."
Wait, are we only meant to attend one of the meetings?
01:17:03
Sophia Gold:Replying to "How does ePBS addr..."
Also wondering if it will be modified at all, e.g. will the blob deadline be moved up?
01:17:04
Tim Beiko:Replying to "I think we should ha..."
Do you think it would have been better to focus this call on EPBS vs. DE @potuz @Francesco ?
01:17:19
potuz:Replying to "I think we should ha..."
I don't think there is a discussion ePBS vs DE
01:17:33
soispoke:Replying to "How does ePBS addres..."
Post based on empirical data about the free option problem coming soon (collab between us and FB)
01:17:51
potuz:Replying to "I think we should ha..."
we've already had that discussion and the sides have spoken overwhelmingly
01:18:20
Francesco:Replying to "I think we should ha..."
I meant more generally
01:19:25
ethDreamer (Mark):Replying to "How does ePBS addres..."
There's two ways:
Decreased PTC deadline
Penalty for non reveal
01:19:59
ethDreamer (Mark):Replying to "How does ePBS addres..."
The free option problem is a spectrum not a switch
01:20:15
ethDreamer (Mark):Replying to "How does ePBS addres..."
We don't even know at this point how much of an issue it is
01:20:22
Ansgar Dietrichs:Replying to "How does ePBS addres..."
decreasing the PTC deadline is actively eating into the scaling benefits of ePBS, I would be stronly opposed to that
01:20:30
Barnabé Monnot:Replying to "How does ePBS addres..."
are we fine with penalising local builders now?
01:20:37
ethDreamer (Mark):Replying to "How does ePBS addres..."
No it's not when we shorten slots
01:20:56
donnoh | L2BEAT:might be early to discuss this but in the context of native rollups any change that current rollups make wrt L1 it makes more complicated to eventually switch to native
01:21:27
ethDreamer (Mark):Replying to "How does ePBS addres..."
Local builders can avoid this penalty even in the most unlucky circumstances by publishing the payload before the beacon block
01:22:26
ethDreamer (Mark):Replying to "How does ePBS addres..."
Decreasing the PTC deadline is something we would already do when we shorten slots
01:22:37
Raúl Kripalani:the execution payload separation from ePBS is very valuable from the p2p perspective
01:22:59
Ahmad Bitar | Nethermind:Replying to "How does ePBS addres..."
Why wouldnt i panalize a builder that commited to a payload and then didnt share it?
01:23:09
Francis:Also want to call out that this is our preference and what we think would be most impactful, would be happy with what the community as a whole decides.
01:23:14
stokes:Replying to "How does ePBS addres..."
It could not be the builder’s fault
01:23:21
stokes:Replying to "How does ePBS addres..."
Could be network problems outside the builder
01:23:28
stokes:I think hard to do this type of penalty in a robust way
01:23:30
potuz:A TL;DR that I sent nixo
01:23:34
Barnabé Monnot:Replying to "How does ePBS addres..."
@ethDreamer (Mark) you wouldn’t decrease the deadline necessarily but it would have more overhead with respect to the slot time, hence the free option would not be as bad
01:23:41
potuz:That's the ETHMAG thread today
01:23:50
Barnabé Monnot:Replying to "How does ePBS addres..."
@Ahmad Bitar | Nethermind you couldn’t tell whether it’s an external builder or a local one
01:23:54
Ahmad Bitar | Nethermind:Replying to "How does ePBS addres..."
Local builders can share the payload even earlier than others since they dont care about hiding content
01:24:26
ethDreamer (Mark):Replying to "How does ePBS addres..."
They also only build using public blobs so blob broadcast isn't an issue
01:25:23
Justin Florentine (Besu):Besu is open to variants. We have a pr that implements EIP as written.
01:25:30
terence:Replying to "How does ePBS addres..."
local builder wont be penalized here though, they bid amount is just 0 here, this is checked in the state transition function
01:25:46
Barnabé Monnot:Replying to "How does ePBS addres..."
i don’t disagree with the arguments, we just had reached a different conclusion last time the question came up around missed slot penalties
01:26:01
Ahmad Bitar | Nethermind:Replying to "How does ePBS addres..."
Oh true, penalty can by a multiple of the bid amount
01:26:28
Julian Ma:Replying to "How does ePBS addres..."
If you make penalty a multiple of the bid amount that would be an incentive not to use the in-protocol bid amount and use trusted relays
01:26:30
potuz:Replying to "How does ePBS addres..."
FWIW I agree with Alex and I am against slashing mechanisms... Assymetric payment is not a bad idea (a refund to the builder if the payload is processed) and easy to implement...
01:26:30
ethDreamer (Mark):Replying to "How does ePBS addres..."
Better for penality to be a flat fee imo
01:26:36
Barnabé Monnot:Replying to "How does ePBS addres..."
@Ahmad Bitar | Nethermind that would give even more incentive to not reveal the true bid to the protocol
01:26:42
Justin Florentine (Besu):provers want to know what was referenced
01:27:16
ethDreamer (Mark):Replying to "How does ePBS addres..."
No need for multiple. Multiple scales with large bids but large bids already outpace the value of the option
01:27:23
Ansgar Dietrichs:so I guess conclusion is “exact variant of BALs still tbd”?
01:27:25
potuz:Replying to "How does ePBS addres..."
More generally, I think the problem is much more constrained than what it is being made of, as I posted elsewhere, this only applies to single builder-searcher integrated, not any existing builder
01:27:57
Justin Florentine (Besu):feels like an "implementation detail" we can play with?
01:28:20
Ansgar Dietrichs:actually both ePBS and DE reduce the ratio of propagation to execution, so they would tighten the (relative) data constraints on BALs
01:28:30
Julian Ma:Replying to "How does ePBS addres..."
Large bids correlate with periods of high volatility which is exactly when the option would be most valuable
01:28:43
Orest Tarasiuk (t1):thx!