All Core Devs - Execution #227

Transcript

Nixo: Akash, are you able to screen share while you're… while you're doing OBS?

Akash | ECH: Sorry?

Nixo: Are you able to screen share, I think Ansgar has a doc, and… He was wondering if someone could screen share it. I can screen share it, if not.

Akash | ECH: Okay, you can screen share.

Ansgar Dietrichs: Awesome. And thank you, Joe. I think, yeah, we'll wait a little bit longer for people to come in before we go live. just because I don't usually run these Monday calls, of course, in terms of, like, live broadcasts and everything, I assume this situation is identical to normal ACDE calls, so we can just decide when to go live and everything?

Pooja Ranjan: Yeah, just let us know. Akash would be streaming today.

Ansgar Dietrichs: Sounds good. Okay, then, given that we only have an hour today, let's maybe just get started now. I think we can go live.

Akash | ECH: Yeah, we are live.

Ansgar Dietrichs: Perfect, hello everyone, welcome to… I always have to look. All Core Devs 20… 227. Happy New Year, everyone! Thank you for making it to this out-of-turn ACDE today. So if you just joined the call and you're expecting an ACDT, today instead will be ACDE, and then basically starting this Thursday, we will be back in the regular schedule, so this Thursday will be ACDC, and then next Monday, ACDT, and next Thursday, ACDE. Mmm… Yeah, basically, plan for today is mostly to just, continue the scoping decisions. I think we're getting pretty close to being done with that for Glamsterdam, so that's exciting. Before we get into that, though, we have a quick, section where Pooja wanted to give a few, updates on the, kind of.

ACD process going into this new year. Pooja, do you want to start with that?

Pooja Ranjan: Thank you, Ansgar, for moving this item to the beginning of this meeting. I understand today's meeting is going to be jam-packed, so I'll be quick. First of all, Happy New Year to everyone. I hope this brings a lot of happiness, success, and good vibes for all of us. Before we move up to the items that is listed in my agenda item for today's meeting, I want to give a quick shout out and let people know that this is a… this is an outcome of multiple asynchronous discussion. Many happened during the DevConnect week. And we have collected feedback that was also reviewed in the most recent EIP IP meeting with Editors on call. I would like to thank Jocham, Mario, Kerry, Rahul, Charles, and many other client developers, testing team contributors, and EIP authors to whom we met during the DevConnect, and they helped with the

input of this document. So the first item is, introduce, ACDG. This is, technically not a new item. It is a kind of a versioning of already existing governance call EIP-IP meeting. For many years, EIP IP meetings have served as the primary venue for EIP and network upgrade process improvement discussions. But recently, EF Protocol support team is organized, and they have introduced new coordination and upgrade processes, which are seen as… which we have seen, at least in one of the upgrades, and possibly will be there for many more upgrades. While these changes are valuable, we have noticed that it has led to several confusion, not only the community, but also the developers itself. As on today, if we take a look at the EIP repo, there are over 350 open PRs.

So, I imagine that some of them could have been closed sooner rather than later, because if we all have been in sync. So, I think that this problem can be solved if we come up with rebranding and renaming. Ethereum is kind of privileged to have some of the most brilliant developers in the ecosystem, and with due respect, all Technical minds excels at writing specification. While they are not necessarily best suited for designing process and policies, this requires a different set of skills and a broader perspective to view subject as a whole. So, with the intention to provide a canonical place for people to follow, where these decisions… how these decisions are made, and it can be including editors and community.

I believe ACDG would serve that venue. That's why I'm having this proposal. Some of the high-level questions are already answered in this document, and I'm looking forward to collect more input from the community about what they think. Just, before we move on to the next topic, I want to mention that another very good reason for renaming and rebranding this EIPIP meeting to ACDG is because ACD already holds a very unique position, and it is… a well-known public forum where Ethereum protocol-related discussion takes place. So, if we rename it, perhaps people will know, just like for testing, for execution, for consensus, we have a governance meeting and they would be following it. as, interested. The next one, I have got is,

optional upgrade field to standards track here. So, as documented here, there are some unnecessary frictions for users trying to understand protocol evolution, and if they are trying to get the historical context by just looking at the EIP. So, Many client developers and protocol testing team members have reached out to us in the past, suggesting that if there is an easier way that can be provided. Of course, it can be done by having some changes in UI, but we believe that this issue can be addressed by introduction of an optional upgrade field. Which is very simple to introduce, we can add it in the EIP template, and that can be, like, followed, and it's not very difficult. The one problem that was faced by editors, that was surfaced by editors, was how would we know that people have

Filling this field appropriately while we are reviewing the proposal and making it merged. Well, I have also documented, like, this can be solved because this would be an optional field which will be added only at the time when the proposal is moving from last call to final. So, there was an agreement in EIP IP meeting 122, and based on that agreement, this proposal is drafted, I guess I have already… Drafted a proposal, but I have not added the link, yeah. The proposal is already drafted, but I have not added the PR, because since then, I get a chance to think a little bit more about it. in order to include some more questions, those were there, especially around the network upgrade stages. So, I came up with multiple variants here, like ABCD12 options. Please take a look and let us know what do you think is the best.

One in your mind, and that can be, perhaps, added as an, as a process improvement. The next thing is a call for input. Yes. So, next thing is a call for input. So, call for input is a process that is being, Followed by EIP editors in order to make any decision, like a decision that requires more input from wider community. Although, it is… the final decision lies with editors, but it is definitely helpful to get feedback from the community. For example, there was a recent call for input for addition of a new EIP editor. I understand that all client devs may not be, participating in this decision-making process, but it would be… helpful for them to learn about, like, why this is there in the first place. So, I… I proposed here that this call for input should be moved out of ETCAT Herder's GitHub repository to Ethereum slash PM repository for broader visibility.

