All Core Devs - Execution #215

Transcript

Tim Beiko: Okay, yeah, we can get started. Let me know when we're up.

Akash | ECH: Yeah, you are live.

Tim Beiko: Okay, thanks. Everyone. Welcome to acde number 2, 1, 5, have a couple of things on the agenda today. So a bunch of Fusaka scope finalizations questions to go through specifically around 7, 9 0, 7 the Max Blob for transactions. And then the MoD exp pre compile re pricing Once we get to that, I wanted to chat a bit about the Amsterdam. So specifically, we have these headliners that have been proposed. We were hoping to finalize that in 2 weeks. But given, we have not yet finalized the few psychoscope that feels unrealistic. So yeah, we should probably revise that. And then finally, Finally, Matt had a couple of things around the history expiry that he wanted to get feedback from teams on

but I guess to kick us off. Does Perry or Barnabas want to give us an update on Devnet 2. And how things are going there.

Barnabas Busa: Yeah, sure so definitely not looking too great. We have on finalization for about 3 days now. we had a bunch of peering issues. And some fork id issues bezel had a forecast, had had some peering issue. Nimbus and Nimbus El. Both are having issues. They are unable to sync, we are about 56% right now. And yes, it's not looking too great and tech. We also had some issues, and in the beginning be before we even hit Hulu, during full transition prison, had a bug as well.

Tim Beiko: Okay, do any of the client teams want to chime in about the issues they've encountered and what the next steps are. Yeah, Roman.

Roman: Yeah. We added some more logs to see what the parent issues are. Exactly. And the it seems to be work. Id related as well we we should fix it by the end of the day.

Tim Beiko: Okay, what did anything change in the fork? Id

Roman: It. It is more likely that we're we're not initially treating videos as regular hard works.

Tim Beiko: Oh, okay. I see that. Okay.

Roman: Most likely. Video related.

Tim Beiko: I see it. And Gabriel, when you say Basic was not calculating the forecast correctly. Is that also the the source.

Gabriel Trintinalia: Yeah. Exactly the same thing.

Tim Beiko: Okay, got it? I know that. When we run into this issue or on the test nets for Petra, we said we would create some test suites to actually test these like static configs for clients. I don't know if we ever did it. yeah, I think Daniel or and or Mario, we're working on this. I don't know if either of them has context on it, but it it does seem like this is also hitting us. Now, we should probably figure out a way to test it. Especially in the context of Vpos easy. Yeah. So I don't. Maybe.

Mario Vega: The in the East Repository. We can okay, work something out. Yeah.

Tim Beiko: Yeah, we yeah. And we can discuss this, I think, around the call Monday. But it does feel like,

Carson | STEEL (EELS): If this.

Tim Beiko: Oh, yeah, it does like, if you have a growing number of just parameters that clients need to align on in Genesis, we should have a way to just test that side. Oh, and yeah, thanks, Spencer. yeah. Oh, I'm I'm not sure that the thing you, link Spencer was the actual was Diana's proposal. I I think he wanted to like extend this or something. but yeah, can follow up Async about this. Any other issue people wanted to discuss. Oh, yes, okay. Sorry. That second link that Gabriel shared is what Daniel's proposal was. So I don't know if this would actually support Bpo's if not, we should probably extend it and

make sure we have some tests around this.

Barnabas Busa: Is this something you could actually ask for next? Would it be hard to as another vip. because this is just a Json Rp. Sequel, so it should be fairly easy to add.

Tim Beiko: Has have any clients actually implemented this.

Felix Lange: So we have nothing yet.

Tim Beiko: Do you have a sense of how big of a lift it is to implement like.

Felix Lange: So one thing about this proposal for sure is that it requires basically a custom implementation of this method. So it's not something that just falls out of the genesis, for example. So we do have to write. okay. But there's we can. Yeah.

Tim Beiko: Yeah. Yeah. And there's a Pr for base 2. Yeah. Oh, sorry. Some.

Barnabas Busa: I I would really want this to be included. To be honest. And because we need to verify if the config is correct, and I just don't understand how this was not there yet before. Yeah. So I think all, all clients should use the same format. That would be very nice.

Tim Beiko: Yeah, like, all the clients will probably have to implement it a bit differently. But exposing. yeah, like, yeah, exposing the the call in the same format would be really helpful. I guess I maybe one thing that could be helpful is if teams have time before Monday's testing calls to get like a a rough sense of what the implementation lift would be. We can make a call then about having it be a prerequisite for definite 3. Does that make sense? And I think, okay, if if we chat about it as well on Monday, the other thing that we should probably consider is, is there some version of this for the cl clients? Because, if the El clients are running into issue issues, then

yeah, we? We probably want to wait for cl clients to also make sure they're like set up with the same configs. But that might be a bigger lift.

Barnabas Busa: Yes, here's already have this Api exposed beginning. Api.

Tim Beiko: Okay, amazing. Okay? Then, yeah, it feels like we, we should definitely should definitely do it on the El And yeah, like, I guess, to Lucas's comment, like, it's not like a consensus change. So it's not like something we would add to definite, free formally. But I think it's maybe something we can just date like we agreed to like not launch Devnet 3 until we have this. But yeah, I I I think we should give teams like maybe a couple of days to look into this and and finalize that decision on Monday. Does that make sense? Okay, let's do that any other. Yeah. Test. Definite issue. Sorry that people feel we should bring up here and discuss.

Okay. then, next up we need to make a call around the Eip. 7, 9 0, 7 so there was a pretty big thread about this this week. I mean, it's been going for many weeks. But yeah, I I don't know if drag on, you want to give a context on your latest proposed change or yeah, life science, either of you. Wanna give us some money.

Dragan Rakita: Sure I can do it. After interrupt. We have discussion, but changes need to be made on 7, 9, 0 7, and likely made Pr, that reduces code size to basically doubling it, whereas it was 10 times it introduced slightly more gas fee from 2 per board to 4 per board. And the last thing was it basically introduced the case with the xt code size. I think all clients are fine, was fine. With that change. Yesterday we had discussion how to implement the warming of the code size in the end. I think all clients are fine to remove it for that thing to be permutation detail. In general. There are 3 Prs that needs to be merged. One is clarification of light, like client Pr, the patch that removes code, size load warming, and the last one is most clarification from Mario is to include the loading of the initial targeted by code when it is hit by transaction.

This was not where indefinite. 2. This this was not done.

