All Core Devs - Execution #213

Transcript

Tim Beiko: Okay? Josh, you want to move us over to the live stream.

Josh Davis: Here you are, live.

Tim Beiko: Okay, thank you. Welcome to acde number 2 13. I've posted a link to the agenda in the chat here. couple of things to discuss today. So on the Fussaka front. There are a few things that came out of the testing call that we should touch on so around the gas limit, and then some bon xp questions. Then for the finalization of the scope we discussed making some changes to rip 7, 2, 1, 2, last call which are in progress, and then wanted to finalize the set of list. The set of eips for that 2. So do those. And then continuing from last week we started discussing potential headliners for Amsterdam. So there were a few El related ones that had been proposed

that we we should cover there are also other eips that have started to be proposed, I think. We probably shouldn't take time on the call to discuss them unless anyone feels very strongly about it. But it's probably best to to stay focused on the the actual fork headliners for now And then, just as a heads up as well the next week, because of the in person meetings we'll cancel the calls, and I will be out in 2 weeks, and Onstar will be taking over for Acbe but just to kick things off. So on acd Monday there was a discussion about raising the gas limit, and and kind of testing it on 60 million on Hoodie, and then moving to Mainnet and after that I know there's some follow up conversations about like what the right approach should be to actually increase it? And are there things we want to see or or like potential blockers there? So if someone might want to recap kind of the

the outcome. That discussion, and what the open questions were about, like actually moving forward with this on Mainnet.

Parithosh Jayanthi: Yeah, I can give a brief update. So on Monday, on Acd, we asked client teams if they saw any other blockers before we started to signal raising the gas limit on on Mainnet for 60 million. However, I mean in the last couple of days. I think once we started planning for Bell interrupt. We realized that we're going to be doing a lot of work on gas limit performance testing, anyway. So in in my opinion, we probably should wait to make a decision until that track is done, and by the end of next week we'll have a better idea about what our scaling limits are what? We? We would have a few more eyes from from

on the gas limit, from a security perspective, and so on, and then probably the acdt. The week after we can make a call on how we want to increase the gas limit.

Tim Beiko: And there's a question in the chat. Yeah, about the intention around either jumping to 60 million straights or having some intermediate steps so I don't know if yeah, is that basically what we're hoping to figure out in the next week or so.

Parithosh Jayanthi: Yeah, I think that would be one of the discussion points. I don't really see any problem with doing intermediate steps other than coordination overhead. I think it takes us quite a bit of time to go through the gas limit increase process. So yeah, I think we should try to prevent as many steps as possible, but at the same time not have the steps too granular.

Tim Beiko: Thanks. Anyone else. Have thoughts, comments on this. Yeah, Micah.

Micah Zoltu: So the testing team appears to have done a great job of digging into digging very deeply into whether or not stakers will run into problems with the high gas limit which I think again, I want to acknowledge that excellent work. But I still haven't seen any research or discussion into how the gas limit affects other participants in the ethereum network. It seems everybody's focused on stakers and builders, and no one has even talked about Rpc. Providers, or, even more importantly, in my opinion, people who are running their own local Rpc. Clients, and how this affects them. I think the storage issue affects those people far more than affects people who are paid providers, and these are end users who, you know, hopefully, are running ethereum on their home computers. I've talked to a handful of people just ethereum developers across the ecosystem over the last few weeks.

and there seems to be a lot of divergence in whether or not. We care whether people can run ethereum at home. There's some people, you know. Dankratt is very forward with this, and I very much appreciate how candid he is where he says, you know, he doesn't think that ethereum needs to be a tool that people can run on their computers at home, and that's acceptable. And there are other people in the developer community who seem to think that they should be able to run clients on home computers. And so it seems like there is a a mismatch between. Whether who we're targeting? Do we care? The question I would like to see answered very clearly is, does do the ethereum core devs. And as a group

want people to be able to run ethereum at home on their just home computers? Or is that something that we're no longer targeting. It used to be a target back in the day. And there's again some subset that don't think it's a target anymore. And these gas limit changes will affect that. And so I would just like to see more discussion and research into how this affects people. Besides stakers and block builders.

Tim Beiko: So I guess like, yes, there's a there's a difference between stakers. Block builders are just like node operators who want to validate the chain running at home versus running a full on Rpc service, which is by definition, like resource, more resource, intensive. we had, I don't know. Like, yeah, I was gonna post in the chat. We have this eip that attempted to define some of these constraints eip 7, 8 70 and I think throughout this discussion, like A did not come up, that, like we should optimize for home. Rpc providers, and so I I feel like this is probably the right like I don't know distillation in a way of the opinion like we should serve like people running their local node. Obviously, you need to be able to make local Rpc calls to that node. But I think when you start to go into like running a kind of high usage

endpoints that's potentially used by others that feels like like like that that feels like a comp like a qualitatively different thing.

Micah Zoltu: Yes, it definitely does the we. the there's there's 3 or 4 different demographics, right? You've got the block builders you've got, which. based on the research roadmap sounds like block builders are expecting to be super high end data center type hardware, you know, doing zk proofs. Yada, Yada, Yada, you have validators. Who are. We still want to support home quote unquote home stakers. These are people who, you know, can put a lot of money into building machines and whatnot. And they have hardware, but maybe not a data center. And then you have Rpc providers again, probably data centers. And the the last group is the group. Again. It used to be a group of people who

existed and dominated the ethereum ecosystem and have basically disappeared as anchor had mentioned in chat here, which is people who just run ethereum on their home computers. They do not buy extra hardware. They do not go to the store. They do not.

Tim Beiko: Right.

Micah Zoltu: Spend a lot of time thinking about ethereum. They just double, click an installer, run it and it runs in the background. Baysu has a thing in their client where you can run a flat database. This is a somewhat trusted system, though it could be made trustless with some additional R&D, and this runs in, I think they said 50 or sorry. 80 GB ish right now for the full state. and so in under 100 GB. You can run an ethereum node today, and with additional R&D work from ethereum core devs. We could make that possible in a trustless way as we increase the gas limit that increases the rate at which that 80 GB grows. Now, we're not talking about 80 GB plus 3 GB a month. We're talking about 80 GB plus 6 GB a month, and that adds up real quick. And so yes, 3 GB a month of state growth. You're looking at one or 2 TB is not much. When you're looking at 80 GB, it's a very significant increase. And so that's the group that

yeah, I really feel like, you know, if we're going to just cut them out, we need to make that clear that we're doing that.

Tim Beiko: I do think like, yes, I do think this is kind of clear in 78 70, like, basically, this is a effectively like, just like a non staking like node and like, or like a full node, basically like and I think it's been pretty clear in the past few years. That like, yeah, the the Median way to run this requires extra hardware. It should be consumer grade hardware. And it should be basically, you know, not like, like, I'm not out of reach for people to do this, but I don't think. I guess I think we've passed the point of saying. we can optimize this for effectively, you know, like a couple of 100 gigs of storage and nothing else.