And I believe the fourth and the last item was a minor update to EIP7723, which we can perhaps take it async, and I would appreciate any feedback and, response in that. With that, I would also like to maybe, invite Jocham if he's on the call, because he had some special points that I believe he wanted to share in order to, like, move the needle, suggesting that these changes are important.

Jochem Brouwer: Yes, I will keep it short. I really think that we should add, like, this ACDG. I already see in chat that people are, well, bringing up the point that another meeting might be too much, and suggestion from Newcast is to actually add this to ACDT. I just want to add that I personally think that we need a call, or at least that we integrated in a portion of a call. Where we, start to discuss the governance process itself, because… At these calls, as also for today, days are, like, super packed, and we don't have time to discuss the process itself. We will just use this call to make decisions. And if people think that this process of improving the decisions should be changed, or that people have complaints about this, then I think we should have a call about this. So this is why we want to rename EIP IP.

to ACTG, And I think that we should, we should do this to discuss, improving the process. there could be specific things about specific ERPs, which I won't mention now, but I think that especially the visibility of this should be raised, because these calls, these IP calls have been there for a long time, but they are just not attended, and I think That, people either not know about the existence of those, Or, yeah, well, I basically think that because ACD, E's, and C's are visited a lot, and these calls are not visited. So I really think that we should add these calls, because I think everyone would agree that if we have, like, a specific goal to improve the decision process, then we should do this. Yeah, thank you.

Ansgar Dietrichs: Just to, mention, we won't have time today for synchronous discussion, so Lukash, if you have a kind of comments on that proposal or something, then…

Łukasz Rozmej: I think… Yes.

Ansgar Dietrichs: Copy, though, right?

Łukasz Rozmej: Okay, sorry.

Ansgar Dietrichs: Just because we don't have time for that today, unfortunately. Just so we can get through the scoping. Yeah, thank you, Johann. Pooja, was this… did this conclude the section? Pooja, was there anything else to add, or was that it?

Pooja Ranjan: No, I just want to request everyone to just take a look at it, and please provide us feedback asynchronously. We will try to collect all of them and get back in future meeting when needed.

Ansgar Dietrichs: Perfect. Yeah, and I'm sure in future calls there might also be time for synchronous discussion of these, but today, really just wanted to give some room, so they can already present these proposals, but, Yeah, go and leave comments asynchronously for now. Perfect. Thank you very much, Pooja and Jochem, for these updates. And then with that, we will move on to the, glamsterdam scoping section of the call. before we get into it, just one update from the, state growth, EAP side specifically. So, on last call, we, said that until basically today, people would look more into, the situation to come up with a finance proposal. The situation is as follows. As maybe it's not super surprising, it was a little bit slower to actually, have worked on this done over the holidays than initially, hoped.

the people working on this still ended up with an update to the EIP, so that is EIP 8037. state creation gas cost increase to reflect the current, kind of best approximation of the plan going forward. However, after several discussions today as well, including with the Pandorps team and with other teams, the feeling overall was that, really, it would be premature to make the decision today, just because things might considerably… would considerably change between now and next week's ACDE, at which point then we would be in a… much more comfortable position locking decisions in. So the recommendation would be to, have this be pushed one last time to next week. Of course, if people here disagree, we can always override that recommendation and make a decision today, but,

yeah, given also that we only have 45 minutes today, and we have a 90-minute call next week, I'd rather try to get through all the other ERPs for now. M… I will, yeah, so if anyone violently disagrees, then please basically, like, voice that. Now, otherwise, I would just then move on to the main ERP section. Do we have someone to share the screen for the document? I think Nexo, maybe you want to do that?

Nixo: Yep, I will do it.

Ansgar Dietrichs: And so the idea would be that we just keep going where we left off last time instead of starting from the top again, so we actually rotate through, and only once we reach the end, we return to the few decisions we actually pushed, last week. So if we scroll down a little bit, we basically made it to, here, to the… Yeah, basically now at the top, well, not gonna go quite as far, to the contract section, basically, above Audit Utility. So last week, we, on the topic of contract size, that you can see at the top of the screen, we ended the call by making a DFI decision on EIP 2926, that is the chunk-based code localization, and again, for context, that was because, there was too much disagreement on whether

the scope of… of a tree change would be… would be too large for this hard fork, and so the idea is to just delay that decision until H star. So then the next decision up would be the EIP you see underneath, which is, EIP7907, which we already considered for Fusaka. It is the, the smaller EIP, that's maybe more, you can think of it as, like, a one-time hotfix to just allow a little bit more, contract size. So the question now, basically, would be, do we want to include this into, Glamsterdam already to have basically a smaller, increase to the… to the maximum contract limit, or do we want to just wait for the more proper thing that we will do either way, likely in H-star?

Do we have, people with opinions on this one. Ben.

Ben Adams: Yeah, to support this, it would make, a massive UX, experience. We didn't include it in… Busaca, because it came in quite late, and it proved A little bit too big, because we weren't… we weren't originally putting the length in the account. And… That became a little bit complicated, and so… It was more that it was late in the process than it was a terrible. And adding the length to the account is also what trunk-based verticalization would do, so it's a… it's a compatible thing.

Ansgar Dietrichs: Guilla? We can't hear you, Guyo. If you're talking.