Tim Beiko: Thank you. Mike signed anything to add on that, or it's okay. If not, then I guess there's yeah. 2 questions the 1st is. are all the teams okay with the 3 Prs that Gabriel from basically posted in chat. So this, pr, 9, 9, 1 0. Then the addition that dragon made to it and then Mario's pr around large contracts. So if we went forward with this. does anyone oppose, merging these 3 prs, and then having that be the final spec. And then the second question is, should we make the code size, index, optional or mandatory. I think optional was where soft consensus was last time I I checked. But yeah, we should definitely get explicit agreement on this.

Dragan Rakita: A Pr assumes that code size index is optional or basically implementation detail.

Tim Beiko: Right? Oh, yeah, yeah. And so, yeah, by, I guess by optional like. not not in consensus, like, I think there's no design where we are actually making this like a like a a part of the consensus. But When we say the implementation detail, it's like we still expect all of the teams to have something or so.

Allan | Offchain Labs: Yes. help catch me up. On the rationale for reducing the contract code size limit to 48 kb. Representing arbitrum and also catching up on all the different threads, so I'm sorry if I missed it.

Dragan Rakita: I think it's mostly to side with caution. 10 times increasing. The contract size seems too much, and with this aip we are doubling it and preparing the work for further increase in the future. Hard folks in future, hard Fork. We could just change the constant, and in the end we will have the bigger, bigger contracts.

Allan | Offchain Labs: That's helpful. Thanks. So there's a path to scaling over time. But we want to start slow. I mean, doubling is not necessarily slow, but we very much would prefer the the full 256 kb, but understand that that's maybe not the safest, most scalable thing to do today, but very much in favor of it being included for socket, even at the 48 kb. Limit.

Tim Beiko: And I guess maybe just a bit of a sidetrack. But on this question, like. Do you have a sense of the distribution of usefulness like you know how many. When you say you want the 256 like, I assume this means, maybe I don't. Arbitrum can run everything in like a single contract. But then, like, yeah, what benefit do you get from? Like, you know? 48 versus, you know. Say, we doubled it to get the 96 like, are there some? Some yeah, some some numbers, or some like sizes that are just like disproportionately useful.

Allan | Offchain Labs: Yeah. So so one of the big benefits to us is, that a lot of the the rest and C and C plus plus binaries that we run with stylus or the laws mentioned is just naturally larger. So we we would like to. you know, add, you know. certain crates that can blow past 24 kb, once they're optimized. So it would be ideal for us to be able to import more crates like that that, you know. Aren't, you know? Just hand rolled maths. There's also yeah. Other rest elements for the rest contracts on the arbitr stack that we would be able to move on chain more and have a lot of performance benefits, too. So we're we're sort of capped right now. On how much of that we can

deploy on chain without having to, you know, spread it out or scattered across many contracts.

Tim Beiko: Got it. Okay, I'm okay. So I guess I yeah, back to the actual spec changes. So like, I think. it seems like there's no objections on those 3 Prs. Then the question is, about the index. If we do leave it as an implementation detail to clients. As Oscar said. we, we want to have we want to make sure we're not introducing new bottlenecks or or new issues. Even in the case where the gas limit increases. We haven't quite benchmarked this extensively. but yes, Lucas, and seem to have an intuition, for, like what kind of bottlenecks would this cause. And yeah, do you wanna maybe give more context on this.

Dragan Rakita: Maybe I can respond. We will still have additional gas that if the bytecode gets code loaded you will still have that initial gas that you need to spend the while we why, we say the code size in this is optional is because this will not apply for the external code size for external code size. The bytecode is not going to be made warm. It will be always cold. It will be cold after the call. That means that if the bycode is not warm somehow from other opcodes. you will still have need. You still need to account for additional gas. So worst case in this sense is covered.

Tim Beiko: Okay. any other thoughts on this. Otherwise I would lean towards including it in Devnet 3. With these changes, I think. We will benefit from actually getting clients to try and implement this. We can also run, you know, large blocks and spammers on definite 3 or the definite. 3. Version, so, and to on, guys point like by optional, I guess we would leave it at the clients how they implement it. But then we should actually test these implementations and like. large scale devnets. Yeah, I'm sorry.

Ansgar Dietrichs: Yeah, I mean to be clear. I didn't mean we should like. I don't think there's an option where at least not for Fusaka, where we would have an enshrined index in any sense meaning like an actual like state object that would be had a specified structure, and would be committed to or anything, because that's just too big of a lift. So the question really is, just, do we want to mandate that all clients have a version of a kind of of a way to to always get the the contract size that is never worse than, say, loading a 24 kB contract? Or do we basically even leave that choice up to the clients? Because that, I think, impacts quite heavily what what kinds of things we like performance? We're testing and and whatnot. So so I just I was really most asking for that decision. Like, do we do we? Do? We make it mandatory that there is some way of efficiently accessing code size or not.

Tim Beiko: Lucas.

Łukasz Rozmej: So, in my opinion, this is the other way around. We should firstly create some worst case scenarios, benchmark and target some kind of performance, and then see if a client can live without those index, the ones that don't have it, and if they don't, they need to implement it.

Tim Beiko: Yeah. So I guess that would be making it optional.

Ansgar Dietrichs: Right. But then maybe just one more point there, like I I do think then just the the point would be that normally all of. I agree with that process. But all of that would have to happen before I final inclusion decision into the hard phone. Because basically, first, st you get some benchmarks. And then you decide, okay, do you need to have a man index or not to basically then hit the performance targets, but only once you hit the performance targets. Can you make the inclusion decision? We want to make the inclusion decision today. So that means we have to basically already be at basically 100% confidence that we will hit the benchmark requirements that we will eventually have. And the problems right now, we just don't have the data for that yet.

if we are also optimistic that we that we are very confident that we will hit them, we can do that, and then just worst case pull the eap, but it just feels very opinionated.

Łukasz Rozmej: Yes, that was my initial reservation against the Ap. And that we don't have any benchmarks for it, and that's why we were not happy with the next thing, the target with 2 xing. We are pretty sure we will hit decent numbers.

Tim Beiko: I would treat this like, basically any other dos vector in a way like we should, we should include it. And then, if we find in testing that there's like a dos issue or like a performance issue, then we can always remove it. But that's that's true of every IP. And I think at this point, like the main thing we're bottlenecked on is actually getting the clients to implement it and and seeing how that works. So like, if we want any chance of shipping this into Saka. I I think we we basically have to include it. Leave the index optional. and then, yeah, make a call based on the performance numbers and worst case, we will remove it if we if we don't feel that we we can actually

like, yeah, address those issues,

Dragan Rakita: Just say we added new gas to mitigate that potential Ddos. So.

