Akash Kshirsagar: Welcome everyone to Orchodev's Call 232. Today we have a few topics around the ongoing preparation for Glamstadam and then looking forward to Hegota and the Headland selection there. Let's start with Glamstadam, DevNet updates. I think Stefan, you could give us some updates on Baal DevNet 2 and 3. Yes, can you hear me? ⁓ So for BAL DevNet 2, it's been going pretty well. I think only Aragon is left to ⁓ get ready and start proposing some blocks. But they've been doing some work on fixing some thinking issues. And they should be ready soon, ⁓ proposing blocks on DevNet 2. We've also ⁓ got further with the efforts ⁓ to get some benchmarking ready on DevNet 2. ⁓ And any benchmarking effort has been done against about definite two so far. We've started dedicated nodes so that we can compare three different approaches. There is ⁓ the all optimizations of bar. Then there is sequential, which is no optimizations of bar, but still with any optimizations that the clients have inherently. then there is no ⁓ prefetch. So with bar, there's the concept of prefetching 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 speed up or not. 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. That's for definite two, unless there's anything else for definite two. ⁓ If not, I would move on to definite three. ⁓ So I've been testing a lot on kurtosis and it seems 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 Spencer 5.4 and it would be good if all clients could ⁓ test and see that they are passing as many tests as possible. Yeah, and I think that's pretty much ⁓ the status for definite three, haven't started it yet. And there's a point from Marius, so I would pass on back. That's good, Marius? Or no, wasn't Marius, it was Eber. No, someone else has a concern. Sorry. Right, Exactly. No, no, no worries. I saw this. So basically, I think there is some concerns around EIP 8037. I heard this already that clients in general were saying that it's a bit more complex than initially thought. For context, course, we do need an approach to state growth if we do not end up addressing street growth at all in Amsterdam, we can't 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 there are 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? Yes, sure. So ⁓ as I wrote, now we have like for four flavors of gas. So 4844 introduces blob gas. Then 7928 introduces this like state gas accounting versus non-state gas accounting. 7778 introduces block accounting versus user refund accounting. And 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. So if like, like if we are keeping 8037 or something similar in Glamstodom, then I think we should take a step back and and make. make the gas changes coherent on the protocol level. So say how I see it, if you look at BALS 3928, they say, okay, you have a gas validation before state access and like pre-state, it's like pre-state validation and post-state validation, right? And then 8037 talks about state versus regular gas. I think that we should just bite the bullet and do it coherently. Now gas is three-dimensional. The dimensions are blob gas, state gas, and computational gas. 79, 28, and 30 talk about state gas, they should talk about exactly the same state gas. So we should refactor both 79.28 and 80.37 to use exactly the same thing, the state guess. And then we should also, we should either drop 77.78 or make it, maybe we should drop refunds entirely, rethink 77.78 or just double check that if we introduce this more or less coherent three-dimensional guess that 77-78 is still fine. Because if we don't do that, if we just add all those kind of independent hacks all together, then we end up in a horrible mess like we are now, with a gazillion of corner cases, things are incoherent, illogical, all kind of... to think about, it's just very hard or impossible to think logically about what gas is now in Ethereum. So if we don't do this coherent approach, then we'll end up with a lot of technical debt. Yeah, we have a few people with hands up. Maria? I just wanted to speak a little bit to the more basic approach. ⁓ So the way I see it is, ⁓ I think we've been using GAZ 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. But we are also using it to control resource abuses 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. And because we are using the same thing for these two things, we end up in a non-optimized approach. So I think one principle way that we should look at it is these are two different things. And so when we talk about transaction gas use, this is inherently different thing from the block limit and block metering. So we should probably even have like these two different concepts. have transaction gas use and we have block metering, block gas metering. So this is, and I think some of the confusion around 1837 is that now we are actually needing to make these specifics on what do we mean by the gas used in a block and what we mean by the gas using the transaction. So this is like the access number one, like these two things need to be separate. The other access is on the resources side. And I think the long-term principle approach is ⁓ as well said, 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 each resource. And I think 8037 is compatible with 7999 and it's already implementing a lot of the things that we need to then have 7999. And so the way I see it, I think is like 8037 is a step. in the direction of the end-reciprocated approach. ⁓ So 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 unmanageable rate. Felix? 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 reverts being handled? Like how was the gas correctly attributed back to parent frames in these scenarios? And it took us a long time to figure out the correct semantics. And I'm pretty sure that there's more cases like this. it really had, it seems the bug potential of this EAP is very high. Doesn't mean the idea of it is bad. It's just, think what Andrew is also kind of trying to say is that it just intuitively feels like something that is super easy to get wrong. And yeah, I just really wanted to voice it that like from an implementer perspective, it's kind of complicated. Andrew? Yeah, so I think it's, yeah, 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 AT37 without a principal approach. So 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. Or we should not ship it at all. ⁓ Otherwise, yeah, we just ship it without a principled approach, it will be very bug prone, error prone. and dragon I think the state gas is very much needed if you want any bigger blocks. 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. ⁓ 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 whole, the reservoir for something that we like talk to weeks ago. And the tests are currently needs to be polished a little bit because they are just made now. So I think it's a little bit chaotic because it's not, we are just coming to the place where the AIP is polished. So in my opinion, we should add it. We should buy the bullet and just implement. it will get better. Yeah, I from my side, I wrote some of this in chat, I think a full rework of gas and basically trying to move towards a principled integrated approach to gas in all ways, I think is to me at least infeasible for Glam Saddam, just because I think this is something that already in the background people have been thinking about. It's just a really kind of complex thing to get right. ⁓ That leaves us, think, the question of specifically on this kind state creation side, can we either A, make some adjustments to 8037 that make it easier to implement, or maybe just bigger changes in principle that really kind of reduce complexity on this topic in particular? I personally have a hard time seeing us making that. final decision today just because I think it was a kind of 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 then make decisions. I do wonder if we were to say today that we need knee changes, whether 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 insights on how it behaves or whether there is a then hold off the DevNet until we have decided what to do about it. I don't know if people have thoughts on this question. Also Maria. I was just going to add that we do have a repricing breakout next Wednesday. So I think that could be a good opportunity. Andrew, if you could come to dive deep into, in your opinion, what changes could be made to make it work better with the other EIPs. I think doing the full, principled approach might not be possible because that would mean like... adding all the resources we want, thinking about what about the ZKVM. So I don't think we'll do like the full thing, ⁓ but trying to make it less prone to edge cases and errors, I think it's a good aim. And so I'll be happy to have a discussion on this. Ben? There's a question. lot of the complication comes from tracking refunds and things. we could go back to the question, do you just drop refunds? Is it the benefit that they bring more valuable than the complexity they're causing? I think the problem that why refunds are a bit complicated with this is because ⁓ the current rule is that we are tracking, that we are refunding the state gas 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, ⁓ then ⁓ it would be significantly easier to implement. ⁓ The logic behind ⁓ refunding to the state gas reservoir is that, you didn't use up the state gas because you are not changing anything. So 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 also don't think it's that complicated. Like the first implementation I had of it was pretty complicated, but ⁓ I've been refactoring it and the only thing that was pretty ugly about it was the thing that we just changed with the recent bar release. ⁓ Otherwise it is pretty straightforward to be honest. When you are thinking about this, it's not that complex to be honest. Yeah, mean, refunds altogether. So we have the one that tracks how much has been used in the block versus how much, you know, there's the separation of here's the refunded gas in the transaction, but here's how much resource the block has actually used less than refund. So if we, so there was like EIP 3298. where was like, rid of refunds altogether. So the question is, the refund incentive, is it that strong that people are deleting Skype? Or is it not? Maybe I have some clarification here. ⁓ In our implementation, we don't touch refund at all. The refilling of the state gas or reservoir with the state gas that's not used is like a different variable. So dropping refunds doesn't touch the refunds in general. constants around that is not touching the state gas or reservoir at all. So it's like totally separate. In that part, it became very simple. Propagating reservoir and coming back from the sub-calls, it's simple logic. The problem that I had mostly is about merging that inside before execution and after execution of the section. So I think the dropping refund is going to solve anything around that. Right. do think, yeah, again, it seems unlikely to me that we will be able to make a decision today. But it seems like an important topic, because if indeed the feeling is that also, say, for example, from the testing side, 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? ⁓ I think Spencer has more context, but I can give the overview that well, I guess my feeling is that it does break a lot of tests. I think it's, it's very complex in the test inside, only because, I mean, primarily because the static tests are not ready for this kind of changes, but we are in the process of converting this. The problem is that this is 10 years of, of tests. So it's not easy. And we've been meaning to do this for a long time. And I think editor seven is like pushing us to just get it done. Spencer, do you have other comments? Yeah, it is tricky. I mean, where the tests are right now, at least in the most, yeah, in the most recent release, we don't have all the tests from the previous works in the most recent release. For Baldead DevNet-free, we specifically chose to simplify some of the, well, simplify a part of EIP-8037 by essentially hard coding the cost per state byte. And so it's already loosely simplified for this DevNet. And my feeling, maybe other clients can speak up here, but my feeling is that we should just go ahead with DevNet for Yaz's ⁓ and then kind of gauge from there if there's a lot more edge cases that pop up. And yeah, for DevNet 4, we will have a lot better coverage and even more, I guess, specific edge cases for 8037. Yeah. One thing is that ⁓ we have not ⁓ successfully filled all the tests. So that's something that we had to take into account. I wouldn't feel confident about signing off this EIP into the fork if we are not passing all tests. ⁓ But we can 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. So ⁓ yeah, I think it's going to take a lot of work from us. if this is a change that we need, I mean, ⁓ it's just something that we have to do. Yeah, sounds good. Thank you. That's good context, I think. Yeah, I agree, I think, with the general take that would be very desirable if we could go ahead with devnet3, baldevnet3 as is, including 8037 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 in the end. And then I would still also like the idea of, say, next Next week's repricing breakout, we specifically focus on the question 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? So to really have people join next week 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 things we can do. It feels like that's the best way forward. Do we have, yeah. How do people feel about that? I guess, Eragon, for example, would you all be able to basically support Biodepna 3 in its current form? Yeah, we working on it. So we will try to make it work. It sounds like a reasonable interim approach, but I think we should... at least a line 79, 28 and 80, 37 in Amsterdam. Yeah, makes sense. And think that's the type of topic for next week. Marius? I totally agree with that. I also think those are two EIPs that both change the way ⁓ receipts work. And I think they are specified very differently. And so we should definitely make them. Sounds good. ⁓ Then I think for now, that's probably a good place to leave it at and move on. Is there any last comments, anything anyone would definitely still want to bring up on this topic for today? Otherwise, before we get into HDIH headliner discussion, which is the main topic for today, just very briefly wanted to ask Barnabas if there's any update regarding EPBS definite zero. That's obviously mostly a CL set topic, but I think it's good to just make sure we have visibility on from the EL set as well. Yeah, sure. So we have a stable dish DevNet, that was launched last week Wednesday, and we've been going on for a whole week. ⁓ We have a few clients that are working. We have Lighthouse, Lowstar, and Prism working fine. Teku and Nimbus are working hard to ⁓ get up to head. We have CheckpointZ working now as well. ⁓ We Withdrawals working and Deposits working. currently do not have exits working, but ⁓ it's something that clients are looking into ⁓ getting fixed, as well as exiting 0.03 builders ⁓ that is not yet working. ⁓ We are expecting to have a new consistency spec released by the end of this week, and we are going to either launch 7.1 next week, Wednesday, or a week after that. That will be based on top of the latest Rx factories. Sounds good. Any outside topics, questions anyone has around the StepNet? We currently only have Gath of the EL. Ideally, we could have at least one more EL just in case there's something wrong with Gath. I'm not saying that there will be, but ideally we would have at least two. Do we have any other EL clients actively working towards like short term, sorry, EPVS definite zero readiness? And if so, how close are we there? I'm not aware of anyone working on it. I think all the EL teams are very busy. So it's like not urgent, but if anyone has a bit of downtime, then let me know and I can point you to do it. It's fairly easy to do. As Marius said. Sounds good. So open invite if anyone is bored from all the state guest questions and thinks this is trivial and wants a challenge. It sounds like a very small challenge from the outside. yeah, to reach out to Banabas. Maybe see if you can join the DevNet. That sounds fun. ⁓ OK. Perfect. Thank you, Banabas. ⁓ Then next up, we do have the Hegoda headliner. selection. Just as a quick reminder, we kind of already had a discussion last call. The plan is to make a decision today. We basically have the different options that we had where the front runner candidates, so to say, were either to do the frame transaction headliner proposal or possibly some clients had the preference of maybe just not having an EL-specific headliner, focus on Fossil as the kind of cross-layer headliner for that fork, and then have smaller features ⁓ or just lower priority features ⁓ otherwise on the EL side. But there were also still the candidates of ⁓ Lucid, the encrypted mempool proposal, ⁓ and the SSE ⁓ PUREES. ⁓ 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 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 we're feeling that this is one hard fork too early and that we should probably just revisit this. for iStar 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. Anders, are you on the call for example? I heard you ⁓ mention something in that regard. ⁓ yeah, can just say that if there's no general support for it, we are of course open for sort of recognizing that we can sort of try. for iStar if there's, if people think that should not do it for hstar. it's, yeah, I would say generally we will still like to put it up here for discussion, but yeah, we are definitely open for thinking that maybe it's suitable for iStar. Sounds good. and of course, my feeling is that clients haven't really changed their take on this over the last two weeks. of course, if that is 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 SSZ 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. ⁓ Yeah, do we have anyone here with opinions on either of those two headliners, ⁓ SSC or ⁓ Lucid, who would maybe potentially want to argue against rejecting them now? Or of course, just confirm this decision. Ben? ⁓ Just SSC. There's been like a recent movement to do a form of some SSE sort of that's not fork related. But I think that might change the topology on that as well. So it doesn't need to be coordinated necessarily through consensus. Yeah, Daniel? Yeah, so from the best of side, had Lucid as the favorite the last time, but now the team changed actually to no headliner as favorite. So from our side, it also would not be Lucid. Makes sense. And yeah, just to confirm, think people are overall quite positive about both of those, SSE and ⁓ Lucid for the future of Ethereum. It's just, yeah, maybe... not the right form as an H-Star headliner. ⁓ That's at least the feeling that I got from conversations. then, like I would just, I mean, that's not really just a batch decision. usually dislike this. So just let's do them one by one. ⁓ I would propose to just reject SSE as headliner proposal for H-Star. ⁓ And again, that does not mean that we are not considering doing this either out of protocol, in protocol, otherwise, but just not selecting it as a headliner, basically. Anyone wants to speak up against that decision? Okay, so then we will not do ⁓ the SSE as a headliner in HSTAR. 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. OK, so then we also ⁓ reject Doosit as headliner for HSTAR. 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's been quite a bit of discussion. Unfortunately, I was not able to join the breakout call last week. ⁓ Yes, do we have anyone who could? briefly summarize the ⁓ discussion from the breakout and then otherwise, yeah, any clients with updated positions on this topic. Felix? Yeah, I can definitely summarize. have also for people to, if you are interested, I have posted a longer comment to the ACD PM issue that summarizes basically everything that we have done on the EAP in the last couple of 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 heard some criticism from various actors. 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... Happy to say that this was also integrated into the forecast website. So I have actually also put a link to it in my comment. And on the breakout call, mostly it was just, 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 post quantum signatures be achieved within the block. There are some technical nuances that still have to be solved around this area. And then, yeah, like I said, 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 just hear what they really want out of this. 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 ⁓ in addition to this being 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 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. yeah, facing this wider landscape of having this, 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, we now are considering an upgrade path for the existing smart accounts which are using ERC437 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. Sounds good, thank you. ⁓ Before we go into the open discussion, I think, you know, see Italics also on the call, I think one of them, well, co-creators of the EAP, but I just briefly wanted to make sure that we have the latest picture of where clients' positions are right now. So for example, I think on the last call, there was a comment from Bezu that in the absence of Lucid, they would actually... prefer doing frame transactions over nothing, but now it sounded like maybe Bezu is actually would rather be in favor of no headliner. Is this correct? to double check? Yeah, that's correct. Sounds, yeah, okay, makes sense. And then I think otherwise I had ⁓ Nethermind and Reth on the side, on the downers on the side of preferring ⁓ no headliner over frame transactions. And Ericon and Geth on the side of the other way around, preferring frame transactions over nothing. Is this still accurate? Ben? Yeah, so no headliner, but we wouldn't want to say ⁓ no to frame transactions. We just don't want to put it on the headliner priority where ⁓ we can't ship the fork if it's not ready, ⁓ but we'd like it to come in as one of the regular EIPs. So what we did to... In the previous fork, as we said, if it came in as the headliner and was rejected, it's obviously a big thing. So it shouldn't come in as a regular EIP. We don't think that's the case with frame transactions. so we'd like that to... Lukasz can probably... Yeah, so if I can say something, would potentially... about working on it and prototyping it and working on the spec, but we are not sure about it yet, so we don't want it as a headliner in that way. So potentially, we are not sure if we should commit to it in this way. Makes sense. Dragan? From the side, yeah, we afford no headliners for H-Star. We don't support frame as our stance is to introduce additional abstraction layer that we don't need. And something like temp intersection as the blueprint for the neutral section could be a lot better. It could give us lot more benefits from and smaller risk from anything. Frame TX in general, it's a very big lift for TX pull and how DDoS protection is done and handled. It doesn't explain how the things are going to be done, but it introduces additional abstraction that allows those things. So directly implementing those and things that we need in some specific or straightforward way, I think it's going to be a lot more beneficial. Makes sense. ⁓ And I think there's a comment by Matt ⁓ on the mempool side question specifically. yeah, OK, sounds good. So then I think we have a picture. So right now we have ⁓ three clients more leaning towards no headliner and two clients leaning to supporting frame transactions, which would, given that I think they're 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. 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 still are in a position to change their mind on this. ⁓ So yeah, think this is the main kind of agenda for 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 people? Sorry, I just give you little bit of extra feedback from an Aragon perspective? Because I think 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 I think what What we want to do probably from a development perspective is work on lucid and frames ⁓ as a kind of thing that we will coordinate together to get into the code base. 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 code base. And One of the things that I think we want to get resolved is Lucid has this composite proposal in it as well as frames. And we don't think it makes sense to have like two composite transaction types effectively. So it seems like there needs to be some coordination there. But we want to work on both. We think it makes sense to work on both of those things in that kind of hegeta timeframe. Make sense. And at least it does seem like, if we wanted to do Lucid, I personally think it's unlikely we'll end up doing it as a non-headliner still for Aged already. yeah, definitely one should think they Yeah, so I think we're kind of sort of less, we're more neutral on the headliner thing, right? Because 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 essentially. So while it makes sense to co-develop it, it doesn't necessarily make sense to us to co-deliver it, if that makes sense. Yeah, that makes sense. And then that would still, at least in principle, be an argument that could still favor having as a headliner in H-Star and then already like in the development process for it, make sure that it is forward compatible with Lucid or a Lucid variant that we would then bring in I-Star. Yeah, because what we don't want to do is do frame transactions and then revisit them for the exact next fork we're putting Lucid in. Yeah, that makes sense. But yeah, I think again, I agree. think what you're saying, basically, it's not about chipping them together. It's not about chipping Lucid in HSTAS 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. Yeah, yeah. That's a good summary. Yeah, sounds good. Yeah, then in general, thoughts? I do know that there's a few people on here that 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 still convince the skeptical clients, anyone who wants to. It kind of seems that the main concern is that frame transactions are going to delay the next fork. That's what I'm understanding, at least from another mind. ⁓ But I'm wondering if it changes people's opinions, knowing that we can choose how complicated to make the transaction pool. That's one thing. The other thing is that we still have quite a long time before this fork is going to go live. We're already talking about maybe large changes to GlamsterDAM. So we're looking at at least one year out before this feature would even go live. Yeah, Ben. I would go further than just saying the latest work in that we're positive towards friend transactions, but we're not 100 % convinced. prefer the optionality to say, okay, maybe this doesn't work at some point in the future. Whereas putting it as headline, would suggest that is the form, if you know what mean. It's not. I mean, yeah, if we say it's headliner, but we reserve the rights to remove it later, if we realize it's not going to work, is that sufficient to accept it as a headliner? Like we don't have to tie our hands behind our back with processes and rules if it's going to lead to worse outcomes for Ethereum. Yeah, but it would be weird messaging to put something as a headliner and then make that like... 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. I don't know if this is what you're proposing or if you're proposing that we consider it as a non-headliner in h star. As a non-headliner in h star. Right. So I would just say, like, if we're going to 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. Because if we say it's not a headliner, now we have to wait several more weeks for the non-headliners to come around. 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? Might as well just not have it as a headliner. I'm going to speak up now. So I think this has been feedback that I also got from talking to client developers individually that it just somehow seems like for this, I think the concept of the headliner was introduced so that clients could all commit to a singular goal, which has to be achieved by the fork. And if 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 we cannot currently gather this kind of support for EIP 8141. 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 H-Star fork, then we wouldn't have such trouble deciding on it. So this is kind of where this hesitation is coming from to say, yeah, maybe we should downgrade it to a non-headliner or whatever. I personally am not super attached to the exact process here. 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 with people exploring different ideas to bring it there. And we feel that with EIP 8141, 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 is always the issue. So this time we are really making sure that at least 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 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 better than what was proposed before for this particular topic. so, yeah, 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 it's like, we might as well do this one. I mean, it is a bit larger change than tweaking gas prices or trying to I don't know, add some convenience features to the protocol. Like it is a pretty fundamental change to the protocol in many ways. so that's for me, this is more important as the headliner. just has like, gives a big upgrade to the chain in some ways. ⁓ thing I wanted to also highlight again is that There's a lot of synergy is between fossil and native account abstraction. ⁓ like those two EIPs are actually quite naturally complimentary basically because ⁓ what fossil does is it creates very strong, rapid inclusion guarantees for transactions. And a native account abstraction greatly increases the set of things that can be directly done as transactions. And so if you have those two things together, then it basically means that a very large sets of applications and including transactions from smart contract wallets, potentially including things that transactions that pay fees and other assets, also including privacy protocols, be able to be 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 much more dominant. And so I think ⁓ this is also a case for treating the tool almost as a very interrelated unit to some degree. Make sense. Dragan, you have the end up? say that there is uncertainty or unclearity about exactly is the frame, the accent, listening from the nethermines. They need more time to evaluate what is needed because they are uncertain if this is the solution that we want to include or not. I think that should be good enough reason to not include it as a headliner. For the frame TX in general, basic house stance is too complex and those things, basic protocols that we want to include to enable all the things that we want to, it should be natively supported. Because if it's natively supported without that executable abstraction that frame.txt now has, ⁓ it becomes a lot easier to use. It becomes more straightforward. It becomes a lot better. So yeah, I think that's my stance here. And Nico, you're unmuted. Did you want to say something? Yeah, sorry. I couldn't raise my hand. ⁓ One thing that I wanted to add is ⁓ on the timeline question, even if we headline or not, even if we ship ⁓ frame transaction in H-star, it's going to be a tight timing for DAOs to upgrade their contracts to post-quantum resistance transaction. So we are looking at, in the best scenario, one year to ship the EIP. Then on top of that, you need to account for a very messy DAO voting decision, which will take a few months. You need to add to that some audits for the verification schemes. So this brings us to 2028 and 2029, or even a bit later with potential delays. So yeah, I just wanted to remind that in this context, it's a bit gamblish to go for something that is not post-quantum. And even if we take the frame transaction and we manage to do everything, it's going to be a race to ship this in a safe time frame, so by 2029. So yeah, I just wanted to... to highlight the urgency here because we have to account for DAOs and we have to account for wallets. So yeah, it's going to take some time to do all this. Yeah, one comment I see in the chat. It doesn't solve post-quantum directly, but it does enable native Solidity verifiers to be the main account. So yes, in a sense, even if it's expensive, it does solve post-quantum. Any Mark you want to say something? Is that an argument for or against making it a headline? It's for and it's for making it an headline. Because basically if we use it, it's going to be very complicated. And we will be gambling with the PQ timelines, which we really don't want to be doing. Yeah, I think if we need to reach consensus, we also maybe need to, because it seems like from a RETH perspective, your concern is, is this the right AA proposal? But I mean, 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 and let's get adoption. And actually, if you look at the history of that adoption still being quite slow, although it was put into the protocol 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. And if we don't, if we delay it by another year, it's another year of delay. 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 AVI and you would would, you know, redeploy the you would update the AVI contract and run everything. You would not target like random wallets. So the main targets are big governance contract and stuff and they take a lot of time to move. So we need to account for that too. Thank you. ⁓ Derek, you're finished up? Yeah, I think I just want to say that I think ⁓ since a lot of people are comparing 7.0.2 with frames, I just want to say that I think it's slightly misleading to use the fact that maybe 7.0.2 has lower adoption than some might have hoped, 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 a one for one will have similarly law adoption because the thing about 70002 is that it's not actually native AA in any real sense, right? Like 70002 is simply a mechanism to allow your ways to upgrade a smart contract to, you know, to upgrade to smart contracts, but it doesn't actually like allow the smart accounts to originate transactions, for example, which is a core goal of native AA. It doesn't give the the ability to have their guests natively sponsored, for example. So if you look at how the wallets have actually used 7.0.2, for example, Metamask, they're using 7.0.2, but they cannot actually give their users the ability to have their guests sponsored without relying on application-level relays such as ERC437 bundlers. Whereas, firm transactions are actually a full-fledged AA proposal that natively introduces the capability of things like guest sponsorship, transaction batching. So I think like, know, from transactions, think especially with the latest updates. I was actually making the opposite point. Basically, I think we should do frame transactions and not do another, let's do something simpler. Oh, amazing. Yeah, think some people in the comments seem to be suggesting otherwise, know, but yes, thanks for people clarifying. 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 get developed. But it feels to me like this is the time that we should do it. Basically. and not have another conversation and come up with a kind of compromise? Right. Yeah, I mean, would, I think, yeah, I personally, you know, like frame transactions. I'm not sure how I feel about that in a situation, but luckily, that's not my decision to make. ⁓ I will just say in terms of purely process. ⁓ I, you know, right now I, I, I, seemingly I only see two clients that would prefer this headliner, ⁓ with Geth and Aragon. I think if, if there was a third client, so if, if any of say, neither mind Bezu 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 to, would be, would be, of course, there's still time, but would be to reject it as headliner and then reconsider it as non-headliner. Yeah. So I'm just wondering out of the three clients that are currently against it, seems like Reth is pretty locked in on being skeptical. I think also with some background there with the temple developments. ⁓ Yeah, I was wondering basically like maybe specifically a question towards Nethermind and Beesu. 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, what's the situation there? Daniel? Yeah. So from the business side, we had like a ranking and no headliner was basically the first one. And from transaction and lucid was a close second. But still if the majority of the other clients is no headliner, then our decision still stays like this. So there is for us, I don't think there's a reason for that to change that. And from the another mindset? I don't know. My personal standards didn't change. don't know if other people. Right. personally don't... Yeah, sorry, Matt, seem to be unmuted. I was just saying, I feel like we're still focusing on the ability to deliver the change, but I don't really understand why We're not accounting for the fact that we can tune how much we're going to deliver with the frame transaction substantially. This isn't like most changes where you have to implement every single thing in the EIP to put on the mainnet, because the consensus changes for the frame transactions are relatively small. Like, Etherex said they implemented it in just a couple of days. The transaction pool is where things get more complicated. Like, if we're going to submit If we're going to support the paymaster sponsoring, then this is going to be a much larger change than if we added frame transactions to the consensus object, which would allow them to use frame transactions, begin the adoption frame transactions, and then let clients after the fork continue working on the transaction pool changes without being blocked on a fork. To some extent, I actually quite agree, but I read the situation differently. I read it like, OK, we specified the easier part and the harder part is left unspecified, but please commit to it. So that's how I read the room. Have you read the ERC about how the transaction pool will work? ⁓ There is a special, specified ERC, not the EIP? Yeah, it's... We can explain this. So the thing is that the EIP 8141 was developed from EIP 7001 and this EIP was itself developed from ERC 4337. So all of these proposals are coming basically from the same family of proposals related to account abstraction. And as part of the ERC 4337, the Ethereum Foundation account abstraction team has developed a set of rules for their mempool, which can be applied 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 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 basically for the account abstraction to be viable in the mempool, there are two strategies. One of them is basically acknowledging that the full generality that account abstraction 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. 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. 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. 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 idea is that we, 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, in some ways, it basically 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. And in practice, this is how I think the mempool will work with EIP 8141 for the node implementations, we will come up with a guidance document that explains like the minimal set of rules that allows some useful subset of transactions to be submitted to the public mempool. But then there will also be third party mempools which implement different rules or more complicated rules. And anyway, the goal of EIP 8141 is primarily just to allow these like arbitrary transactions with any kind of like approval interaction to be included in a block. 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 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. And so this is the other reason why we do not specify all the rules directly in EIP 8.1.4.1, because there is just no one set of rules that works for everyone. It is like a nuanced thing. Okay, sorry, it was kind of a long text, but I hope you guys... Yeah, yeah, I understand it. So... ⁓ My question is, should we make it a headliner, which we want, without polishing those rules for public Ethereum mainnet mempool? I'm not sure. We have created some examples already in the ERP that show you, for example, the frame structures 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 the frame transaction than it is with for example a simple 1559 transaction because you will have to So we have created some frame structures there that can show you okay? is approximately what this can look like and also obviously it depends a lot on for example, which signatures 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 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. And so yeah, this doesn't really change, but like in the 8.1.4.1, 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 this will become quite an important thing. We have not fully finished our experiments for this either. We are still working towards figuring out what are going to be these limits, what are going to be these rules. This is for us also a big part of the work that lies ahead in the coming year. And this is also why Fundamentally, the guest team is working so much on these changes because we feel like we have a good understanding of the public mempool. And this is kind of why we took over this account abstraction thing because we feel like, the mempool is kind of the primary challenge here. yeah, I mean, we don't have to end all the answers right now. Definitely. It's a bit unfortunate, but we have to propose the headliner a year before the fork. we have to just, there will be. Exactly, I agree. So that's why we propose to make it a non-headliner EAP and go this path because of these uncertainties. That was exactly our point. Okay. Well, I there's no... I can't really argue with that. just... I mean, anyway, I'm pretty happy that you understand my points and why we chose to work on it. Ben, you also have your hand up or is it resolved? Yeah, I was just going to say, so potentially, ultimately you'd be in a situation where to accept transactions, you'd have to be invoking the EVM in the transaction pool to decide whether it's a valid transaction. Yeah, mean, that's kind of a part of it. Yeah. But then there's a question like, can the EVM do? And like, what do you allow the EVM to do in this environment? It is definitely a new environment for the EVM. The EVM has not run in the transaction pool before. So in this case, we are treating the EVM as more like an arbitrary function, basically. Yeah, I think it's fair to say you have to introspect the EVM instructions in the transaction. You don't need to necessarily. I think part of the crafting of the rules was so that for certain of them, you don't need to execute. You can just inspect. There are various ways to do it. 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 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. Or there are various other ideas that can basically save you some of these more expensive evaluations. So it's 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 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 frame. So it's pretty clear to the transaction pool. For example, this is the reason why verify frames exists in this proposal so that the mempool can say, okay, verification is in this exact call 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. 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 going to have any chance at actually validating, for example. Anyways, it's going really deep now, but I feel like these discussions are valuable because this proposal seems to be heavily misunderstood sometimes. Might also be worth mentioning this. Oh yeah, I was gonna say Frederick's point, but Frederick, you can say it. Yeah. Yeah, I just want to say that there is this other aspect of it as well, which is revolving around end user security. And one of the things that we've seen and heard a lot from end users is that... They are losing quite a bit of funds through various types of hacks, scams and drainers and other means. And 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 driving people away from using blockchain technology because once they lose all their funds through a scam, they're not super happy to continue transacting. So one of the things that we can do is to implement something like transaction assertions, which will allow people to basically, or wallets to provide 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 token X and the transaction is actually doing something else, then the transaction would re... revert and they would not end up losing their funds. And this is something that Frame Transactions could solve pretty nicely from the looks of it, which is why I am personally pretty excited about it. And I think it will have a very big positive impact on the user ecosystem. feel like if we don't make frame transactions the headliner here, it's going to be harder to build things like this on top of it because we don't want to multiple non-headliners that are dependent on each other. Then we create a large risk profile for one of them not shipping, causing a cascading failure of the fork. OK, so we add. 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? And I did see in chat that don't say on another my team, maybe there's just kind of different opinions, but it did seem like the team overall was still pointing more towards no headliner. ⁓ 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, us to then make a decision. the cost of, of course, delaying these types of decisions is high. So I'm very hesitant to like, to, to, to pay that cost. Unless there's a specific reason why we would think that there will be significant resolution within those two weeks. And other, otherwise it just feels very hard to accept a headliner with so such significant. ⁓ client skepticism. I think the clear default decision here would be to just not accept it as a headliner. just don't really see. ⁓ but ⁓ just process wise. are in favor of adding it as a headliner. then even Lukas is saying now he doesn't know for certain and doesn't want to block it. Like there is risk in changing Ethereum. There always is. But part of having the governance decisions now early means that we can try to minimize that risk a lot by iterating on this rather than continuing to spend time figuring out what we're going to even do with the fork. but I mean, so right now, don't think unless again over the next five minutes, there's still more change. I don't think we're in a position to accept. transactions at 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 Banabas was proposing it in chat for example. 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. ⁓ Yeah. But then again, I think the understanding for next, for two weeks from now would be that, 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? I'd just like to pull out what Vivek said in chat. I think that's interesting. Maybe promoting it to headliner later. Well, we don't really have a process for that. ⁓ I personally am always leaning on the side of some flexibility with processes. This seems like it would be bending the process quite a bit, which I definitely don't feel prepared to say that that's going to be possible today. mean, obviously, could discuss this and see maybe over the next two weeks, decide whether that's something we would be willing to do. ⁓ But yeah, I feel like it's a bit tricky to just impromptu make such big changes to processes. Well, I mean, it's the no headline, no campaign. ⁓ What's that? Well, then if we don't have a headliner, then it may not be a situation covered by process. Sure. Yeah. ⁓ Can you hear me? Yes. ⁓ Yeah, so I wanted to just surface that the Netherman team is split among this. Some think that it shouldn't be a headliner, but some of us think that we like it as a headliner, just to ⁓ be clear about that. I also noticed or heard similar feedback from Bezel, but I might be wrong. And we know that Geth and Reth are not not sorry again and it rex are supporting so doesn't it seem like most consensus is saying they support it as a headliner or am i understanding this incorrectly i think you guys would need to have to get off the fence 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 maybe that's the question that we should ask because that's the only way that it'll take the process forward. presumably the sum, sum. ⁓ definable reason why shouldn't be for people who saying no. Maybe we need to understand what those issues are and address them. So for me definitely some kind of rules that are acceptable by everyone, like the consensus on the rules around the transaction pool that is on the one hand not dosable and works in a reasonable way, on the other hand has ⁓ reasonable ⁓ usability, which I'm not sure if it's easy to achieve both. So does that just require it? Because the EFAA guys have spent quite a lot of time on that. Have you looked at what they've proposed? Well, not completely. ⁓ And Felix says they already kind of have a bit different idea for the frame transactions. Yeah, I just wanted to quickly highlight again that there are two different things here. So we're talking about this rule set, which is also cited within EIP 8141. And this rule set is giving this... 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 rule set and 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 the whole other thing because the account implementations are technically something that is arbitrary in this proposal. 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 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, once this is in, then it's like the question like these, these like public mempool rules definitely should permit using the default account. And then like 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. That's just not how the process works. We have to provide the EAP early on so that it can be worked on during the fork cycle. We cannot just like finish everything and then present it. That's, that's, that 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 time to actually implement it, then all the changes come. 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 it still requires the work. So, ⁓ we have two minutes left. Then it does sound like, well, 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 decision today and several people suggesting that we should decide we should wait for two more weeks, just given that it seems to be so on edge. 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 ⁓ 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. ⁓ Default outcome again, I think would be to not select it as a headliner. you know, just people should have that as a mindset, yeah, I think we are not far away from enough client support to change that. Yeah. So, and then I think it's on the frame transaction champions to maybe set up some, some sort of, you know, one more breakout call or something like this between now and then to, to, find the, which it seems like needs to focus on the, the usability in the mem. or the ability to build something in the mempool at least a minimum that's actually practical because that seems to be where the questions are. Yeah, that's what the break out should address. It seems reasonable for this to least be a big focus. And yeah, Matt also asked in chat. then I think, let me put it this way, think ideally anyone who has some specific questions or concerns or thought that they would want addressed to reach out to the champions. ideally we have an agenda item. issue are 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 decision where everyone is behind and then we can actually, I think that's best for a theorem 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. In terms of non-headliners, there's the question already. At the moment, we lock in the headliner decisions. We can open up the proposing window for non-headliner EAPs. And then we will communicate specific deadlines there around by when do non-headliners have to be proposed at a later point, either two weeks from now four weeks from now. We'll communicate the specific deadlines there. So look out for this, but. Basically, can prepare to drop your non-headliner proposals starting next call, basically. Okay, with that, we're also running up on time. had a few more agenda items on the agenda, but I think I'll just bump them to two weeks from now and leave it at that. Awesome, thank you everyone. And talk to you all in two weeks.