Guillaume Ballet: Sorry, yeah, classic. Classic, forgot to unmute. Resuming the conversation from last time, I think this is not the right thing to do, simply because, yeah, there is a better proposal, which was indeed deified, but that's okay, there's actually a lot more proposals that are better than this one. And if you… what you need is a cosmetic change, I think you can just… you know, increase the code size limit to a little bit more, maybe 32 kilobytes. There was a proposal by Julio back in June. where you would just do this and not change the gas cost. Because the problem with the gas cost, like, changing the gas cost, is that people are going to do gas golfing, they're going to optimize, and then we're going to find ourselves

Yeah, just do that, don't make it too big, but if you want to create a new, a new gas model, it's going to be… Yeah, people are going to work around it, and this gas model proposed in that EIP, just 2 gas per bytes, where does that come from? It's not consistent with… it's not consistent with the rest of the storage model. blocked, because as soon as we try to propose a proper fix, people always say, oh, but my use case is optimized for this thing. You can't do that anymore. We've been there many times. The last one I remember especially was the removal of self-destruct, but there's been other things. If it was consistent, we would have a lot higher gas per byte. It's also a bit weird, because the first 24 kilobytes are free, but then they're not. So, actually, it sounds like reading the first 24 kilobytes is free, but it's not, it's just…

So, I think… If you really want an increase in code size. Up until 24KB is completely free, and then it's not, so that's a bit awkward, and this is guaranteed to cause people to start optimizing around this, and we're going to have some issues.

Ansgar Dietrichs: Ben?

Ben Adams: I wouldn't object to just going for the straight increase that's proposed, if that's… That's the, switch.

Ansgar Dietrichs: Yeah, and maybe just one comment on this, of course, from the repricing side, given that this time around in the Hartford, we will actually change prices anyway, we could take, basically, the worst case that would come from a small, just, base increase, so if we were to just go through 32 kilobytes or something, we could just take that into consideration on the pricing side. That was… less of a realistic option in Fusaka, where we just didn't want to do otherwise repricings. So, indeed, this, like, even simpler than this proposed EAP would Wouldn't be more possible this time around. Charles?

Charles Cooper: Hello, yeah, I just want to point out that the first 24 kilobytes is not free, it's just the price is unchanged, so it's backwards compatible, and The 2 gas per byte is not out of line with the rest of the storage model, because the read from the disk is, like. A sequential read, and it's very different from a random access. key-value lookup.

Ansgar Dietrichs: Right. Yeah, so the thing is, I think it would be really nice to make a decision today. I think that the options that we have would be either to go with the CAP7907, Or to go with the simpler change of just basically a static small bump of the maximum size. Obviously, technically, we don't have a PFI DIP for that. I personally think replacing this existing one with a simpler one would be fine process-wise, but of course, we would have to double-check if people agree. Or option three, just to not do anything about contract size in Glamsterdam. Yeah, it would be good for us to come to a conclusion today. So far, it seems like opinions are mixed on these three options. Do we have other people, other clients, with views on this?

Preferences across these three options.

EF Berlin office: I guess one other thing I would keep in mind is, like, there is a bigger design space within the, yeah, the 7907 world than, like, I think that particular EIP has explored, right? So, like… one example is, that, you can, like, I think it would be rational to make the gas price, like, fully linear and actually charge less for contracts that are smaller than 24 kilobytes, which would, give us room for increasing the cost of accessing the full-size ones, and then, like, basically we would just charge existing ones at the 24 kilobyte level. Or if you don't want to do that, potentially solve it with a refund. So, like, if we, yeah, believe in the principle that, like, in today, at least, you know, like, before we have.

some kind of perfect world model where, like, you know, like, trees are better or something else, Then, like, we agree with the principle that, like, bigger contracts should cost more to access than smaller contracts, then, like, there's… ways to do that that don't fit the, yeah, like, that aren't the, yeah, ex… the exact numbers in 7907, and so I think it might be, yeah, also worthwhile to kind of, like, split apart that question, and then, like, once we, yeah, make that decision, then, Like, then think about the constants. Hmm.

Ansgar Dietrichs: Right, so the decision today would be first more about the mechanism approach, so do we do the constant bump, do we do the 7907 change, or don't we… do we not do any change? And then, yes, we can revisit the specifics, say, of 7907 in case we end up going with that. yeah, Ben?

Ben Adams: I mean, it is… I have been a smart contract developer. Prior, and the 24K is a very annoying, limit, because you're normally We normally… Hit it, even if you're trying to optimize as much as you can. And so a small increase would probably take the edge off for a lot of… a lot of developers. And then larger sizes, maybe we can look at. Doing something more intelligent later.

Ansgar Dietrichs: Right. Barnabas has a question in chat about the kind of size of 7907, whether this might be too large. I personally don't remember it being proposed as a headliner or anything like that, but, Yeah, of course, the question would be whether clients feel comfortable with Adding 7907 to an already relatively large, fork? Do we have… maybe… so we've heard from Guillaume, and we've heard from Ben, from the NetherMind side. Do we have other client devs that have, maybe, either this time around, or back for Fusaka, looked at 7907 and have an opinion on The complexity involved, of a mechanism like that. And how comfortable they would be having this part of the fogscope this time around.

Ben Adams: I mean, the… if we do the simple bump, that's obviously… Very minimal change. The 7907 changes the account structure, because it adds the length. So… it is… is more invasive, but, I mean… Chunk-based code also wanted that… that change. But the simplest would be… Just to bump the size, and then we don't have to change any of the data structures.