Tim Beiko: Great.

Dragan Rakita: Yeah, it's there.

Tim Beiko: Okay, and then when we'll need to see these new benchmarks. I think once we have Devnet 3 up and running, and it works. In the happy case, then our priority should be to actually do the stress testing. If we can do it in parallel, then great. But it does seem like Devnet 2 is still struggling with some issues. So we we 1st need to get it implemented. Get it, live on Devnet 3, and then we should stress. Test it shortly after. And okay, so any objection to move forward with 7, 9 0, 7 indefinite 3. It's already specified, I believe, since the since the last call. let me just actually double check that real quick, but

almost certain. Yeah. So it was specified on the last call. So I would just add it to definite 3 and flag that we are merging the 3 the 3 prs that that were at the agenda. So that will be the final spec. Yeah, Millen.

Milen Filatov: Yeah, hey? I just have a quick question. Every everything so far sounds good to me. But I was just wondering, do you guys think that there would be a definite 4 and a definite 5? And if there is, I'm wondering. and if we're gonna do all these performance tests and benchmarking. I'm wondering if it's worth leaving the 256 kB unchanged for Devnet 3, so that we can gather.

Tim Beiko: Right I would lean against. I think we should do. 48. And we tried to have definite 3. Be the last def net, and to the extent, there's a definite 4. It's because there's a bug on definite 3 that requires like restarting the definite. But I think we should consider this like the final final spec, and given the concerns around benchmarking and whatnot, I think. I think we do. 48 now and then. and yeah, potentially for the next work, we consider some different design to get us to 56, or making the index mandatory, or something like that. Yeah.

Milen Filatov: Okay. Cool.

Tim Beiko: okay, anything else on 7, 9 0, 7. If not, then. Yeah, let's try to get these Prs merged in the next couple of days. So that we have this the final spec. And we can implement it. Next up we had. We discussed this, I think, on the last couple of calls, but I want to finalize the the Max blobs for transactions in Bpos. So right now they were set they were set up 12, and there was there was set at 12, starting at Bpo. One, and there was conversations about moving it back to 2. yeah, I guess. Do we want to limit this back to 6 again? Move it to 9.

yeah. It would be nice to get to a final decision on this today.

Alexey Osipov: Yeah. I guess. The current proposal is to have it pn 6, right? But.

Tim Beiko: So which proposal? There was no Pr, I guess I know we discussed it. But like, yeah, I couldn't find like Apr or anything. So I guess that's kind of why I wanted to bring it up again. Yeah.

Alexey Osipov: It would be cool to have a inform of Pr, I was asking about this in chat. Maybe it will appear later. This meeting but I guess another cause of not having this pair is because it's in kind of discussion. because we can go even 3 ways. 1st way is to keep for what we already implemented in the current form, and.

Tim Beiko: That's that's the 6, and then 12 for the vpos, as the eip States. Correct by 12. What number do you mean like per transaction. So when you say what's currently implemented, the Eip currently says sticks up to Osaka, and then Bpo, one Bpo, 2 have 12. So is that what the clients already have.

Barnabas Busa: The Erp states that we're gonna use the Max value by default. If you don't re specify.

Tim Beiko: Okay, I see. And so what the clients already have is they use this Max value by default which is which goes from 6 to 12 in the 1st vpo.

Alexey Osipov: Yeah, I guess. this can be split into 2 discussions. 1st one is, how do we actually define this value. Is it a constant in a pure desk eap, and we will not change it in schedule. and whether it is a consensus, a value that affects consensus or just at the expo value. And after that we can decide about specific value. As far as a remember, answer post 6 for Vpr. I guess. But this is seems to me like the second part of discussion. So let me say a couple of parts about the 1st part I still think that it is quite convenient to have this video in both schedule, and to gradually increase it through the forks

Should it affect consensus or not? Right now it it does not affect consensus. Everybody can build blocks with without with limit. defining just by how much blobs we can include in the block and the the initial idea was to limit how much one transaction can includable transition can contain blobs like single transaction. and I see that some clients support the idea is to have it as a text pool limit only. and the I wanted to hear more opinions about that. You guys have anything to say. Is it a taxable limitation for propagation, or we cannot include huge transactions into a block too.

Tim Beiko: Oh, yeah. Francesco.

Francesco D'Amato: Yeah. Personally, I don't really see the point of making it a blood pool. Only thing I I think it should. We should make it. we should have in consensus as well. And the reason is, that if you're not going through the map pool like you're sending directly to to builder. I don't think this is much of any limitation like you can just split. Add multiple transactions, and split them that way. I I don't think it really like. The only thing that it does is that you cannot amortize more. But that's kind of a negligible thing that I don't think we should care about like beyond a certain point, it just doesn't matter. And yeah, and for.

And you do get benefits from. I have any consensus that it's impossible to to kind of send a really large transaction that makes packing much harder. So I I just really don't see the benefits of having it only in the pool, and not in consensus.

Alexey Osipov: Okay, if you guys, anyone wants it to be textual. Only or could you raise your oh. opinion and otherwise. Zone, the question, yeah. Sorry no one. If so. The second question of whether we should place it in blob schedule or just in the product. Api. I right now, I have no strong opinion, because we always can switch back to what schedule settings if we decide to use them. Oh, we're changing this video but for me it seemed that it would be nicer, because it would prioritize, takes full changes towards scalability. And if we could like, keep in mind that we could increase it. Value from fork to fork, and spend some time on it. It would be better for text pool scalability with which we can.

If we have this just as a constant, we can then like deprioritize in some sense this like improvements, potential improvements otherwise it would be very easy and flexible to change it in the future. If we will. Figure out that we can do this, we can make it 1224, 72 in other value. So but the concern that it looks ugly in the blob schedule right, because you need to set value if you don't want to make it. No. I don't think. Yeah. I don't think the concern is just. It looks ugly. It's like we were literally talking about consensus issues based on fork id, because the blob schedule is a bit weird now. So I.

Tim Beiko: I I might be a bit low context on this, but like I really don't see a strong rationale towards making raising that number like I I don't know if 6 or 9 is the right number. I I don't have a strong opinion on that, but I I don't see why we don't just like hard code it. And then, if people feel like it's insufficient, we just change it in the next real hard fork. I I don't think the cost of amortizing beyond, like 6 blobs, is is crazy to ask of of roll ups.

Alexey Osipov: 10 is like 10 times more than what base now uses. They use like one, and point.

Barnabas Busa: Not in a single transaction. They they don't care if it's in a single transaction or in.