some client implementations might be able to help with this. But but yeah, like, it's, it's definitely not like the median. yeah, the the median approach. I guess. Yeah. Okay, odds are. And then, yeah, let's do that.

Ansgar Dietrichs: Yeah, I just wanted to say that, like, I think one way in which maybe I think many people at least have expressed in the past. The intention to change a little bit. How we do things in ethereum is maybe that we want to still like continue to take these concerns very seriously, because obviously this is crucial to the core of ethereum that we actually get this right kind of this trade-off and really understand the costs of scaling, and when that is acceptable and when it isn't, but that we stop doing it. The way where we always basically 1st get blocked on like 7 rounds of conversations before we have exact agreement, and only then make any moves, because then, in the meantime, the experience for actual users is just really really bad. So I, personally would just say that the the basically the process here of saying over the next 2 weeks, with the in person, events and everything. We basically make initial decisions for the short term. And we're only talking about at most, 1 point, something X increase right? Like 60 million is not even double today's level

and then going forward, we will have a process. And I think, Mike, I'm happy to to reach out and and have you been involved in this, where we we will also, over time, become more precise in the, in distinguishing between different types of nodes, including Rpc. Notes explicitly, so that we actually have a fundamental basis. And then we can still have the conversation which assumptions to use. There was not used there. But I think, basically, for now we should still move forward with this process and not be blocked for 6 months while we have that discussion.

Tim Beiko: It's Dunker.

Dankrad Feist: Yeah, I mean, I think, like, when I hear these discussions, I often just feel like it's really disconnected from reality, like, I mean, I think, like the we're still thinking about ethereum as if it were 2050. And it's like people want to run like a home like this this node at home that has all these properties. But, like the Median ethereum user now, is so far away from that that's pretending that we still get the same like we still operate in the same space and still get the same benefits, is like not very reasonable to me, like, I think, like in practice, we, we know exactly like most of us know exactly what normal ethereum users do, and yet we keep designing for something completely different. And I think, like we need to move away from that and like, be like, well, this is what is really happening. And like.

we want to get the Median ethereum users. The best properties that we can, rather than like a small set of like people who like do something very different from that.

Lightclient (Matt Garnett): Lukesh.

Łukasz Rozmej: So I'm somewhere in the middle. So I agree with that we should be able to run ethereum nodes on standard consumer hardware, and we can. And if you need to buy a SSD. If you want the full history from Genesis. it's also fine, and if you need some decent connection to keep up with the network. And it's also fine. If as long as it's reasonable and available in a in a lot of locations, it's so. Yeah, I don't see a problem. You can build blocks with Nevermind and not only Nevermind, probably a few 100 Megabogas blocks. You can process them. You can store them relatively easily with newer architectures like Arygon free. Even archive node

is somewhat reasonable, but it's also fine for us to say if you want that. By a SSD, right? It's technical limitation. We would love not to have that. But it's fine. I do agree that we should maybe focus a bit more on eap 4 force, and having it post merge pruning of that to to help with that. But that's about it.

Tim Beiko: Thanks. So I guess, like, yeah. The the main thing I wanted to revisit today was like, yeah, whether we were okay, just whether we were okay, just moving forward with 60 million on main net as of now, it does seem like there's more data that we wanna collect, at least in the next couple of weeks, we should we should figure out the like, yeah. what what? What like the the requirements are, whether we want to do a 1 off like bump to 60 million, or to be more gradual. And I expect in like 2 weeks or so we'll we'll have a bit better of a an answer there. And yeah, Marson.

Marcin Sobczak: Yeah, I would like just to add that on recommended specification from 7, 8, 7 0. If we are running tests on it, and there are, like the the worst scenario is performing at about at about 20 megas per second. So we need to be conscious that there will be a possibility to craft a block which will take 3 seconds about 3 seconds to process on 60 megas or 60 mega cut limit. I'm not saying that it's a blocker, but we just need to be to be conscious about that.

Tim Beiko: Yeah. okay, so I do, wanna move on for now, because, yeah, we could probably spend the next 90 min talking about this. But yes, let's follow up on this in the next 2 weeks. and then do we have. There is a discord channel gas limit testing. So we should use that to to actually talk about like, yeah, what what the constraints are and how we're addressing them, or next week's. I guess. Okay. So following up there were 2 minor update or updates to at least some of the the fussaka eips 1st off Powell had a had an update to 7, 8, 8, 3 that he wanted to discuss.

yeah, I don't know if you're on the call, Powell.

Marcin Sobczak: Yeah. So I can give you some insights about that. because it was in touch with Pavel about that. This Apa is proposing. This Pl. Is proposing 2 changes. We already agreed with Pavel that one of them will be withdrawn. So it is proposing to to not increase the mean price from 200 to 500. But it's opening the doors for for some case scenarios which we don't want to have, so it will be. It will be reverted, so we'll be keep increasing it from 200 to 500. And like right now, in 7, 8, 8, 3, there are 3 small tenders in the code, and this will add the 4th one so for on on real network, base and model are always have 22 Byte or more, but in theoretical scenarios which we can like craft to to be worst case setup scenarios, etc. We can craft

modex usages with with smaller amount of bytes for for base and modulla, and hmm it. The the spr is in increase increasing gas price like we we are. We are counting price. If it is 52 Byte, even if it's smaller, thanks to that. like, we will cover some at case scenario at case scenarios, and they will have 0 impact on on common cases on my net. So it's a clear win. And yes, I'm I'm I would like to to add this this 4th change to to this.

Tim Beiko: Thanks. Has anyone else had the time to review this or or comments on it? Okay, otherwise. Yeah, let's have people review this Async and try to make a decision in the next week or so. next up so on the last call we discussed some issues with rip 7, 2, 1, 2 needed to be addressed and that led to kind of a a change in the spec. So we opted to effectively write a new eip that provides basically the same functionality. But that addresses these issues. Carl has been working on that. And I'll call, are you on the call.

Carl Beekhuizen: Yeah, Hi, yeah. So I mean a few things. Basically, why do we want this? It's like the most ubiquitous signature scheme across the web. And most modern tooling stacks like it's basically the sha-two 56 of the signature world. Like defaults in Tls or Ssh for Vpns. It's like massive, but the main gain that we care about here is that, like it is the signatures that's used like embedded in most hardware, so like android key stores apple secure Enclave Ub keys. Anyway, we can use a passkey you could. You would now be able to just sign so that means we could like switch to a model where you just sign transactions with face id or fingerprints, or whatever works for you.

So I think really massive. Ux unlocks. This exists in the form of Rip 7, 2, 1, 2, deployed across many of the L twos at the moment, as I mentioned previously on here before we had a small bug in 7, 2, 1, 2, which, like basically had undefined behavior and a degenerate edge case. And so we kind of needed a a new spec for that. This eip, 79, 51 is identical from an interface standpoint. So from within the Evm, you can't, you definitely won't be able to tell the difference. But we just patch this one edge case and have extensive tests for it. So that's I think, something we should really consider. Consider having in this fork.