Ansgar Dietrichs: I see. We have a comment from the testing team in chat saying that the complexity for 7907 is… medium to high, if I read that correctly. To me, yeah, that at least puts it a little bit in question, whether we have enough room in the part fork that's already relatively large.

EF Berlin office: Can I, quickly propose a small delta to 7907 that would, probably solve the problem, which is you just charge based on max cost, and then once you read the code, you refund based on the actual size.

Ansgar Dietrichs: Yeah, I think there's just some concerns around, maybe, some of these, like, very old hard-coded stipends that. Might not be enough for that, but… Right. M… Yeah, it… that's… I… I don't know, like, I… so right now, I see the… the two options I see is… given that, given that there's this… the concerns about the scope, at least, it doesn't seem obvious that we have a decision basis to include 7907 today. I think the two choices that we then… I mean, unless there's more support by more clients right now, which there doesn't seem to be. I think the only two decisions we then have left is either we go with making a decision for, you know, either nothing or this just constant bump from 24 to 32, for example. Now…

Otherwise, if given that there is so much interest in this mechanism now, it seems like if people are actually committing to working on this over the next week, we could have this be one of the two last decisions we revisit next week, but only if there's actually people committing to actually working on it in the meantime. Otherwise, I think it would be… not be useful. And Greg?

Greg K | Lido: Yeah, so, I had emphasized also in the previous ACD call that, I think it's quite important to increase the max contract size, so… and I think that there are… there were more client teams supporting this, but perhaps some people are not here today. So I will definitely… Disagree to just doing nothing. I… We might do this kind of, simpler bump, but, I would strongly disagree to, like, do nothing. We could discuss if we do the full EIP or just some smaller, chains. But, yeah, this request for larger contract sizes was already a long time ago, even for Fusaka, so I don't think we should delay more on this. And then, of course, for H-star, we could do a more kind of long-term approach.

Ansgar Dietrichs: Yep, sounds good. Yeah, so, given that, I think we also need to move on to the other ERPs, here's a proposal. I know people don't want to delay further, but I think goal for next week. next week's ACDE is to really absolutely finalize and close the scoping. So that's why I would, personally propose that we have pushed this decision one more week, but with the understanding that on next week's call, if people… if we don't come on and people have specifically worked on 7907 in depth in the meantime, it is out of consideration. It seems like it's… the uncertainty about the scope and the variance would mean that either people work on it In this week in between, or we only have the choice between the constant bump to 32, or

doing nothing in Glamsterdam. So that's basically understanding, so there won't be… otherwise, we won't have, like, infinite deliberations on 7907 anymore next week. Is that okay with people?

Lightclient (Matt Garnett): I mean, isn't that what we said for this call?

Ansgar Dietrichs: I don't think we actually talked about 7907 at all, last week. Oh, sorry, before, before Christmas, the ACD, we didn't get to it.

Guillaume Ballet: We did talk about it through 2926.

Lightclient (Matt Garnett): I mean, I think we just keep saying, you know, next call, if someone has actually done something on it, then we'll make a decision, and people just aren't working on it. So I don't think it's gonna change again. Between now.

Ansgar Dietrichs: posing to DFI today?

Lightclient (Matt Garnett): If we want to have faster forks, we need to just be realistic, and this doesn't have a lot of… clarity from clients, and we already have a lot on our plates to deliver with Glamsterdam, so… I think it's totally fine to just plan on doing something in H-star.

Jochem Brouwer: Yeah, I just want to add, as I said in the chat, I don't want to overload myself, but I also think that this contract code size increase is, like, a big community ask, so I think we should at least try to do something. As I said, I don't want to overload myself, but I will like to assist here, so I will suggest to indeed delay this decision to next call. And I will… well, I will just try to… to… to do this, yeah. But I could use, like, a lot of help. Yeah, thanks.

Ansgar Dietrichs: just because we need to move on now, like, I understand, Matt, I think you're probably right, but I think, given that there's enough interest here, I will make the decision, we will bump it one more time, but yeah, if by next week no one has really worked on this, like, we don't talk about it anymore, it's gonna be a very quick decision. Like, there's basically, like… Yeah, either there is substantial kind of, like, progress, or it's just going to be a quick decision. Okay, with that, we'll move on to the next ones. So then, we will also… I suggest we also move the decision on 7903 one more time, because that one is basically just in connection, it's the question of.

Do we need more init code size if we have more contract code size, given that we don't know yet whether we will increase contract… it'll be a bundled decision? Which then, leads us to, oh, Marius, did you want to comment on 7903?

Marius van der Wijden: Yes, we cannot remove the import size limit. That's not possible. Because of the… the jump dust attacks. We need to do something more. Small toe, but.

Ansgar Dietrichs: Okay, so then… it's basically the same thing here, like, if anyone actually thinks we need to do something about this, then by next week, you have… you either present work that actually makes it viable to include something like this, otherwise it's also going to be out. But yeah, I don't want to be held up too much by these contract size. discussions. Charles, if you have a comment on just specifically 7903, I would request to maybe push it to next week. Okay, perfect. Then, let's move on to 7997, the factory pre-deploy. That one, it… I marked it as a DFI, kind of, just because it was very… there was very little, feedback by clients, very mixed,

So, given that we have limited room, it's just a default, no, just because there's no clear yes. Has this changed? Have clients, in the meantime, realized that that is a priority for them? Or would we just go with the DFI? yeah, if there's no change from opinion, then I think we just, DFI7997. And then the, the next one, EIP8058, I'm not sure if we have Carlos on the call today, I don't think so, but, he, as the author, he specifically requested to withdraw, the EAP because, because there was, Just, you know, too much focus? Oh, sorry, never mind that. Do you still want to… I just wanted to basically wait with the decision for the call, just in case anyone wanted to object or something, but are you still… you'd still prefer for the CRP to be withdrawn?