Tim Beiko: Yeah, exactly. They have to pay what it's like, 21,000 gas difference, basically. Maybe a bit more, because they have to call like the contract. But like, I, yeah, and.

Alexey Osipov: Oh!

Tim Beiko: And like, yeah, if the if the limit is, if the limit is 9 today, then like, yeah, maybe we just leave it at 9. We don't necessarily need to like we don't necessarily need to to lower it. I I don't have a super strong view there, but I guess I do have a relatively strong view that we this doesn't seem like we're a worthwhile place to introduce complexity.

Alexey Osipov: We don't need a lot of blocks in one transaction.

Tim Beiko: I guess, to your point about the specs where this is maybe a dumb question. But, like, where is this value currently specified? Like? Is it in the? Is it in the blob extension eip from Petra that specifies the cap? Sorry.

Barnabas Busa: It's gonna be Po yet.

Tim Beiko: No, I mean but on my net now.

Alexey Osipov: And I I think it's just specified as a text pool limit in some implementations. And and the.

Tim Beiko: No, there is no limit on Mainnet today. Okay.

Roman: There is a limit which is the maximum you can have per block. Technically.

Tim Beiko: Could. Oh, right? Right? Yeah, yeah. Okay. So there's no transaction limit. Vip, only block. I see.

Alexey Osipov: Yeah. And I just wanted to mention about 9 which is another topic. Why, 9 is better, because, you know, do not need to take care of eviction of such transactions when Osaka happens. Because we had limit 9 before then it became 6, and you need to remove it from a transaction pool and take care of block building for this specific block, you know. Because we we had such case when we could build a block, we fixed it, but we could build a block with a big number of blocks in transaction, because we did not evict it. And yeah.

Tim Beiko: Yeah. So I guess the question then is like, yeah, do we? It seems like, we probably do want a limit in consensus now. So we're gonna have to add this, no matter what I guess I don't know on guard. What is the decision we made 2 weeks ago.

Ansgar Dietrichs: Well, I mean.

Tim Beiko: On Monday. It didn't seem it didn't seem super clear to people. Yeah.

Ansgar Dietrichs: No. 2 weeks ago, we said we moved the per transaction limit out of the Bpo specification just into the and set it to 6. And I mean again, that's just an arbitrary choice. We can totally make a different choice. But like I don't know, it's like.

Tim Beiko: Yeah, I guess I'm yeah. I'm fine with that. If we agree to that, then there's no objection. It just seemed on Monday people were still discussing off this call. But yes, does anyone oppose this? And if if not like, can we just open the Pr after this call? Okay. The issue was that nobody actually made the change. so does anyone want to volunteer to open those Cprs. I guess anyone who's implemented peer peered us on the El side. Get someone do that. Pr.

Alexey Osipov: Let's ask in the chat, probably to to agree.

Tim Beiko: 10 years.

Alexey Osipov: This and you do it 3 or 2 yeah, I can. But I already did this. And maybe it. The details were not not obvious enough to decline it.

Tim Beiko: I'm sorry. Did did you actually have an open Pr, because I could not find one.

Alexey Osipov: No, no, I might block schedule changes. Okay, let me do this simply.

Tim Beiko: Okay, amazing. So yeah, so the Pr would be to remove this Max blob per transaction. constant from the eip. 7, 8, 9 2 to add a cap in the pier. Peer cip for 6 and yes, sorry if this is not your favorite choice, but thank you in advance for for making the Pr. There was an other comment in the chat that came up by Lewis. Or sorry. No, I forget who but as we were talking about keeping the specs simple for the vpo sorry, Gabriel said, that we should consider removing base fee update fraction from Vpos and only have the target. And Max, because effectively, from Osaka, it's it's like a stable. So this would mean that if we want to change the base fee update fraction. We need another real hard fork.

The people think we should also do that change to make ppos simpler. Barnabas says, yes, Gabriel says yes. Is there some reason to remove the feature when we already have it? I guess it's just to limit the risks of consensus changes and consensus issues. where is that specified? Here.

Parithosh Jayanthi: Well, the only kind of question is, if we ship Fusa, and we do the analysis, and we decide that we want Ppo value that doesn't have the same ratio. Then we won't be able to right. So we kind of limit what.

Tim Beiko: Well, what?

Parithosh Jayanthi: We can choose in the future.

Tim Beiko: Well, when we ship from Saka we have to choose that value right? And then what we're saying is that we would not change that value before the next quote real unfold. Hard fork. Sorry. So so we could ship. You know, Fusaka, we're Gonna say, these are all the Bpos. They all have the same ratio, and then for a future fork. Either we choose to change that ratio for all of the Bpos, or we choose to reintroduce this. it's fine. It it's fine to to leave it in. But like, yeah, it's just like another source of complexity. Yeah, on scar.

Ansgar Dietrichs: Yeah, I would. I would personally prefer to leave it in unless clients have that as a pain point specifically, that this this specific extra value has caused issues because it is very convenient to be able to to basically have that extra lever where, if we feel like, we want to get a little bit more throughput. But we, we are already at the maximum. The network can handle that. We can basically in principle, if if the data support supports that that we have a little bit more room to go, and just squeezing that ratio a bit more. It just yeah. It feels like in the spirit of of of Bpos to to be able to have that configurable but.

Tim Beiko: Do we want this in the 1st iteration of Vp, like, do we think we're gonna well, I mean. yeah.

Ansgar Dietrichs: Meaning. Do we want to use this Pre Amsterdam? Right? But because it could be that like, it's not in the 1st Bpo that comes with Fusaka, but it could be that we we then have a later client release. That's basically Bpo, 2, 3, 4, that that still comes. Pre Amsterdam, and I do think there's a chance we might want to do it in there. No.

Parithosh Jayanthi: Yeah, and also just adding onto that, we might run into this weird situation in the future when we do change it. Where clients then need to have extra logic that says, for Bpo, 1, 2, 3, use the base fee, update fraction from Prague, but for 5, 6, 7, use it from Amsterdam. And at that point you basically come back to just defining it in the blob schedule because you need that mapping between Bpo and Blob schedule. Anyway.

Tim Beiko: Okay, okay, I think this convinces me. So I think we leave this as is. And if it does become a pain point, we can reconsider removing it. And so for now, okay, let's just stick with the previous decision. We remove the Max Blobs per transaction from the Bpo config, and we add a cap of 6 per transaction in the pure desk. Spec. Anything else on peer to us or Bpo's? Okay. Next up. Then there was an update on MoD. Exp, where Marson said that it still poses some issue performance wise at higher gas limits. And there's 2 paths to dealing with this. Either we do a bunch of client optimizations or we potentially just radically increase the price where we where we triple the price of MoD exp. So there was a pr for this.