we had bls in the previous fork, and I think everyone can. Everyone's a little jaded. After that I totally understand that this is a much simpler cryptographic eip. so it only has one interface slash entry point versus bls, which had 9, I believe And the there's only like internally, cryptographically, there's only like one group where the whole Bls thing has 3, and they all interrelate and weird in wonderful ways. Because it is so ubiquitous. There are just many libraries that have it, and this eip matches the interface of all those libraries. So we don't use Ec recover like we do for the k 1 curve we use just verify as the interface again, just because that matches all the existing libraries. So it should just be plug and play

and, unlike the Bls things, we already have extensive tests. Before we wanted to do this, I think there are 780 odd tests in this this new version of the Eip. So I think it's in a really solid place and ready to ship, and something that from Ux standpoint would be fantastic if we can. We can just have in there. As far as I'm concerned, the Major, unknown is just gas cost benchmarking. There's a number in there now which matches rip 7, 2, 1, 2, my intuition is, was probably a little on the cheaper side. But yeah, I think we should like we, we should basically just need to implement those in clients and see where that would would

see how much that costs relative to other things, and then we can we can get that.

Tim Beiko: Right? Yeah. Thanks for for sharing. And so I guess yeah, there's 2 like decisions here. The first, st it's just like, Are we okay, swapping out, rip 71, 2 for this. It seems like. yeah, we we obviously should. And then I think, next, item is just what do we want to include in definite, too? So I feel like we should make the decisions about the Devnet as a whole rather than just 7, 2, 1, 2, or not. so. But yeah, before we do that, just like, does anyone have any concerns swapping? 7, 2, 1, 2 with 7, 9, 5, 1. Otherwise we could just do this after the call. And then, okay, so assuming there's no concerns,

basically on on the last call we had sfi, a bunch of vips for the definite one spec. Devnet one is not live yet. However, we did want to finalize the potential list for definite 2 today, meaning that like assuming that that one goes well, this is what we'd add in definit 2 and then finalize the scope for Fusaka finalize the scope for Fusaka so the 4 eips we still had. In the Cfi list, where the payoff code 7, 2, 1, 2, which is now being replaced by 7, 9, 5, 1 7, 9 0, 7 and 7, 9, 3, 4. I guess. Yes, I would like to hear from client teams. Like which of these should we prioritize for Devnet 2. And then, I think, what doesn't get included for definite 2, we would probably just decline for inclusion now and leave the rest. And Cfi once we've so once we've shipped that this one, we can move move the the rest.

But and so, Gabriel, to your question, like so far nothing has been confirmed for Government 2 and we want to figure out of the set of vips we already have set for that. f 1. What do we want to add? In addition to this, and I can post. I'll post the full list of vips for devnet one in the chat. Now. So this is what we had in the event. One. Yeah, yeah, Ben.

Ben Adams: So the 7, 7, 2, 1, 2 replacement. Block execution size. I'm living on pay fine with that. The meter contract size still needs work. So would be against that. But potentially, we could just do in the interim, like 50% on the on the contract sizes.

Tim Beiko: Okay. So so sorry. That was 7, 2, 1, 2. And then what was the other one? Sorry you said I just wanna make sure I got it right.

Ben Adams: 7, 9, 3, 4.

Tim Beiko: Okay. The okay, yeah.

Ben Adams: But yeah, but 7, 7, 9 o, 7 still needs a bit of work. and would be willing to to swap that for Fusaka, for like a 50% bump in size, and then look at doing the full eip for Amsterdam.

Tim Beiko: Got it. Thanks. Andrew.

Andrew Ashikhmin: So I agree with Ben. It's the should be the r 1 precompile and the rop execution block size limit. I I, personally don't have a strong view on on the increase limit, Eip. As to the pay OP. Code, I think it. It has some implications to the tooling, and it's it's not trivial. So if we decide to do it, I would rather do it early in in Glamsterdam, so we have more time to think about it and test it so I wouldn't do it this late in in Fussaka.

Tim Beiko: Okay. Anyone from Beisu or Geth.

Marius van der Wijden: I put my personal opinion on the chat already. I like 7, 2, 1, 2, and 7, 9, 3, 4. I don't mind the others, but I also don't really need to push for them at this moment. Okay, and.

Tim Beiko: And then, yeah, Gabriel, you're being put on the spot for basic.

Justin Florentine: If he's not near a mic, I think. we don't really have a strong opinion. We published our earlier things. I think the pay. OP. Code is good. We'd like to see that included.

Tim Beiko: Oh, okay. Marius.

Marius van der Wijden: And this is actually just thought maybe I should give, because, Mario said he has his personal opinion. So I do think that, like from my point of view, the 7, 2, 1, 2 is pretty important to ship like this has been sitting for so long, and it's kind of a small one. So we should just we should have this and the 7, 9, 3, 4 for me, also pretty important one, just to basically be able to constrained the other ones. I have less than a routine. But opinion about but I know that the 7, 7, 9 0, 7 is pretty important for the community as well. So I would say, like, if we can pull off, then it's probably also something good.

Tim Beiko: Thanks. Yeah. Roman.

Roman: But this is a response to Felix. I would recommend to catch up on some manners and thread which I was unable to do. Yet there was basically a long discussion on on the implications. And I posted the comment earlier in the chat as well, that we're for 7, 2, 1, 2, and 7, 9, 3, 4, and we're generally supportive of 7, 9 0. 7. But given the extensive discussion, I cannot give opinion right now, because I have not caught up yet.

Ben Adams: To to be effective. The 7 9 0, 7 really needs a change in the database structures of the El client. And it's a bit close to Fusaka. In terms of you know where we are in the devnets and things. If it was like at the start, I I would say it's fine. It seems a bit too much at this stage.

Tim Beiko: Okay, so I guess if 7, 9 0 7 is gonna be too complicated. Then this is like, yeah, the last of net that we want. It seems like 7, 2, 1, 2, 7, 9, 3, 4 are pretty much supported by by everyone. So I would keep those, hey? And and then like yes, should we decline effectively? 7, 9, 0, 7. And I would also lean towards declining. 5, 9, 2. 0. Because it seems like it has pretty mixed support. and also like, had some unintuitive implications. Okay.

Ben Adams: I wanted to.

Lightclient (Matt Garnett): People think about trying to do 7, 9 0, 7 for this devnet. And if we find the database, changes are just going to be too complex. We drop it like, I know the database changes for us is only like one or 200 lines of code. It's not substantial. I don't know if that's pretty different for everyone else.

Ben Adams: Yeah.

Lightclient (Matt Garnett): But it's 1 of those things.