CPerezz: Yeah, I mean, I did it so that we can focus on repricings, because there's a lot of confusion already with it, so if no team is hardly interested on this one, yeah, I think we can drop it. It's just a good UX improvement, but it won't be critical.

Ansgar Dietrichs: Yes, Felix, do you have a comment on, 8058?

Felix Lange: No, my question is about the previous decision. It's about the 7997. Because, I was just… I was just curious, so why was it DFI?

Ansgar Dietrichs: Oh, you're right. I mean, you can revisit this one more time, it's just, there was… so, we… if we look at the client votes, we had, two Bs, and an A. for it, that those were the only kind of considerations, and then every time so far it's come up, there's never been anyone arguing for it, so it's just a default. That's why I asked if anyone basically specifically by now thinks it's actually a priority. So if you, for example, would want to argue for, actually, for it, that it should be a priority, I'd be happy to check with the clients to revisit that decision. Would you want to argue for 7997 inclusion?

Felix Lange: I mean, I just wanted to quickly bring up that this particular EIP is very, very small, and it doesn't have… any kind of… so the implementation impact of this is very small. And so, for this reason, I feel like we might either be able to decide it based on a simple vote, or something like that, because there isn't gonna be a lot of… testing, or… It's just about… Making sure that a very specific contract exists in the chain at a known address. So, I would just be curious to basically hear the official statement from all the clients. About this, and it should be decided like that, and not just, you know, because nobody said anything, we're not gonna…

We're just gonna DFI.

Ansgar Dietrichs: Yeah, that's very reasonable. Again, that's why, you know, it was… that's specifically the type of comment I wanted to elicit, someone specifically arguing for it, so we can… we can check with other clients. Justin, do you have an opinion on… 7997? Because you have your hand raised, or is it on a different point? You are muted. Not sure. Yeah, Justin, if you're… Yeah, I don't know, sounds… sounds like Tristan might not be able… To say anything? Any, any, anyone else?

Han, did you want to comment on the EIP?

Han | Stateless: I wanted to comment on AD58, but maybe I'll wait until someone else… Yeah.

Ansgar Dietrichs: Yeah, okay, I mean, we can… I can briefly go through, so, Yeah, I mean, it sounds like we have difficult technical difficulties from the Besu side, Then, do we have anyone from Nethermind, that… that has an opinion on 7997? NetherMind was the only client that ranked it as A.

Ben Adams: I think it's… Oops, there we go.

Łukasz Rozmej: Yeah, we think it's good. It wasn't a priority for us, but we don't oppose it in any way. We think it's actually.

Ben Adams: It also provides, a… Straightforward. entry point for L2s and everything to copy, so that you can have deterministic deployment across chains, because there's… there's some issues with, L2s that are not quite EVM… 100% EVM.

Ansgar Dietrichs: Sounds good. So, maybe, if anyone from Besu, like, I mean, maybe either Justin, or if… voice doesn't work, maybe in chat could briefly say whether Besu would Be open to inclusion, or… I mean, in the meantime, do we have anyone from Erigon or Reth on the call that, could say whether the clients have a take? I think… I think there were no comments from either client on the CIP?

Andrew Ashikhmin: Yeah, so… I would, I'm slightly against it, because I think, We have bigger fish to fry, and with pre-compiles, there will be… Subtle points, like… does it, change… does it actually create a contract? Does it change the tri-state route or not, and things like that. So, there will be… it's not, like, completely trivial to implement.

Ansgar Dietrichs: Right Yeah, so it sounds like there's some interest, there's some skepticism, Felix, you have your hand up again, do you… yeah, do you want to say some more on this, on the UP?

Felix Lange: Sorry, I just left it up, there was no… There's no further comment on this from my end. I really just wanted to raise it in a more formal way than just declining it by default. I do also think that this is useful, and it is useful also in some ways as a prep work for account abstraction, because it removes the requirement to have an EOA to perform the deterministic deployment. So, in some ways, this is actually… Very important for… some roadmap of a construction or something. So there are things there, but Andrew is also right, it has some… They're awesome. untried things in there.

Ansgar Dietrichs: Yeah, so given that, I'm just curious, because I think most people are, kind of, could go either way, like, would you rec… like, just… from… from your… from Geth's point of view, would you prefer this to be in… in Glamsterdam, or would you prefer this? to be revisited for H-star.

Felix Lange: I think it's easy enough for us to put it in the… in Amsterdam. And then, I mean, we can always drop. Like, the way I see it is that, like, if it turns out too complicated, it can be dropped, but it's more like a question of… I… I think it… there's an argument from the guest side, the way we argued it is that, like, most of these, like, simple changes that benefit the community should just be included in Glamsterdam, because Yeah, it's not complicated to do.

Ansgar Dietrichs: Okay, then, yeah, I would, then also just maybe go with also… Barnabas also said this in chat, we can just CFI it for now, and then remove it again, given that it's such a small change, I think that is feasible. And Drew, would that be okay with you from your end?

Andrew Ashikhmin: Yeah, sure.

Ansgar Dietrichs: Okay, then, okay, then we will actually see CFI now, 7997. Thank you, Felix, for… Bringing that up again. And my apologies for maybe going over it too quickly. Then, back to AD58. So again, the author, Carlos, was, basically proposing to just withdraw it, but it sounded like, Han, you wanted to say something?