I don't know if Marcin is on the call, and so do you want to give some more context, on on the work you've done.

Marcin Sobczak: Yeah, yes, sure. So. I think like our target after Fusaka is to be ready for 100 million cost limit. And unfortunately, with 8, 7, 8, 8, 3 in current shape and with current clients implementations that we can't do this. Because you can take a look at the graph. I I posted it it in issue of this meeting. and Ref, never mind and bezel are per performing good enough but we have, and argon with worst modex cases. After repricing at 26 mega gas per second, when 33 is the minimum requirement for for going to 100 million gas limit. And at this point we can, we have to try. We have a we have a choice to try to improve clients, or to increase modex pricing even more.

And if we exclude modex and look at other bottlenecks, and then there are, of course, some clients, specific bottlenecks, but on protocol level the next blocker is easy recovery and easy mall, and they are performing at about 50 to 55 megabits per second, and we would like to avoid the situation when we reprise Modex, and it will become a bottleneck again after Fussaka. So if you want to avoid it, we need it to perform at least at this level of 50 to 55 megabits per second. And right now we have 2 clients at 26, so they would need to double the performance. And why, there are so big differences between clients so in Ref. And never mind this, this client are using very fast library in Gmp. And it is because they are so fast and it might not be

not be a good idea to force our clients to to move to to the same library, and probably it's better for protocol in general to have it more diversified. But then the the question is, if it is possible to to move performance to be twice faster. And if it is possible it's great, but if not, we need to increase the the prices again. And I pass 7, 8, 8, 3 in current shape, and it. It was designed to have the lowest possible impact on the calls. So in current form. it's affecting only 38% of calls. And we already know the addresses which are affected. There is a great report made by Tony about the impact of of this, and all the edge cases are already already addressed.

So if we want to increase prices more, then we just need to do like a general price increase. So then, 100% of calls and 100% of users will be affected. And if we will affect all users, then we can probably go pricey and just triple the price, because everyone will be affected in a way. So at the end. Hmm, that I left everyone with the question, what we want to do we can try to to improve gaff and argon, but it will require doubling the perf the speed of the worst case of modex, or we need to reprice modex more. But then all the users will be affected. Yeah, thank you.

Tim Beiko: Thanks for sharing Milan.

Milen Filatov: Yeah. Hi, I just wanted to mention quickly on that note that we are experimenting with improving the performance. For modex at the moment. And it's without gmp. but we probably need, like maybe a few more days, to actually see the outcome of this. So if if, if, like, a few more days is is okay, then we can provide some, input then on this.

Tim Beiko: Okay, And then, yeah, I asked who would be most affected if we could. if we were to reprice this and it seems like it's been hard to get some numbers out of out of dune for like, what are the biggest users of this free compile. Oh, matter! Labs seems to be one of them. I guess. Given. This is like a relatively small change spec wise, and I expect we still probably have a couple of weeks before launching definite 3. Does it make sense to spend the next 2 weeks actually investigating this more deeply? And then making a final call before the definite 3, the definite 3 launch.

I guess. Okay. On guard. As a question like, are we certain we're gonna have another acde before launching Devnet 3. I guess. Based on the the reports of W. 2 today. I expect we're probably not going to launch Devnet 3 this week or next week. But I don't know is that is that potentially off? Yeah, Felix.

Felix Lange: No, I just sorry, maybe. But off topic, I just want to say that, like within Geth, we are definitely investigating the performance increase in terms of just like improving the performance of the implementation. But I also think that it would be wise to just like slightly overprice the MoD. Xp, anyways, because, yeah, maybe we missed something or so might actually be a good idea to just go with the higher price if it makes no difference, after all. I mean, we have to see it can't be unreasonably like can't be priced unreasonably high, but if it doesn't make that much of a difference. We might as well just do it.

Tim Beiko: Yeah. And I guess what we would want to figure out is, is there any application that breaks at a 3 x price from odd. Xp are there any applications that become kind of cost? Prohibitive? And so it seems like Maris listed a few like matter labs coinbase smart wallet Eigenda. So maybe we can reach out to those in the next week. yeah, get their thoughts. And potentially, we could also just finalize this on Acdc next week, even though it's not a Cl. Topic. But if we want to move fast and not not worth delaying. Demo 3 That seems like a reasonable path forward.

Parithosh Jayanthi: Could we make a plan as to what the open questions are? And who's gonna be investigating them?

Tim Beiko: So I guess the one question I would have on the pricing is just if we if we reach out to like, you know, say, these 3 and potentially other large users that precompile asking them with a 3 x with a 3 x price increase of this precompile. If it let if it led us to being able to raise a gas so that significantly make a difference for you. I think that's like something we can ask those 3. I'm happy to own that, I guess, on the library benchmarking. I'm less sure what the actual next steps would be.

Felix Lange: We were on it with the, with the with the library stuff like. That's the thing we.

Tim Beiko: Yeah.

Felix Lange: There's like changes being investigated. And I mean. yeah, we can in the other thing to know is that we only ever really worry about MoD exp in the context of like worst cases. So like worst case attacks, we're not really seeing that like blocks are being filled with the MoD exp right now. So the other thing we could do is kind of just like implement gmp, as a kind of optional back end or something like that. But it will. It will have some technical downsides. But it's something that we could do where basically, we will have the option of activating it at if we need to, or something like that. But I would strongly prefer to try to have at least like 2 implementations of this function

somehow, like, if it's fine if it's Gmp. And one other one, I think that would be good enough.

Tim Beiko: I'm Anskar.

Ansgar Dietrichs: Yeah, on the on the question of like, basically reaching out to people or what to investigate. I personally think if we are serious about scaling, which I think we are then coming up like in Glamsterdam, at the latest, and then the fox. Afterwards we will probably have to make very at least we will have to be comfortable with starting to make decisions that are a bit more breaking. Some use cases, or basically just in general, a bit more disruptive, because that just comes with the territory like we will have to change the evm a bit more in general, and the execution system. I feel like this is a very mild case. If we already have concerns here, I feel like that. The entire kind of project seems doubtful. So I, personally would actually say, we should just go ahead and make this decision as a bit of a just

getting used to settling the tone that basically people have to expect that occasionally prices change and prices change in like mildly disruptive ways, and there's no way around it. And that's just the cost of actually going to higher throughput. So I would personally just prefer to make make that decision today.