Ben Adams: Changing all that good and pricing. I mean, I I think it would be better just to like increase the contract sizes by like 50% for Fusaka, as like a an interim, feel good, and then not not feel good. But you know it would be useful for Dev. And then in Glamsterdam we we do the the fuller, more complete thing.

Lightclient (Matt Garnett): Yeah. But it already has a lot of things that people really want to do that are gonna be super critical. And it feels like we can just focus some effort now over the next month, and really lock in 7, 9 0, 7. Now, when there's not so much going on in the year. and then Glamsterdam is open for try to, the all the different yeah piece being proposed. Yep, my like, I just see us having the same conversation again, and 6 or 9 months, and then saying, You know, there's a lot of stuff going at this fork. we should just wait till the next fork.

Ben Adams: Yeah, but it's it's the fact. We're at the end of the 4 promise. That's that's the main part.

Lightclient (Matt Garnett): I don't think we're at the end of the fork almost.

Roman: Okay,

Tim Beiko: Robin. Yeah.

Roman: Yeah. Quick comment. My understanding that the problem with 7, 9 0, 7 was not this additional index. but, like other explored implications of storing these huge contracts and and the database like. No, nobody just did the the analysis.

Lightclient (Matt Garnett): I mean, I think Julia did look into it, and sequential reads is extremely fast from disks. So it's not really a major issue, but it's 1 of those things where we probably aren't going to get the best information until clients actually start to look at it. And I don't think that it like. It's not a big lift to begin looking at it like the whole implementation of this is probably sub 500 lines of code. and I think it's like a good stretch goal for us for the next devnet. And if we start implementing and we learn that this is not going to work out. Then we drop it no worries, and we look at Amsterdam.

Roman: Okay, I'm gonna Flip, I'm persuaded. Rep is also for including 7, 9, 0, 7, or at least trying to implement it. And if it's too difficult, we can always take it.

Tim Beiko: I guess one thing.

Lightclient (Matt Garnett): Ultimately, the thing is that this is very important. IP for the community. They've been asking for this type of thing for many years, and we're close like we're really close. We just need to push through a little bit over the next month, and I think we can give it to them.

Tim Beiko: I think one thing to note about definite 2 is, even though Devnet one already has a bunch of things in it. The 2 other Ips we're considering are quite small. So 7, 2, 1, 2 is not trivial, but I believe most clients already have it implemented and would only need would would only need like to- to- to do the changes add from Vip 7, 9, 5, 1, 7, 9, 3, 4 is like also pretty straightforward. And it's like a a check on the size. So I guess. like, yeah, do we want to commit to have it in Devnet 2. If it doesn't work out in Devnet 2. We do that, and I get there's 2 comments about like tentatively including. This is why we call it scheduled for inclusion now, and not included, like, you know, if we learn something as we're working on it, that makes it no longer be a good fit, we should reevaluate that

but if we want to, if we feel like we have to actually include it on the Devnet, then I think it makes sense to ship that one and then potentially have that be like the one slightly more complex feature of that the 2. And if it works out, then great, we ship it. If we find that the issues are too big and that it's gonna delay the fork. yeah, we we should just remove it. So I guess if yeah, I guess and rest are in favor. I know. Basically, never mind, Eric, on. Yeah. Do you have thoughts about this If we did this, I think we should probably not do pay off code, and then that too. So this means, I think, if we include 7, 9 0. 7, and and there's some concerns we should probably

decline pay from this fork.

Ben Adams: Happy to experiment. Yeah, how it goes.

Tim Beiko: You're what sorry.

Ben Adams: Happy to experiment. See how it goes.

Tim Beiko: Okay. Okay. Bay, Su. Argon. I don't.

Andrew Ashikhmin: Andrew, we can try experimenting, implementing it. So I haven't thought about it in detail. But well, at least we can. Yeah, we can, we can start experimenting with it.

Tim Beiko: Okay, so let's do that, then let's do so so this means we'll leave 7, 2, 1, 2, 7, 9, 3, 4, 7, 9 0, 7 in Cfi, for now move 5, 9, 2 0 to Dfi. And then once we have shipped Devnet one assuming things don't break there, and there's not like a bigger correction. We would default to move these 3 Ips to Sfi and depart. Devnet 2 and then, if we find some issue with any of the Ips we should, we should reconsider whatever we want them in the fork, or just to remove them. And if there's some investigation that we can do on 7, 9 0, 7 in the meantime. Yeah, we should do that.

Yeah. But I think we are set on the maximum possible scope for Fusaka. So as of this point anything that's not in this list effectively out of scope. And if everything goes well, then, what's in Sfi now? And the Devnet? 2 scope will be what ships.

Justin Florentine: So that includes pay. OP. Code is what I'm hearing.

Tim Beiko: No, I would say we, if we if we move forward with 7, 2 sorry with 7, 9, 0, 7, I would move to not do pay, and Devnet 2, because it seems like most teams didn't support it. Then, if 7, 9 0 7 is already going to be complex. I try to limit complexity, but.

Justin Florentine: Sure. Okay.

Tim Beiko: Okay.

soispoke: Yeah. Over here.

Tim Beiko: Okay? Great. So, yeah, that's it for Fusaka. So looking ahead for Amsterdam, like, we discussed previous couple of calls, we want to start and consider headliners for the 4 1st line on that before we we we discuss other eips. So there were 3 headliners proposed already. I wanted to make the space if either of those proposals on the call to yeah, give a quick overview, and then I think it would be helpful. If people on this call have like questions or concerns that need to be investigated to raise them, so that the champions, for these headliners can go and look into that over the coming weeks. There were also a bunch of like smaller, more minor eips. I don't think we should start making decisions about those, but I wanted to at least flag them so people could start proactively reviewing them.

But yes the 1st the 1st headliner candidate was fossil. I don't know if anyone anyone championing fossil is on the call. Okay, I linked the 3 threads in the chat so we can. We can follow up Async and discuss another call, and second was Evm. 64.

Wei Tang: Yeah, but I'm I'm here. So I'm the champion for 64. So this is something that I hope I'll probably give a formal introduction on this later. But at this moment I really want some more reviews. But the basic idea is quite simple. It's just we define a new group of codes that are only operating on the least significant of a stack value. And the good thing about this is that we can then, I mean the the each operation is done significantly faster, because you only have to do one statement of 4 for the 2, 56 bits. We currently have 2 different merchants.

The 1st version is built directly on the legacy, or I, I would probably just use this name legacy Evm, which we define a prefix of code, and and the other set of the the opcode that follows it is is the 64 bits operation and the good thing. The the advantage of doing this is the way is less complicated. And we we just have. I mean. we have we? We can make the interrupt with 2, 56 bits really easily, because it's just a different set of codes. It can work with other calls really easily, and the second option is built on top of Eof. In this case, what I, what you have 64 will need is a change to Evm format, which does. Yes, we have a question already?

