Ansgar Dietrichs:Welcome everyone to All Core Devs Call 232.
Transcript
Ansgar Dietrichs:Today, we have a few topics, around the ongoing preparation for Glamsterdam, and then looking forward to
Ansgar Dietrichs:Hegota and the headline selection there. Let's start with, Glamsterdam. DevNet updates, I think, Stefan, you could give us some updates on BAL DevNet 2 and 3?
Stefan Starflinger:Yes, can you hear me? So…
Ansgar Dietrichs:Yes.
Stefan Starflinger:for BAL DevNet 2, it's been going pretty well. I think only Erigon is left to,
Stefan Starflinger:get ready and start proposing some blocks, but they've been doing some work on fixing some syncing issues, and they should be ready soon, proposing blocks on DevNet 2.
Stefan Starflinger:We've also got further with the efforts to get some benchmarking ready on DevNet 2, and any benchmarking effort has been done against BAL DevNet 2 so far.
Stefan Starflinger:We've started dedicated nodes so that we can compare three different approaches. There is the all optimizations of BAL, then there is sequential, which is no optimizations of BAL, but still with any optimizations that the clients
Stefan Starflinger:have, inherently. And then there is no, prefetch, so with BAR, there's the concept of prefetching.
Stefan Starflinger:the state through the block-level access list before executing in parallel, and we wanted to see in the block-level access list if reading all the state in the beginning, is actually a speedup or not.
Stefan Starflinger:And there we see a little bit of mixed results, but it's just the average case, so we haven't been testing the worst case yet. So, so far we see that without prefetch, it's currently faster than with it.
Stefan Starflinger:That's for, DevNet 2, unless there is anything else for DevNet 2.
Stefan Starflinger:If not, I would, move on.
Stefan Starflinger:To, DevNet 3.
Stefan Starflinger:So I've been testing a lot, on kurtosis, and it, seems…
Stefan Starflinger:that most clients are not ready yet for, especially, 8.37. There are still some, issues that clients are resolving, and a recent test release was made by Spencer5.4.
Stefan Starflinger:And it would be good if all clients could test and see that they are passing as many tests as possible.
Stefan Starflinger:Yeah, and I think that's pretty much, the status for DevNet 3. We haven't started it yet.
Stefan Starflinger:And there's a point from Marius, so I would pass on.
Stefan Starflinger:Fuck.
Ansgar Dietrichs:Sounds good, Marius.
Stefan Starflinger:Or no, it wasn't Marius, it was, Iber, no, someone, someone else has.
Ansgar Dietrichs:Yes.
Stefan Starflinger:Sorry.
Ansgar Dietrichs:Right, right. Exactly. No, no worries. I saw this. So, basically, I think there is some concerns around, EIP8037. I'd heard this already, that clients in general were saying that it's a bit more complex than initially.
Ansgar Dietrichs:a thought, for context, of course, you know, we do need a…
Ansgar Dietrichs:an approach to state growth, if we do not end up addressing state growth at all in Amsterdam, we can't make use of all of the scaling benefits in the fork, so in some ways, it's kind of without alternative, but of course, the specific version of it is with alternative, and so…
Ansgar Dietrichs:their concerns whether the current shape of 8037 really is the thing we should or can do. Andrew, do you want to give a bit of an overview of your concerns, your team's concerns?
Andrew Ashikhmin:Yes, sure. So, as I wrote, now we have, like.
Andrew Ashikhmin:for 4 flavors of gas, so 4844 introduces blob gas, then 7928, introduces this, like, state gas accounting versus non-state gas accounting. 7778 introduces blob… block accounting versus user refund accounting.
Andrew Ashikhmin:And the 8037 introduces state versus regular gas, and each of the… all of those changes in isolation, they make sense, but if you look at all of them together, like, they end up in a horrible mess, because they are not aligned with each other.
Andrew Ashikhmin:So, if, like, if we are, keeping 8037 or something similar in Glamsterdam, then I think we should take a step back and…
Andrew Ashikhmin:And make…
Andrew Ashikhmin:make the gas changes coherent on the protocol level. So, say, how I see it, if you look at… if you look at, at Bells, 3928, they say, okay, you have
Andrew Ashikhmin:a gas validation before state access, and, like, pre-states, like, pre-state validation and post-state validation, right? And then, 8037 talks about state versus regular gas.
Andrew Ashikhmin:I think that we should just bite the bullet and do it coherently and say, okay, now gas is three-dimensional, the dimensions are blob gas, state gas, and computational gas.
Andrew Ashikhmin:When, like, 7928 and,
Andrew Ashikhmin:8037 talk about state gas, they should talk about exactly the same state gas, right? So we should refactor both… both 7928 and 8037, like, to use exactly the same thing, the state gas.
Andrew Ashikhmin:And, then we should also, like, we should either drop, 77, 78,
Andrew Ashikhmin:Or make it, like, maybe we should drop refunds entirely, rethink 7778, or just double-check that if we introduce this more or less coherent
Andrew Ashikhmin:three-dimensional gas, that 7778, is still…
Andrew Ashikhmin:is still fine. Because if we don't do that, if we just add all the… all those kind of independent hacks all together, then we end up
Andrew Ashikhmin:In a… in a horrible mess, like… like we are now, with a gazillion of corner cases, things are incoherent, illogical, all kind of… you need to…
Andrew Ashikhmin:To think about… just very hard or impossible to think logically about what gas is now.
Andrew Ashikhmin:In Ethereum. So, if we don't do this coherent.
Andrew Ashikhmin:Approach, then we'll end up with a lot of technical data.
Ansgar Dietrichs:Yeah, we have a few, people with hands up. Mario?
Maria Silva:So I…
Maria Silva:I just, I just wanted to speak a little bit to the more principled approach. So I… the way I see it is…
Maria Silva:I think we've been using GAS for two different uses so far, in DVM. So, on one hand, we use Gaz for transaction pricing, so to decide how much a user should pay for things.
Maria Silva:But we are also using it to control resource abuses through the… through the block limit. So we want to make sure that execution doesn't take more than a certain amount of seconds, and that state doesn't grow at more than a certain rate.
Maria Silva:And because we are using the same thing for these two things, we end up in a non-optimized approach. So, I think one…
Maria Silva:principal…
Maria Silva:way that we should look at it is these are two different things, and so when we talk about transaction gas use, this is an inherently different thing from
Maria Silva:the block limit and block metering, so we should probably even have, like, these two different concepts. We have transaction gas use, and we have block metering, block gas metering. So this is… and I think some of the confusion around
Maria Silva:1837, is that now we are actually needing to make these specific
Maria Silva:On what do we mean by
Maria Silva:the gas used in a block, and what we mean by the gas used in the transaction. So this is, like, the axis number one. Like, these two things need to be separate. The… the other axis is on the resources side, and I think the long-term
Maria Silva:principal approach is as, as was said, which is, like, we need to separate the resources if we want to have a better control over them. And I think the… the end goal for that would be something like 7999, where we are actually… have, like, a separate fee market for
Maria Silva:For… for each resource.
Maria Silva:And I think 8037 is compatible
Maria Silva:With 7999, and it's already implementing a lot of the things that we would need to then have 7999.
Maria Silva:And so…
Maria Silva:the way I see it, I think it's, like, 8037 is a step in the direction of the ends
Maria Silva:principled approach.
Maria Silva:So that's, that's, that's how I see it, and it's also a needed thing we need now if we want to continue to scale without having, state grow at the, at the, unmanageable rate.
Ansgar Dietrichs:Felix?
Felix (Geth):Yeah, thank you. I just wanted to quickly give the feedback from the implementer point of view. I was recently also debugging something related with this EAP, and the primary issue that we see right now is things like, for example, how is the reverse being handled? Like, how is the gas correctly
Felix (Geth):Attributed back to parent frames in these scenarios, and it took us a long time to figure out the correct semantics.
Felix (Geth):And I'm pretty sure that there's more cases like this, so it really has… it seems the bug potential of this EAP is very high. Doesn't mean the idea of it is bad, it's just, I think, what Andrew is also kind of trying to say here is that
Felix (Geth):It just intuitively feels like something that is super easy to get wrong.
Felix (Geth):And…
Felix (Geth):Yeah, I just really wanted to voice it that, like, from an implementer perspective, it's… it is… it's kind of complicated.
Ansgar Dietrichs:Andrew.
Andrew Ashikhmin:Yeah, so… so I think it's… yeah, right, right now we are reaching this level of complexity that we need the principal approach now, so I'm very uncomfortable with, implementing and shipping,
Andrew Ashikhmin:8037 without a principal approach, so…
Andrew Ashikhmin:It either has to be refactored with a principled approach, and that principled approach should be also applied to 3928, 7778, and also blob gas should be consistent with the principled approach.
Andrew Ashikhmin:Or we should not ship it at all.
Andrew Ashikhmin:Otherwise, yeah, if we just, yeah, ship it without a principled approach, it will be very bug-prone, or error-prone.
Ansgar Dietrichs:And Dragon?
Dragan Rakita:I think the state gas is very much needed if you want any bigger blocks.
Dragan Rakita:It is complex change because it touches the gas, and everything that touches gas is very sensitive. There's a lot of edge cases there.
Dragan Rakita:I do think that there was a moving target regarding this AIP. There was a lot of cases that would not cover the example of how to return or revert to the halt. The reservoir was something that we, like, talked to weeks ago.
Dragan Rakita:And… The tests are currently… Needs to be polished a little bit, because they are just made now.
Dragan Rakita:So, I think…
Dragan Rakita:it's a little bit chaotic, because it's not… we are just coming to the place where the AIP is polished.
Dragan Rakita:So, in my opinion, we should…
Dragan Rakita:Add it, we should bind the bullet and just implement it.
Dragan Rakita:It will get better.
Ansgar Dietrichs:Yeah, I mean, from my side, I wrote some of this in chat, I think a full rework of,
Ansgar Dietrichs:Gas.
Ansgar Dietrichs:and basically trying to move towards a principled, integrated approach to gas in all ways, I think is, to me at least, infeasible for Glamsterdam, just because I think this is something that already in the background people have been thinking about. It's just a really, kind of.
Ansgar Dietrichs:Complex thing to get right.
Ansgar Dietrichs:Mmm…
Ansgar Dietrichs:that leaves us, I think, with the question of specifically on, this kind of state creation side, do we… can we either A make some adjustments to 8037 that make it easier to implement, or maybe just
Ansgar Dietrichs:Bigger changes, in principle, that, that, that really kind of reduce complexity on this topic in particular.
Ansgar Dietrichs:I… have… personally have a hard time seeing us making that…
Ansgar Dietrichs:final decision today, just because I think it was a kind of very short-term, short notice raised concern, and it's a consequential decision. So I'd rather than, say, schedule a breakout call for something like next week to really dive in on that call than make decisions.
Ansgar Dietrichs:Hmm…
Ansgar Dietrichs:I do wonder if we were to say today that we need changes, where that would leave us with regards to BAL DevNet 3, whether we would say we would still go ahead with 8037 as is, just to get it out the door, and then maybe have some more…
Ansgar Dietrichs:insights on how it behaves, or whether to then hold off the DevNet, until we've decided what to do about it.
Ansgar Dietrichs:I don't know if people have thoughts on this question. Also, Maria?
Maria Silva:was just… I was just going to… to add that we do have a repricing, breakout, next Wednesday, so I think that could be a good opportunity. Andrew, if you could,
Maria Silva:to dive deep into, in your opinion, what changes could be made to make it, work better with the other EIPs. I think, like, doing the full, principled approach might not be possible, because that would mean, like.
Maria Silva:adding all the resources we want, thinking about what about the ZKVM, so I don't think we'll do, like, the full, full thing, but…
Maria Silva:trying to make it less prone to edge cases and errors. I think it's… it's, it's, it's, it's a good aim, and so I'm… I'll be happy to have…
Maria Silva:In-depth discussion on this.
Ansgar Dietrichs:Ben?
Ben Adams:There's a question… a lot of the…
Ben Adams:Some of the complication comes from, like, tracking refunds and things, and…
Ben Adams:We could go back to the…
Ben Adams:question, do we just drop refunds? Is it… is the benefit that they bring
Ben Adams:More… more valuable than the complexity they're causing.
Dragan Rakita:So…
Marius van der Wijden:I think the problem that, why refunds are a bit complicated with this is because we are,
Marius van der Wijden:the current rule is that we are tracking… that we are refunding the state gas to this… to, to the state gas reservoir. If we would just refund the gas as… or if we had the same logic for the state gas as for normal gas.
Marius van der Wijden:Then, it would be significantly
Marius van der Wijden:easier to implement. The… The logic behind…
Marius van der Wijden:Refunding to the state gas reservoir is that, hey, you didn't use up the state gas, because you are not changing anything.
Marius van der Wijden:So, you are… you are being refunded that gas. But if we just say, hey, the state gas is handled, the same way that the regular gas is handled, then we can pretty significantly simplify things. But I…
Marius van der Wijden:I also don't think it is that complicated.
Marius van der Wijden:like, the first implementation I had of it was pretty complicated, but, I've been refactoring it, and
Marius van der Wijden:The only thing that is… That was pretty ugly about it was the thing that we just changed.
Marius van der Wijden:With, with the recent BAL release.
Marius van der Wijden:Otherwise, it is pretty straightforward, to be honest. When you are in this… when you are, like, yeah, when you are thinking about this, it's not that complex, to be honest.
Ben Adams:Yeah, I mean… refunds altogether, so we have the…
Ben Adams:The one that tracks how much,
Ben Adams:Has been used in the block versus how much
Ben Adams:You know, there's the separation of,
Ben Adams:Here's the refunded gas in the transaction, but here's how much resource the block has actually used.
Ben Adams:less the refund.
Ben Adams:So… if we… so there was, like, EIP…
Ben Adams:3298, where it was, like, get rid of 3 funds altogether.
Ben Adams:So the question is, the refund incentive, is it that strong that people are deleting space?
Ben Adams:Or, or…
Ben Adams:Is it enough?
Dragan Rakita:m-maybee… I have some clarification here. In REV implementation, we don't touch a refund at all.
Dragan Rakita:The refilling of the state gas of reservoir with the state gas that's not used is, like, a different variable.
Dragan Rakita:So, dropping refunds doesn't, like…
Dragan Rakita:touch the refunds. In general, the constants around that is not touching the state gas, or…
Dragan Rakita:Or, reservoir at all. So it's like, Totally separate.
Dragan Rakita:In that part, it's like, it became very simple.
Dragan Rakita:propagand reservoir and coming back from the subcoals, it's simple logic. The problem that I had mostly is about merging that inside,
Dragan Rakita:Before execution and after execution per section.
Dragan Rakita:So I don't think the dropping…
Dragan Rakita:Refunds is going to solve anything around that.
Ansgar Dietrichs:Right. I do think, yeah.
Ansgar Dietrichs:Again, it seems unlikely to me that we will be able to make a decision today, but…
Ansgar Dietrichs:It seems like an important topic, because if, indeed, the feeling is that also, say, for example, from the testing side, I mean, maybe, do we have someone from the testing side who could briefly, like, maybe Mario or someone who could briefly speak up on what the latest feeling is around testing complexity of AD37 in particular?
Mario Vega:I think Spencer has more context, but I can give the overview. Well, at least my feeling, is that it does break a lot of tests. I think it's very complex in the testing side, but only because
Mario Vega:I mean, primarily because the static tests are not ready for this kind of changes, but we are in the process of converting this.
Mario Vega:The problem is that this is 10 years of…
Mario Vega:of tests, so it's not easy. And we've been meaning to do this for a long time, and I think 8037 is, like, pushing us to just get it done. Spencer, do you have other…
Mario Vega:Comments?
spencer:Yeah, it is tricky, and I mean, where the tests are right now, like…
spencer:At least in the most… yeah, in the most recent release, we don't have all the…
spencer:All the tests from the previous, previous works.
spencer:In the most recent release?
spencer:For about DevNet Free, we specifically chose to simplify some of the
spencer:or simplify… simplify a part of EIP8037 by essentially hard-coding the cost per state byte.
spencer:So it's already loosely simplified for this devnet, and My feeling…
spencer:maybe other clients can speak up here, but my feeling is that we should just go ahead with, DevNet Free as is.
spencer:and then kind of gauge from there if there's a lot more edge cases that pop up.
spencer:And yeah, for DevNet4, we will have a lot better coverage, and even more, I guess, specific edge cases for…
spencer:88037.
Mario Vega:One thing is that, we have not, successfully filled all the tasks, so that's something that we have to take into account. I wouldn't feel confident, or, about signing off this EIP into…
Mario Vega:into the fork if we are not passing all the tests. But we can process progress about this. I do feel that we have to make sure that none of the tests break, or worse than breaking is that they pass without verifying what they correctly did verify before.
Mario Vega:So, yeah, I think it's gonna take a lot of work.
Mario Vega:from us, but if we… if this is a change that we need, I mean, it's just… it's something that we have to do.
Ansgar Dietrichs:Yeah, sounds good, thank you, that adds good context, I think.
Ansgar Dietrichs:Yeah, I agree, I think, with the general take that it would be very desirable if we could go ahead with DevNet 3, BAL DevNet 3, as is, including AD37 in its current form, if that's at all feasible for clients, just because even if we then still want to consider making changes, I think it would be really good to just also see, in practice, how does it work, you know, in the end.
Ansgar Dietrichs:And then I would still also like the idea of, say, next week's repricing breakout, we specifically focus on the question of
Ansgar Dietrichs:kind of 8037 and complexity there, and is there anything we can do? What would be potential alternatives in terms of trying to find ways to simplify? Is this already the best we can do here?
Ansgar Dietrichs:Yeah, so to really have people join next week, if… on that topic. Does that, for now, seem like a reasonable approach? And then we basically see, after next week, basically, whether we just stick with it, even, and just accept the complexity, or whether there are things we can do?
Ansgar Dietrichs:It feels like that's the best way forward. Do we have, yeah.
Ansgar Dietrichs:How do people feel about that?
Ansgar Dietrichs:I guess Erigon, for example, would you all be, able to,
Ansgar Dietrichs:basically support BileDevNet 3, in its current form.
Andrew Ashikhmin:Yeah, we are working on it, so yeah, we'll try to make it work.
Andrew Ashikhmin:It sounds… Yeah, like a reasonable interim approach, but I think we should,
Andrew Ashikhmin:at least a line 79, 28, and 8037 in Glamsterdam.
Ansgar Dietrichs:Yeah, makes sense, and I think that's… The type of.
Marius van der Wijden:Yeah.
Ansgar Dietrichs:Next week, Maris?
Marius van der Wijden:I totally agree with that. I also think those are…
Marius van der Wijden:those are two AIPs that both change the way, receipts work, and, I think they are, yeah, they are specified very differently, and so we should, we should definitely, yeah, make them.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs:Mmm… then I think for now.
Ansgar Dietrichs:That's probably a good place to leave it at and move on. Is there any, like, any last comments, anything anyone would definitely still want to bring up on this topic for today?
Ansgar Dietrichs:Otherwise, before we get into Hegota headliner discussion, which is the main topic for today, I just very briefly wanted to ask Barnabas if there's any update regarding EPBS DevNet Zero. That's obviously mostly a CLSAT topic, but I think it's good to just…
Ansgar Dietrichs:Make sure we have visibility on from the EL side as well.
Barnabas:Yeah, sure. So, we have a stable-ish .NET, .NET Zero launched last week, Wednesday, and we've been going on for a whole week.
Barnabas:We have a few clients that are working. We have Lighthouse, Lone Star, and Prism working fine. Taku and Nimbus are working hard to, get up to head. We have Checkpoint Z working now as well. We have…
Barnabas:withdrawals working and deposits working. We currently do not have exits working, but it's something that clients are looking into getting fixed.
Barnabas:As well as exiting, 0.03, builders, that is not yet working.
Barnabas:We are expecting to have a new consensus pack released by the end of this week, and we are going to either launch the 1 next week, Wednesday, or a week after that.
Barnabas:That will be based on top of the latest, sales factual release.
Ansgar Dietrichs:Sounds good. Any EL-side topics, questions anyone has around this DevNet?
Barnabas:We currently only have, GAF as the EL. Ideally, we could have at least one more EL, just in case there's something, wrong with Geth. I'm not saying that there will be, but,
Barnabas:Ideally, we would have at least two.
Ansgar Dietrichs:Do we have any other EL clients actively working towards… like…
Ansgar Dietrichs:short-term… sorry, EP-based DevNet Zero readiness, and if so, how close are we there?
Barnabas:I'm not aware of anyone working on it. I think all the teams are very busy.
Barnabas:So, it's, like, not urgent, but if anyone has a bit of downtime, then,
Barnabas:Let me know, and I can point you to the…
Barnabas:Yeah, it's fairly easy to do.
Barnabas:I was going to use it.
Ansgar Dietrichs:Sounds good. So, open invite if anyone is bored from all the state questions and thinks this is trivial and wants a challenge. Sounds like a very small challenge, but, from the outside, but yeah, do reach out to Barnabas, maybe see if you… if you can join the DevNet, that sounds fun.
Ansgar Dietrichs:Okay.
Ansgar Dietrichs:Perfect, thank you, Barnabas. Then, next up, we do have the Hagota headliner selection. Just as a quick reminder, we kind of,
Ansgar Dietrichs:Already had a discussion, last call. The plan is to make a decision today. We basically have the different options that we had, where
Ansgar Dietrichs:The frontrunner, candidates, so to say, were either to do the frame transaction headliner proposal, or possibly some clients would have the preference of maybe
Ansgar Dietrichs:just not having an Yale-specific headliner, just, focus on FOCIL as the kind of cross-layer headliner for that fork, and then have smaller features, or just lower priority features, otherwise.
Ansgar Dietrichs:On the EL side, but there were also still the, candidates of, Lucid, the encrypted mempool proposal,
Ansgar Dietrichs:and, the SSE, pure ETH, proposal.
Ansgar Dietrichs:Yeah, I would maybe want to start, because it seemed to me, like, last time we were basically saying that both of those, MSSE and also Lucid only had outside chances, and…
Ansgar Dietrichs:I just wanted to check in on this first. My understanding was, for example, from the encrypted mempool side, that many people in general are very open to this, but, were feeling that this is one hard fog too early, and
Ansgar Dietrichs:that we should probably just revisit this for I-Star, and I think I heard from some of the champions as well that they are, kind of starting to at least be very open to this, lean in that direction. I don't know, Andas, are you on the call, for example? I think I heard you mention something in that regard.
Anders Elowsson:Yeah, I can just say that, yeah, I mean, if there's no general support for it, we are, of course, open for…
Anders Elowsson:sort of, recognizing that we can sort of try… try for iStore if there's, if people think that we should not do it for Hegota, so it's…
Anders Elowsson:Yeah, I would say, generally, we would still like to put it up there for discussion, but yeah, we are definitely open for thinking that maybe it's suitable for iStore.
Ansgar Dietrichs:Sounds good. Yeah, and of course, my feeling is that clients haven't really changed their take on this over the last two weeks, but…
Ansgar Dietrichs:Of course, if that… if that is…
Ansgar Dietrichs:different, then we can discuss it now. I was just thinking we should maybe, at the beginning of this discussion section, just make the decisions around SSE or Lucid as headliners, most likely just reject them as headliner candidates, so we have a simplified design space, and then we can just talk about frame transactions versus no headliner.
Ansgar Dietrichs:Yeah, do we have anyone here with opinions on either of those two headliners, SSE or,
Ansgar Dietrichs:Lucid,
Ansgar Dietrichs:would, yeah, maybe potentially want to argue against rejecting them now, or, of course, just confirm this decision. Ben?
Ben Adams:Just on SS… SSE, there's been, like, a recent movement to do a forum
Ben Adams:or some SSE, sort of, that's not… Walk-related.
Ben Adams:So I think that might change the topology on that as well.
Ben Adams:There doesn't need to be.
Ben Adams:Coordinated, necessarily, through consensus.
Ansgar Dietrichs:Yeah, Daniel?
Daniel Lehrner (Besu):Yeah, so, from Besto's side, we had Lucid as the favorite the last time.
Daniel Lehrner (Besu):But, now the team changed, actually, to no headliners figured, so…
Daniel Lehrner (Besu):From our side, it also would not be Lucid.
Ansgar Dietrichs:Makes sense. And yeah, just to confirm, I think people are overall quite positive about both of those, SSE and Lucid for the future of Ethereum. It's just, yeah, maybe…
Ansgar Dietrichs:not the right form as an Hegota headliner. That's at least the feeling that I got from conversations. So then, yeah, like, I would just… I mean, let's not do this as a batch decision, people do usually dislike this, so just let's do them one by one.
Ansgar Dietrichs:I would propose to just… reject SSE as headline-up proposal for Hegota?
Ansgar Dietrichs:And again, that does not mean that we are not considering doing this either out of protocol, in protocol, otherwise, but just not as… not selecting it as a headliner, basically.
Ansgar Dietrichs:Anyone who wants to speak up against that decision?
Ansgar Dietrichs:Okay, so then we will not do, the SSE as a headliner in Hegota. And then same proposal for, Lucid, basically saying, to officially reject it as a headliner candidate. Anyone who wants to speak up against that decision?
Ansgar Dietrichs:Okay, so then we also, yeah, brilliant.
Ansgar Dietrichs:reject Lucid as headliner for Hegota. And then that indeed leaves us with the decision. We can either accept frame transactions, or we can say we just do not have a separate headliner. I know that there has been quite a bit of discussion. Unfortunately, I was not able to join the breakout call last week.
Ansgar Dietrichs:Yes, do we… do we have anyone who could briefly summarize the discussion from the breakout? And otherwise, yeah, any clients with updated positions on… on this topic? Felix?
Felix (Geth):Yeah, I can definitely summarize. I have also four people to… if you are interested, I have posted a longer comment to the ACDPM issue that summarizes, basically.
Felix (Geth):everything that we have done on the EAP in the last couple weeks, just so… I mean, ever since it was proposed initially, we have made some updates to it, and we've done a lot of research to, like, see, you know, like, we've heard some criticism from various actors.
Felix (Geth):I've just been researching how this can be addressed, or, like, what is, like, the wanted feature set from this EAP, from the wider community. So, this is definitely an ongoing process, but some interesting changes have already happened. And, with regard to the breakout call, I'm very,
Felix (Geth):happy to say that this was also integrated into the forecast website, so I have actually also put the link to it in my comment. And, on the breakout call, mostly it was just
Felix (Geth):yeah, addressing people's questions. So there were just a lot of questions of what is the purpose of this EIP, why do account abstraction, what is the connection of account abstraction with post-quantum? We went a little bit, again, into these discussions of how can
Felix (Geth):post-quantum signatures be achieved within the block. It has some… there are some technical nuances that still have to be solved around this area.
Felix (Geth):And then, yeah, like I said, I mean, after the breakout call, it became clear that really what's necessary for us as the next step is just to engage way more with the wallet developer community, to… to just hear
Felix (Geth):what they really want out of this. Like, when native account abstraction comes to the mainnet, what do they want to see? And, I can just give a very high-level comment here that
Felix (Geth):In addition to… this being…
Felix (Geth):a change that would obviously affect the mainnet. What everyone is also seeing this as is, like, a chance to generally resolve some user experience issues across the wider network of Ethereum-compatible chains. So it is becoming kind of important that
Felix (Geth):once native account abstraction makes it in the mainnet, that it kind of makes it in the same way on the L2s, because this will enable people to use their account on all of these chains in the same way.
Felix (Geth):And, yeah, facing this wider landscape of having this
Felix (Geth):making this, like, work in the multi-chain context, we… yeah, like I said, we started making some changes and started considering all these upgrade paths and, like, stuff that people already have done in the past. For example.
Felix (Geth):we now have… are considering an upgrade path for the existing smart accounts, which are using EIC437, and which people are already using on some of these chains, things like that. Anyway, I highly recommend to read my comment to see all the updates, and, yeah, that's it.
Ansgar Dietrichs:Sounds good, thank you. Before we go into the open discussion, and I think, you know, I see Italik is also on the call, who's, I think, one of them.
Ansgar Dietrichs:well, co-creators of the EIP, but I just briefly wanted to make sure that we have the latest,
Ansgar Dietrichs:picture of where clients' positions are right now. So, for example, I think on the last call, there was a comment from Bisu that in…
Ansgar Dietrichs:in the absence of Lucid, they would actually prefer doing frame transactions over nothing, but now it sounded like maybe Besu is actually… would rather be in favor of,
Ansgar Dietrichs:No headliner? Is this… is this correct? Just to double check?
Daniel Lehrner (Besu):Yeah, yeah, yeah, that's correct.
Ansgar Dietrichs:Sounds… yeah, okay, makes sense. And then, I think otherwise, I had, Nethermind and Wrath on the side… written down as on the side of…
Ansgar Dietrichs:preferring no headliner over frame transactions, and Erigon and Geth on the side of… the other way around, preferring frame transactions over nothing? Is this still accurate?
Ansgar Dietrichs:Ben?
Ben Adams:Yeah, so, no headliner, but we wouldn't want to say…
Ben Adams:for end trans… no, to… for end transactions, we just don't want to put it on the headliner priority, where…
Ben Adams:We can't ship the fork if it's not ready.
Ben Adams:But we'd like it to come in as one of the regular EIPs. So we did… what we did in the previous work was we said.
Ben Adams:Or if it came in as the headliner and was rejected, it's obviously a big thing.
Ben Adams:So it shouldn't come in as a regular EIP. We don't think that's the case with frame transactions, and, so we'd like that to…
Ben Adams:Lucas can probably…
Łukasz Rozmej:Yeah, so if I can say something, we would potentially think about working on it, and prototyping it, and working on the spec, but we…
Łukasz Rozmej:We are not sure about it yet, so we don't want it as a headliner in that way, so potentially it's… we're not sure if we should commit to it, right? In this way.
Ansgar Dietrichs:Makes sense, Dragon?
Dragan Rakita:From red side, yeah, we have for the no headliners for Hegota.
Dragan Rakita:For… we don't support frame as such as it is to introduce additional abstraction layer that we don't need, and something like tempo intersection as the blueprint for the new intersection could be a lot better.
Dragan Rakita:It could give us a lot more benefits from… and smaller risk from anything.
Dragan Rakita:Frame.tx, in general, introduced a very big lift for TX pool and how DDoS protection is done and handled.
Dragan Rakita:It doesn't, explain how the things are going to be done, but it reduces additional abstraction that allows those things.
Dragan Rakita:So, directly permitting those end things that we need in some, like, specific or straightforward way, I think it's going to be a lot more beneficial.
Ansgar Dietrichs:Makes sense. And I think there's a comment by Matt, on the
Ansgar Dietrichs:Manpool side question, specifically. But, but yeah. Okay, sounds, sounds good. So then I think we have a picture. So right now we have, 3 clients more leaning towards no headliner, and 2 clients leaning to… or, supporting frame transactions, which would…
Ansgar Dietrichs:you know, given that I think that doing nothing is always the default, right now, tilt the decision more towards not doing frame transactions as a headliner, and then we could revisit it as an ERP still for the fork.
Ansgar Dietrichs:But I do think client opinions on these topics overall are still uncertain enough from what I felt, that it seems reasonable to have a discussion here and see if actually people
Ansgar Dietrichs:Still, in a position to change their mind on this.
Ansgar Dietrichs:So yeah, I think, we… this is the main, kind of, agenda point for today, so I think we have, basically the rest of the call, if we need it, if we want it, for this discussion. With that, do we have…
Ansgar Dietrichs:people, again.
mark:Can I just give you a little bit of extra feedback from an Erigon perspective?
Ansgar Dietrichs:Yes.
mark:Because I think we're… we're sort of…
mark:we were… we're more certain about, Lucid now than we were, I think, the last time we discussed this, basically because the proposal's firmer, so…
mark:I think what… what we want to do, probably from a development perspective, is work on… lucid and…
mark:frames.
mark:As a… as a kind of thing that we will coordinate together to get into the codebase.
mark:Now, I think that's probably because we're in a position where, because we worked on account abstraction before, we've already got, effectively, frame support in the codebase.
mark:And one of the things that…
mark:I think we want to get resolved is Lucid has this composite proposal.
mark:In it, as well, as frames.
mark:And… We don't think it makes sense to have, like, two composite transaction types.
mark:Effectively. So it seems like there needs to be some coordination there.
mark:But we basically want to work on both… we think it makes sense to work on both of those things in the, kind of, Hegatar timeframe.
Ansgar Dietrichs:Makes sense.
Ansgar Dietrichs:And it… at least it, yeah, it does seem like…
Ansgar Dietrichs:I don't… yeah, if we wanted to do Lucid…
Ansgar Dietrichs:I personally think it's unlikely we'll end up doing it as a non-headliner still for aged already, but, yeah, definitely one should think they're.
mark:Yeah, yeah, so I think we're kind of, sort of, less…
mark:we're more neutral on the headliner thing, right? Because…
mark:It seems like it makes sense from a development point of view, but it seems quite risky, and it's one of those things that if we try to do too much, we might end up not delivering anything.
mark:Essentially.
mark:So… While it makes sense to co-develop it, it doesn't necessarily make sense to us to co-deliver it.
mark:If that makes sense.
Ansgar Dietrichs:Yeah, that makes sense. And then that would still, at least in principle, be an argument that could still favor having, frame transactions as a headline and H star, and then already, like, in the development process for it, make sure that it is forward compatible with
Ansgar Dietrichs:Lucid or a Lucid variant that we would then bring in ice down.
mark:Yeah, because what we don't want to do, yeah, is do frame transactions, and then revisit them for the exact next fork, because we're putting Lucid in.
Ansgar Dietrichs:Yeah, that makes sense. But yeah, again, I agree, I think what you're saying, basically, it's not about shipping them together, it's not about shipping Lucid in H.S. still, it's just saying, like, if we were to select frame transactions to go first, we should make sure that it's already co-developed so that we can make sure that it's seamlessly forward compatible with the later Lucid change.
mark:Yeah, yeah, that's a good summary.
Ansgar Dietrichs:Sounds good. Yeah, then, in general, thoughts, kind of, I do know that there's a few people on here that have… that are actually very strongly in favor of frame transactions. I think now would be a good opportunity to speak up, to make the case, see if we can…
Ansgar Dietrichs:Still convince the skeptical clients.
Ansgar Dietrichs:Anyone who wants to.
Ansgar Dietrichs:Sweet.
lightclient:Kinda seems that the main concern is that frame transactions are gonna delay the next fork. That's what I'm understanding, at least from NetherMind.
lightclient:But I'm wondering if it changes people's opinions, knowing that we can
lightclient:Choose how complicated to make the transaction pool.
lightclient:That's one thing.
lightclient:The other thing is that…
lightclient:you know, we still have quite a long time before this fork is going to go live. We're already talking about
lightclient:maybe large changes to Glamsterdam?
lightclient:So we're looking at, like, you know, at least one year out before this feature would even go live.
lightclient:Yeah, Ben.
Ben Adams:I… I would… I would go further than just saying the latest work in that we're… we've…
Ben Adams:Positive towards friend transactions, but we're not 100% convinced, so… we've…
Ben Adams:Prefer the optionality to say, okay.
Ben Adams:Maybe this… this doesn't work at some point in the future.
Ben Adams:Whereas putting it as headliner would suggest
Ben Adams:That is the fork, if you know what I mean. It's not.
lightclient:I mean, yeah.
lightclient:If we say it's headliner, but we reserve the right to remove it later, if we realize it's not gonna work, is that…
lightclient:You know, sufficient to…
lightclient:accepted as a headliner. Like, we don't have to tie our hands behind our back with
lightclient:processes and rules if it's gonna lead to, like, worse outcomes for Ethereum.
Ben Adams:Yeah, but it would be weird messaging to put something as a headliner and then… Think about it later.
lightclient:I mean, what you're proposing is also not possible with the process either. Like, if we don't accept it as a headliner, now, because it's been proposed as a headliner, then we couldn't accept it as a non-headliner until I-Star.
lightclient:I don't know if this is what you're proposing, or if you're proposing that we consider it as a non-headliner an Hegota.
Ben Adams:As a non-headliner in Hegota.
lightclient:Right, so I would just say, like, if we're going to, like, change the process, we might as well just accept it as a headliner now, with the assumption that we could decide later that we are not going to be able to deliver this, or that there's not enough agreement on what the shape of the thing needs to be.
lightclient:Because if we say it's not a headliner, now we have to wait several more weeks for the non-headliners to come around.
Lumi | Offchain Labs:That's kind of the definition of a headliner, is we delay our upgrade, so why would we call it a headliner if we won't delay the upgrade?
Lumi | Offchain Labs:Might as well just not have it as a headline.
Felix (Geth):I'm gonna speak up now, so I think the,
Felix (Geth):this has been feedback that I also got from talking to client developers individually, that
Felix (Geth):it just somehow seems like for this… I think the concept of the headliner was introduced
Felix (Geth):So that clients could all commit to a singular goal, which has to be achieved by the fork.
Felix (Geth):And if this… this basically kind of defines it as being this thing that the fork will be delayed over, and that will not be pulled from the fork. So it seems that
Felix (Geth):we cannot currently gather this kind of support for EIP8141. If everyone was agreeing on it, or the absolute majority of the clients would be agreeing on it right now, that this is the single most important thing we have to achieve within the Hegota fork, then we wouldn't have such trouble deciding on it.
Felix (Geth):So, this is kind of where this hesitation is coming from, to say, yeah, maybe we should downgrade it to a non-headliner and whatever. I personally am not super attached to the exact process here.
Felix (Geth):for me, personally, I feel like it's a good moment in time to introduce native account abstraction. It has been sitting there on the side for a good number of years.
Felix (Geth):With people exploring different ideas to bring it there, and we feel that with EIP8141, we have
Felix (Geth):it's probably our best shot at it yet, especially regarding the mempool compatibility. Like, if you look at the previous account abstraction proposals, the mempool was always the issue, so this time, we are really making sure that
Felix (Geth):at least
Felix (Geth):some of the native account abstraction flows can be handled by the public mempool, whereas with previous proposals, it was always clear from the start that, yeah, even if we have native account abstraction, there will just not be a mempool as we know it for these transactions. So I feel like it is…
Felix (Geth):Better than what was proposed before for this particular topic.
Felix (Geth):And so, yeah, I've… I mean, given that there is no other good candidate for the headliner on the EL, that is, like, another reason for me to say, yeah, I mean, this…
Felix (Geth):It's like, we might as well do this one.
Felix (Geth):I mean, it is a bit larger change than tweaking gas prices or trying to…
Felix (Geth):I don't know, add some convenience features to the protocol. Like, it is a pretty fundamental change to the protocol in many ways, and so that's… for me, this is more important as the headliner. It just has, like, it gives a big upgrade to the chain in some ways.
vitalik:One, one thing I, wanted to also, highlight again is, that, there's a lot of, synergies between FOCIL and native account abstraction, and, like, those two EIPs are actually, quite, quite naturally complementary, basically, because, what, what FOCIL, does is.
vitalik:It creates very strong, rapid inclusion guarantees.
vitalik:For transactions, and native account abstraction greatly increases the set of things
vitalik:That, can be directly done as, as transactions. And so, if you have, those two things together, then it basically means that, very large sets of applications and, including transactions from smart contract wallets, and potentially including
vitalik:Things that, transactions that pay fees and other assets, also including privacy protocols, will… Bie,
vitalik:will be able to be inter, intermediary-free across the full stack, meaning they'll be able to no longer need intermediary choke points, both at the, layer of getting included into a transaction, and at the layer of needing to go through a block builder if block builders become…
vitalik:much more dominant, and so I think,
vitalik:And this is, also a case, for, base, treating the two, almost as a very interrelated unit to some degree.
Ansgar Dietrichs:Makes sense.
Ansgar Dietrichs:Dragon, if you want to?
Dragan Rakita:I would say that there is uncertainty or unclarity about exactly is the frame, the accent…
Dragan Rakita:listening from the Nethermine, Erigon, and basically all the clients.
Dragan Rakita:They need more time to evaluate what is needed, because they are uncertainty, this is the solution that we want to include or not.
Dragan Rakita:I think that should be a good enough reason to not include it as the headliner.
Dragan Rakita:for the…
Dragan Rakita:Frame.tx, in general, basically our stance is it's too complex, and those things, basically protocols that you want to include to enable all the things that you want to, it should be natively supported.
Dragan Rakita:Because if it's natively supported without that SEQTVM obstruction that FrameTX now has.
Dragan Rakita:It becomes a lot easier to use, it becomes more straightforward, it becomes a lot, yeah, better.
Dragan Rakita:So… Yeah, I think that's my stance here.
Ansgar Dietrichs:And Nico, you're unmuted? Did you want to say something?
Nico Consigny:Yeah, sorry, I couldn't raise my hand. One thing that I wanted to add is, on the timeline, timeline question, even if we headline or not, even if we ship,
Nico Consigny:frame transaction in Hegota. It's gonna be a tight timing for DAOs to upgrade their contract to post-quantum-resistant transaction. So, we are looking at
Nico Consigny:in the best scenario, one year to ship, the EIP. Then on top of that, you need to account for a very messy,
Nico Consigny:DAO voting decision, which will take a few months.
Nico Consigny:You need to add to that some audits for the… For the verification schemes.
Nico Consigny:So this brings us to 2028 and 2029, or even…
Nico Consigny:a bit later with, potential delays. So yeah, I just wanted to remind that, in this context, it's… it's a bit…
Nico Consigny:Gamblish to go for something that is not, post-quantum.
Nico Consigny:And, even… even if we take the French transaction and we manage to do everything, it's gonna be a…
Nico Consigny:a race, to, like, ship this, in a, in a safe time frame, so by 2029. So yeah, I just wanted to, to highlight the urgency here.
Nico Consigny:Because, yeah.
Nico Consigny:we have to account for DAOs, and we have to account for wallets, so yeah, it's… it's gonna take some time to do all this.
Nico Consigny:Sweet.
Nico Consigny:Yeah, I just… yeah, one comment I see in the chat, it's, it doesn't solve post-quantum directly, but it's… it does enable native, solidity verifiers.
Nico Consigny:to be the main account. So yes, in a sense, even if it's expensive, it does solve, post-quantum, yeah.
Ansgar Dietrichs:Any, mug you want to say something?
mark:I was just gonna… is that an argument for or against making it a headline?
Nico Consigny:It's foreign, it's, for,
Nico Consigny:Yeah, it's for making it evident by committing to it.
mark:Yeah.
Nico Consigny:Basically, if we eat it, it's gonna be very complicated.
Nico Consigny:And we will be gambling with the PQ timelines, which we really don't want to be doing.
mark:Yeah, I think if we need to reach consensus, we also maybe need to…
mark:Because it seems like, from a RET perspective, your concern is, is this the right AA proposal?
mark:I mean, I think the other thing that we need to think about is what happened with 7702, which… it's kind of… it was a less-than-perfect solution on the basis of, let's get it in.
mark:And let's get adoption. And actually, if you look at the history of that, adoption has still been quite slow, although it was put into the protocol.
mark:quite a long time ago. So that kind of, I think, speaks to what you're saying. It's saying we need to make the change sooner, because the adoption process after that is going to be pretty slow anyway.
mark:And if we don't… if we delay it by another year, it's another year of delay, fundamentally.
Nico Consigny:Yeah, exactly. And just, we also need to take into account that it's just not only wallets, it's also DAOs. Like, if you were a quantum attacker, what you would attack right now is the governance contract from Aave, and you would…
Nico Consigny:You would, you know, redeploy the…
Nico Consigny:the… you would update the Aave contract and run everything. You would not target, like, random wallets. So the main, targets are, big governance contracts and stuff, and they take a lot of time to move. So, yeah.
Nico Consigny:We need to account for that, too.
Ansgar Dietrichs:Thank you, derek, you fanned up?
Derek Chiang | ZeroDev:Yeah, I think I just wanted to say that I think, you know, since a lot of people are comparing 702 with frames, I just want to say that I think it's slightly misleading to,
Derek Chiang | ZeroDev:use the fact that maybe 7702 has lower adoption than some might have hoped, you know, even though, like Matt said in the comments, it still has decent adoption. But I think it's slightly misleading to use that as sort of, like, proof that, like, maybe A141 will have
Derek Chiang | ZeroDev:similarly low adoption, because the thing about 702 is that it's not actually native AA in any real sense, right? Like, 702 is simply a mechanism
Derek Chiang | ZeroDev:to allow EOAs to upgrade to smart contracts. To, you know, to upgrade to smart accounts. But it doesn't actually, like, allow the, smart accounts to originate transactions, for example, which is a core goal of NativeAA. It doesn't give the,
Derek Chiang | ZeroDev:the, you know, the accounts the ability to have their guests natively sponsored, for example, right? You know, so if you look at how the wallets have actually used 7712, for example, MetaMask, right, you know, they're using 7712, but…
Derek Chiang | ZeroDev:they cannot actually give their users the ability to have their guests sponsored without relying on application-level relayers, such as ERC437 bundlers, right? You know, whereas firm transactions is actually a full-fledged AA proposal.
Derek Chiang | ZeroDev:that natively introduces the capability of, you know, things like guest sponsorship, transaction batching. So I think, like, you know, firm transactions.
mark:Yeah, so…
Derek Chiang | ZeroDev:With the latest updates.
mark:Yeah, I was actually… I was actually making the opposite point.
mark:Basically, I think we should do frame transactions and not do another, let's do something simpler.
Derek Chiang | ZeroDev:Oh, awesome. Amazing. Yeah, I think, yeah, I think some people in the comments seem to be suggesting otherwise, you know, but yes, thanks for clarifying.
mark:Yeah, I'm just saying, because I originally bought it up, but my reason for bringing it up was to use it as an example of, there's where we did something which wasn't the full solution. Now, actually, I think it's quite good, because I think the frame solution is a lot better than the original AA one, because it's had time to
mark:It's had time to get developed, but it feels to me like this is the time that we should do it.
mark:Basically.
mark:And not… and not have another conversation and come up with a kind of compromise.
Ansgar Dietrichs:Right.
Ansgar Dietrichs:Yeah. I mean, I would… I think… I… yeah, I personally…
Ansgar Dietrichs:you know, like frame transactions, I'm not sure how I feel about the headliner situation, but luckily, this is not my decision to make. I will just say, in terms of purely process, I, you know, right now, seemingly, I only see two clients that would prefer this headliner.
Ansgar Dietrichs:With Geth and Erigon, I think if there was a third client, so if any of, say,
Ansgar Dietrichs:Neithermind, Beisu, or Reth would change their minds. I think we… we would be in a place where we could at least reasonably consider whether we would still want to go ahead with Headliner status. I think as long as it's only two clients, I think the default decision here will be…
Ansgar Dietrichs:To, or would be, would be, of course, there's still time, but would be to reject it as headliner and then reconsider it as a non-headliner,
Ansgar Dietrichs:Yeah, so I'm just wondering, out of the three clients that are currently against it, it seems like Ref is pretty locked in on being skeptical, I think also with some background there with the tempo developments.
Ansgar Dietrichs:Yeah, I was wondering, basically, like, maybe specifically a question towards Nethermind and Besu. Do you two… do the two clients think that they are pretty much locked in on the decision of preferring no headliner for today, or are either of you two still kind of, like, considering, open to arguments? Yeah, what's the situation there?
Ansgar Dietrichs:Daniel?
Daniel Lehrner (Besu):Yeah, from… so from Best's side, we had, like, a ranking, and no headliner was basically the first one.
Daniel Lehrner (Besu):And frame transaction and Lucid was a close second, but still, if the majority of the other clients is no headliner.
Daniel Lehrner (Besu):Then our decision, still stays like this, so…
Daniel Lehrner (Besu):There is for us. I don't think there's a reason to change that.
Ansgar Dietrichs:And from the nethermine side…
Łukasz Rozmej:I don't know, I don't… my personal standard didn't change, I don't know if other people.
Ansgar Dietrichs:Right.
Ansgar Dietrichs:Yeah, I personally… Don't… yeah, sorry, Matt, you seem to be unmuted?
lightclient:I was just gonna say, I feel like we're still focusing on…
lightclient:the ability to deliver the change, but I don't really understand why
lightclient:We're not accounting for the fact that we can…
lightclient:tune how much we're going to deliver with the frame transaction substantially. Like, this isn't like most changes where you have to implement every single thing.
lightclient:in the EIP to put on the mainnet, because the consensus changes for the framed transactions are really relatively small.
lightclient:Like, Etherrex said they implemented it in just a couple days.
lightclient:the transaction pool is where things get more complicated. Like, if we're going to submit, you know, if we're going to support the, you know, paymaster sponsoring.
lightclient:Then this is going to be a much larger change than if we added frame transactions to the consensus object.
lightclient:Which would allow them to, use frame transactions, begin the adoption of frame transactions, and then let clients, after the fork, continue working on the transaction pool changes without being blocked on a fork.
Łukasz Rozmej:So, to some extent, I… well, I actually quite agree, but I read the situation differently. I read it like, okay, we specified the easier part, and the harder part is left unspecified, but please commit to it, right? So, that's how I read the room.
lightclient:I mean, have you… have you read the ERC about how the transaction pool will work?
Łukasz Rozmej:Boom.
Łukasz Rozmej:there is a special specified ERC, not the EIP.
lightclient:Well, I mean, it's…
Felix (Geth):And we can explain this. So, the thing is that the EIP8141 was developed from EIP7001.
Felix (Geth):And this EIP was itself developed from ERC43C7, so all of these proposals are coming, basically, from the same family of proposals related to account abstraction.
Felix (Geth):And, as part of the ERC4337, the Ethereum Foundation account abstraction team has developed a set of rules for their mempool, which
Felix (Geth):Can be applied.
Felix (Geth):to analyze if a, basically any account, any contract interaction is somehow safe for the mempool. I have to, preface this, though, to say that the mempool that was implemented for ERC4337
Felix (Geth):is quite resource intensive, so I would not like to use it as the best possible example of it, but let me still go into detail a bit more to explain how this works. So.
Felix (Geth):basically, For the account abstraction.
Felix (Geth):to be viable in the mempool, there are two strategies. One of them is basically acknowledging that
Felix (Geth):the full generality that account extraction allows basically requires a very complicated mempool, and this is what this ERC represents. It basically gives you a full set of rules where if you implement that, you can judge any transaction to see if it… once it matches these rules, it is safe to include in the mempool.
Felix (Geth):But you do also have to trace the execution steps of the transaction to validate these rules. So basically, these are rules like, if this opcode is followed by this opcode with this parameter, then the transaction is invalid, basically.
Felix (Geth):So, it is good to have this rule set, and I think it's quite an achievement that they got very far with it, because it allows to build a general mempool for all account abstraction transactions.
Felix (Geth):At the same time, this is not the mempool that we would want to see included in, like, the full nodes, and I don't think it's very likely that this will ever happen. What we will be doing instead is, basically, with the frame transaction, the idea is that we, we…
Felix (Geth):develop the frame transaction specifically so that the protocol implementation has an insight into what the user is trying to achieve with their transaction by inspecting the frame structure. And also.
Felix (Geth):In some ways, it… basically, it allows to implement more strict mempool policies that only allow a subset of transactions to be accepted into the public mempool as we know it today.
Felix (Geth):And in practice, this is how I think the mempool will work with EIP8141. For the node implementations, we will come up with a guidance document that explains, like, a minimal set of rules that allow some useful subset of transactions to be submitted to the public mempool.
Felix (Geth):But then, there will also be third-party mempools which implement different rules or more complicated rules. And anyway, the goal of EIP8141 is
Felix (Geth):Primarily just to allow these, like, arbitrary transactions with any kind of, like, approval interaction to be included in a block.
Felix (Geth):Because this means that, ultimately, it is up to the block-building community to figure out, like, how, like, all of these flows can be optimally supported. And, for example, in the L2,
Felix (Geth):world, where most L2s use a sequencer. They actually have the capability to introspect transactions in a better way, so they can have different policies than, for example, a public Ethereum mainnet full node can have.
Felix (Geth):And so this is the other reason why we do not specify all the rules directly in EIP8141, because there is just no one set of rules that works for everyone. It is, like, a nuanced thing.
Felix (Geth):Okay, sorry, it was kind of a long text, but I hope you guys…
Łukasz Rozmej:Yeah, yeah, I understand it. So,
Łukasz Rozmej:My question is, should we… should we, make it a headliner, which we want, without polishing those rules for, public Ethereum mainnet mempool?
Łukasz Rozmej:And… We won't…
Felix (Geth):DevNetly. I mean, we have created some examples already in the ERP that show you, for example, the frame structure
Felix (Geth):of certain transactions. For example, if you just want to transfer, like, if you just want to do a simple balance transfer, it is actually more involved with a frame transaction than it is with, for example, a simple 1559 transaction, because you will have.
Felix (Geth):So, we have created some frame structures there that can show you, okay.
Felix (Geth):approximately what this can look like. And also, obviously, it depends a lot on, for example, which signature verification scheme is in use, and how much. We have been stressing this point quite often, that there is also this ability to set the validation gas, because if you think about the mempool, how it works right now.
Felix (Geth):the mempool basically performs a signature validation on every transaction. In most clients, this is cached somehow, but basically, one time, when the transaction is received new, it has to verify the signature of this transaction to make sure that the sender is correctly identified.
Felix (Geth):And so, yeah, this doesn't really change, but, like, in the 8141,
Felix (Geth):Obviously, it says the sender address is directly a part of the transaction, but it's not proven, so in order to prove it, you have to spend some amount of gas to determine that. In the public mempool, we will assume that every node will have some amount of validation gas, which it is willing to expend to perform this check. And we think that the
Felix (Geth):this will become quite an important thing. We have not fully finished our experiments for this either, like, we are still working towards, like, figuring out what are gonna be these limits, what are gonna be these rules. Like, this is for us also a big part of the work that lies ahead in the coming year, and this is also why
Felix (Geth):Fundamentally, the guest team is working so much on these changes, because we feel like we have a good understanding of the public mempool.
Felix (Geth):And this is kind of why we took over this account abstraction thing, because we feel like, yeah, the mempool is kind of the primary challenge here.
Felix (Geth):And, yeah, I mean, we don't have all the answers right now, definitely. It's a bit unfortunate, but…
Felix (Geth):We have to propose the headliner a year before the
Felix (Geth):You know, fork, so we have to just… there will.
Łukasz Rozmej:Okay, exactly, I agree, so that's why we proposed to make it a non-headliner EIP and go this path, because of these uncertainties.
Łukasz Rozmej:That was exactly our point.
Felix (Geth):Okay, well, I mean, there's no… I can't really argue with that, I'm just… I mean, anyway, I'm pretty happy that you… you understand my points and, like, why we,
Felix (Geth):Chose to work on it.
Felix (Geth):Ben, you also have your hand up, or is it resolved?
Ben Adams:Yeah, I was just gonna say, so…
Ben Adams:Potentially, ultimately, you'd be in a situation where to accept
Ben Adams:transactions, you'd have to be invoking the EVM.
Ben Adams:On the… in the transaction pool.
Ben Adams:To decide whether it's a valid transaction.
Felix (Geth):Yeah, I mean, that's kind of a part of it, yeah. But then there's a question, like, what can the EVM do, and like, what do you allow the EVM to do in this environment? Like, it is definitely a new environment for the EVM. Like, the EVM has not run in the transaction pool before, so in this case, we are treating the EVM as more like, yeah, like an arbitrary function, basically.
mark:Yeah, I think it's fair to say you have to… you have to introspect the EVM instructions in the, in the…
mark:in the transaction.
mark:you don't need to necessarily… I think part of the crafting of the,
mark:of the rules was so that for certain of them, you don't need to execute, you can just inspect.
Felix (Geth):There are various ways to do it. There is, for example, also the possibility of allow listing certain contracts, because they are known to be safe. So, for example, if you know that a certain, like, a certain account contract has a specific semantics, you can just model these semantics in native code, and then apply this model in your transaction pool, then you don't have to run the EVM.
Felix (Geth):or there are various other ideas that can basically save you some of these more expensive evaluations. So it is kind of an open area, but we feel like, fundamentally, the goal of the frame transaction is to make it actually possible to do this, because we will, over time, I already foresee it, be adding more and more things
Felix (Geth):to this transaction to allow the protocol to kind of introspect ahead of time what is, like, the validation intent of this transaction. And we already kind of have it now with the verify frames, so it's pretty clear to the transaction pool, for example. This is the reason why verify frames exist in this proposal, so that the mempool can see, okay, the verification is in this exact call.
Felix (Geth):and this call has this much gas, so it can right away say, yeah, I mean, it's trying to use way too much gas for the verification, I'm not even going to start executing that, for example.
Felix (Geth):So, it's not like you have to run the EVM to the full extent for every single transaction, you only have to run it, like, when it seems like it's gonna have any chance at actually validating, for example.
Felix (Geth):Anyways, it's going really deep now, but I feel like these discussions are valuable, because this proposal seems to be heavily misunderstood sometimes.
lightclient:It might also be worth mentioning this… Oh yeah, I was gonna…
lightclient:say Frederick's point, but Frederick, you can say it.
Fredrik:Yeah, yeah, I just want to say that there is, this,
Fredrik:There's other aspect of it as well, which is revolving around end-user security, and one of the things that we are… that we've seen and heard a lot from end users is that
Fredrik:They are losing quite a bit of funds through various types of hacks, scams, and drainers, and other means, and…
Fredrik:One thing that can solve this is, or at least one part of solving this kind of problem that end users are facing, which in some ways is driving people away from using blockchain technology, because they… once they lose all their funds through a scam, they're not super happy to continue transacting.
Fredrik:So, one of the things that we can do is to implement something like transaction assertions, which will allow people to
Fredrik:Basically, or wallets to provide
Fredrik:certain assertions, that needs to be true for the transaction to go through and otherwise revert. So if a user believes that they will receive
Fredrik:token X, and the transaction is actually doing something else, then the transaction would revert, and they would not end up losing their funds. And this is something that framed transactions could solve pretty nicely from the looks of it, which is…
Fredrik:why I am personally pretty excited about it, and I think it will have
Fredrik:A very big positive impact on the user ecosystem.
lightclient:I feel like if we don't make frame transactions the headliner here, it's gonna be harder to build things like this on top of it, because we don't want to accept
lightclient:You know, multiple non-headliners that are dependent on each other.
lightclient:Then we create, like, a large risk profile for, you know, one of them not shipping, causing
lightclient:A cascading failure of the fork.
Ansgar Dietrichs:Okay, so we are 10 minutes before the end of the call. I do think I want to at least actually try to make a decision today, so just another check. How are people feeling?
Ansgar Dietrichs:I did see in chat that, say, on the Netherland team, maybe there's just…
Ansgar Dietrichs:Kind of… different opinions, but it did seem like the team overall was Still pointing more.
Ansgar Dietrichs:Towards no headliner.
Ansgar Dietrichs:Mmm…
Ansgar Dietrichs:yeah, it just… it seems hard. You know, I think… I mean, obviously, we could just not make a decision, but I don't see how… what would improve by two weeks from now that would make… allow us to then make a decision, and the cost of, of course, delaying these types of decisions is high, so I'm very hesitant to, like, to pay that cost, unless there's a specific reason why we would think that
Ansgar Dietrichs:That there will be significant resolution within those two weeks.
Ansgar Dietrichs:And otherwise, it just feels very hard to…
Ansgar Dietrichs:Except a headliner with such significant,
Ansgar Dietrichs:client skepticism, so I think that the clear default decision here would be to just not accept it as a headliner. I just don't really see…
Ansgar Dietrichs:M… Yeah, how… what else, again, like, just process-wise, I don't…
lightclient:are in favor of adding as a headliner, and then even Lucas is saying now he doesn't know for certain and doesn't want to block it.
lightclient:Like, there is risk in changing Ethereum, there always is, but, like, part of…
lightclient:Having the governance decisions now, early, means that we can
lightclient:Try to minimize that risk a lot by iterating on this, rather than continuing to spend time figuring out what we're gonna even do with the fork.
Ansgar Dietrichs:Okay, but, I mean, so right now, I don't think, unless, again, over the next 5 minutes.
Ansgar Dietrichs:there's still more change. I don't think we're in a position to accept frame transactions as headliners, just because right now there's two clients in favor, and then a little bit of openness, but uncertainty from some of the other clients. That's not enough of a basis. I do think we could say we wait two more weeks if people think, like Barnabas was proposing it in chat, for example.
Ansgar Dietrichs:we, yeah, because it is really on the edge, I'm open to that. I would want to get the feeling that at least the majority of clients would prefer delaying that decision. Then I think we can do that.
Ansgar Dietrichs:Yeah. But then again, like, I think the understanding for next… for two weeks from now would be that, yeah, the default would be to not accept it as a headliner, so things would have to tilt more in the direction of headliner support, for it to make a difference. Ben?
Ben Adams:I'd just like to… pull out what Pelix said in… in chat. I think that's interesting.
Ben Adams:Maybe promoting it to Headliner later?
Ansgar Dietrichs:Well, we don't really have a process for that. I am…
Ansgar Dietrichs:But personally, I'm always leaning on the side of, like, some flexibility with processes. This seems like it would be bending the process.
Ansgar Dietrichs:quite a bit, which I don't… I definitely don't feel like…
Ansgar Dietrichs:prepared to say that that's going to be possible today. I mean, obviously, we could see, we could, you know, discuss this, and see, maybe over the next two weeks, decide whether that's something we would be willing to do.
Ben Adams:But yeah, I feel like…
Ansgar Dietrichs:I feel like it's a bit tricky to just impromptu make such big changes to processes.
Ben Adams:Well, I mean, it's… it's the no headliner gambling.
Ansgar Dietrichs:What's that?
Ben Adams:Well, then, if we don't have a headliner, then…
Ben Adams:It may not be a situation covered by process.
Ansgar Dietrichs:Sure, yeah, Avat?
Ahmad Bitar | Nethermind:Yep, can you hear me?
Ansgar Dietrichs:Yes.
Ahmad Bitar | Nethermind:Yeah, so I wanted to just… Like, surface that…
Ahmad Bitar | Nethermind:The Netherland team is split among this, some think that it shouldn't be a headliner, but
Ahmad Bitar | Nethermind:Some of us think that
Ahmad Bitar | Nethermind:we like it as a headliner, just to, be clear about that. I also noticed or heard similar, feedback from Bezo, but I might be wrong.
Ahmad Bitar | Nethermind:And we both… we know that death and wrath
Ahmad Bitar | Nethermind:are… no, no, sorry, Geth and, A3X are supporting, so…
Ahmad Bitar | Nethermind:doesn't it seem like most consensus is saying they support it as a headliner, or am I understanding this incorrectly?
mark:I think you guys would need to have to get off the fence.
mark:I think is what the situation is. I mean, I guess the question is, what would it take to persuade you that it's a good idea?
mark:Maybe that's the question that we should ask.
mark:That's the only way that'll take the process forward.
mark:Because presumably there's some, some…
mark:definable reason why it shouldn't be for people who are saying no. Maybe we need to understand what those issues are and address them.
Łukasz Rozmej:So for me, definitely, you know, some kind of rules on…
Łukasz Rozmej:That are acceptable by everyone, like the consensus on the rules around the transaction pool that is, on the one hand, not dossable and works in a reasonable way, on the other hand, has
Łukasz Rozmej:reasonable, usability, which I'm not, you know… I'm… I have… I'm not sure if it's easy to achieve.
Łukasz Rozmej:Both.
mark:So does that just require… because the EFAA guys have spent quite a lot of time on that. Have you… have you looked at what they've proposed?
Łukasz Rozmej:Oh, well, not completely, and,
Łukasz Rozmej:Felix says they already kind of have a bit different idea for the frame transactions.
Felix (Geth):Yeah, I just wanted to quickly highlight again that, like, there is two different things here. So, we're talking about this rule set, which is also cited within EIP8141, and this rule set is giving this
Felix (Geth):basically, we are citing this rule set because we feel like it is a very comprehensive way of analyzing the behavior of the frame transaction. I don't think we are going to apply all of this rule set in every client, it's just not possible. We have to come up with, like, a simpler ruleset
Felix (Geth):And…
Felix (Geth):this is still being worked on right now. I mean, one of the key things is that we do not actually have, like, the account implementations, like, fully worked out. That's a whole other thing, because the account implementations are technically something that can
Felix (Geth):is arbitrary in this proposal, right? At the same time, maybe one thing I can also highlight is that recently there was this default account added into the EIP, and the default account definitely is kind of a bigger change, so it means that, like,
Felix (Geth):all of the existing EOAs get some features added, like gas sponsoring and native batching and things like that, possibly even the ability to do different types of signatures. Like, there's a lot of things in the EIP now that were added all at once with this default account. This is also still something being worked on, but then the thing is that, like.
Felix (Geth):Once this is in, then it's, like, the question, like, these, like, public mempool rules definitely should permit using the default account.
Felix (Geth):And then there'd be, like.
Felix (Geth):The thing is that we are proposing this EIP now with some ideas, and we have pretty good ideas about, like, the space of it, but the absolute details, like, there is still some things that are being worked on. We're not presenting a fully finished design that has, like, every little corner worked out.
Felix (Geth):that's just not how the process works. We have to provide the EAP early on.
Felix (Geth):So that it can be worked on during the fork cycle. We cannot just, like, finish everything and then present it.
Felix (Geth):that's… that's… it doesn't work like that with other EAPs either, like, the… no… most EAPs get proposed, and then do… when… once it comes to…
Felix (Geth):Time to actually implement it, then all the changes come.
Felix (Geth):So that's also how I see it with this one. I mean, we have a pretty good idea how this can all work, but…
Felix (Geth):It still requires the work.
Ansgar Dietrichs:Okay, so, with 2 minutes left, then it does sound like, while I'm usually always… like, I don't like delaying decisions, I'm sometimes guilty of it, but it feels like, in chat also, it seemed like there wasn't really anyone pushing for a decision today, and several people
Ansgar Dietrichs:Suggesting that we should decide, we should wait for two more weeks, just given that it seems to be so on edge.
Ansgar Dietrichs:M…
Ansgar Dietrichs:Yeah, so then, I do think the right decision here is to say we make the final decision on whether to have frame transactions as headliner or not.
Ansgar Dietrichs:Two weeks from now. By that time, we then also will have some more information on, we can see if there's anything else process-wise that would be an option or anything.
Ansgar Dietrichs:M…
Ansgar Dietrichs:default outcome, again, I think, would be to not select it as a headliner, so, you know, just… people should have that as a mindset, but… but I… yeah, I think we are not far away from enough client support to change that.
Ansgar Dietrichs:Yeah, so… and then, I think it's on the frame transaction champions to maybe set up some, some sort of…
Ansgar Dietrichs:You know, one more breakout call or something like this between now and then to finish.
mark:Yeah, which it seems like needs to focus on the usability in the mempool, or the ability to build something in the mempool, at least a minimum.
mark:That's actually practical. Because that seems to be where the… where the questions are.
mark:So maybe that's what the breakout should address.
Ansgar Dietrichs:It seems reasonable for the sterleys to be a big focus.
Ansgar Dietrichs:Mmm…
Ansgar Dietrichs:And yeah, Matt also asked in chat, and then I think, let me put it this way, I think ideally anyone who has some specific questions or concerns or thought that they would want addressed.
Ansgar Dietrichs:do reach out to the champions. Also, ideally, we have an agenda item.
Ansgar Dietrichs:issue open where people can comment questions, topics they want to have addressed in advance. Let's try to make the most out of this so we can make an informed decision, because I feel like we should not end up having this be a coin flip. I think, ideally, by two weeks from now, we have a clear
Ansgar Dietrichs:clear decision where everyone is behind, and we can actually… I think that's best for Ethereum. Usually, coin flips are not great. So let's try to get there in two weeks. And then one last comment there, I think also,
Ansgar Dietrichs:In terms of non-headliners, there's the question already, at the moment we log in the headliner decisions, we can open up the proposing window for non-headliner EIPs, and then we will communicate, kind of, specific deadlines there around by when do non-headliners have to be proposed.
Ansgar Dietrichs:Yeah, at a later point, either 2 weeks from now or 4 weeks from now, we'll communicate, the specific deadlines there. So, look out for this, but basically, you can, you can prepare, like, you can prepare to drop your non-headliner proposals, starting, starting next call, basically.
Ansgar Dietrichs:Okay,
Ansgar Dietrichs:With that, we're also running up on time, we had a few more agenda items on the agenda, but I think I'll just bump them to…
Ansgar Dietrichs:Two weeks from now.
Ansgar Dietrichs:And… leave it at that.
Ansgar Dietrichs:Awesome. Thank you, everyone.
Ansgar Dietrichs:And talk to you all in two weeks.
lightclient:Thanks.
Marius van der Wijden:Thank you, bye.
Chat Logs
00:06:14
FLCL:Depends on how prefetch is implemented probably
00:06:40
Toni Wahrstätter:Replying to "Depends on how prefe..."
yeah and what matters are worst-cases not average cases.
00:06:41
spencer:JICYMI, new EELS release for bal-devnet-3 with the latest 8037 tests: https://github.com/ethereum/execution-spec-tests/releases/tag/bal@v5.4.0
00:06:46
Łukasz Rozmej:8037 is ☠️
00:06:53
Karim T. (matkt):Replying to "Depends on how prefe..."
And state size also
00:06:55
Ansgar Dietrichs:my understanding is that the read locations part of BALs is only for allowing deterministic prefetch, right?
so we’d need to see it actually have (significant) benefits for the worst cases there to justify keeping it in the EIP?
00:07:29
FLCL:Any simple way to benchmark prefetch for an EL? Liek a pipeline or so?
00:07:53
Karim T. (matkt):Replying to "Depends on how prefe..."
If it is on top of devnet 2 state I think we will see less performance improvement than mainnet state
00:07:53
Dragan Rakita:Replying to "JICYMI, new EELS rel..."
I think there is a bug here. Have reported in discord
00:08:05
Stefan Starflinger:Replying to "my understanding is ..."
yeah
00:08:09
FLCL:Replying to "Depends on how prefe..."
We want to not wait prefetching state, but start execution in parallel and hope it will speed up
00:08:20
Łukasz Rozmej:Replying to "my understanding is ..."
probably it is not worth it
00:08:44
Stefan Starflinger:Replying to "Any simple way to be..."
what do you mean with pipline?
00:09:53
Karim T. (matkt):Replying to "Depends on how prefe..."
Yes the same in Besu we start without waiting for the prefetch
00:10:22
FLCL:So the testing happend for different optimizations right? But what if I have a new branch with more optimizations and want to test if it is more performant. Currently reruning some blocks from devnet locally, but it's very inconvinient
00:10:38
Ansgar Dietrichs:from my side regarding 8037 etc: moving to a more “principled” approach to gas accounting would be high up my priority list for H*, but I worry that trying to change things for G* will block process a lot. better to just try to just ship things now with minimal changes
00:10:57
Stefan Starflinger:Replying to "Any simple way to be..."
Felipe has been working on making it possible to run benchmarks with benchmarkoor
00:11:07
Stefan Starflinger:Replying to "Any simple way to be..."
do you have testing_buildBlockV1 implemented?
00:11:14
Ansgar Dietrichs:Replying to "from my side regardi..."
but obv I am missing the implementer perspective, maybe this is impractical
00:11:58
FLCL:And no huge gains?
00:12:48
Anders Elowsson:Replying to "from my side regardi..."
Yeah so EIP-7999 would here be the principled solution, but EIP-8037 is still to our benefit today.
00:12:49
Karim T. (matkt):Replying to "Depends on how prefe..."
As I said I think the devnet 2 has a really small state so not sure we will see huge difference. Compared to only // transactions imo
00:12:50
jochem-brouwer:Antwoord verzenden naar "Any simple way to ..."
We are setting up benchmarkoor to run (BAL) benchs against bloatnet (mainnet fork but then beefed up in state) which targets BAL branch in order to run it. So a re-run should then use the new image of that branch
00:13:09
Karim T. (matkt):Replying to "Depends on how prefe..."
But in mainnet or bloatnet I think we will see more better performance imo
00:13:41
DanielVF | Monad:Replying to "from my side regar..."
I don't think EIP-8037 has immediate benefits beyond what a simple repricing would do.
00:14:15
Dragan Rakita:Replying to "from my side regardi..."
EIP-8037 is really desirable for bigger blocks
00:14:20
Ben Adams:EIP-7999 as H* headliner?
00:14:45
Anders Elowsson:Replying to "EIP-7999 as H* headl..."
Hehe late headliner. It will be proposed as a regular EIP
00:15:00
Łukasz Rozmej:8037 is very very complicated
00:15:37
Łukasz Rozmej:and then we will complicate it even more in next forks
00:15:55
Luis Pinto | Besu:Me likes coherent approach
00:16:15
Ansgar Dietrichs:we won’t be able to completely rework gas (including say blob gas) by Glamsterdam
00:17:19
Marius van der Wijden:I don't think that 8037 is actually that complex. There is a few things about the refund logic
00:19:00
Dragan Rakita:EIP-8037 as a change is good, I would not change it at all imo.
00:19:25
Ben Adams:Replying to "I don't think that 8..."
Drop refunds? https://eips.ethereum.org/EIPS/eip-3298
00:19:38
Francesco:What is the alternative? We are not going to do 7999 in Glamsterdam. What is this simple solution?
00:19:47
Dragan Rakita:Replying to "I don't think that 8..."
H*
00:21:10
FLCL:Replying to "Any simple way to be..."
Just a draft of testing_buildBlockV1 for now looks like
00:21:24
CPerezz:Replying to "8037 is very very co..."
The alternative is doing nothing then wrt. Multidimensional & state-size/growth?
I mean, complexity only can’t be an argument. Complex and not useful sure, complex and underspecified sure.
But complex only isn’t an argument enough powerful.
Marius implemented it in 3 days passing 99% tests. Can’t be that impossibly complicated
00:21:39
Stefan Starflinger:Replying to "Any simple way to be..."
when merge?
00:21:56
Stefan Starflinger:Replying to "8037 is very very co..."
make no mistakes
00:22:24
Łukasz Rozmej:what did we just changed?
00:22:53
Daniel Lehrner (Besu):Replying to "what did we just cha..."
https://github.com/ethereum/execution-spec-tests/releases/tag/bal@v5.4.0
00:23:04
Marius van der Wijden:Replying to "8037 is very very co..."
None of it was done with ai, I had an ai version but it was very ugly
00:23:09
Ansgar Dietrichs:if we think it’s at least possible we make larger changes here still, how do ppl feel about bal-devnet-3? still go ahead with 8037 as-is, or delay?
00:23:20
FLCL:Replying to "Any simple way to be..."
🤷♂️ Will ping back when merged or can say more
00:23:22
Łukasz Rozmej:Replying to "8037 is very very co..."
Ethereum narrative: simplify protocol
Ethereum reality: spaghetti?
:(
00:24:07
spencer:Replying to "what did we just c..."
Only EELS spec & test changes in the above release: https://github.com/ethereum/execution-specs/pull/2468
00:24:55
felix (eest):https://github.com/ethsteel/pm/blob/main/complexity_assessments/EIPs/EIP-8037.md
old take but u can see how much pain it is for us
00:25:43
CPerezz:Replying to "8037 is very very co..."
Open for improvements. But saying it’s complex doesn’t help simplifying it. Nor gives any alternative solutions 🙁
00:25:59
Stefan Starflinger:I agree
00:26:15
Luis Pinto | Besu:Well I would argue the spaguetti is already there and right now gas cost does not only reflect client effort. Having a coherent solution just makes it leaner.
00:26:24
Maria Silva:I also agree with Spencer
00:26:34
Stefan Starflinger:We wanted to do this EIP early before the others exactly becuase it's not easy but worthwile
00:26:52
lightclient:how will 8037 and 8038 affect contracts on mainnet?
00:27:29
CPerezz:Replying to "how will 8037 and 80..."
I think Carl was running the analysis IIRC. He has all the data.
@Carl Beekhuizen
00:27:36
CPerezz:Replying to "how will 8037 and 80..."
(For 8037)
00:28:15
Maria Silva:Replying to "how will 8037 and 80..."
Butta collected some early feedback from the ecosystem: https://x.com/EFprotocol/status/2031056150427242892
00:28:35
Maria Silva:Replying to "how will 8037 and 80..."
Also, Carl is currently looking into 7904 and 2870
00:28:46
Maria Silva:Replying to "how will 8037 and 80..."
We will do the analysis on 8037 and 8038 next
00:29:05
lightclient:Replying to "how will 8037 and 80..."
im looking more for analysis to see what will break when the prices change, not people’s concern level
00:29:26
Maria Silva:Replying to "how will 8037 and 80..."
Got it. That analysis is what Carl as been working on
00:29:33
Maria Silva:Replying to "how will 8037 and 80..."
We will share when we have final results
00:30:38
Marius van der Wijden:Replying to "how will 8037 and 80..."
We will also give grants for security reviews to see what breaks once the eip is in a more final form (hopefully starting in ~2weeks)
00:32:00
Marius van der Wijden:Epbs devnet 0 can be implemented in 1 hour
00:32:13
Marius van der Wijden:Replying to "Epbs devnet 0 can be..."
*on EL!
00:32:37
Daniel Lehrner (Besu):Replying to "Epbs devnet 0 can be..."
Where can we see the spec changes needed for the devnet?
00:33:04
Barnabas:Replying to "Epbs devnet 0 can be..."
https://notes.ethereum.org/@ethpandaops/epbs-devnet-0
00:33:10
Barnabas:Replying to "Epbs devnet 0 can be..."
For this devnet we are going to use:
engine_forkchoiceUpdatedV3
engine_newPayloadV5
engine_getPayloadV5
00:33:34
Barnabas:Replying to "Epbs devnet 0 can be..."
we need to be able to trigger amsterdam without activating bal which is the important bit
00:37:07
Łukasz Rozmej:we are open for engine API SSZ as non-consensus change
00:37:35
Luis Pinto | Besu:Replying to "we are open for engi..."
Are you fine with adding content-type from HTTP headers into the Ethereum protocol?
00:37:55
Łukasz Rozmej:Replying to "we are open for engi..."
Although PR we got from Giulio needs to be compleatly reworked from ground up.
00:38:08
Luis Pinto | Besu:Replying to "we are open for engi..."
Or how would we do it in a non-consensus way?
00:38:24
Derek Chiang | ZeroDev:Felix posted a summary of the major updates to Frame Txns since the last discussion: https://github.com/ethereum/pm/issues/1955#issuecomment-4046894879
00:38:32
Marius van der Wijden:Replying to "we are open for engi..."
We should use this as a shelling point to rework the engine api imho
00:38:39
Łukasz Rozmej:Replying to "we are open for engi..."
Isn't it just a transport entry-point?
Not sure if we are talking same thing
00:38:39
Barnabas:Replying to "we are open for engi..."
https://github.com/ethereum/execution-apis/pull/764
00:38:43
Barnabas:Replying to "we are open for engi..."
do you mean this?
00:39:00
Ben Adams:Replying to "we are open for engi..."
Non-consenus as via discovery either engine capability and/or accept headers
00:39:44
Barnabas:Replying to "we are open for engi..."
negotiation could happen with json, but once negotiation is done, it would use ssz if CL and EL both support ssz, otherwise fall back to using json
00:40:02
Luis Pinto | Besu:Replying to "we are open for engi..."
>do you mean this?
yup
00:40:08
nixo:https://github.com/ethereum/pm/issues/1955#issuecomment-4046894879
00:40:33
FLCL:May be a separate rest endpint for metadata btw and don't touch capabilties (there rest of the spec is super cool)
00:40:37
Luis Pinto | Besu:I think I would prefer it through an exchange capabilities request instead of using HTTP headers
00:41:06
Ben Adams:Replying to "we are open for engi..."
capabilities exchange has benefit of allowing different urls rather than having to generically parse payload first
00:41:14
Barnabas:Replying to "we are open for engi..."
We can hash this out, this is just a detail question
00:41:46
Barnabas:Replying to "we are open for engi..."
the main question is whether people are willing to add ssz in their codebase. If the answer to that is a yes, then we should finalize the spec and lets get it merged
00:41:56
FLCL:Replying to "we are open for engi..."
http headers are necessary if you mean Accept/Content-Type
00:42:41
Derek Chiang | ZeroDev:What was the reason for the change for Besu?
00:43:46
lightclient:IMO the complexity of frame tx is in the txpool, and we have the ability turn the knob of how much the txpool allows based on time available.
so i guess i’m not sure what complexity you are worried about?
00:44:40
Daniel Lehrner (Besu):Replying to "What was the reason ..."
No headliner was not a realistic option when you did a team internal pool the last time. Now that it is, that was preferred.
Frame tx and LUCID where close 2nd options.
00:44:55
jvn:IMO When trying out a impl , abstracting mempool , maybe Frame Tx might not be as complicated as I thought
00:45:02
Barnabas:I think not handling frame tx as a headliner could lead to wasting huge amount of resources and not including afterall. Which is not an ideal outcome imo.
00:45:29
FLCL:Frames look a bit like a separate simplest language on top of contract. Might be one top frame with simplified rules.
00:47:29
Trent:Wasn’t LUCID just rejected 5min ago?
00:47:53
lightclient:I think we can keep LUCID in mind with respect to frame tx design
00:47:53
Luis Pinto | Besu:Replying to "Wasn’t LUCID just re..."
What he’s saying is that he wants to look at them both holistically
00:48:01
Marius van der Wijden:Replying to "Wasn’t LUCID just re..."
Erigon can still work on it if they choose to
00:48:06
Barnabas:I’d prefer to keep our focuses on a single/few EIPs instead of working on mutliple headliner sized EIPs
00:48:55
Łukasz Rozmej:Replying to "IMO the complexity o..."
that sounds a bit handwavy, I would like to have a proper mempool spec/consensus as it is a main unknown at the moment
00:49:17
lightclient:it seems like the main concern is that frame tx would delay the next fork? does it change people’s opinion knowing we could simply not allow frame tx in txpool and the implementation is very straightforward
00:49:40
Anders Elowsson:Replying to "it seems like the ma..."
But we would like to eventually right?
00:50:20
Ansgar Dietrichs:so say a scenario of shipping frame txs as headliner, but with very limited txpool support at first. would that be worth it?
00:50:30
Dragan Rakita:Reth take is that it is over abstracted and simpler solution would be better in general.
00:50:54
Parithosh Jayanthi:TBF we have taken out headliners before
00:51:06
Łukasz Rozmej:It is always harder to remove
00:51:14
CPerezz:Replying to "Reth take is that it..."
You refer to the PQ part? Or the entire thing?
00:51:21
Fredrik:It’s part of the process that we can take it out though, for example if we find security issues and such
00:51:45
Anders Elowsson:From a decision-theoretic perspective, we may have not gathered sufficient information to make a robust decision. The marginal cost of exploring non-headliner EIPs at this point is relatively low, meaning one option is to not take a decision but to start exploring non-headliners over the next month. So that we know what the competition is so to speak.
00:52:15
Danno Ferrin - Tectonic.xyz:It’s less damaging to the process to elevate a feature to headliner than to demote it.
00:52:23
soispoke:That rule of not being able to repropose as a non headliner is still puzzling to me
00:52:31
Marius van der Wijden:There are two competing definitions of headliner 😅
00:52:34
spencer:Footliner?
00:52:48
Iván | ethrex:In ethrex we’ve made an early implementation of EIP-8141. We got it working in 1-2 days. You can take a look at it and see if it looks complex for you https://github.com/lambdaclass/ethrex/pull/6326. There’s some docs listing some gaps and the decisions we took
00:53:05
Greg K | Lido:Replying to "it seems like the ..."
I think also people are not convinced of the effectivness of this EIP for the problem is supposed to solve
00:53:22
lightclient:Replying to "it seems like the ma..."
that’s not what i’m hearing?
00:53:36
lightclient:Replying to "it seems like the ma..."
seems like people are just worried about ability to ship in a timely manner
00:53:37
Iván | ethrex:There’s also a web demo for the e2e with some examples https://demo.eip-8141.ethrex.xyz
00:53:52
Barnabas:I’d like to take the input of not only core devs to make a decision whether we want frame txs or not.
00:53:58
Iván | ethrex:Replying to "In ethrex we’ve made..."
Using an ethrex dev node
00:54:20
Barnabas:Replying to "I’d like to take the..."
we always say that we should listen to the community more, so lets give the floor to them, and hear them out.
00:54:26
Iván | ethrex:Replying to "In ethrex we’ve made..."
The code still needs to be cleaned up a little bit, but it’s clear enough
00:54:28
lightclient:one important point to do native AA in H*, if we don’t then smart accounts won’t be able to take advantage of FOCIL
00:55:08
Luis Pinto | Besu:Replying to "I’d like to take the..."
TBF what I hear mostly about the community it’s to raise code size and nothing about frame txs
00:55:27
Barnabas:Replying to "I’d like to take the..."
thats already happening in glammy tho
00:55:53
Luis Pinto | Besu:Replying to "I’d like to take the..."
Not lifting the limit altogether, just pushing the bar a bit up
00:56:03
Łukasz Rozmej:I'm also afraid it will end up in YAGNI space and don't get hoped adoption, similar to 7702, due to complexity
00:56:46
Parthasarathy Ramanujam:Replying to "I’d like to take the..."
@Luis Pinto | Besu There is demand for native AA amongst all wallet developers. 8141 seems to be the most popular candidate now. Especially, a poll conducted by @lightclient among wallet and AA developers.
00:57:03
lightclient:Replying to "I'm also afraid it w..."
this is why we’re adding the default account, it solves these problems for wallets and users that are more skittish
00:57:22
FLCL:We can agree on frames as is not final design, pick at as headliner and improve it on the way. It a significant change that may need more time that usually
00:57:41
Parthasarathy Ramanujam:Replying to "I'm also afraid it w..."
The only way, you can increase adoption is by deprecating EOAs. That will get “lazy” users to migrate to smart accounts.
00:59:47
Łukasz Rozmej:Frame transaction doesn't solve post quantum, it gives a potential to solve it later
00:59:55
DanielVF | Monad:PQ doesn't require frame transactions though
00:59:58
Dragan Rakita:Replying to "I’d like to take the..."
From devtooling feedback that I shared last time, it is unnecessary complex and bad eip.
01:00:15
Danno Ferrin - Tectonic.xyz:We need a PQC algo as a precompile
01:00:23
lightclient:hoping we have a PQ precompile as a non-headliner in H* 🙂
01:00:53
FLCL:PQ is not solved at all for now and can be solved purely in parallel by people with very different competency
01:01:31
lightclient:guys 7702 has 4 million ops per week
01:01:38
Ansgar Dietrichs:7702 is very synergistic with native AA, because it allows EOAs to upgrade to smart accounts that can then use e.g. frame txs
01:01:43
CPerezz:Replying to "hoping we have a PQ ..."
Can’t cheaper compute and bigger gas limits get us there already without precompiles?
01:01:47
soispoke:One thing to maybe keep in mind is that we’re also deciding very early (compared to last time) so in theory it gives more time to iterate on EIPs after the decision point
01:01:59
Felix (Geth):Most definitely there will be iteration on the EIP
01:02:08
Ansgar Dietrichs:Replying to "7702 is very synergi..."
then we’d just at some point have to introduce a way to fully revoke the original ecdsa key
01:02:35
Parthasarathy Ramanujam:Adoption of 7702 or the lack of it, wasn’t due to the EIP, it was the reluctance of few wallets to support it and also due to a lot of false information spread about “alleged” vulnerabilities!
01:02:58
Nico Consigny:FCLC for some reason I can't reply directly to
01:03:17
Nico Consigny:> PQ not solved at all
01:03:43
Łukasz Rozmej:Replying to "Adoption of 7702 or ..."
so won't they have similar issues with frame transactions?
01:04:21
lightclient:Replying to "Adoption of 7702 or ..."
i think the default code will basically guarantee that frame tx has wide adoption
01:04:33
Parthasarathy Ramanujam:Replying to "Adoption of 7702 or ..."
As I said earlier, unless EOA are specifically deprecated, you wont have users migrate. But the default code definitely help here.
01:04:51
Łukasz Rozmej:Replying to "Adoption of 7702 or ..."
@lightclient but then it is basically standard transaction?
01:04:57
Ahmad Bitar | Nethermind:My personal stance is to support frame as headliner for hegata
01:05:00
Barnabas:What do EL teams want to work on in the second half of this year, if they oppose all headliners?
01:05:16
lightclient:Replying to "Adoption of 7702 or ..."
it is a standard tx, but it doesn’t make non standard accounts 2nd class
01:05:21
lightclient:Replying to "Adoption of 7702 or ..."
which is important
01:05:40
Barnabas:does ethrex count?
01:05:42
Francesco:Sorry but reth should clearly not be considered in this decision?
01:05:44
Iván | ethrex:+1 for ethrex
01:05:48
nixo:i think the idea here was clean up on a lot of non-headliners (based on comments from last ACDE)
01:06:09
Dragan Rakita:Replying to "Sorry but reth shoul..."
Why is that?
01:06:14
Francesco:Replying to "Sorry but reth shoul..."
There’s a clear conflict of interest\
01:06:48
Francesco:Replying to "Sorry but reth shoul..."
(I don’t care or have opinions about frame txs at all fwiw)
01:06:54
Barnabas:@Daniel Lehrner (Besu) its a chicken and egg
01:06:58
Barnabas:you could make it the majority lol
01:07:07
Dragan Rakita:Replying to "Sorry but reth shoul..."
This does not make sense, we still think what is better for eth protocol
01:07:26
Francesco:Replying to "Sorry but reth shoul..."
You can say that and we can choose to believe you, there’s still a glaring conflict of interest
01:07:41
Dragan Rakita:Replying to "Sorry but reth shoul..."
Frame tx or not, it does not effect tempo at all.
01:08:11
Anders Elowsson:Replying to "What do EL teams wan..."
7999 😎
01:08:12
Giulio:Unreal chat
01:08:29
FLCL:3h sound scary now, 2 days may be a lot 😂
01:08:39
Dragan Rakita:Replying to "Sorry but reth shoul..."
We did a lot good for the protocol, this just feel a bad take.
01:09:17
Francesco:Replying to "Sorry but reth shoul..."
On a personal level, I believe you. But it is a conflict of interest, there’s a competing standard being proposed essentially...
01:09:23
lightclient:mempool rules: https://eips.ethereum.org/EIPS/eip-7562
01:09:43
lightclient:i wouldn’t say that “it isn’t defined” we just have to decide how much of 7562 we want in the core protocol
01:09:51
lightclient:it is very well thought through and thorough
01:10:09
Ansgar Dietrichs:I will keep the discussion open for however much longer there are things to discuss, but I would need either Besu, Nethermind, or reth to flip to frame tx headliner support to not then propose rejecting this headliner proposal at the end.
01:10:44
Marius van der Wijden:Replying to "Sorry but reth shoul..."
I agree, Reth should be able to voice their opinion, even if they have a conflict of interest. I would hope that they won't die on the hill of not implementing it if it came to that though.
01:10:45
Marc:Replying to "I will keep the disc…"
Nethermind team is split on this, personally I would be open to making headliner
01:11:09
DanielVF | Monad:EIP-8141 spec metions rules "similar to"
https://eips.ethereum.org/EIPS/eip-7562
01:11:09
Dragan Rakita:Replying to "Sorry but reth shoul..."
If you believe me, you wouldn’t state it like that, it is really hurtful. The outcome we all want is what is best for etheream, proposing different approach does not make our vote invalid. It is just a bad take.
01:11:17
Francesco:Replying to "Sorry but reth shoul..."
It’s not personal, really
01:12:10
Francesco:Replying to "Sorry but reth shoul..."
And one thing is expressing an opinion, a different thing is getting a “vote”. Seems very standard to not get a vote when there’s a clear conflict of interest?
01:12:15
Lumi | Offchain Labs:Replying to "I will keep the disc..."
Where is Tomasz when we need him 😜
01:12:16
Alex Forshtat:Replying to "Sorry but reth shoul..."
Just a question, why didn't Reth propose Tempo transactions for Hegota headliner?
01:12:17
soispoke:Replying to "i wouldn’t say that ..."
I agree, the only thing to point out is that this was designed without FOCIL in mind
which will impact some of the parameters (e.g., VERIFY gas)
01:12:27
Dragan Rakita:It is like saying drop everyone oppinion except geth
01:12:40
lightclient:some non-headliners may depend on frame tx, such as tx assertions. this is a very important upgrade to improve security of transacting on ethereum
01:13:04
lightclient:Replying to "some non-headliners ..."
frame tx works very well for this because you can have a post-op frame to analyze the outcome of other frames
01:13:21
Giulio:Replying to "Sorry but reth sho..."
Claude, should Reth be included in decision-making? Make no mistakes.
01:13:21
Dragan Rakita:Replying to "Sorry but reth shoul..."
@Francesco I don’t see the conflicts, as I said implementation of frame does not touch tempo. Modular approach of reth allows that.
01:14:49
DanielVF | Monad:Replying to "some non-headliner..."
Will need batch reverting frame ability for post-op frame checks, which I think you are planning on adding?
01:14:59
jvn:I think a year is actually plenty of time to revise the EIP if needed and implement it properly. The benefits could be significant - bringing native account abstraction and even leaving room for a post-quantum pathway. Considering that, Making it as a headliner might actually be worthwhile. IMO
01:15:02
FLCL:Maybe something can be done with tx gossip scores or so
01:15:20
lightclient:Replying to "some non-headliners ..."
there are a few ways it could be implemented. i personally imagined it would be done by only approving payment at end of tx
01:16:05
Fredrik:Replying to "some non-headliners ..."
This is that it’s one of the most asked for features by end users as it basically protects users against drainers and other types of attacks, and is coming from many discussions with various parties during 1TS
01:16:22
Emma:I do not think it is fair to say we shouldn’t be considered in the decision making, when we are clearly supporting and working hard on Reth for Ethereum….
01:17:23
Parthasarathy Ramanujam:Isn’t there a native tracer built (in geth) that validates a transactions against erc7562 rules?
01:17:46
Parthasarathy Ramanujam:Wouldn’t that help with most of the complexities associated to mempool validation?
01:17:55
lightclient:Replying to "Is there a native tr..."
we would just run the evm in a specific mode
01:18:26
Parthasarathy Ramanujam:Replying to "Isn’t there a native..."
I blame auto-correct. I was supposed to type “Isn’t”
01:18:38
Danno Ferrin - Tectonic.xyz:Replying to "Sorry but reth shoul..."
So one of the arguments is “Frame beacuse no alternateives have been proposed” and then when reth proposes an alternative they get penalized?
01:19:16
Francesco:Replying to "Sorry but reth shoul..."
I never said anything about decision making in general, this just happens to be a case when there’s a conflict of interest, in my opinion. You can disagree on that, fine, agree to disagree
01:21:05
Felix (Geth):Just to clarify, Fredrik is talking about the ability to add arbitrary post-conditions to any transaction. Notably this feature is not related with the mempool at all.
01:21:07
soispoke:fwiw implementing encrypted mempools designs (e.g., LUCID) on top of frame txns is quite nice
01:21:25
Enrico Del Fante (tbenr):The security argument is very appealing
01:21:35
Nico Consigny:Nethermind team is splitted
01:21:38
nixo:if we settle on “no headliner” - can we also get a decision on whether or not it can come back as a non-headliner since that’s technically been against process since the headliner process was introduced? but seems reasonable that acd can overrule
01:21:39
Dragan Rakita:Replying to "Sorry but reth shoul..."
We are sharing experience from something that we already have, so hope from here that synergy can be taken.
01:21:56
Alex Forshtat:Replying to "Sorry but reth shoul..."
@Danno Ferrin - Tectonic.xyz But Tempo transactions are not formally proposed for Hegota, are they?
01:22:06
Łukasz Rozmej:I personally don't know, I dont want to block it, but I still see the risk of adding it and then potentially removing as a headliner
01:22:14
Danno Ferrin - Tectonic.xyz:Replying to "Sorry but reth shoul..."
This hiding behind process is not a good look.
01:22:39
Ahmad Bitar | Nethermind:Replying to "if we settle on “no ..."
It frame cannot come back as a non headliner then i believe we should have it in
01:22:39
Barnabas:Can we wait another 2w in deciding? I’m usually not into delaying decisions but its really on the edge.
01:22:46
Danno Ferrin - Tectonic.xyz:Replying to "Sorry but reth shoul..."
process should reflect consensus, not enforce it.
01:22:49
Dragan Rakita:Replying to "Sorry but reth shoul..."
For example this is improvement ever tempo in terms in EIP: https://eips.ethereum.org/EIPS/eip-8175 that would be even better than tempo,
01:23:08
Derek Chiang | ZeroDev:What would need to change to change Besu/Nethermind/Reth’s minds?
01:23:15
Dragan Rakita:Echoing that we all want to improve protocol, and think what is best for it.
01:23:25
Felix (Geth):can we promote it to headliner later?
01:23:48
Felix (Geth):like what if it turns out really good
01:24:37
Dragan Rakita:Replying to "Sorry but reth shoul..."
I will start referring this as composable tx. This is not a headliner as it is smaller scope
01:25:38
Ansgar Dietrichs:can we get a temperature check on delaying the decision?
👍 = delaying decision
👎 = make decision today
01:25:47
lightclient:does anyone want to absolutely block it if we accept as headliner?
01:25:53
lightclient:maybe another way to frame the Q
01:26:12
Ben Adams:Replying to "does anyone want to ..."
I don't think we'd block
01:26:12
Barnabas:if majority of nethermind is for it, then thats the decider
01:26:37
Fredrik:I think the security improvement alone is really valuable. People are losing hundreds of millions of USD each year, and this together with transaction assertions could remove or at the very least significantly reduce that
01:26:52
Parithosh Jayanthi:Also note that we have a lot of ZK related priorities the next few forks. If we don’t do frame txs now, I don’t imagine us getting another chance for a while.
01:27:18
Felix (Geth):we can work out some prototype rules within 2 weeks
01:27:58
Guillaume:Replying to "Also note that we ha..."
priorities change
01:28:36
Łukasz Rozmej:Replying to "we can work out some..."
make sense to me, to try
01:28:39
Orca 0x:Replying to "we can work out some..."
rule clarity in 8141 itself is essential
01:28:57
nixo:i’m for delaying this decision - it seems a bit like support is broad but weak just because of a lack of familiarity / the newness of the EIP. i think it’s on the champions to shore up people’s opinions over the next two weeks
01:29:04
Emma:Replying to "Sorry but reth shoul..."
I do not see where the conflict of interest lies…. We are here representing Reth for the Ethereum community.
My thoughts are that frame txs introduce more account abstraction galaxy braining by delegating complexity into frames. Developers don't want to work with defining "frames".
Reduces complexity in the sense that we don't need a "bundler" (which imo is like 5% of the problem of current AA landscape), but then introduces a ton of complexity on devtooling layer (both contracts and app devtools like viem), and makes account orchestration flows super difficult to reason about.
Generally think accounts don’t need to be galaxy brained abstracted for 95% of real world users. We should enshrine native features for the 95%, and escape hatch to account abstractions for the 5%.
This proposal is good for the 5% and migrating to PQ: https://github.com/ethereum/EIPs/pull/11330
01:29:08
felix (eest):my main impression from the eth mag thread is that many people were sceptical at first but as the EIP got clarified they understood its value and now most support it
01:29:18
Guillaume:Replying to "Also note that we ha..."
allocating 3+ years just to zk is a bad idea - so we'll need to make room for other stuff anyway.
01:30:15
lightclient:what do people want to see in 2 weeks to sway opinion?
01:30:26
Derek Chiang | ZeroDev:Replying to "Sorry but reth shoul..."
I think it’s unfair to discount Reth’s opinion because of perceived conflict of interests. That said, I’m also trusting that Reth will go along with the decision if the clear majority is for it
01:30:29
Barnabas:frame-devnet-0 😂
01:30:29
lightclient:Replying to "what do people want ..."
we can definitely build a prototype and bring txpool rules into 8141 itself
01:30:48
Nicolas Consigny:Replying to "what do people want ..."
More txpool rules ?
01:30:52
Nicolas Consigny:Replying to "what do people want ..."
yes this would be good
01:31:10
Iván | ethrex:Let us know how we can help here, we’ll be glad to do it
01:33:12
Łukasz Rozmej:Replying to "what do people want ..."
some base on realistic tx pool rules
Summary
13 highlights
· 3 decisions · 2 action itemsExperimental
Summary
13 highlights · 3 decisions · 2 action itemsExperimentalfork status and schedule
critical infrastructure
testing progress
- bal-devnet-2: Erigon syncing issues being fixed; benchmarking shows prefetch slower than expected00:04:22
- bal-devnet-3 blocked: most clients not ready for EIP-8037; test release 5.4.0 available00:06:28
- epbs-devnet-0: running 1 week, Lighthouse/Lodestar/Prysm working; Teku/Nimbus joining; exits/builders not working00:29:57
repricing updates
- Repricing breakout scheduled next Wednesday to address 8037 complexity and align with 792800:18:54
headliner selection
- SSZ/Pure ETH rejected as Hegotá headliner; focus on out-of-protocol implementation00:36:20
- Lucid rejected as Hegotá headliner; can be reconsidered for I-Star00:37:48
- Frame transactions support: 2 clients favor (Geth, Erigon); 3 prefer no headliner (Nethermind split, Besu, Reth)00:45:46
- Post-quantum urgency highlighted: DAO migration timeline 2028-2029 requires native AA soon00:57:22