Tim Beiko: Okay, let's do some. And then, yeah, we can see if we want to do this and commit to it now. But yeah, some.

Somnath Banerjee: Question to get actually, have you guys shipped the improvements in a release? Or are you planning to move Release it, because Arizon and I think get had initially gotten some improvements with knock. But the latest libraries for Ec. Stuff isn't really audited fully.

Felix Lange: Hmm, so yeah, there was a problem with the. So we disabled it again. But I think it's I have to actually check if we if we chipped. enabling it again. So basically, we enabled it for a short time. Then we disabled it because of some like bug and then. So now we have to check it back. If it's like.

Somnath Banerjee: Yeah. So the issue was, some kind of encoding on the 1st bite or something. But.

Felix Lange: Yeah. Yes. Okay.

Somnath Banerjee: Yes, the point I'm trying to make is enabling that because you disabled it, you know you had one reason to. There might be more reasons to disable it. If you don't go for the audit. So chasing performance may have security issues just like this. And it's only that we saw in the perf net that we were able to get these performance gains with the switched library that we are now discussing modex but otherwise would we would be discussing the Ec. Precompiles on this call. So maybe it's worth revisiting that as well. Which would mean, repricing may just be the way to go if you want to bank on the battle tested. Libraries we've been using in the Evm for for so many years, and not really

be enthusiastic about switching them all just to fit the same cost for those.

Felix Lange: That's actually a good point, especially with Canarq. So basically, your point is that all the clients use Canarq. Now for this, for these preconfers or.

Somnath Banerjee: I just get an arrogant. But the point is, Ju, just because we saw the performance improvements. I don't think we're in a position to make releases in the next 2 weeks on that. And that would mean that it's not battle tested. Even if we do you know, even if we take the risk, which is kind of big? So I would say. If you want a higher limit just raise the prices. Assuming the bad performance of the libraries we have been using over the years which you know, for easy add. The performance, I remember, was like 13 mega gas. So if we are not comfortable, say by the next devnet that we want, which you know. By the way, I'm not because, you know, we have to do some internal analysis on our side as well. We have made some releases since then, but none of them have this connect switch

and even if we are able to get some performance gains with more decks. I'm not sure we should just not reprice anything and just claim that you know the performance is great. So now we are good to go. So repricing should be the way to go for Fussaka.

Tim Beiko: But I don't know who iphone is, but.

Kev: Oh, sorry I forgot to rename. Yeah, I was just gonna say that I think that Gaff and probably Aragon rely on Ganak already, just because of the Kg precompile.

Somnath Banerjee: It's the audit covering those. And the easy stuff was different.

Kev: well, to do the Kg precompile, you need sort of a curve underneath, right? Like Bls. 12 freight one. So like it's it's the same like, yeah, it's like the same code. It's just that we have a library on top of it for Kg, precompile.

Tim Beiko: Okay, so. but I guess yeah, based just on the previous comments. Like, if if we don't feel confident in in relying on the libraries, at least. Now, like, I guess. Yeah, is there any downside? Is there any significant downside to accepting the the. the the price increase now and again, if our if our confidence really increases that we don't need to do this, we can always walk it back. But just in terms of finalizing the specs for Fusaka, I would. I would probably lead towards I would probably need towards moving forward with the repricing and having that indemnant 3. Yeah. So I guess any objections to including that. Pr to 3 x MoD, dxp gas price.

Okay, then, let's get this merged. I'll also reach out to the 3 projects we listed to. Just see if they have any kind of concerns that come up. After this. But let's assume we're moving forward with this. And we'd include this change for Defnet 3. Okay, I think this was the last Fussaka issue to cover today. Anything else before we move on. Oh, Spencer actually had 2. So okay, we agreed to change the Blob base cost in 7 9, 18 on the last acde, 7, 9, 18. did anyone open that pr.

if not, is anyone. Can anyone just make that change? Okay, Francesco is, gonna do the the 7 9 18? Pr, thank you. and then, for 7, 9, 5, 1 repricings. Does anyone have context on this one? I actually don't quite remember this one. Yeah, does anyone have context on the 7, 9, 5, 1, the 7, 2, 1, the the r, 1 curve repricing.

Marius van der Wijden: I don't have much contact. No one is picking up. I can. I can say that I think the last benchmark we did. It felt like it was also underpriced compared to other pre compiles, and we should also consider repricing it. Think the number we kind of look that was 2 x price. But yeah, I've kind of low contacts on this as well.

Tim Beiko: Okay? So yeah, I was, gonna say, if we don't have more data to prove it's safe lower, we should just 2 x the price. this. Does anyone have an objection to that? If not that thing, then yes, we should just move forward and and hopefully get to a final pricing scheme today. so does anyone want to open a Pr to 2 x the price of that one.

Marius van der Wijden: Let's do it.

Tim Beiko: Okay, thank you. Okay. Any other Fusaka related issues people want to bring up. Okay? Then, moving on to Glamsterdam, so we've had many different headliners being proposed for for Glamsterdam. The deadline for the proposals was June 20, th and I don't think that we've seen any new proposals since then, at least, I I haven't so I think we've we're pretty good in terms of freezing the like proposals for to Amsterdam headliners. But originally we said that we would make a final decision 2 weeks from now. That does seem quite premature. So I I want to ask client teams like.

what's the amount of time you think we need to actually review this have, like a proper discussion around the different candidates, headliners? My senses. We need at least a month potentially more. But yeah, how the client teams feel about this? Yeah, Andrew.

Andrew Ashikhmin: Yeah, I don't speak for Aragon. I don't think we've collected Aragon's point of view, but personally, I think we should go for the block access list. It helps a lot with parallelization, especially in the worst case, and I think parallelization is crucial for achieving a scalability of ethereum.

Tim Beiko: Got it? And yeah, I guess to Luke's comment, like, yeah, I think we should consider the the proposals being closed. And it's more a question of like. how much time do people need to actually review this? And how many discussions we want to have on on Acd about it? and my instinct is like we probably need at least like 2 calls or something like and and I expect we could probably spend a big chunk of the next call on this. but I, yeah, I this, this assumes that client team actually have time to start looking into this. yeah, before the next. The next calls. and yeah, it's possible that the next 2 weeks are spent on like Devnet 3. So I,

