Ansgar Dietrichs:Perfect, hello everyone, welcome to…
Transcript
Ansgar Dietrichs:I always have to look. All Core Devs 20… 227.
Ansgar Dietrichs:Happy New Year, everyone!
Ansgar Dietrichs: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.
Ansgar Dietrichs:Mmm…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Pooja Ranjan: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.
Pooja Ranjan: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
Pooja Ranjan: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.
Pooja Ranjan:For many years, EIP IP meetings have served as the primary venue for EIP and network upgrade process improvement discussions.
Pooja Ranjan: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.
Pooja Ranjan: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.
Pooja Ranjan:So, I imagine that some of them could have been closed sooner rather than later, because
Pooja Ranjan:if we all have been in sync. So, I think that this problem can be solved if we come up with rebranding and renaming.
Pooja Ranjan:Ethereum is kind of privileged to have some of the most brilliant developers in the ecosystem, and with due respect, all
Pooja Ranjan: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.
Pooja Ranjan: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.
Pooja Ranjan: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.
Pooja Ranjan: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…
Pooja Ranjan: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.
Pooja Ranjan:as, interested.
Pooja Ranjan:The next one, I have got is,
Pooja Ranjan: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,
Pooja Ranjan: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.
Pooja Ranjan: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
Pooja Ranjan:Filling this field appropriately while we are reviewing the proposal and making it merged.
Pooja Ranjan: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…
Pooja Ranjan: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.
Pooja Ranjan: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.
Pooja Ranjan:One in your mind, and that can be, perhaps, added as an, as a process improvement.
Pooja Ranjan:The next thing is a call for input.
Pooja Ranjan:Yes. So, next thing is a call for input. So, call for input is a process that is being,
Pooja Ranjan: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
Pooja Ranjan: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…
Pooja Ranjan: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.
Pooja Ranjan: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,
Pooja Ranjan:response in that. With that, I would also like to maybe,
Pooja Ranjan: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.
jochem-brouwer: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.
jochem-brouwer:Where we, start to discuss the governance process itself, because…
jochem-brouwer: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.
jochem-brouwer: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.
jochem-brouwer:to ACTG, And I think that we should, we should do this to discuss, improving the process.
jochem-brouwer: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
jochem-brouwer:That, people either not know about the existence of those,
jochem-brouwer:Or, yeah, well, I basically think that because ACD, E's, and C's are visited a lot, and these calls are not visited.
jochem-brouwer: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,
Ansgar Dietrichs:Yeah, go and leave comments asynchronously for now.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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,
Ansgar Dietrichs: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.
Ansgar Dietrichs:the people working on this still ended up with an update to the EIP, so that is EIP 8037.
Ansgar Dietrichs: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
Ansgar Dietrichs:things might considerably… would considerably change between now and next week's ACDE, at which point then we would be in a…
Ansgar Dietrichs: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,
Ansgar Dietrichs: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.
Ansgar Dietrichs:M…
Ansgar Dietrichs: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?
Ansgar Dietrichs: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…
Ansgar Dietrichs:Yeah, basically now at the top, well, not gonna go quite as far, to the contract section, basically, above Audit Utility.
Ansgar Dietrichs: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
Ansgar Dietrichs: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,
Ansgar Dietrichs:EIP7907, which we already considered for Fusaka. It is the,
Ansgar Dietrichs: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
Ansgar Dietrichs: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?
Ansgar Dietrichs:Do we have, people with opinions on this one.
Ansgar Dietrichs:Ben.
Ben Adams:Yeah, to support this, it would make, a massive UX, experience. We didn't include it in…
Ben Adams:Busaca, because it came in quite late, and it proved
Ben Adams:A little bit too big, because we weren't… we weren't originally putting the length in the account.
Ben Adams:And… That became a little bit complicated, and so…
Ben Adams:It was more that it was late in the process than it was a terrible.
Ben Adams: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?
Ansgar Dietrichs:We can't hear you, Guyo.
Ansgar Dietrichs:If you're talking.
Guillaume: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.
Guillaume:And if you… what you need is a cosmetic change, I think you can just…
Guillaume:you know, increase the code size limit to a little bit more, maybe 32 kilobytes. There was a proposal by Julio back in June.
Guillaume: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
Guillaume: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.
Guillaume:So, I think… If you really want an increase in code size.
Guillaume: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…
Guillaume: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.
Guillaume: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…
Guillaume: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
Ansgar Dietrichs: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…
Ansgar Dietrichs: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
Ansgar Dietrichs:Wouldn't be more possible this time around. Charles?
Charles: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
Charles: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.
Charles:A sequential read, and it's very different from a random access.
Charles: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,
Ansgar Dietrichs: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
Ansgar Dietrichs: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?
Ansgar Dietrichs: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…
EF Berlin office: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.
EF Berlin office: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.
EF Berlin office:some kind of perfect world model where, like, you know, like, trees are better or something else,
EF Berlin office:Then, like, we agree with the principle that, like, bigger contracts should cost more to access than smaller contracts, then, like, there's…
EF Berlin office: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,
EF Berlin office:Like, then think about the constants.
EF Berlin office: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.
Ansgar Dietrichs:yeah, Ben?
Ben Adams:I mean, it is… I have been a smart contract developer.
Ben Adams:Prior, and the 24K is a very annoying, limit, because you're normally We normally…
Ben Adams:Hit it, even if you're trying to optimize as much as you can.
Ben Adams:And so a small increase would probably
Ben Adams:take the edge off for a lot of… a lot of developers.
Ben Adams:And then larger sizes, maybe we can look at.
Ben Adams: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,
Ansgar Dietrichs:Yeah, of course, the question would be whether clients feel comfortable with
Ansgar Dietrichs:Adding 7907 to an already relatively large, fork?
Ansgar Dietrichs:Do we have…
Ansgar Dietrichs: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
Ansgar Dietrichs:The complexity involved, of a mechanism like that.
Ansgar Dietrichs: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.
Ben Adams:The 7907 changes the account structure, because it adds the length.
Ben Adams:So… it is… is more invasive, but, I mean…
Ben Adams:Chunk-based code also wanted that… that change. But the simplest would be…
Ben Adams: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
Ansgar Dietrichs:the complexity for 7907 is… medium to high, if I read that correctly.
Ansgar Dietrichs: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.
Ansgar Dietrichs:Might not be enough for that, but…
Ansgar Dietrichs:Right.
Ansgar Dietrichs:M…
Ansgar Dietrichs:Yeah, it… that's… I… I don't know, like, I… so right now, I see the… the two options I see is…
Ansgar Dietrichs: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.
Ansgar Dietrichs:I think the only two decisions we then have left is either we go with
Ansgar Dietrichs:making a decision for, you know, either nothing or this just constant bump from 24 to 32, for example. Now…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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…
Greg K | Lido:Disagree to just doing nothing.
Greg K | Lido:I…
Greg K | Lido: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.
Greg K | Lido: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.
Greg K | Lido: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.
Ansgar Dietrichs:next week's ACDE is to really absolutely finalize and close the scoping. So that's why I would, personally propose that we
Ansgar Dietrichs: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
Ansgar Dietrichs:In this week in between, or we only have the choice between the constant bump to 32, or
Ansgar Dietrichs: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: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:We did talk about it through 2926.
lightclient: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.
lightclient:Between now.
Ansgar Dietrichs:posing to DFI today?
lightclient:If we want to have faster forks, we need to just be realistic, and this doesn't have a lot of…
lightclient: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.
jochem-brouwer: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.
jochem-brouwer:And I will… well, I will just try to… to… to do this, yeah.
jochem-brouwer: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…
Ansgar Dietrichs:Yeah, either there is substantial kind of, like, progress, or it's just going to be a quick decision.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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?
Ansgar Dietrichs: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.
Marius van der Wijden:That's not possible.
Marius van der Wijden:Because of the… the jump dust attacks.
Marius van der Wijden:We need to do something more.
Marius van der Wijden:Small toe, but.
Ansgar Dietrichs:Okay, so then…
Ansgar Dietrichs: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.
Ansgar Dietrichs:discussions. Charles, if you have a comment on just specifically 7903, I would request to maybe push it to next week.
Ansgar Dietrichs:Okay, perfect.
Ansgar Dietrichs: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,
Ansgar Dietrichs:So, given that we
Ansgar Dietrichs: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?
Ansgar Dietrichs:yeah, if there's no change from opinion, then I think we just, DFI7997.
Ansgar Dietrichs:And then the, the next one, EIP8058,
Ansgar Dietrichs: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,
Ansgar Dietrichs: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 (Geth):No, my question is about the previous decision. It's about the 7997.
Felix (Geth):Because, I was just…
Felix (Geth):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.
Ansgar Dietrichs: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
Ansgar Dietrichs:check with the clients to revisit that decision. Would you want to argue for 7997 inclusion?
Felix (Geth):I mean, I just wanted to quickly bring up that this particular EIP is very, very small, and it doesn't have…
Felix (Geth):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…
Felix (Geth):testing, or… It's just about…
Felix (Geth):Making sure that a very specific contract exists in the chain at a known address.
Felix (Geth):So, I would just be curious to basically hear the official statement from all the clients.
Felix (Geth):About this, and it should be decided like that, and not just, you know, because nobody said anything, we're not gonna…
Felix (Geth):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…
Ansgar Dietrichs:7997?
Ansgar Dietrichs:Because you have your hand raised, or is it on a different point?
Ansgar Dietrichs:You are muted.
Ansgar Dietrichs:Not sure. Yeah, Justin, if you're…
Ansgar Dietrichs:Yeah, I don't know, sounds… sounds like Tristan might not be able…
Ansgar Dietrichs:To say anything? Any, any, anyone else?
Ansgar Dietrichs: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,
Ansgar Dietrichs:Yeah, I mean, it sounds like we have difficult technical difficulties from the Besu side,
Ansgar Dietrichs: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.
Ben Adams: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
Ben Adams:EVM… 100% EVM.
Ansgar Dietrichs:Sounds good. So, maybe, if anyone from Besu, like, I mean, maybe either Justin, or if…
Ansgar Dietrichs:voice doesn't work, maybe in chat could briefly say whether Besu would Be open to inclusion, or…
Ansgar Dietrichs: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,
Andrew Ashikhmin:We have bigger fish to fry, and with pre-compiles, there will be… Subtle points, like…
Andrew Ashikhmin: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
Ansgar Dietrichs: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 (Geth):Sorry, I just left it up, there was no…
Felix (Geth):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.
Felix (Geth):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.
Felix (Geth):So, in some ways, this is actually… Very important for…
Felix (Geth):some roadmap of a construction or something. So there are things there, but Andrew is also right, it has some…
Felix (Geth):They're awesome.
Felix (Geth):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?
Ansgar Dietrichs:to be revisited for H-star.
Felix (Geth):I think it's easy enough for us to put it in the… in Amsterdam.
Felix (Geth):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…
Felix (Geth):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
Felix (Geth):that benefit the community should just be included in Glamsterdam, because
Felix (Geth):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…
Ansgar Dietrichs:Bringing that up again.
Ansgar Dietrichs: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.
Han | Stateless:As, what I know is that most clients internally already deduplicate their contract code.
Han | Stateless:So, yeah, it would be nice for users to get this,
Han | Stateless: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.
Han | Stateless: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.
Han | Stateless: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.
Han | Stateless: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,
Ansgar Dietrichs: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…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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:Yeah. So, we are currently discussing it, on a different channel.
Guillaume: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.
Guillaume: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…
Ansgar Dietrichs:officially DFI it today.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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…
Ansgar Dietrichs:Do clients have an opinion 7668, should this be in Amsterdam, or should this wait for another hard fork?
Felix (Geth):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…
Felix (Geth):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
Felix (Geth):There are some…
Felix (Geth):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
Felix (Geth):These filters are basically totally unused, and they are just legacy.
Felix (Geth):So yeah, if we can avoid it, it's nice, but it's definitely something to consider that this can…
Felix (Geth):This can, you can… you can have some issues.
Felix (Geth):Yeah, so as Matt is saying, there's also the possibility of remove… leaving the… Leaving the filters the same.
Felix (Geth):It's… it's just something to consider, like, when we are hashing the… when we are hashing, receipts, for example, then,
Felix (Geth):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.
Ansgar Dietrichs:Is there, yeah, any other client that would… Specifically want this included.
Ansgar Dietrichs: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.
Łukasz Rozmej: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…
Marius van der Wijden:Block filter, so, yeah.
Marius van der Wijden:I think maybe we should just postpone it for now.
Ansgar Dietrichs:Okay, then I think… We have heard enough, kind of.
Ansgar Dietrichs:concerns or ideas to replace it with a different EIP in the next HardFog that
Ansgar Dietrichs:obvious decision seems to be DFI.
Ansgar Dietrichs:Is there anyone who wants to still argue for CFI?
Ansgar Dietrichs:Okay, then for Glamsterdam, we DFI7668.
Ansgar Dietrichs: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.
Ansgar Dietrichs:it was mostly the guest team and Salt that was interested in this.
Ansgar Dietrichs: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…
Zsolt Felföldi: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,
Zsolt Felföldi:Concerns about high complexity, which
Zsolt Felföldi: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.
Zsolt Felföldi: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…
Zsolt Felföldi: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
Zsolt Felföldi:structure added, and so the thing is, I think, I think this thing could also, in the future, have
Zsolt Felföldi: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.
Zsolt Felföldi:So, the thing is that,
Zsolt Felföldi: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.
Zsolt Felföldi:So, yeah, I was still…
Zsolt Felföldi: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.
Zsolt Felföldi: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…
Zsolt Felföldi: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…
Zsolt Felföldi: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.
Marius van der Wijden: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
Marius van der Wijden:going to be… Much more important going forward.
Marius van der Wijden:In the future, where not all nodes will have
Marius van der Wijden:will have the state, and not all nodes will have the receipts. It is, much more important to… to where we…
Marius van der Wijden:to be able to query stuff trustlessly, so I think this is definitely a step in the right direction.
Marius van der Wijden:from a… I…
Marius van der Wijden:I don't think we should ship it in Amsterdam, in my personal opinion. I think it's…
Marius van der Wijden: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.
Marius van der Wijden:Because again, The more we move away from from, like,
Marius van der Wijden:Every node having everything, the more important it will become to have trustless, Ways of querying stuff.
Marius van der Wijden:And this provides a trustless way to query receipts and events, which is really nice.
Ansgar Dietrichs:Lukash?
Łukasz Rozmej:So, I,
Łukasz Rozmej: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…
Łukasz Rozmej:with some of Guillaume EIPs, that those EIPs are very important, and they address a lot of, like.
Łukasz Rozmej: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.
Łukasz Rozmej:and, like, in a really, really big way, so… unless we kind of agree that we are doing some…
Łukasz Rozmej:more just address, those, tagged them, or kind of headliners in some way. It's really hard to schedule those, because
Łukasz Rozmej: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…
Łukasz Rozmej: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…
Łukasz Rozmej:On a stateful data structure that is big, which is the hardest thing to debug.
Łukasz Rozmej:like, it's State 3 kind of, consensus-level issue generating, structure, right? So,
Łukasz Rozmej: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
Tamaghna Choudhuri: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 (Geth):I'm sorry, I just wanted to go back to the argument that was presented by,
Felix (Geth):Abukas right now, so the,
Felix (Geth):and maybe tie it also to what Joel said, so one of the things about this EIP
Felix (Geth):Is that… it introduces
Felix (Geth):Logic in a place where we didn't have the logic before, which is in the,
Felix (Geth):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
Felix (Geth):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
Felix (Geth):Transactions, so it's basically a data structure that supports one operation, which is to append Items?
Felix (Geth):And then it has another operation to compute the root. So I think, for this reason, it's actually quite easy to test
Felix (Geth):it exhaustively, and I think it makes it less dangerous.
Felix (Geth):Maybe it's something to consider to…
Felix (Geth):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.
Felix (Geth):Whereas with some other changes that are related with
Felix (Geth):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…
Felix (Geth):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
Ansgar Dietrichs:M.
Ansgar Dietrichs:With some of these objections around, scope,
Ansgar Dietrichs:And I… yeah, so I… I think unless you can live convince
Ansgar Dietrichs:People right now, and we are basically approaching the end of the call.
Ansgar Dietrichs:I think we don't really have much of a choice but to DFI it, but, Sol, do you want to…
Ansgar Dietrichs:Have a quick… one quick more comment?
Zsolt Felföldi:Yeah, I just wanted to add that, okay, so the process…
Zsolt Felföldi: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…
Zsolt Felföldi: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…
Zsolt Felföldi: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.
Zsolt Felföldi: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,
Ansgar Dietrichs: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.
Ansgar Dietrichs:Have enough change of mind from clients.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Zsolt Felföldi: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.
Zsolt Felföldi: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.
Ansgar Dietrichs:Yeah. So, any objections to DFI now, then, for Glamsterdam?
Ansgar Dietrichs:Okay.
Ansgar Dietrichs:than, than we deify this.
Ansgar Dietrichs:So yeah, then, I think we reached the end of the call, the ACDT slot is only 60 minutes, not 90 minutes,
Ansgar Dietrichs:We have, we have one more. Mug?
Marc: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.
Marc: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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,
Ansgar Dietrichs:contract size, question. So these are all the decisions left for next Thursday. I think that is a very realistic scope for one call.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs:Yeah?
Ansgar Dietrichs: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.
Chat Logs
00:02:29
nixo:gm
00:02:31
EF Berlin office:Rugged
00:02:33
jochem-brouwer:Happy new years :)
00:03:14
Chris Berry:Happy New Year!
00:04:49
lightclient:a lot of ppl in regular link
00:06:48
Łukasz Rozmej:I'm afraid of too much meeting fragmentation and too many meetings in general. Soon we will need full-time position just to join all meetings.
00:07:31
Barnabas:I’d suggest if we do ACDG, it should replace a ACDT/E/C, instead of adding to it.
00:07:37
jochem-brouwer:Antwoord verzenden naar "I'm afraid of too ..."
This ACDG meeting is about improving the ACD(E/C) process itself so we can focus on the decision on ACD(E/C) and the process improvement in ACDG
00:07:47
nixo:Replying to "a lot of ppl in regu..."
they should start using the calendar or the discord-posted link 🙂
00:08:03
Łukasz Rozmej:Replying to "I'm afraid of too mu..."
yeah but I want to know about those potential changes, they afffect me
00:08:03
Barnabas:Replying to "a lot of ppl in regu..."
whats the “regular link” ? And where does it live?
00:09:09
lightclient:“regular link” is the ACDT one on the calendar
00:09:22
Guillaume:Replying to "a lot of ppl in regu..."
there's a calendar? I only get ACDC in my calendar
00:09:25
nixo:Replying to "a lot of ppl in regu..."
ACDT link - they prolly saved the link cuz it’s a recurring zoom meeting
00:09:50
nixo:Replying to "a lot of ppl in regu..."
@Guillaume it’s on the Ethereum Protocol calendar. listed in the pm repo
00:09:58
Ansgar Dietrichs:Replying to "a lot of ppl in regu..."
did we successfully move everyone over to this call?
00:10:16
nixo:Replying to "a lot of ppl in regu..."
i’ll check
00:10:30
Łukasz Rozmej:not my suggestion
00:10:44
Barnabas:Replying to "not my suggestion"
I’m you now.
00:10:55
Ansgar Dietrichs:we won’t have time for sync discussion of these topics today, you can find the links to these proposals in the github agenda: https://github.com/ethereum/pm/issues/1854#issuecomment-3708564165
00:12:38
Pooja Ranjan:Thank you!
00:14:18
Justin Florentine (Besu):i'm only seeing a black screen being shared, what'd i do wrong
00:15:50 Łukasz Rozmej: So my comment: I don't expect many people joining that ACDG meetings because: already too many meetings, governance & politics is boring ect. So would this meeting mean there are decisions that are made there? Or it will just be proposals which will be brought later to other ACD calls? If that is the case it more "governance breakout room", and it is fine.
Another question how often do you expect those meetings?
00:15:34
Anders Elowsson:Replying to "So my comment: I don..."
It’s a big difference indeed if it is a decision-making body or just a forum for deeper discussion, that can make a recommendation, where the decision is then taken on a regular call for example.
00:15:56
Yassine Ferhane:It’s once per month
00:16:20
Csaba:As a reminder I would have 2 Networking EIPs (8077, 8094) to introduce briefly. Would take 3 minutes.
00:19:05
jochem-brouwer:I think this one https://eips.ethereum.org/EIPS/eip-7954
00:20:10
Pooja Ranjan:Replying to "So my comment: I don..."
So would this meeting mean there are decisions that are made there?
In short, yes. ACD-G would define the process—for example, limiting an upgrade to five EIPs—while EIP selection and decision enforcement would remain within ACD.
Expected participants include EIP Editors and the EF Protocol Coordination / Protocol Support teams; however, interested client team representatives and other community participants are also welcome.
00:21:49 Marcin Sobczak: We prepared an EIP for increasing price of point evaluation precompile: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8096.md
Point Evaluation is currently performing in all clients ~32MGas/s on reference machine which is a bottleneck for compute on protocol level.
It is not included in general repricing eip, so we proposed brand new EIP-8096, potentially it can be unified with next iteration of general repricing eip.
00:21:55
Ben Adams:I would prefer to have some increase
00:22:36
Łukasz Rozmej:I prefer smaller bump without complexity
00:23:07
Charles:i'm all for removing the 24kb speed bump
00:23:31
Marius van der Wijden:My prio list high to low: doing nothing, small bump, 2926, 7907
00:23:35
jochem-brouwer:Antwoord verzenden naar "I prefer smaller b..."
Support for bump w/h gas price change (so just static bump and no further changes)
00:24:01
Marius van der Wijden:Replying to "My prio list high to..."
Any change will require significant benchmarking efforts
00:24:34
EF Berlin office:Replying to "My prio list high to..."
Yeah but hasn’t this been a massive ask from the community justifying the efforts?
00:24:37
Barnabas:didn’t we agree last few calls that 7907 is headliner sized change? In which case, this should probably be proposed for hegota, and just DFI now?
00:25:04
Pooja Ranjan:Replying to "So my comment: I don..."
@Anders Elowsson
ACDG will serve as a discussion and decision-making forum, helping save time in ACD meetings by allowing those calls to focus on technical specifications. This ensures that governance questions are resolved early and technical meetings remain technical.
ACD-G aligns on governance and process, while ACD enforces and executes.
00:25:20
Łukasz Rozmej:Replying to "My prio list high to..."
Do we have an idea how to do 2926 without performance hit on clients?
00:25:21
Marius van der Wijden:Replying to "My prio list high to..."
Yes definitely, I just don't see anyone doing the leg work for it yet (except maybe Carlos)
00:25:28
Ben Adams:Replying to "didn’t we agree last..."
Is fairly small; was just too late in fork last time
00:26:13
EF Berlin office:Replying to "My prio list high to..."
Usual circular dependency problem I guess, people won’t do the work until the thing is scheduled
00:26:18
felipe:An early complexity assessment for the testing team for EIP-7907 puts this at a medium complexity, leaning on the higher end because of the account changes on the testing infra. The simpler approach would make this significantly lower.
00:27:23
jochem-brouwer:This delta has been proposed before with the challenges Ansgar described
00:27:36
CPerezz:Replying to "My prio list high to..."
I am doing it. But I’m blocked on PRs such that I can bloat bloatnet again and have an answer to the performance claims
00:27:41
CPerezz:Replying to "My prio list high to..."
So we can take a data-driven decision
00:27:53
Charles:Replying to "An early complexit..."
what is the simpler approach?
00:28:05
Ben Adams:Replying to "An early complexity ..."
https://eips.ethereum.org/EIPS/eip-7954
00:28:08
Łukasz Rozmej:Yeah I also am thinking 7907 as a dead end and we should focus on 2926-like chunking - how to prototype/implement it correctly for H* to avoid performance hit.
00:28:12
felipe:Replying to "An early complexit..."
EIP-7954 for example
00:29:46
CPerezz:Replying to "Yeah I also am think..."
What made you change your mind? Since you objected a bit last call. Curious to know!!
Would help to frame it for H* if this time it doesn’t make it! 🙂
00:29:49
EF Berlin office:Can we quickly discuss who is doing the data gathering work?
00:29:55
EF Berlin office:i.e assign the work stream to someone
00:30:17
jochem-brouwer:I don't want to overload myself, I could assist here but do not want to take this task
00:30:26
Łukasz Rozmej:Replying to "Yeah I also am think..."
I objected on the scope size + timing + lack of prototype mostly
I just think it is a big one
00:30:45
Łukasz Rozmej:Replying to "Yeah I also am think..."
and I think it isn't obvious how to make it performant
00:31:00
Łukasz Rozmej:Replying to "Yeah I also am think..."
quite the contrary
00:31:01
Barnabas:Replying to "Yeah I also am think..."
maybe I was mixing 7907 with 2926. What’s the scope of 2926 chunking? Is that a headliner sized change?
00:31:51
EF Berlin office:Can we then align on what data is important to collect by next week?
00:32:03
EF Berlin office:Just generic, think more about it or something specific?
00:32:05
frangio:is bump to 32 on the table for next week?
00:32:07
Łukasz Rozmej:Replying to "Yeah I also am think..."
Hard to say, it might be close, but it is not "cool", so I don't see it as a headliner for popularity reasons
00:32:18
Guillaume:Replying to "Yeah I also am think..."
exactly
00:33:01
Łukasz Rozmej:Replying to "Yeah I also am think..."
but my intuition is that unless cleverly done it will hit performance bad
00:33:10
jochem-brouwer:Ansgar, for 7907 we have thus decided that we bump to 32 and not do the gas accounting? So like EIP-7654
00:33:17
jochem-brouwer:Antwoord verzenden naar "Ansgar, for 7907 w..."
For decision next week
00:33:21
lightclient:i don’t think it actually removes the limit, just increases the limit to 2x the contract code size limit
00:33:33
Charles:i've done the benchmarking for 7903, there are no jumpdest attacks
00:33:52
CPerezz:Replying to "Can we then align on..."
I collected a bunch of data on different size contract reading.
For empty state data suggests linear increase and recommended hardware is fine.
But I need to test this in bloat net and I will be able to provide perf and IO numbers for all sizes of contracts (up to 24 as nothing else is supported so far)
00:34:00
Charles:Replying to "i don’t think it ..."
it was already 2x the contract size limit, it's either removing the limit entirely or bumping it
00:34:13
CPerezz:Replying to "Can we then align on..."
I can try to have for next week the same data over 2.5x main net size and try to use this data to decide
00:35:21
EF Berlin office:Replying to "Can we then align on..."
Okay and is it just spa moor PRs missing from your side?
00:35:37
CPerezz:Replying to "Can we then align on..."
Yes. And then PRs in execution-specs
00:35:48
CPerezz:Replying to "Can we then align on..."
I have PRs everywhere already, Just need the merges and run the tests then
00:35:56
CPerezz:Replying to "Can we then align on..."
If I get the merges I can have the data by next week
00:36:22
EF Berlin office:Replying to "Can we then align on..."
Cc @Mario Vega and @pk910 I guess?
00:36:53
CPerezz:Replying to "Can we then align on..."
Pk is on it already. For the execution-specs they’re overloaded. I think @Louis is on it
00:37:06
Mario Vega:Replying to "Can we then align on..."
@CPerezz send the PR numbers via dm and we’ll prioritize
00:38:01
lightclient:I think 7997 is nice
00:38:48
CPerezz:Replying to "Can we then align on..."
https://github.com/ethereum/execution-specs/pull/1961
00:39:02
Charles:i'd like to bring up 7923 again, i was not available to advocate for it last time. i also wrote an argument for 7923 and against 8024 here https://ethereum-magicians.org/t/eip-8024-backward-compatible-swapn-dupn-exchange/25486/3
00:39:03
Danno Ferrin (Tectonic):Replying to "I think 7997 is nice"
I like it has no EOA requried toehold.
00:40:32
lightclient:we have added several system contracts now though so we kind of know how to do it
00:40:39
Mario Vega:Replying to "I think 7997 is nice"
It’s indeed nice to have, we are going to use it a lot for execute tests, it would be nice for it to be ready instead of having to deploy it each time
00:41:11
Barnabas:Could we CFI it and see if its actually a difficult lift?
00:42:25
jochem-brouwer:Yes agreed with Felix, we have simple community asks, ship it (or at least try to)
00:42:27
Marius van der Wijden:Very much in the nice to have category for me
00:44:16
Marius van der Wijden:I'm leaning slightly against 8058 for glam
00:44:32
Marius van der Wijden:Replying to "I'm leaning slightly..."
Because of scope creep
00:46:58
Marius van der Wijden:Do we have a list of cfi'd eips for scope considerations?
00:47:44
lightclient:can’t we keep encoding the same just ensure it is always 0?
00:47:55
Marius van der Wijden:We could just put 0x000.. instead. I don't think we can remove the header field
00:48:00
Justin Florentine (Besu):can anyone see my chat yet?
00:48:06
Ansgar Dietrichs:Replying to "can anyone see my ch..."
yes
00:48:07
Ahmad Bitar | Nethermind:Replying to "can’t we keep encodi..."
what benefit? just so you dont calculate them?
00:48:08
Ben Adams:Replying to "can anyone see my ch..."
yes
00:48:08
Ansgar Dietrichs:Replying to "can anyone see my ch..."
now we can
00:48:10
Ansgar Dietrichs:Replying to "can anyone see my ch..."
welcome back
00:48:10
Tamaghna Choudhuri:Removing bloom filters and replacing it with the log filter summary is better option
00:48:14
jochem-brouwer:Antwoord verzenden naar "can’t we keep enc..."
The logs bloom of an execution block is now required to be empty (ie. 0 bytes long). The logs bloom of a transaction receipt is now required to be empty (ie. 0 bytes long).
00:48:33
jochem-brouwer:Antwoord verzenden naar "can’t we keep enc..."
Part of spec, its now 0x. Can also change to 0x00..00 or 0xff..ff
00:48:40
jochem-brouwer:Antwoord verzenden naar "can’t we keep enc..."
(latter being an always hit filter)
00:49:08
Justin Florentine (Besu):Replying to "can anyone see my ch..."
fuckin corporate managed laptops fml... all I was trying to say is that if 7907 comes back next call, will there be a written proposal for just a size increase without the added cost mechanic
00:49:31
Justin Florentine (Besu):Replying to "can anyone see my ch..."
we had nothing to add for 7997, it's fine just lower priority
00:50:13
Ben Adams:Replying to "can anyone see my ch..."
@Justin Florentine (Besu) https://eips.ethereum.org/EIPS/eip-7954
00:50:31
Justin Florentine (Besu):Replying to "can anyone see my ch..."
word, thanks man
00:50:44
lightclient:Replying to "can anyone see my ch..."
corporate has decided we won’t be doing 7907 this fork
00:51:10
jochem-brouwer:I'm not gonna push this but I get the feeling that the bloom filter is misunderstood due to its title. Title: "remove bloom filters". However the EIP spec just says: bloom filters are now always 0x. So they are not "removed" they are just this constant value.
Just to inform everyone. Will revisit in Hegota
00:51:35
jochem-brouwer:Antwoord verzenden naar "I'm not gonna push..."
Specification
The logs bloom of an execution block is now required to be empty (ie. 0 bytes long). The logs bloom of a transaction receipt is now required to be empty (ie. 0 bytes long).
00:51:43
jochem-brouwer:Antwoord verzenden naar "I'm not gonna push..."
https://eips.ethereum.org/EIPS/eip-7668
00:51:46
Ansgar Dietrichs:geth and besu signalled for 7745 inclusion, nethermind and erigon against
00:51:55
Łukasz Rozmej:it is consensus, it is as dangerous as consensus issue
00:53:16
Tamaghna Choudhuri:For 7745 it is better to postpone it to next fork just from the implementation and also the deep testing and fuzzing required for the filtermap X log index
00:53:54
Tamaghna Choudhuri:I have been working on implementing it inside nimbus el and also some feedback from other devs of the ideas
00:54:27
Justin Florentine (Besu):we agree it is very big, but a potentially big unlock for cross-chain functionality
01:00:55
Justin Florentine (Besu):sidequestion: is it really trustless if it's not covered by the stf?
01:01:12
Łukasz Rozmej:@Zsolt Felföldi propose it for H* headliner
01:01:32
Tamaghna Choudhuri:Replying to "@Zsolt Felföldi prop..."
+1
01:01:36
Justin Florentine (Besu):Replying to "@Zsolt Felföldi prop..."
you think this is headliner size?
01:01:49
Łukasz Rozmej:Replying to "@Zsolt Felföldi prop..."
we agree it is very big, but a potentially big unlock for cross-chain functionality
01:02:04
Łukasz Rozmej:Replying to "@Zsolt Felföldi prop..."
if very big isn't headliner size than what is? :)
01:02:35
Justin Florentine (Besu):Replying to "@Zsolt Felföldi prop..."
FOCIL i guess is what i'm framing it against
01:03:11
Łukasz Rozmej:Replying to "@Zsolt Felföldi prop..."
for EL this is bigger than FOCIL
01:03:56
Felix (Geth):sorry I always forget
01:04:24
nixo:are we not going 90 minutes?
01:04:46
Marius van der Wijden:I think we should dfi 7793
01:04:53
Ahmad Bitar | Nethermind:https://ethereum-magicians.org/t/conditional-transactions-eip-7793-for-glamsterdam-faq/27228
01:04:55
Justin Florentine (Besu):Replying to "I think we should df..."
BOOOOOOO
01:05:06
Ahmad Bitar | Nethermind:Replying to "I think we should df..."
Why DFI?
01:05:07
Justin Florentine (Besu):Replying to "I think we should df..."
c'mon its tiny
01:05:13
Łukasz Rozmej:I can go for 120 :D
01:05:26
Barnabas:The only issue is that we have a rpc standards call thats started 4 mins ago. Not sure if anyone attending that who isn’t here tho.
01:05:34
jochem-brouwer:Antwoord verzenden naar "I can go for 120 :D"
New years energyyyy
01:05:36
Marius van der Wijden:Replying to "I think we should df..."
Its not tiny and it makes block building extremely hard
01:05:41
Łukasz Rozmej:Replying to "@Zsolt Felföldi prop..."
I see FOCIL more of CL headliner not EL
01:06:08
Ahmad Bitar | Nethermind:Replying to "I think we should df..."
It does not, it is a conditional transaction, not an opcode
01:06:12
Danno Ferrin (Tectonic):Replying to "I think we should df..."
with slotnum opcode this can be done with a trampoline contract
01:06:29
Marc:Replying to "I think we should df…"
I disagree, would be good to discuss on the thread shared
Summary
9 highlights
· 4 decisions · 3 action itemsExperimental
Summary
9 highlights · 4 decisions · 3 action itemsExperimentalfork status and schedule
eip scoping
- EIP-7997 (factory pre-deploy) CFI'd after Geth argued it's low-complexity community ask00:41:38
- EIP-8058 (code deduplication) withdrawn by author; team to rework for H-star00:45:31
- EIP-7668 (remove bloom filters) DFI'd; encoding variance concerns raised00:49:48
- EIP-7745 (trustless log index) DFI'd; too large for Glamsterdam, target H-star headliner01:02:31