Han | Stateless: Yeah, I just wanted to say something about this EIP. So, even though our team, sales team, thinks that this is not a prioritized EIP, but, the motivation behind this, EIP is primarily a UX improvement for users and contract developers, since it basically reduces code deposit gas costs. As, what I know is that most clients internally already deduplicate their contract code. So, yeah, it would be nice for users to get this, gas cost discount, but we haven't actually gotten any feedback from contract developers, so it'd be nice if anyone has any opinions on this. But, yeah, another pass point is that it's also highly probable that this EIP is fairly simple to implement and test. So based on our latest analysis on the deployed contracts, 80% of the contracts have a code size under 1KB, so adding this discount likely wouldn't affect the majority.

But that said, given the repricing effort more broadly, longer term, we would still want users to pay for what's actually being stored and not pay redundant costs. So yeah, just to say a few words about this EIP.

Ansgar Dietrichs: Yeah, I think the default would be to go with the intention of the, EIP author, just because if a championed author wants to withdraw, then I think it's best to withdraw, although Carlos did seem to say that if there was strong interest, then of course he'd be willing to reconsider, so… Are there from the client team side? Is there… is there strong interest? It seems like we have not gotten any specific feedback from the smart contract developer's side that… that there was concrete interest in this. Which, yeah, to me indicates we could also wait and revisit this in H-star. Is there any client that would really want to see this in Glamsterdam now already?

Guillaume Ballet: Yeah. So, we are currently discussing it, on a different channel. And, I'm saying we, the stateless team. I think there's a good, interest, that just declared itself, and we would like to, to expand a bit on this. So, I'm going to make, at the team level and the executive decision, to withdraw it. Even though, yeah, it has some potential, but I think if we rework it, a bit, we could actually make a very strong case for it in, in H-star, and I would like to see that. So, yeah, sorry, Han, but I think, it's better for the long term.

Ansgar Dietrichs: then, yeah, with all these comments, I think, this has promise, and I think we hopefully then have a version for it for HSA, but then it sounds like for Glamsterdam, we will… officially DFI it today. Okay, then, we can move on to the next block, which is these… the… what I call the utility EIPs. There was this EIP7668 remove bloom filters. This, the situation there is that every client basically had the… seemed to have a similar opinion, which was basically. this, seems easy and nice to have, but also not super high priority. So in that sense, kind of similar to the deterministic, pre-deploy that we just discussed. So basically now, today would then also be a decision, decision time on this. Do we…

Do clients have an opinion 7668, should this be in Amsterdam, or should this wait for another hard fork?

Felix Lange: So, I can say something, sorry, I didn't raise my hand, but I guess nobody else did. So, one problem with removing broom filters is that it will introduce… some encoding variances, based on fork, and we have seen in the past that this can be problematic, so the implementation of this can actually be There are some… it can actually turn out to be a lot of work. I just wanted to raise it up front. At the same time, it has a nice promise that These filters are basically totally unused, and they are just legacy. So yeah, if we can avoid it, it's nice, but it's definitely something to consider that this can… This can, you can… you can have some issues.

Yeah, so as Matt is saying, there's also the possibility of remove… leaving the… Leaving the filters the same. It's… it's just something to consider, like, when we are hashing the… when we are hashing, receipts, for example, then, we would have to just hash some zero bytes or something, maybe that's a possibility, but either way, like, changing the hashing of receipts in a fork requires some logic in the clients, and it might not be easy to add, or it might be very easy to add, I don't know, it totally depends on client.

Ansgar Dietrichs: Right. So that is an argument for some caution here, although with some of these variants proposed, it could be simple. Is there, yeah, any other client that would… Specifically want this included. I can… I mean, I can go through the list, do we… Nethermine, do we have a… do we have a take on… on the CRP?

Łukasz Rozmej: I'm not talking by the whole… for the whole Nethermine, but just for myself, I… I would skip it to do the scope creep. Why? Because it's… might… might be more complicated than expected.

Ansgar Dietrichs: Okay, so then that's some skepticism for Glamsterdam from both guys and another mindset. Yeah, understanding you're not necessarily speaking for the entire team. Marius?

Marius van der Wijden: Yeah, I also… I'm also, favorable to the argument that instead of just removing it, we could replace it with a… Block filter, so, yeah. I think maybe we should just postpone it for now.

Ansgar Dietrichs: Okay, then I think… We have heard enough, kind of. concerns or ideas to replace it with a different EIP in the next HardFog that obvious decision seems to be DFI. Is there anyone who wants to still argue for CFI? Okay, then for Glamsterdam, we DFI7668. then we can, go to the next one, EIP7745, the Trustless Log Index. My understanding is that there was, part of, like, this broader change that, Salt was working on. I marked the TSDFI candidate just because there was some scope concerns, and I think so far. it was mostly the guest team and Salt that was interested in this. But yeah, as also, do you want to give an update? Do you want to make an argument for inclusion?

Zsolt Felföldi: Yes, thank you. So, so the thing is, as far as I can see, yeah, it's, it's mostly, like, like, like, like, came out, like, this, from the GATT team, and we have our roadmap of this, this, trustless execution API, which is… well, cool as it is, but it would be way more cooler if we could make it, like, full-featured and could, properly prove everything trustlessly, which is, well, yeah, yeah, might be high priority for some and lower for some others. And I think Besu also signaled, like, put it in the A tier. I know, like, Netherland raised, Concerns about high complexity, which Okay, so about the complexity. So I've talked about how to approach this, and so it's a… it's kind of horizontally complex, it's true. Like, it's a complicated data structure, but as far as the implications to the rest of, like, the protocol go, it's, I think, not so dangerous. So, like, it has an input, like, like, like, throwing the logs into the data structure.