if if we, if we assume that that it meant, you know, like July 17, we finalized them at 3. Then, like on the 31st of July and the 15th of August. We would like spend time looking into these headliners, at least for the for the for the el side, and I think this also gives us enough heads up to like reach out to the rest of the community. And get their thoughts on this. so yeah, I guess maybe. Yeah. This is my proposal is that we we kind of focus on them the 3 in the next call. So July 17.th And then the 2 calls after that. We. We try to sort through at least the El side of the headliners, and then teams can start start reviewing them.

you know. In the meantime. We can obviously discuss them on these magicians. And if there's stuff that comes up we can do so on these calls. But we can kind of proactively mark these 2 calls as as when we would discuss it, when we would want community input to come in by and and whatnot And then the okay, miss question. I think we would want to only sort out all the other eips once we've actually chosen the the headliner. Because otherwise. Yeah, it's kind of hard to make decisions about the small features if we don't know what the big feature is already. And yeah. So just to be like, really explicit. So in terms of the schedule like July 17, th in 2 weeks, we would just focus on them the 3 in Fusaka, wrapping that up and then, like the 2 main calls we would use to discuss the El Headliners would be August 31st and

oh, sorry. July 31st and August 14, th And yeah, on that note. And Nick, so you had a comment about forecast, do you? Wanna you want to give a quick overview of it.

Nixo: Sure happy to. So Mark and I have been working on this resource. It's forecast.org and basically it just shows the main benefits of every eip, and also how stakeholders are affected. And we would love input from any any interested parties in the Eip. We already got most of the Eip authors to look over, except, I think, except for one eip. But yeah, we would love feedback on that. Or if anybody has ideas for additional features that might be useful to help compare across these. There's also a Fusaka page, but we would like to focus on Glamsterdam just to be a good resource for people to look at the headliners and really understand what those headliners are.

Tim Beiko: Yeah. thanks. And yeah, this is a really cool tool. So if you have feedback on it, please reach out to Mixo or mark, and they will keep improving it. But they already have all the different headliners for the that have been proposed listed there. Okay. And so the for the other eips in Amsterdam. I think we should wait, like, I said, to to have a headliner before we make a call on them. So Guillaume had proposed this, adding a code chunking eip to Amsterdam but then we also have Cfi, a bunch of eips for Amsterdam really early on that were mostly vertical, related. So my proposal would be that we move both those vertical related eips, and also the code chunking eip and any other eip that wants to be proposed as a not headliner just to the Pfi list, so anyone can open a Pr. We can start tracking them. But we don't quite make a decision about them yet. And then, once we actually have the decision on the headliner, then we review this like long.

long tail of of smaller vips, and and decide which ones can fill in. I guess. First, st the people generally agree. This makes sense, and then second. second, like, is it okay to move the previously Cfi vips from like the old process back to Pfi, because I I don't think we actually add pfi. When we move those to Cfi.

Guillaume Ballet: Which which Ips are we talking about like the the. Ones.

Tim Beiko: I posted the Pr. It's more than 2. It was state 4, 7, 6, 2. The statelessness gas cost changes 6,800 the vertical, 1, 6, 8, 7, 3. Pre image, retention, 7, 5, 4, 5, vertical proof, verification, precompile, and 7, 6, 6, 7 raised the cost of hash functions. So all of these were like Cfi before we actually had efi kind of status and

Guillaume Ballet: The pre compile one. I think it should be withdrawn or abandoned because I thought it was actually 4, 7, 6, 2. Yeah. Makes no sense in Glamsterdam, 6,800 should be withdrawn, so no need to move them anywhere the Hashing one. I don't think it's mine or mine or my teams? Yeah. Did we cover them all.

Tim Beiko: So yeah, stateless gas cost change. I mean, if you wanna just look at the Pr, if you if you think it's fine to just remove them all. Just leave a comment on the Pr. And I'll do that.

Guillaume Ballet: Okay, yeah. I just saw you here. Okay, I can leave a comment. But yeah, most of them are need to be gone. And one of them, like the 4, 7, 6, 2 needs to be saved for later.

Tim Beiko: Yeah, okay, perfect. Yeah. And then, yeah. So for guille for your next eip. Then I would just, I would just open a Pr. Against the Amsterdam Meta eip. Add it to the Pfi list, and then once we're ready to discuss those after the the headliners, we'll discuss it then, and I'll be the others people can obviously start discussing it Async in the meantime. But yeah, this allows us.

Guillaume Ballet: Sorry you mean 2029, 26.

Tim Beiko: Correct. Yeah.

Guillaume Ballet: Okay.

Tim Beiko: Yep, And then yes, there was one last question about the deadline for pfi and small vips. We also had a deadline for this, but I think I I didn't. Wanna set this given this revised date. I think it's fine to discuss this in the next 2 weeks or Async. But I we should have a deadline, it should be after we've chosen the headliner. So so so yeah, like, I don't. I know when we want to have this. But I yeah, I think a month or 2 after the headliners were chosen. and so I don't. I think it's fine to wait for the Pfi deadline for the next call. We've agreed on like when the headliners should come.

And then on the point of multiple headliners. Historically. we've never succeeded at that. So I would have a very strong bias against it. But it's possible that, like there's exceptions here. But the whole point is saying, like, what is the most important thing we wanted to fork. And what would you want to like? Build the fork around? And the only time we ever tried to do this with 2 things was the original version of Petra, and I went pretty porty, so I I I think we should try to stick to one as as much as we can. Yes, if we aim for a quick, small fork, we'll get a regular sized medium time fork. Okay? So just to recap. Yeah, headliner discussions focused on or focused on the July 31st and August 14th call. We'll figure out the deadlines for the

for for the other the other stage of the process after and then we can move these other vips to either pfi or remove them if they're no longer relevant. Anything else on capsdam. Okay? Then Matt had some history. Ex fiery updates. yes. Do you want to give some context on the error file.

Lightclient (Matt Garnett): Yeah, sure. So there's 2 quick things I want to touch on. The 1st is this error, e-file format, which I linked to on the Pm. Repo. I will share a link here as well. Basically the motivation for this is the error. One file format. We sort of designed this several years ago, with the intention that arrow one would always and only be for the information that was before the merge, and we had thought that we would go for the post merge data, using this file format that already existed on the consensus layer, which was just error. And over time of the last year or so. We've kind of realized that maybe it makes sense for execution layer and consensus layer to have different file formats.

If you're an execution layer, and you were trying to bootstrap an archive node. You don't necessarily want to download all of the Beacon state data, and whatever else that the error file might have that, you know, the consistent layer file might have that allows them to do debugging. And so when we were in Berlin a few weeks ago, we sat down with some of the people, and we talked about what an execution! Only error file would look like. and it looks very similar to how era one looks like. With a couple notable exceptions, I'll just give you the footnotes of it. But the specification will go over in detail the things that changed the most important things that changed is that instead of storing the values per block sequentially meaning storing the header, followed by the body, followed by the receipts