No. So- so- so, yeah.

Alex Stokes: Sorry. Yeah, after this I just wanted to circle back to fossil for a second. I was just raising my hand for that.

Wei Tang: Okay, yeah, I will. Okay, I'll continue then. Then the second version, second option is built on top of Ui. And in this case we do need to do a change to the evm format which add a type. a type parameter into the code section. So the interpreter can can know, whether is running a code section of the the legacy evm or evm 64 and I think this this is the option I would prefer is it will be open up. A lot of organization approaches for us. And we can, we can basically write really fast jits for 64, like building on top of existing ui format.

Quite well. And yeah, this, this is basically the the current proposal. And I will really looking for some reviews at this moment. If you have questions, I would really like to answer them. So yeah.

Tim Beiko: Okay, thanks any questions. Oh, there's a question by kev there, there's a question by Kev around whether this has been prototyped and and and whether we have a feeling of what the actual performance improvements are.

Wei Tang: I have a I have a prototype in for the the option one which just directly build on top of the the legacy. Vm, I haven't really benchmark it yet, but I will hopefully do that soon. So, but but I mean, if we write a jit for that, it will be faster because we are just not doing the actual work of of the actual extra 1 92 bits. So so for those, those computationally intensive operations functions that we only we can only use 64 bits. So this will be beneficial.

Tim Beiko: Thanks. I think, like, yeah, having hard benchmarks would definitely be helpful here. Are there other questions, comments, concerns? Okay? Then. Otherwise, I think, yeah, we can continue this conversation on these positions. And then, yeah, move on to fossil so I think, was, yeah. Toba, I think, is on the call. Maybe if you want to start to give like a quick overview. But then there were already a few questions about fossil in the chat, so we could get to those as well.

Thomas Thiery: Yeah, sure. So maybe first, st I can signal that I did give like a more sort of like fleshed out presentation on so like, everyone can sort of like refer to to the presentation, I guess if they want more details. But yeah, for so is Vip 7, 8, 0, 5 we presented it as a potential headliner for Amsterdam. What it essentially does is basically really improving ethereum censorship resistance by enabling multiple validators to just make sure that any transaction that is valid according to the protocol rules is actually included in ethereum blocks, and basically does so by having, like the multiple validators. build inclusion lists that are filled with transactions from the public main pool to impose some constraints on the

on the builder. It has, like a bunch of interesting properties. I think maybe highlighting. Why it matters. It's because I mean, today, we have, like more than 80% of all works that are produced by just like the 2 builders. And we can just like decide whether to include or exclude transactions sort of arbitrarily. So folks, basically, what foci does is like it fixes this by empowering like the more like obviously decentralized set of validators to enforce inclusion constraints and build those plugs. for who it benefits it benefits basically everyone because it ensures. Like all the transactions are included on chain without sort of like any discrimination between different kinds of transactions that are just like arbitrarily decided by an external party instead of local.

yeah, it has some benefits like you could like tie to scaling and improving ux. But of course, like the main, very big feature is improving censorship resistance. And why not? I think, yeah, it's really a solution to basically mitigate the censorship risk we've been having since. Pbs was introduced. and I don't know. Like the builder market is very, very centralized. It's like sort of inherent, because it's due to private. And I don't think it would change. And yeah, we have observed, like, sort of like increasing vertical integration across builders relays, and so forth over time and like, not the other way around. So yeah, I think there is a question also of like the urgency of including it. We've so that's been discussed and proposed a lot like there was another think fossil is is much better in many sense. But, like.

yeah, there is a case for fossil, I think, because now we are like quite lucky that there's not much censorship on the network. I feel like in the future that can definitely change and make the inclusion of something like fossil or proposals to improve. I don't know censorship, resistance and privacy much harder to get in in the 1st place. So yeah, I think there is some big urgency in taking care of this. In terms of technical readiness. It's also, like like now fully implemented in 5 different clients and running on local, and get that are interrupting with each other soon. Lighthouse, I think. We've had 11 fossil breakouts. And we made sure, like, it's compatible with everything that's sort of like already in protocol, and also like other proposals. So

yeah. I think there is a good case for fossil. I really want to. For for the for us to move this forward and not wait until things get back to get a proposal like fossil included.

Tim Beiko: Thanks. One question that came up earlier in the chat was just the interaction of a fossil with delayed execution and block access lists. I don't know if you have like a some thoughts on that. Yeah.

Thomas Thiery: Yeah. So there has been some recent progress on that front. It was mainly driven by Tony and Francisco. But there are like some very nice integrations between the 3 of them. So it basically works with delayed execution. But like, there are like some tricks that you have to sort of like deal with. To make it work together and plug level access is actually sort of like, make that easier. So there is a write up by Tony that I can link. But there is a nice integration between the 3 which is very nice.

Tim Beiko: Fixed any other questions. Thoughts about fossil.

Zane Starr: Oh!

Tim Beiko: And okay, then, yeah, thanks a lot for jumping on a quick overview. next up, the other proposed headliner was available at the stations. It's the one I have the least context on. I'm not sure if the author is on the call.

Mingfei Zhang: Yeah, I'm here.

Tim Beiko: I hope. Do you want to give a quick overview.

Mingfei Zhang: Oh, yeah, I will give us quick presentation for this. Hmm. oh, sorry. Wait wait a few minutes. Okay.

Tim Beiko: Yeah. Thanks.

Mingfei Zhang: Okay? So yeah, Hello, everyone. So today, I'm excited to present my eip 79, 79, 42 available attestation. So this is a proposal designed to make ethereum provostic fully reorg resilience. So first, st we are talking about what is real. So as we as we can see, is it table? So, despite money advancing ethereum approvals protocol. The system also feeds the many new attacks. So some of tech we have already know about, like the ex, the balancing attack. It's a Lebanese attack and other attacks about attacking the Gasper

Cusper like the bouncing attack. So, and some of the attack, like the justification with holding. So these attacks they mainly focus on attacking ghost or attacking customer, and they call mainly cause reorganizations, kind of like so the balance attack is more powerful, and it cause the finalization. Stop also the Boston attack. So these attacks they have some mitigation by theorem. However, some of this mitigation has its limitations, like the proposal posting the.

Somnath Banerjee: Mitigation.

Mingfei Zhang: Oh, sorry I can't hear. Okay, so the proposal boosting was 1st proposed, and it is. It set a very high boosting, and it calls sandwich, and then it is degraded to 40%, and it cannot fully prevent, however, if we set the anniversary stack to more than 20. Also, the bouncing attack was 1st mitigated by the safe slot, so the justification cannot be update if if apple has processed it slots. However, this medication is now removed, so currently is now still facing the bouncing attacks. Vulnerability also, the justification withholding attack is not fully mitigated, and this cause, the staircase attack. This is one of kind of justification, withholding attacks