and then a root comes out, and everything, and and since the last call, I also did some measurements. Now I have some numbers, not all of them yet, but… So I can also say this is kind of a really performant thing. So, right now, I think, the 7… or 375 gas cost of log addresses and topics could be maintained with this structure added, and so the thing is, I think, I think this thing could also, in the future, have positive implications for scaling, because, like, it's just a lot cheaper to add logs than state entries, and this could be good for, like, cross-chain or cross-shard, or add to communications, or anything, and I'm also trying to work out these ideas as we go.

So, the thing is that, Yeah, I'm not sure, yeah, we have lots of features proposed for Glamsterdam, but the thing is, if we just deify this now, then probably I will keep working on this mostly alone, trying to get some interest around it, but also, like, this is a big thing, and maybe it's just too big to, like, next time at the H-star decisions, I just don't want to be at the same place. So, yeah, I was still… argue for maybe CFI English now, and, so that just we consider it. It means considered for inclusion, not scheduled, and, and, and, and, and so that, like, like, we start, like, more inter-team communication about this, and we figure out.

yeah, how much time it takes, and if it takes more time, then yeah, it's fine to defer it to H-star. I just think, like, this is an important… thing, not just because it's my project, but… but yeah, so I… I think I… each… each week, I will have better and better arguments for it, but, yeah, so… That's… that's what I wanted to add.

Ansgar Dietrichs: Okay, thank you. And just from the process side, like, I think for a CFI decision, we would need at least rough consensus from all clients, for inclusion, or at least preliminary inclusion. So, so far, signaling-wise, NetherMind and Erigon had signaled against it, so we would need them to change their minds to move to CFI. Marius?

Marius van der Wijden: Yeah, I, I'm only arguing on behalf of myself. And, just wanted to, like, kind of talk a bit about my opinion about this. I think it's a very good idea, and I think it is going to be… Much more important going forward. In the future, where not all nodes will have will have the state, and not all nodes will have the receipts. It is, much more important to… to where we… to be able to query stuff trustlessly, so I think this is definitely a step in the right direction. from a… I… I don't think we should ship it in Amsterdam, in my personal opinion. I think it's… Not as, important as some of the other things, but I think there should be significant work going into this so that it is, able to ship in, in, in extra.

Because again, The more we move away from from, like, Every node having everything, the more important it will become to have trustless, Ways of querying stuff. And this provides a trustless way to query receipts and events, which is really nice.

Ansgar Dietrichs: Lukash?

Łukasz Rozmej: So, I, I agree that this is, unlocks interesting use cases, so completely agree here, and this might be really, really useful, so… it's something I would also like to see at some point, maybe not even at that long point. But the problem is, again, and I kind of seize with some… with some of Guillaume EIPs, that those EIPs are very important, and they address a lot of, like. tech depth, kind of, in some way, or features that were kind of missed, but are really useful. But they are not really hot and sexy, but they are, on the other hand, on the size of headliners. and, like, in a really, really big way, so… unless we kind of agree that we are doing some…

more just address, those, tagged them, or kind of headliners in some way. It's really hard to schedule those, because I agree, I get that Geth team, for example, has this log build already, has this thing more or less done, so it's easy for them, but… I disagree that it's easy for everyone just to catch up, and I also disagree that this isn't dangerous, this is as dangerous as it can get, because this is a potential consensus issue on… On a stateful data structure that is big, which is the hardest thing to debug. like, it's State 3 kind of, consensus-level issue generating, structure, right? So, Yeah, so I would like to have this kind of thing at some point, but again, if we want to schedule that, we probably need to schedule that as a headliner, or as a… in a fork that has maybe another headliner, and just this, and nothing really big that we can really focus on that for a longer period of time.

Ansgar Dietrichs: Yeah, so it seems like the decision is trending towards DFI with several clients with concerns, but come back now?

Tamaghna Choudhuri: Yeah, hi. So I have been working on Pureths, and under that, I have been working on this too. So, the thing about… inside the Nimbus EL, so the thing that the team, both Dustin and Ethan, are agreeing on is, it's better to have this for the next fork, and also, from an implementation standpoint, as I've been working on it, some things, it would be better to have more tests, like, let's say, the minimal state index that we need to to send through the wires and other stuff. So, like, it's better to have it in the next fork than the current fork.

Ansgar Dietrichs: Okay, Felix?

Felix Lange: I'm sorry, I just wanted to go back to the argument that was presented by, Abukas right now, so the, and maybe tie it also to what Joel said, so one of the things about this EIP Is that… it introduces Logic in a place where we didn't have the logic before, which is in the, as a kind of post-processing step after indexing transactions, after processing transactions. And I think for that reason, it actually has slightly lower danger, because it is not really on the main path of executing an individual transaction, but rather than it's just, like, an update to a data structure. And the update function is the same for all Transactions, so it's basically a data structure that supports one operation, which is to append Items?

And then it has another operation to compute the root. So I think, for this reason, it's actually quite easy to test it exhaustively, and I think it makes it less dangerous. Maybe it's something to consider to… I don't know, change your mind or something, but I think it's something where if a single person can work on this, and basically create an implementation, and then also exhaustively test it. Whereas with some other changes that are related with EVM execution, or things like that, it can often have a higher complexity because it ties in with the other workflows that the client has, or the state implementation, or… But this isn't like that.