we now store all of the headers, all of the bodies, all of the receipts. This allows for us to do to respond to range queries more efficiently for syncing. We also changed the receipt format because most people don't actually store the 2718 receipt format. And so we've stored it in like a more optimal way. And then we've added a proof format which is kind of optional for error E, but allows. if included, for anyone, to verify any block within the error E file against some historical root in the consensus layer. So it still kind of gives this like good verifiable property. So the area E file. This is kind of like my proposed specification. I would love to get some feedback on this over the next couple weeks. Basically, what we want to do now is that we've we've kind of done this pre-merge history, expiry and clients support this.

and we'll talk about like defaults in a second. But we also want to continue expiring history, and we're working towards rolling history. Expire. This is kind of the golden standard, the thing that we, you know, once we achieve this, and we can say that like history expires. kind of finished. But before then there's still a lot of data between the pre-merge history and the moment when Rollops began to use blobs. So Eric E. Is kind of the the one thing in our way from really going from pre-merge history expiry to expiring up to the Cancun hard Fork. So that's kind of why I'm like trying to get feedback on this and iterate on this pretty quickly is because the faster that we can get sorted out, the faster we can generate the files the faster we can start having people serve and store these files, and the faster we can begin expiring history post merge up to Cancun

and potentially before. But basically, I just want to get agreements on this file format. And then once we agree and we generate the files for the history it's up to clients to kind of decide what they're comfortable with. If clients don't feel comfortable pruning history beyond the merge. That's fine. I know some clients are really are really hoping to do this sooner than later, so we want to make sure that it is going to be possible for them to do that as soon as possible. So my goal is by the end of July. We agree on this area e format. And in parallel, we're kind of working on implementation. But the expectation is that once we agree on this file format, it shouldn't take more than a few weeks to complete the implementation. Generate the files, share the files, and we could kind of say, All right, if clients want to start expiring up to Cancun. Then that's okay. It's their decision.

So that's era E files. Are there any questions or comments on that? See? Storm asked if receipts are optional right now, receipts are not optional in the error. E file format. Okay.

Tim Beiko: White. We have so many error formats.

Lightclient (Matt Garnett): This is the yeah. Maybe I kind of like glossed over this. But this error format is the one to rule them all for the execution layer. So arrow one we I mean we we. It came up with Era one when we were in Austria several years ago. and, like I said at the time we felt that error. One was just this one thing we needed to do to then unlock execution clients to use error files. But over time we realized that the error file just wasn't quite the right fit for what the execution layer needed. It's not the execution layer can't even generate the error file itself by itself because it needs the consensus layer data as well. So what we want to do is we want to migrate to era E over a period of time.

So eventually, when clients are. you know, implemented error E, they can begin to deprecate area one, and move off of that file format. Well, arrow one kind of refer to Eth one. And so it's sort of weird that it would also refer to era post merge, too.

Tim Beiko: Oh, yeah, aside from the naming convention. any other questions. Okay, so yeah, questions around the receipts. We can probably discuss that, I think where's the best place to talk about this? Do you think.

Lightclient (Matt Garnett): I think there's a channel called History Expiry in the R. And D. Discord.

Tim Beiko: Okay.

Lightclient (Matt Garnett): That would.

Tim Beiko: So.

Lightclient (Matt Garnett): Yeah, there is. So I think that's a good place. Also. Execution. Dev, I read that channel just tag me anywhere.

Tim Beiko: Okay, so let's at least have the conversation around the receipts being optional or not. And yeah, when would we need to make a final call on this.

Lightclient (Matt Garnett): I think we have 2 more execution layers of meetings Acds before we should, so not the next one but the one after we should probably be wrapping up any discussion and kind of say, this is the format.

Tim Beiko: Okay? And I guess this kind of brings us to our your last point around like dropping pre merge history by default. when should we do that? Do we want to couple this with Fusaka? Before that? Or, yeah.

Lightclient (Matt Garnett): Yeah. So there's a blog post going out this this week or early next week. I've been in touch with all the client teams about this, so most are aware. But we're going to kind of announce that this partial history, expiry, aspect of history. Expiry is is possible now, and in Berlin a couple weeks ago. I mentioned that because of the work that everyone's done around implementing E. 69 implementing the era, one format that I felt comfortable, saying, it's okay for clients to start making it a default to not download the history. I think Baysu, in the latest release, now makes a default for snap guns. Yeah. So I think some clients are beginning to do this.

I just wanted to get a temperature check on if people still feel it's okay, or and also here, like which clients are doing this or intend to do it, and just getting a rough idea of what people's timelines are.

Tim Beiko: I'm rest, Aragon. Never mind anyone. Some topics on this.

Andrew Ashikhmin: Yes, so we are making a release tomorrow that supports it, and that I be. I think it's enabled by default. Please correct me if I'm wrong. But yeah, I think we are dropping them by default.

Tim Beiko: Great, neither mind. And Russ. And then the lines ready. Okay? Awesome. And yeah, that. But oh. okay. Roman checking, but should be able to support it. So great. That's if people could just confirm that on the history expiry channel as well in the next day or so, that'd be great. but yeah, it seems like we should be able to make this a default across all the clients quite soon. Sorry. Do you have anything else at times.

Lightclient (Matt Garnett): I was just gonna say that it is kind of clients decision. I think it is okay to do this. But we're fortunately past the point where we need to move in lockstep. And that was kind of a big goal that I mentioned in Berlin is that we're trying to figure out the things that require group agreement and moving together, and that was doing a 69 waiting until after we stopped relying on receipts for generating the merge genesis. So that is all complete. And then for the error E, we all need to sort of agree on this file format. But once these types of things get done, then it's on the clients to implement it at their convenience, and I know that, like not, every client has the same bandwidth at the same time. And so that's kind of why it's okay for you to make a release, to drop the history when it makes sense for your client.

Tim Beiko: Okay, I think we could wrap up here anything else before that? Well, thank you. Everyone. Yeah, we'll talk to you all on Monday's testing call. And I'll share a summary of of all of this call and the action items in the chat a bit later today. Yeah.

Lightclient (Matt Garnett): All right, thanks, all.

Andrew Ashikhmin: Thank you. Bye-bye.

Jochem Brouwer: Bye, guys.

Łukasz Rozmej: Bye.

Marius van der Wijden: Nice.

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