warranty, and this attack has been fixed in the current, and it is not really be fully mitigation, and what we want to do is to keep the parent restriction. The idea is that so in the Vernida Protocol, so if there is no adversary, the honest validator can propose one block of another. So the idea is like that. So this is block, one by one, and oh, sorry. And if there are some proposals that want to do something harm like they just want to make the system very bad. So what they want to do is that they just build a block and dot point to the previous. They point to another block, and they may cause a chain fault, and there are 2 chains, and there are any other situation like this is

so, it may withhold a block, and it may released after this block is proposed, and cause a cause. A fog like this. So this block, it will be fogged. So so this is why restricting the parent is very important. Our idea is that since the only validators always vote for the head. So if this is a chain and honest validator like the blue one, they always vote for this, and the adversary may vote for this and other blocks we don't know. So what we want to do is make the honest validators vote be the parent candidate. So so the idea is that. So if the adversary want to propose a block to this, this cannot be

our valid parents, since this block, it does not receive enough attestations, because only 1 3rd of the State is controlled by the adversary, and we assume that we require that more than 1 3rd of attestation would for a block. This block can be the value, the parent so.

Tim Beiko: Big Faye. Yeah, yeah. I guess. Like, yeah. 2 things. One is would it be possible to share these slides in the chat to get for people to be able to review Async. But also, yeah. Given the topic, I think. Apologies about this, we should probably yeah, we should probably discuss this more on the the Cl call. yeah. And this is my bad. I I think I I.

Mingfei Zhang: Yeah, yeah, I see. I see. So I'm I'm.

Tim Beiko: But if if you want to post the slides in the chat, I think we can. yeah, we can have conversations, I think, as well on the youth. Magicians threads. If there's anything really important you want to finish like the minute or so. go ahead.

Mingfei Zhang: Yeah, I think we will talk about it later. So.

Tim Beiko: Yeah. But yeah, I think, if yeah, if people can, if people can review the the actual slides that would be that'd be helpful. Okay.

Mingfei Zhang: Okay. Okay.

Tim Beiko: I'm thanks. I'm okay. And I think those were the headliners that have been proposed for Amsterdam so far. if people want to propose more. There is the East magicians thread for that. yeah. Any other Glamsterdam Level conversation people want to have. Otherwise. There's also like something about pay that we should get back to in the chat. But yeah want to wrap up the collapse of that headliner thread before

Toni Wahrstätter: I could quickly talk about blocks of accesses. Maybe we forgot that now.

Tim Beiko: yeah. So yeah, I guess one question I would have for Bl is like, Do you think that's like a liner feature? And like should be the main thing of the fork, or, like, I know, we've talked about combining it potentially with fossil, potentially with delighted execution, so that might be also worth getting into.

Toni Wahrstätter: Yeah, I'm not sure about combining it with both of the 2, because it's more like block 5. Access list is a feature that helps delete execution, and possible to be more aligned and to work more smoothly together. I saw Justin's comments and the chat that it might not be a headline. I think we can discuss that right now. I would say. It's it has the size of a headliner. I did the specs already, and there. It definitely looks like it's more of a headliner size. But yeah, debatable. Just to give a brief context on the eap, it's 7, 8, 28 and block level accesses, tries to introduce some parallelization. So we can do batch I/O plus parallelly, executing transactions or executing transaction and doing the state root calculation in parallel.

So this is the primary goal there, and some secondary goals would be that. for example, imagine a Ck world. You get the proofs, and you want to up the your state, and for that you can use the block of access list, because it essentially contains a full state. So without executing. You could keep your state up to date. And this is also nice for syncing, because we could kind of take the healing phase and replace it with the block of access list. and then do the check. If if you are on the right chain at the end by comparing the headers and regarding helping fossil and delayed execution. So the thing there is that fossil comes with post execution checks. So you have to execute the whole block, and then you have to check. Was there any transaction that was on an inclusion list? But it was not in the block, so you would have to try to append that transaction to the block and see if it could have been appended. If so, then the block would be valid

and Blocklet access list help there, because usually you would need the post state for that. and you only get the post state after execution. But with Blocklet access list you could have a function that looks like it takes the pre-state and the block level access list and outputs the post state so you could do any checks that you would normally do post execution. You could do pre-execution. and this is kind of where it aligns to that execution with puzzle a little bit.

Tim Beiko: Thanks. Any questions. Comments. Yeah. Lucas.

Łukasz Rozmej: So one comment of mine about like scheduling. And so if we decide we want to do block access list, I wouldn't. I'm a bit reluctant to include fossil before, because then, with block access list, we would have to rework fossil a lot. So maybe it would be better to include them both, or actually block access list going before fossil just for redundancy of the work. It kind of seems. But it needs 1st decision. If you want to include block Ssds. In the 1st place. that's all.

Tim Beiko: Thanks, anzago.

Ansgar Dietrichs: Yeah, more on the process side around block level access lists and also discuss this a bunch with Tony. Basically the the way the structure of block level access works is that it's kind of it has 2 separate aspects to it. It's the the read side and the right side. And the count proposal, I think, for the for the reads basically only includes the location and for the rights, the location, and the values. each on a per transaction level. It makes a lot of sense, if we want to ship both of these aspects of it to actually combine the implementation, because you can get a lot of synergies out of this, so you shouldn't have this completely, separately specified. But in terms of governance we should decide on both of these things independently. So I think we should really. Maybe that means splitting the Ap. But either way, like we should decide on. Do we want the reads? Do we want the rights plus diffs.

and then, if we want both, we ship them in a unified way. But if we only want to ship one of the 2. Then we should basically explicitly talk about that. So just on the process side.

Tim Beiko: Thanks. Guillaume.

Guillaume Ballet: Yeah, I mean, that's kind of building on what said, I am generally supportive of blocks access list, because I think it's it's a good 1st step to what I want to happen next the biggest issue I have with, you know, scheduling this right now is that there's actually 5 flavors of it. And I think, actually, there's a lot more. And we need to really really limit the amount of of moving parts so that we know what we ship. Because no, we're not gonna ship like we can't do it in 5 steps like it's it's completely useless if we? If we just move this in like many steps, because, you know, some of it might not be shipped. Some of it. You might change your mind and realize you took a wrong turn. So you need to get the final design. And I would say, the cip is.

quote unquote, small enough that we could reach a design, but I think before we even talk about scheduling it, and Tony knows my opinion. So it's not a surprise to him. I think before we talk about scheduling him, we should really get this this designed and and properly understood.

Tim Beiko: It's some.

Somnath Banerjee: So on some level, one or more flavors are already there, and, like historically enabling parallel execution, and so on. We have had some eips in the past as well. Tony, do you know why we did not ship this, or a variation of this in the past. And what changed now that we're in the position to do it.