Ansgar Dietrichs: Right. Yeah, I mean, purely on process grounds, I just would say that, again, we would need rough consensus of clients to move this forward to CFI. So far from the comments, that doesn't seem to be the case with M. With some of these objections around, scope, And I… yeah, so I… I think unless you can live convince People right now, and we are basically approaching the end of the call. I think we don't really have much of a choice but to DFI it, but, Sol, do you want to… Have a quick… one quick more comment?

Zsolt Felföldi: Yeah, I just wanted to add that, okay, so the process… is what it is, but, I mean, I mean, I mostly just, want to make sure to somehow get the ball rolling, and, from, like, like, Lukash's comment, I sense that, okay, it is pretty great that at least, yeah, others are now interested in this, so… I mean, if in any way we can start working on this, like, together, and I will try to, like, reach out more and share whatever I have, then… Yeah, I mean.

Ansgar Dietrichs: Yeah.

Zsolt Felföldi: So if we DFI is now, I just… I would just like to ask somehow to just also spend a little bit of thought on this and start working on it. I mean, others should just… just give it a little… some priority or some… some… some resources, but, yeah. Okay, so probably I will not live convince everyone in this call, like, in 10 seconds, right? I don't know, so yeah, that's it.

Ansgar Dietrichs: Yeah, I think this is… we sometimes have these situations, I personally think it's probably just very tough to, go through the Ocodevs calls, the synchronous calls directly, to basically change people's minds whenever there are changes where there's already pre-set opinions by clients. I think for this, often, like, breakout calls and these types of processes can help a lot, so what then my recommendation would be, well, like, my proposal for today would be to say we DFI it for Glamsterdam, just because I don't think we will, in time. Have enough change of mind from clients. But then maybe, Zald, if you could, I think, ideally, maybe be in touch with Nick, so I think that would be the easiest, and discuss, like, one… maybe not immediately, because people's mind will now still be on Amsterdam, but, like, at what moment in time over the next month, it might be a good time to just organize an ACD breakout.

on this topic. I think that would actually be a really good way of, outside of the main ACD schedule, basically make progress on this and make sure that it's not in the same place again for HSTAR. Would that be okay with you?

Zsolt Felföldi: Yes, absolutely. I think we already spent, quite a lot of time on this, on, like. the ACD, so right now, we just have to figure out how and better we can move forward this. So yeah, let's do breakouts, and as Lukash also suggested, maybe I should just propose it for headliner for H-star. Yeah, but actually, actually, yeah, I… I'm not really… I wouldn't really want to do… make it a headliner, but yeah. We will figure this out, and probably we won't figure this out on this call. So yeah, let's do a breakout. Alright.

Ansgar Dietrichs: Yeah, sounds good. And then, so then I propose to DFI it for now, for Amsterdam. Any last objections to this? Felix, you still have your hand up, but it might be from the previous comment. Yeah. So, any objections to DFI now, then, for Glamsterdam? Okay. than, than we deify this. So yeah, then, I think we reached the end of the call, the ACDT slot is only 60 minutes, not 90 minutes, We have, we have one more. Mug?

Marc Harvey-Hill: Hi, so I just wanted to very quickly, raise something, because, so 7793 is the next to be discussed, so I assume we'll cover that next week. But I made this thread, which kind of briefly explains it, and I can… wait, I'll try and share that in the chat. Okay, I can't share it in the chat, but I'll add it to the next agenda, and it'd be great if anyone had any feedback on the EIP, if they could share that there, to help us make a decision next week.

Ansgar Dietrichs: Yeah, that sounds good. Just a very quick, question because Nixon. Chad just asked about, are we not going for 90 minutes? My understanding is, I just saw it on the calendar. scheduled for 60 minutes. I'd be happy to go for 90, but I feel like… I assume people probably planned for 60, given that that's what it was on the calendar for. I also do think we're actually now in a good shape to really finalize the scope next week. I think we went through enough EIPs, so just to mention, so basically the last ones that we will basically have to discuss, then on next call. is 7793, conditional transactions. That one is flagged as maybe the default DFI just because there wasn't much… so much active interest on the last calls, and Geth specifically only put it in C, so if…

the champion could convince Geth asynchronously until next week, that would make a big difference for its chances of success. The payoff code, same thing, kind of like default EFI, just because we only had Cs and Bs from all the clients, so it doesn't seem likely that there's enough interest to get it included. We have one more EIP on the crypto quantum side that we have to discuss. 8051, I think. the big default would be to delay all the quantum changes until next fork, and again, if someone disagrees with that, they would have to try to convince core devs. asynchronously, we have some of these questions… these non-protocol changing EIPs, where we have to just make a decision whether they should be part of the focus group or not, including this one specifically about revert creation in case of non-MP storage, where we just have to decide process-wise where that even fits in general.

And then, with all of those things out of the way, the last two, earlier ERPs that we have to revisit would be, one on the, storage, the state growth, basically, like, how do we exactly handle state growth, and then the, contract size, question. So these are all the decisions left for next Thursday. I think that is a very realistic scope for one call. And then the goal really is that, and we will also timebox all these discussions, that we… at the end of next week's call, we have a finalized at least CFI scope for Glamsterdam, and then, of course, EAPs can still fall off if they end up causing problems down the road. Yeah, does it sound good for everyone? Then I think now's a good stopping point.

Yeah? Thank you all for attending, and yeah, I can't wait for 12 Amsterdam Scope finalized. This has been a lot, but thank you all for the patience, and see you next week.

Jochem Brouwer: Thank you.

Marius van der Wijden: Pretty good.

Andrew Ashikhmin: Thank you, bye-bye.

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