Toni Wahrstätter: Yeah, I think I think this is primarily because the community had some very clear stance on what the what we want to achieve in the next one or 2 years, and it feels like l. 1 scaling was definitely on that list, and I would even say, on the top of that list. So I would say, the focus shifted towards looking more into our one scaling and block of Access list. So parallelization was always a thing, and it. It is a thing today, right? All clients, almost all clients, have some prefetcher logic, some pre loading logic that already achieves that and is very good for that. In the average case. block level access list would now go one step further by making sure that every block is parallelizable. There is this other year. Pf, I think it's 7, 8, 25, with the capping the gas limit, which is also already a

a step into the right direction, there to make sure that blocks are actually parallelizable, no matter if it's the worst case or the average case. And just one more comment. I totally agree with what Anska and Guam said. We have to kind of get to the final design as fast as possible the 5 designs that were mentioned. This was just the 1st post I had on design space exploration. But in the meantime I've been talking with some client teams. There was also a lot of great input in the discord channel, so check that out. And essentially it felt like. What clients wanted was the post transaction status, because this has many different advantages, not only for parallelization, but also parallel state route calculation or for execution by state updates. So the post transaction value seemed like something that clients really wanted.

and the storage locations. This is then something where clients could replace Prefetcher code with the storage locations, because this is just a deterministic list that is 100% correct, and it always gives you the the right locations. And you're never yeah in the position where you run your prefetter. And it's actually incorrect. Yeah, I think that that's kind of.

Łukasz Rozmej: I want to just add that I disagree that this wasn't the focus, because vertical trees and its witnesses carried a lot of these properties that we are now simplifying. Let's say with block access lists. So it was the focus of research for the last few years. It's just in a more complex form. And now it's being somewhat simplified with this proposal.

Toni Wahrstätter: Oh, yeah, totally agree. I was more me thinking of focusing on kind of how to make it best for l, 1 scaling.

Somnath Banerjee: Are there going to be any? My apologies? Changes in the block size because of this? Let's say you've manage to scale the block nx of what it is. And then you have to ship a lot of extra data as well, because right now, that is not being. you know, taking place and like with higher block limits and more transactions. the bandwidth would be like a premium.

Toni Wahrstätter: Yes, this is correct. So block type access list would add some additional size to the current block size. And the worst case is not a problem here, because the worst case would be around 0 point 9 MB. So this is smaller than the worst case from call data, and the 2 are exclusive. So you cannot build a block that has a lot of call data and a big block level access list. But we should more focus on the average case here, anyway, and on average, the block of access list design, as it is in the Ap. Right now, would add on average, 40 kB per block. And this is definitely a non negligible increase. And we should, yeah, carefully analyze that. I think when we look at the pros and cons, I think it's worth it. But this is definitely, I would say, one of the most important points to to stress here that the block that access lists are not like

a super small object compared to yeah, anything that requires witnesses. It's very small. But yeah, definitely. Some some block average block size increase.

Tim Beiko: Odds are.

Ansgar Dietrichs: Yeah, on this point, I just wanted to briefly add a kind of caveat, just that, indeed, as account throughput levels, and especially at current pricing levels, even if we were to increase throughput. And this kind of extra data consumption is indeed not a concern, because for the same gas that you otherwise would have spent on call data. You already like, spend it on state breeds or writes instead. And so you can't spend it on call data. So the worst case block size does not actually get worse. However, there's a big big caveat there, because going forward, we have more headroom to scale state accesses, reads or rights. And then we have to scale data. And so this could actually change in the future. So basically we are locking us potentially in and basically, as we would want to change that pricing, we would then hit that wall, that now, basically, there's this, this this limit.

Same thing where we would. We are looking into these like multi dimensional pricing. Again, a bit of a scary term. But like, basically just like, make it so that you can consume call data and execution at the same time. Now, that would then also basically run into this bottleneck. And none of this again, this is just a qualitative argument, not a quantitative argument. So I think over the next few weeks we will look into quantitatively. What does it actually mean, and what kind of relative consumption levels gas limit levels that would actually start to be constraining start to become an issue. And then hopefully, we have an empirical basis to actually make that decision. But I just wanted to flag that this argument that when you just brought up holds at today's levels, but not necessarily in that future that we're aiming to enable here.

Tim Beiko: Thanks. And okay, anything else on block level access list. For now otherwise, I do want to come back to this pay OP code and and devnet inclusion. So previously, we said we would remove pay from Fusaka. It seems like a bunch of people in the chat voice that they they would actually like to keep it. And some of the client team said they already have implementations or the implementations are trivial. So there was a an ask, or should we consider this for definite? 3 for Fusaka? So 2 min ago, we said we wanted definitely 2 to be the last definitely where we add things, I think, even if we want to add one more, for with definite 3 we should be clear that

like, we need to ship what's in Devnet one, and then what's in Devnet 2. And then, if that all goes well we could potentially add pay to to defnet 3. But yeah, how how do people feel about that? Do we want to keep pay? Cfi, and then add it to Devnet 3. If everything goes wrong, everything goes correct, and we don't see major issues. And then that's 1 and 2. Yeah, Ben.

Ben Adams: Yeah. So a very simple opcode in terms of it's just old that you delete 90% of the implementation. The the main thing would be around testing it, I guess.

Tim Beiko: Okay. Since base. You also wanted in Defnet 3 at the latest. 3 yeah. Lewis.

Luis Pinto: Yeah. So this came about in Uf, well, it was mandatory to to, because of the to to include it because of the not passing the gas to the call anymore. I see it was still useful as a simplification for, and even security wise, wise for mitigating reentrancing calls. So I haven't seen that much pushback on arguments against it. So yeah, would like if there's any arguments against it. But it's it's a really simple one, as Ben said, to add.

Lightclient (Matt Garnett): I mean, I feel like I gave arguments against it last all quartz. which is that it's a very simple thing to implement. But the implications of implementing it are not as simple. And I don't know if people have thought really deeply about this, how we want people to use the epm going forward. It seems like something that people just want to do, because it's easy, and we can just do it. And it might make some like people's lives easier. But have we thought about? Is this really what we want the Evm to look like? Because we can't undo this.

Luis Pinto: As okay. So as I, I think the the use case is already available through self district. So it's not something new that we're gonna add, it's just making it explicit with the pay, with your code.

Andrew Ashikhmin: Yeah, I I'd like to add to like like clients. Point is that it changes the tracer. And if you want to trace historical balances. It just adds a new mechanism to transfer. If, which is fine. My only worry is that it's maybe too late for Fusaka, and it's easy to implement in the Evm. But it has the non trivial implements in consequences. Down, down the stack, and we are disregarding that. We're only thinking, oh, it's easy to implement. Let's implement it.

Tim Beiko: Okay. So I think, I'm fine, Le, leaving it. Cfi, if we want for the next 2 weeks. But I think we should definitely. like, yeah. Have a better grasp on the implication if we are to include it in the 3. But I would not. But we're not gonna get that in the next 2 weeks. So if we're not, then should be just remove it.

Andrew Ashikhmin: Is it possible to move it to Cfi for Glamsterdam, or something.

Tim Beiko: I would not do that yet. When we do this, it's like we. We can propose it again for Amsterdam. We can have that conversation again in a few months, but I think it would be a mistake to decide today, when we don't even know what the biggest feature

Andrew Ashikhmin: Correct.

Tim Beiko: That will be yeah. So like, not like nothing against considering it for Glamsterdam. But I I think we should make those decisions independently. Yeah, Daniel.

Daniel Lehrner: Yeah, I just wanted to say we we should be careful not not to repeat a similar mistake as with Evf, and maybe ask smart contract developers why they they wanted, you know, to to get outside voices, because there are things, maybe, that that we are missing.

Tim Beiko: Okay. So this makes me lean towards the word like, yeah, previous decisions removing it from Fusaka and reconsidering for Amsterdam. And if it's mostly a question of like design implications and community support. Then we have plenty of time to do that for Amsterdam, and if it's a trivial implementation, if it's a trivial implementation, then it shouldn't be too too big to add to the fork, regardless of what goes in. But yeah, given, we're already pretty full for Fuzaka. We've already stretched into this. In the 3rd definite I would lean towards removing it and just keeping your scope as is for basically what we had for def one, and then adding, 7, 9, 1, 2, 7, 9, 3, 4, 7, 9, 0, 7 2,

okay. one more thing that I wanted to bring up on this call so there was an eip in the past about a versioning scheme for eips that the testing team had put together with, never mind they wanted to discuss it again on this call. yeah.

Ahmad Bitar: See.

Tim Beiko: Yeah, I'm on. Yeah.

Ahmad Bitar: Yeah, hey? So I I won't take much of everyone's time. I just wanted to go quickly and suggest that we do the IP versioning scheme for all the Ips that we plan to include for Glamsterdam, which means that any IP that reaches the reviews. Date should have a version, and then any consequent changes should probably ha add a an a minimum at the end, saying, what was the change? If it was just a linguistic change or deeper change, etc. Based on the spec that is written in the aip. There were concerns from raised from Tim about the friction that this would add to the to the process. and I think that we, like all core devs, have had instances where tests

and client implementations did not align just because we were not sure about the version of the aip that these tests were testing or the version of the implementation of that client that we are trying against these tests, or that even the version of the spec, like as an eels that we are using to generate these test what they're called. yeah, to generate like the test. So like a lot of a lot of things would benefit a lot of things in the process of the development and implementation of these Ips would benefit from this versioning scheme and this little friction that this adds, shouldn't account for should be like outweighed by the benefits that we get in testing, etc.

And yeah, like, I'd like to hear from everyone their opinions and potentially, if if there is like if if no, if people haven't even haven't haven't started looking at the aip, please do. And like, we can decide on it later. Obviously.

Tim Beiko: Yeah, I've I've looked at it in the past, and I frequently wrestle with the eip bot and get and harass people to go wrestle with the eip bot. So I think anything that's blocked on the eip. But then, like anything that's like a strict enforcement. it is something I would. I would have like pretty big concerns on like I would want us. I would basically want us to come up with like a proposal. For how do you actually automate this and and not add more friction to the process if you ship it? My counter proposal was like, let's just use the hash because we get it for free every time we do a commit to the eip. I think this gets you basically the value of clearly identifying the changes which

which which is like half the battle. It doesn't get you. This idea of like, okay, the the magnitude of the change, and it doesn't quite couple it to the process. But I think if if that's kind of what we want like, then we should probably just have a much deeper rethink of eips around like, you know. What do we want statuses to mean? How do we want that to work with versions? How should that work with devnets and whatnot. And to me this feels like a much, much bigger can of worms that like we shouldn't just add a new versioning scheme about like the the updates to the eip without taking this consideration. So I would say, like, if we want to say that, like the hash, is like the official version, have a way to automatically add that to the eips with a bot or something strongly support it. But I I think, any sort of versioning scheme should be much more comprehensive, and and reflect, like the Eip, state, the Hard Fork state, and all of that, and we should make sure the automation is is set up supported.

Yeah, I'm Andrew.

Andrew Ashikhmin: Yeah, I agree with you, Tim. I think this is a bit unnecessary, this this extra version, and it introduces more friction, because, we can always check the history in Github, but I think what would be helpful is to be stricter about freezing eip commits on the devnet spec, because sometimes we do it and sometimes we don't. And I think that this is really helpful, because this gives us the level of that we should target. So we are targeting devnet, say, 5 versions. We are doing tests for Devnet 5 versions. We're doing implementations for Devnet 5 versions. Everything is frozen, and we should do it like reasonably well in advance, and like new commands, can be merged, and so on. So.

But we'll have an explicit like for Devnet 6, we'll we can see the diffs between the commits and update everything to the Devnet. 6 version.

Danceratopz: I.

Tim Beiko: Yeah, hey, Gavin?

Danceratopz: It's, hey? It's it's Dan here. From the testing team from East. thanks a lot Tim, for the input, about having a more sort of fully encompassed solution, and I completely agree. So I think my proposal would be as the Eip, 7,577 stands. Now. it's a little bit out of date, because that was written when we used the 1st available reference implementation from any client team in order to fill the test for any IP. And now we've moved since Prague 5, I think of September like last year or October. We actually generally, and I think we've managed to always use eels as the reference implementation as it should be, and if eels was more tightly coupled with the eip process.

that if you propose an eip and you get like Cfid, then you should propose an implementation in eels, and the and the Eip document is tightly coupled to this eip implementation. then it becomes a bit more reasonable to start adding a versioning on top of that. I I don't want to take up much more time. It's just a thought that that we've had in the meantime. Thanks. Yeah. I.

Tim Beiko: I think. And yeah, I think this is like an important discussion to have like I. But I do want to make sure that whatever process we have or whatever like scheme we use is both like semantically useful, like we, we know what they're getting out of it, but also not completely independent from from the other parts of the process. so my like, yeah. My again, my proposal, if we just want to track changes, then commits or or commit. Hashes are are kind of nice because you get them for free, and then, if we want to have a much more comprehensive thing. I think it should. it should encompass a bit more. yeah, we. I think it's worth continuing this conversation, I think, and happy to trial something for Glamsterdam as we as we work through the fork, which obviously we would, we would adjust.

And we're already at time with this anything else people have to bring up quickly before we wrap up. Okay? Well, oh, yeah, Ben.

Ben Adams: Just the issue. The blob, count Max per transaction that was just raised about. So the paired pair Dash related. It is, where is it? Re. Forward this that Alexia raised.

Tim Beiko: Okay, we're already past time. So let's have people review this. I think.

Marius van der Wijden: Alright, thank you. See you bye.

Gary Schulte: Bye Marius thanks Marius, Hi.

Ameziane Hamlat: And I.

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