Ansgar Dietrichs:Welcome, everyone, to AllCoreDevs 225, if I didn't miscount.
Transcript
Ansgar Dietrichs:M… We have two main issues for today. One will be, Fusaka, looking back at the last fork.
Ansgar Dietrichs:First, of course, congratulations, everyone, to a overall very successful hard fork.
Ansgar Dietrichs:And then we'll get back into Glamsterdam scoping.
Ansgar Dietrichs:For Fusaka, we have… A document with a quick summary of incidents that
Ansgar Dietrichs:happened around for Fusaka. Do we have someone on the call to briefly present that?
Ansgar Dietrichs:Yeah, Terrence, if you want to go first regarding the prison situation?
terence:Yeah, so over last night, about, like, let's see, 9 hours and 4 minutes ago, EPOC411440, the participation, or the target vote, dropped to 79%, so this is the recent issue that
terence:like, previously, as we know, to validate an attestation requires you to reconstruct the target state, right? And this is the state of the target checkpoint, advanced
terence:to the targeted park. And normally, this is very cheap, because of attestations share the same target. But attestations from the lagging node, the node that's catching up, or forks.
terence:can force client to regenerate the old state, and which is expensive, and this maybe does better on some client implementations.
terence:So to basically avoid this, we added a heuristic in Capella, right? And then the heuristic stated as such that if the target epoch is the current epoch, we just use the head state. If the target epoch is older, then we will check if the target is basically a real checkpoint and generate if needed, right? But this introduced a subtotal bug in Fusaka, which we fixed earlier.
terence:that head state may not be compatible with the target state, right? And then, because of this fix, we added some refactor that we kind of widened the scope on what we consider
terence:a valid checkpoint, but we also added a future flag to essentially gate under that, right? And this kind of recreated the same issue we saw in the Capella outage that
terence:notes from receiving older attestations from the previous EPOC are generating state heavily, causing them to miss attestation duty. So the current phase recommendation is to add that feature of
terence:use that feature flag, which we had in multiple posts and threads, and that will resolve the issue for now. And we're also working on a long-term fix, which we should have a release out, next week. And we also have a formal post-mortem to be released next week as well.
terence:Yeah, that's an update from us.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs:Any other comments, or anyone else, that wanted to talk about anything regarding the Prism?
Ansgar Dietrichs:Incident in particular?
Ansgar Dietrichs:Otherwise… there were… Very small other minor issues mentioned.
Ansgar Dietrichs:in, this incident document that, I think connects to also linked in chat.
Ansgar Dietrichs:is there anything, that we should address on the call here?
Ansgar Dietrichs:Or are these things we can deal with async?
Dustin:I guess I'll just mention, in terms of the Nimbus Nethermind one, and Nixo's link, this appears to be… as mentioned, it may be a build issue, it's… I would say this is not a…
Dustin:A productive or appropriate forum for that.
Dustin:It's not… it's not clear if it's another mite issue at all.
Dustin:It's still being looked at.
Ansgar Dietrichs:That's good.
Ansgar Dietrichs:Yeah, and what does I see? You just joined, just in case you have anything specific you wanted to add as well, but yeah, we just got an update from Terrence already.
Ansgar Dietrichs:Otherwise, Barnabas, if you're on the call, could you give a just a quick update of the current, mainnet state?
Ansgar Dietrichs:Are we looking?
Stefan Starflinger:Barnabis can't talk right now, but I'm happy to kind of give an update that Fusaka went very well in the fork. It's just the prism issue was pretty much the only thing that happened for us in the middle of the night, but we had the Australians and the lab team working on trying to understand
Stefan Starflinger:What's, what's going on with the attestations?
Stefan Starflinger:And I think, Terrence already summed it up pretty well.
Stefan Starflinger:Otherwise, there's not much more from us.
Ansgar Dietrichs:Yeah, and it looks like participation back to very healthy levels.
Ansgar Dietrichs:Yeah, overall, of course, I think this was, again.
Ansgar Dietrichs:Very quick and amazing responses by everyone involved.
Ansgar Dietrichs:Thank you all very much.
Ansgar Dietrichs:Okay, is there anything else regarding Tusaka, then, that we should address on this call?
Ansgar Dietrichs:Okay, yeah, Alex, did you prefer to mention BP01, just so people have it top of mind?
stokes:Yeah, yeah, really just… just mentioning the BP01s coming up, so it's in about a week,
stokes:There's not anything anyone needs to do, but it should raise up the, the bulk counts, so…
stokes:Super exciting, and more just something to have everyone… have on everyone's radar.
Ansgar Dietrichs:Good.
Ansgar Dietrichs:Yeah, then…
Ansgar Dietrichs:For the next, agenda point, just… there's a few housekeeping items for today's call, and I split them into urgent and non-urgent, so that we talk about the urgent ones before going to glam system scoping, and then the other ones only if we have time. So for the, more brief time-sensitive ones.
Ansgar Dietrichs:first, all could have timings regarding future calls, not the one, coming up right after this one, in two weeks, but, but after that, both on the ACDC and ACDE side, there was questions around the holiday period, maybe to already briefly address.
Ansgar Dietrichs:In particular, Alex, and you mentioned possibly cancelling ACDC on December 25th, is that already locked in? Like, what's the status there?
stokes:Yeah, I think we should.
stokes:It's a holiday.
stokes:Pretty much everywhere.
Ansgar Dietrichs:Yep, okay.
Ansgar Dietrichs:So, everyone be aware that we'll likely have… that we won't have an ACDC on December 25th. And then the question more relevant on our side here is for the week after, so that's January 1st.
Ansgar Dietrichs:Obviously also a holiday in many places. The question is, what do we do there?
Ansgar Dietrichs:whether to keep or to cancel. Of course, on that ACDE side, we have a lot of continued scoping work, so the question is, is it worth keeping the ACDE on January 1st, or do we want to cancel it, or do we maybe try to, for example, see if we could borrow the ACDT on the week after or something?
Ansgar Dietrichs:to replace ACD.
Ansgar Dietrichs:Do people have?
Ansgar Dietrichs:it looks like in chat that January 1st, at least, people really want to cancel as well.
Ansgar Dietrichs:So then I would say, unless people disagree, that we decide to cancel January 1st ACDE, but I'll look into potential replacement candidates to not just have that be
Ansgar Dietrichs:canceled without a replacement, and then on ACDE in two weeks, we can…
Ansgar Dietrichs:Make potential decisions around a replacement.
Ansgar Dietrichs:Okay, that's that housekeeping item. And then, the other one was, Fossil. Didn't really quite fit into Gramsadan, because it's actually more about specifically not being in Gramsadan, potentially, but in the hard work after, there was these continued discussions about the potential
Ansgar Dietrichs:a need for a credible pre-commitment, to… to have fossil,
Ansgar Dietrichs:in HSTA, if we don't put it into Gromsadam, and whether there's any process, mechanism that could help with such a credible commitment. Alex, I think you had a topic you wanted to bring up from… from the ACDCs out there?
stokes:Sure, yeah. So, yeah, we've been talking about this on the CL side, for a couple weeks now, and…
stokes:Essentially, it wasn't clear how to move forward last call, and, like, one point that was made was to also get a temperature check from the EL. So, that's really all I wanted to do today.
stokes:We'll just try to understand…
stokes:Yeah, how people are thinking about this over here. You know, should we try to scope this for HECA? Should we, you know, just think about the headliner process and how fossil there? How does it square with Clemsterdam? And all of the above?
Ansgar Dietrichs:Right. And again, the idea is more temporary check than specific decisions. Do we have…
Ansgar Dietrichs:EL client devs with… Opinions on this topic.
Ansgar Dietrichs:I see the Netherland team supports SFI in Fossil.
Ansgar Dietrichs:a Facebook?
soispoke:Yeah, I don't want to be, difficult, but…
soispoke:I mean, I think a legit question will be… How many temperature checks?
soispoke:Do we need to have a bud force soon to…
soispoke:Move on and make progress at some point, because it… it does seem like we had…
soispoke:A lot, of… temperature checks, and I do feel like they…
soispoke:Converge, into one direction quite often, so…
soispoke:I would love for us to be able to make progress at some point.
Ansgar Dietrichs:Yep, that's a reasonable comment. I think from my side, I can only say that that's a little unfortunate, because this topic's obviously split between ACDC and ACDE, with more of the actual decision-making driven from the ACDC side, so that's why on ACDE, it always sounds like we're basically just asking for yet another round of input.
Ansgar Dietrichs:But yeah, next one?
nixo:I'm just gonna… I'm gonna say, after the Glamsterdam headliner process, I think we created an expectation of a public process that people can participate in and predict and,
nixo:It would… it makes…
nixo:ACD and, like, the government process feel a lot less messy, because people can understand what's going on, and I think that we should…
nixo:continue to do this headliner process, so I think…
nixo:in my head, the best path forward is CFI-only fossil right now, going through a headliner process, and then publishing this
nixo:the headliner… process timeline.
nixo:for everybody to see and understand that we are choosing the HECA headliners,
nixo:And then choose it at the end of that headliner proposal process.
Ansgar Dietrichs:And tomorrow?
soispoke:Yeah, is there then a reason why we do these temperature checks? If it's sort of decided anyways that
soispoke:The clients expressing opinions about wanting it included just don't…
soispoke:make a difference? I'm just wondering, like, why do we do these temperature checks if at the end, like.
soispoke:I don't know, it feels like protocol coordination, or like…
soispoke:Other people just make calls about, yeah, you know what, there's gonna be a headliner process, and we're gonna do things a certain way.
soispoke:If that's the case, it's fine, like, but then we should do the temperature checks and sort of, like, the…
soispoke:gather opinions and have the teams come together, at that point. Like, it feels like we are repeating the same process over and over and over.
nixo:I agree with that. I… I agree that, like, taking temperature checks every call is… it seems un… seems messy and redundant and not productive. And the reason I see behind… behind having a headliner process is because the clients are…
nixo:The people who come to these calls. And generally people… other people do not
nixo:Pay a lot of attention to these calls, and so…
nixo:Having a published headliner process, especially after having set a precedent in Glamsterdam.
nixo:Gives people an expectation that they know how to participate in this process.
Ansgar Dietrichs:Muck.
Marc:I think my feeling here is that we're not really bypassing the headliner process necessarily, but since there's been, kind of, very clear, enthusiasm from the community for Fossil, you know, in Glamsterdam, it's more like we're just kind of shifting it to the next fork.
Marc:And just on an implementation level, I think if it's SFI'd and we commit to it, then, like, personally, I'm working on fossils, so, you know, I can actually start working on that, whereas if it's…
Marc:still CFI'd, and there's a lot of…
Marc:you know, will it go in or not? Then it becomes kind of…
Marc:We don't know where to allocate resources.
Ansgar Dietrichs:Sounds good. Before the next, people, just wanted to briefly mention, yeah, I understand the criticism around this continued temperature check ping pong, but I do think this will be a decision that we will ultimately make in one week, on the ACDC side, so obviously everyone who
Ansgar Dietrichs:feels passionate about that should also be on that call, so we can hear a few more opinions, but I would try to, like, timebox it to not have too much of a back-and-forth debate on this call. Yeah.
Carl Beekhuizen:I think the important part of the…
Carl Beekhuizen:The headliner process and why we should go through this thing is that
Carl Beekhuizen:Like, there's an opportunity cost to shipping?
Carl Beekhuizen:fossil here. I think most people here, or pretty much everyone here, wants some form of fossil. It's just like, is that…
Carl Beekhuizen:like, better than shipping everything else, and I think that's why we should go through the headliner process. I imagine that we're just gonna end up back at Fossil, because that seems like what the overwhelming support is, but I think we need to be considering
Carl Beekhuizen:what we are choosing to not ship by shipping fossil, and I think that's why it's very important we go through the full headliner process for this.
Ansgar Dietrichs:And Nico?
Nicolas Consigny:Yeah, my one comment that I wanted to make later on for the PQ precompiles, but it's the same here. We should definitely reflect that new process, if it is, like, enforced in the EIP1 and in the main EIP page.
Nicolas Consigny:Because as of now, like, if you're a new contributor to Ethereum, you go and you check EIP1, you go and you check, the EIP, Ethereum.org website.
Nicolas Consigny:And none of this, like, new process is specified, so, like, for the PQ precompiles that we will be discussing later, we have different, precompiles that we've been working on, and,
Nicolas Consigny:like, some people showed up because they liked the EIPs and, like, proposed them for inclusion. These peoples are not the authors, and so we end up in a situation where, like, we are about to discuss precompice, but the authors didn't really ask for it.
Nicolas Consigny:So yeah, I think it's… it would be much clearer if we could just have this in one document. Currently, you have to follow forums, ACMDs, EIP1, then you have to find about the Meta EIP, and so it's an entire process that is quite long and quite difficult.
Nicolas Consigny:And so, yeah, I think we did great with the new, forecast and the new…
Nicolas Consigny:the new tools that are surrounding ACD, but this part should definitely be reflected in EIP1.
Ansgar Dietrichs:That's good. Do we have any further comments from the EL side? Regarding…
Ansgar Dietrichs:The first narrowly the process here.
Ansgar Dietrichs:Tamar?
soispoke:Yeah, sorry, it's actually an actual question. Like you said, a decision will be actually made next to ACDC,
soispoke:But I feel like…
soispoke:going through the normal headliner process is not that, so is there a way to clarify exactly, you know, if a decision will be made in the next ACDC, and what the decision will be?
Ansgar Dietrichs:So, I don't want to fully speak for Alex, so Alex, please feel free to correct me if this is wrong, but my understanding would be that on next ACDC, we just make a decision regarding the question of
Ansgar Dietrichs:what special treatment process-wise do we want to give fossil, with respect to H star? So, like, do we want to CFI it, SFI it, how would that relate to the
Ansgar Dietrichs:headline our process as it starts. Again, I think on the social layer, everyone already agreed that we all are pre-committed to having it in the next hardbook either way, but again, the decision of, like, how does it exactly kind of relate to the process?
Ansgar Dietrichs:for H-star, that would be the decision that I would expect for next week.
stokes:Yeah, I mean, basically just how to handle it.
Ansgar Dietrichs:Okay, yeah, I also agree with people in chat that have the need to timebox this topic here, so I would say that unless there's any urgent other comments on this, then I would
Ansgar Dietrichs:end that section here for now. And then we can actually move on to… Lamsterdam. And,
Ansgar Dietrichs:Yeah, so for… for continued stem cell scoping, I went through the… both the individual client preference docs, and then also specifically just, like.
Ansgar Dietrichs:all the discussion we had on last ACDE, which was 4 weeks ago, and assembled… like, a document 8, I just find that more useful than the meta EIP document, because it separates out the 40 EIPs into different categories.
Ansgar Dietrichs:And then also with some annotations, around, potential CFI, DFI candidates. This is not a formal kind of status, process-wise, the candidate is just an annotation of, like, this seems to have either very strong support, or this has had a lot of skepticism.
Ansgar Dietrichs:So the idea would be, before we go and discuss all the EIPs that are not yet on either side of that, that we start by maybe the ED.
Ansgar Dietrichs:potentially easy decisions. I do apologize, I only published this very, very last minute before the call.
Ansgar Dietrichs:which was not a proper process, I should have… should have published this much earlier.
Ansgar Dietrichs:But if we… do we have someone that could, share their screen and…
Ansgar Dietrichs:Have the document open.
Josh Davis:Yeah, if you post it, I'll share it.
Ansgar Dietrichs:Yep.
Ansgar Dietrichs:That's… I put it in chat.
Josh Davis:Cool, just give me a second to configure the things with the strain as well.
Ansgar Dietrichs:Yep, boys.
Pooja Ranjan:Josh, would it be helpful if I share my screen and you continue with streaming?
Josh Davis:Yeah, no, I think I've got it here. Maybe for next time, though.
Ansgar Dietrichs:Yeah, thank you, and my apologies for ambushing you live on the call with this.
Ansgar Dietrichs:Perfect. So, the idea is that, if you can scroll down a little bit, they are in yellow, these marked, yeah, exactly. So, basically, the first few sections, we'll get to this a little bit later, but they don't have yet clear CFI DFI candidates. The first section that does have them is the
Ansgar Dietrichs:general, repricings. And the idea here is not that, again, for each one to just highlight.
Ansgar Dietrichs:Why… why it is marked this way, and then if there's maybe anything…
Ansgar Dietrichs:Yeah, so basically, like, if we just go on the list to start, specifically the block accounting without refunds seem to be actually one of the most clear candidates for inclusion of all, seemed to have universal support, so I was just curious, do people feel ready today to make a CFI decision on
Ansgar Dietrichs:EAP7778, the… Block gas limit accounting without refunds.
Ansgar Dietrichs:And I'm not sure if I want to…
Ansgar Dietrichs:for every single client on each topic. Maybe for the CFI candidates, is there anyone that would object, any client that would object to a CFI decision here?
Ansgar Dietrichs:Otherwise… then I would say… 47778, we make a CFI decision now, and it's… In the hot book.
Ansgar Dietrichs:Okay,
Ansgar Dietrichs:you can see some of them have a question mark. The question mark is just, if there's still any unresolved issues that might preclude a full decision on today's call, but they are a strong candidate, so 7971 overall, that's the, the, global cut for T-Store.
Ansgar Dietrichs:That had, some concerns around
Ansgar Dietrichs:the kind of abstraction compatibility. Otherwise, people really liked it.
Ansgar Dietrichs:Is there an update on the… Account abstraction concerns, do we feel ready to…
Ansgar Dietrichs:Make an inclusion decision, or does this require help?
Ansgar Dietrichs:One more round off.
Ansgar Dietrichs:Iteration to resolve these issues.
Ansgar Dietrichs:Sorry, that's… yeah, I should be a bit clearer about this. There's EIP7971, the hard limit for transient storage.
Ansgar Dietrichs:if there are no concrete, opinions, then I would…
Ansgar Dietrichs:for now, basically postpone the decision, because, again, it still has one unresolved issue, which I would say would preclude CFI.
Ansgar Dietrichs:Also, Justin, I see in chat the question, how many ERPs are we planning to CFI? Basically, I would, for now, just do individual one-off decisions. I would expect that going through this list, we will not end up with more than a small handful of decisions.
Ansgar Dietrichs:And then afterwards, maybe have a… take a step back and… See where we're at, or…
Ansgar Dietrichs:Yeah, I'd be happy, happy to have comments on alternative process, if that doesn't make sense.
Justin Florentine (Besu):Yeah, let me just clarify why I'm asking. So, like, I have the Bayeswood Team's tier list up in front of me, and I'm looking at that, and so if you say, okay, this one, should it be CFI'd, and I see it as maybe in the A tier, but not the S tier.
Justin Florentine (Besu):Should I agree with the CFI situation or not?
Justin Florentine (Besu):this is what I'm… I'm trying to… I'm trying to figure out, like, how many of these CFI quote-unquote votes do I need to apportion, because I would like to save them all from my S tier,
Justin Florentine (Besu):selections. I'm just trying to kind of square how this is gonna work.
Ansgar Dietrichs:Right.
Ansgar Dietrichs:Yeah, Barnabas in chat saying that we should not maybe have a strict number limit.
Ansgar Dietrichs:I can… if we… if we… so basically, like, in the… in the document, I have, I think, 4 clear CFI candidates that I saw, and 5 with a question mark that maybe had something still to be resolved, so that's already 9 ERPs.
Ansgar Dietrichs:Most of them are, though, like, very, very small, like the SWATNAM opcode, that should be pretty self-contained.
Ansgar Dietrichs:then the main, other sources of potential APs that, did not… were not on that list yet were specifically around repricing, just because there were unresolved issues.
Ansgar Dietrichs:and, possibly around contract size. So that, I think, maybe is overall… The kind of the,
Ansgar Dietrichs:the sources of likely, ERPs, so… but yeah, I don't know. I personally would just continue on with the list for now.
Ansgar Dietrichs:But I'm also, you know.
Ansgar Dietrichs:leading the scoping process for the first time, so I'm just going with what feels reasonable to me, and I'm happy to correct costs.
Ansgar Dietrichs:But I… in the interest of time, I would, for now, just move on with the idea here. So, like, I would say with… for the highlighted EIP currently, 7971, I would say, given that there was last time unresolved account protection, concerns, that we are, for now, postponing a decision, and,
Ansgar Dietrichs:refer that back to the EIP champion to address these concerns, until the next call.
Ansgar Dietrichs:Then we have on the list a DFI candidate that is EIP8011, the multidimensional gas metering, that can be highlighted.
Ansgar Dietrichs:They are specifically, DFI…
Ansgar Dietrichs:Because, kind of, people's clients overall felt that it was overly complex for now, and, premature, and probably better fit for future hard work.
Ansgar Dietrichs:Are there comments on this? Do we feel ready to make that DFI decision?
Ansgar Dietrichs:And in particular, there was one, comment, I think, by Anders, pointing out that for specifically just state growth, like, basically once we'll talk about the,
Ansgar Dietrichs:the repricing solution to state growth, it could be that we would want some very lightweight, kind of, minimum version of multidimensional metering if we want to consider an alternative approach today to the currently selected EAP, or proposed EAP, but I would still say that that should be separate, not
Ansgar Dietrichs:And not… not just reusing AD11, so I personally would post that we just make a DFI decision now,
Ansgar Dietrichs:And… Yeah.
Ansgar Dietrichs:So basically, is there any client opposed to DFI-ing 8011?
Ansgar Dietrichs:I did talk with Maria, because there's a question that she has a champion on the call today, and she's okay with AT11 not in Amsterdam, so then I would say Precision AT11DFI.
Ansgar Dietrichs:Yes. And then, Tony, by the way, just to address your comment, the idea is, again, process-wise, we first go through the
Ansgar Dietrichs:CFI DFI candidates, because that's hopefully easy wins, and then go through all the sections that, are still… have more open questions.
Ansgar Dietrichs:So the next, next one on the list is the, the one right under, under this, AT32,
Ansgar Dietrichs:size-based storage gas pricing. So, clients generally spoke in favor of this one on the call.
Ansgar Dietrichs:the reason I still put a question mark there is just that there was an ERP that does make pretty significant changes and came relatively late in the process, so I just wanted to check with people how much they've looked into the details here, how
Ansgar Dietrichs:comfortable there with the majority of the IP, and if we are ready to make the CFI decision.
Ansgar Dietrichs:So that's 8032 size-based storage gas pricing.
Łukasz Rozmej:Is this the one with relatively complex migration?
Ansgar Dietrichs:My understanding is that there is a migration step, 8.
Ansgar Dietrichs:I don't… I'm not sure if it's complex or not. Do we have, anyone on the call that has looked into this?
draganrakita:I think you will need to know the size of the current storages per contract, so you need to extract that information from somewhere.
draganrakita:I think that's the migration.
Łukasz Rozmej:Yeah, but… I think this is…
Łukasz Rozmej:hand-waving on the quite big concern over the CAP.
draganrakita:Yeah, same, in my opinion, AIP seems complex to do.
draganrakita:And I would rather skip it.
Łukasz Rozmej:Yeah, unless we have a very good idea how to… how to do that, I'm also not sold on…
Łukasz Rozmej:Well, CFI is considered, so…
Łukasz Rozmej:We can consider it, but I have reservations.
draganrakita:Additionally, it clashes a little bit with state creation, gas cost increase, AP8037.
draganrakita:we… if we include the state creation gas increase, then this ARP becomes, less relevant, because we already, like, increasing the gas by n times.
draganrakita:So, yeah.
draganrakita:Maybe DFI, but… Consider it later is… it looks fine.
Ansgar Dietrichs:Okay, yeah, then, given that there are questions,
Ansgar Dietrichs:I would, for now, by the way, just to, you know, just so this all doesn't seem completely arbitrary, like, so one of the reasons that this… I put this on the list is, for example, that Nethermind had listed this as
Ansgar Dietrichs:as an A as well, so,
Ansgar Dietrichs:yeah, Lukash, just so you don't feel like I'm trying to just push… push EFPs on people. But then I would postpone the decision on this one for extra two weeks, and I do see in the comment the question of, can't we just immediately DFI everything that
Ansgar Dietrichs:that does have questions, I would say I would at least not do that with the ones that overall had pretty strong support. So, for example, this one had 3 A's by clients, only Aragon, from the ones that… from the teams that commented on it.
Ansgar Dietrichs:had it listed as D.
Ansgar Dietrichs:So for an ERP like that, I would just wait for 2 weeks to… to give people more time to look into them, and yes, but… but anything that's already more often on the DFI kind of side, and then if there's questions, I would just default to DFI.
Łukasz Rozmej:So, our opinion on that was that we like the AP, like, idea, but the transition process sounds,
Łukasz Rozmej:Impractical at what the current is, and…
Łukasz Rozmej:Someone might convince me I'm wrong, but… But that's… that's the case.
Ansgar Dietrichs:Okay, sounds good. So the point here is someone needs to convince, Lukash and other people that, like, from the rest team as well, there seem to be concerns about the transition, so…
Ansgar Dietrichs:Yeah, this one.
Ansgar Dietrichs:No decision today.
Ansgar Dietrichs:Then we can move to the, last three in this section, so the next one is…
Ansgar Dietrichs:AT53, this is the high precision through milligars.
Ansgar Dietrichs:Overall, there's two ERPs here that, both are about,
Ansgar Dietrichs:head precision, it's this one, and then the last one in the section, AD59, both of those overall head client comments that while higher precision for, popcodes is useful, it's just not worth
Ansgar Dietrichs:having an EFP in Amsterdam, so I would propose DFI. Is there anyone that really wants to save either of those two?
Ansgar Dietrichs:Earpiece.
Ansgar Dietrichs:Otherwise, okay, I would say we lock in the DFI for those two. So that's, that's 8053 and 8059.
Ansgar Dietrichs:both of those EFI.
Ansgar Dietrichs:Okay, and then the one in the section that we didn't yet get to is the second-to-last EIP8057. That is Interblock temporal locality gas discount. That was the strongest candidate already from last call to make a DFI decision, even though we had said no decisions on that call yet.
Ansgar Dietrichs:Just because it seems like clients really had to… were…
Ansgar Dietrichs:Pretty convinced that that was not a good idea, so… unless everyone changed their minds, I would…
Ansgar Dietrichs:Assume that that's… PFI by default.
Ansgar Dietrichs:Okay, I assume this call, at least this section, will just be me, a lot of me talking, but at least we are coming out of it with a bunch of decisions, so maybe bear with me.
Ansgar Dietrichs:Okay, so then, yeah, we have basically, like, so the two that are delayed are the ones that have the question marks, those we will revisit in two weeks, and then the other ones actually follow the Canada recommendations, so that's…
Ansgar Dietrichs:Good to see.
Ansgar Dietrichs:Then can we scroll to the next section?
Ansgar Dietrichs:Okay. So, on… contract,
Ansgar Dietrichs:Besides, there was one ERP that did have relatively strong support, which is EAP7903,
Ansgar Dietrichs:the removal of the init code size limit. The reason that that had a question mark is…
Ansgar Dietrichs:That there was one client, let me, let me check.
Ansgar Dietrichs:Yeah, Beso specifically had listed that as C tier.
Ansgar Dietrichs:So I wanted to check, how people overall, specifically Basel, but also other clients, feel about it, because it did not specifically… it wasn't specifically discussed on last call.
Ansgar Dietrichs:how realistic is this SSCFI candidate?
Łukasz Rozmej:So… I think, never mind… Comments where that we are put… Potentially… unsure about the… Drum test analysis?
Łukasz Rozmej:But we would like to see some numbers. I think it might be, like.
Łukasz Rozmej:We might be overly cautious here about it, but yes, having some numbers would be good.
Łukasz Rozmej:So, I think CFI is fine, but again, before, like, scheduled, we would like to see some numbers.
Ansgar Dietrichs:Right, but given the limited scoping Ramson, I would personally, for now, only make CFI decisions when they are clear that there's pretty universal support, so…
Ansgar Dietrichs:And then it seems like… We might not be there.
draganrakita:I would say that the impact analysis is kind of… we're not sure what…
draganrakita:What would happen if we remove that?
draganrakita:So it's, like… It's better to stay, in my opinion.
draganrakita:We can always remove it. The gas calculation is already covering the jump desk analysis, but it's kinda… the limit is there for
draganrakita:Little bit more protection on the… Maybe some educators.
Luis Pinto | Besu:I… I wonder what's the benefit of that without increasing the contract size limit, which we obviously cannot do without the chunk-based code, VIP.
Luis Pinto | Besu:So if there's… what would be the added benefit? If there is none either, where would just TFI?
Ansgar Dietrichs:And Greg?
Greg K | Lido:Yeah, I also have the same question, and I also posited that I think that…
Greg K | Lido:Yeah, perhaps someone else should verify, but I think that 7903 is kind of contradicted with 7907, which…
Greg K | Lido:increases the unit code size, but does not… the maximum size, but does not make it kind of infinite. So, I think that 7903 removes the limit completely, but 7907, what this does is, like, it increases the current limit, and also increases the contract size limit.
Greg K | Lido:So, among those VIPs, I think…
Greg K | Lido:Like, it's the same direction, but only one could be the final spare. You cannot have, for example, both…
Greg K | Lido:7903 and 7907.
Greg K | Lido:So I think that these, like, discussion should be, like, Kind of together, right?
Ansgar Dietrichs:Okay, so yeah.
Greg K | Lido:Sometimes, but just, yeah.
Ansgar Dietrichs:No, it,
Ansgar Dietrichs:Yeah, thank you. Then I think it's pretty clear we at least will definitely not make a CFI decision here.
Ansgar Dietrichs:We will revisit it once when we talk about the general contract size, but it sounds even more that weird.
Ansgar Dietrichs:leading towards not inclusion here. Okay, then we have, two more in the utility section.
Ansgar Dietrichs:one of them is 7668, removal of, bloom filters.
Ansgar Dietrichs:Right, this one, I wasn't sure whether to put a question mark. It seemed pretty universal support, but we also didn't hear many comments on the… on it on last call, so I would want to hear more active
Ansgar Dietrichs:support for this before actually making the CFI decision, so…
Ansgar Dietrichs:Does… do people have strong opinions on the removal of bloom filters?
Ansgar Dietrichs:Huh?
Carl Beekhuizen:I think this is one of the features where
Carl Beekhuizen:it doesn't really provide much benefit for anyone, and I think, like, most people agree that it should be removed, the question is, like, how does it fit in with the rest of the fork? So, if we have
Carl Beekhuizen:a fork that's rather empty, and we have the capacity for it, then I think we should consider it, but I think we should, like, defer this decision until we know
Carl Beekhuizen:What else we are trying to put in this fork?
Carl Beekhuizen:Because I think they're much higher priorities on this list.
Ansgar Dietrichs:Okay. That seems very reasonable, actually, especially because, again, this one just did not have that many comments yet on last call, so then…
Ansgar Dietrichs:that's… postpone the decision. He might still be a candidate, but more as a filler beats on.
Ansgar Dietrichs:also matches the comments in chat. Then we have, one more. That one seemed, actually, to have quite enthusiastic support, last time. There was 7708 ETH transfers emitting a lock, and I think we also had a specific extra
Ansgar Dietrichs:comment and support, in the agenda GitHub issue.
Ansgar Dietrichs:How do we, like…
Ansgar Dietrichs:have… has anyone basically soured on the CRP over the last two weeks? Is this… is this something that,
Ansgar Dietrichs:That we are ready to CFI or not.
Łukasz Rozmej:Again, here, I would love to see some numbers, like, what's the biggest receipt?
Łukasz Rozmej:After that, because then, especially if we decrease the cost of the transfers, the simple transactions, Then…
Łukasz Rozmej:What kind of receipts are we getting, right? That's a very good question, my opinion.
Łukasz Rozmej:And I haven't seen any numbers.
Carl Beekhuizen:Yeah, so… we don't have any numbers here. Part of this is because…
Carl Beekhuizen:Whatever this… whatever we do here, we will have to update the pricing of…
Carl Beekhuizen:this part of an ETH transfer to account for the new logs.
Carl Beekhuizen:Which we'll only know once we have more of the harmonization stuff, so, like, this ties into a lot of the repricing things, which we already decided we'd like to ship.
Carl Beekhuizen:So, I think we just need to assume that this will…
Carl Beekhuizen:like, be harmonized with everything else. The total amount of work that's required to be done here is very small, so…
Carl Beekhuizen:like, by node, so I think that…
Carl Beekhuizen:Like, from that perspective, there's not too much to worry about.
Carl Beekhuizen:Like, this to me is just, like, this one weird edge case where ETH is, like, just much worse than pretty much every other asset for people trying to interface with the chain.
Carl Beekhuizen:And I think this is, like, a great way of
Carl Beekhuizen:like, reducing the delta between ETH and all other assets on-chain.
Łukasz Rozmej:One comment I also heard, I'm not sure about it, that because this is not from Genesis, it's less valuable, just adding at this moment than…
Łukasz Rozmej:But it's not really that valuable. But… because you still need the old way somewhere in… in indexers, etc. Well…
Carl Beekhuizen:I mean, yes and no, it's like…
Carl Beekhuizen:if this is the only data you consider, then yes, but it means running an indexer, like, forward, like, henceforth, you would be able to just be able to look at what comes in via these logs, and make deltas. There's a one-time calculation you need to do for all the stuff in history. I don't think it's worth us making
Carl Beekhuizen:clients implement this records compatible, like, like.
Carl Beekhuizen:putting this back towards Genesis, because I think that's just a lot of extra work, and I think for very little benefit, but I think we still get most of the benefits without it, but your point is definitely valid, that it is a little… like, you can't just look at all the logs since Genesis and know the values of everything.
Carl Beekhuizen:But I think this is more about knowing about, like, new deposits and transfers and that kind of thing.
Zsolt Felföldi:Yeah, may I just quickly interject here? So, so I believe that, this could be very valuable, so right now, right now, it's, like, extremely hard to use logs anyway, so,
Zsolt Felföldi:if we, at some point, not sure if we glamster demo or not, but we do 7745 at the log index, then it's totally possible to just, like.
Zsolt Felföldi:I mean, create the new logs, the transactional logs, eTransfer logs from the fork, and also create the log index from the fork, but then just re-troactively re-index
Zsolt Felföldi:or the pre-fork chain history with the, eTransfer, new eTransfer logs for the, like, the old history in, like, the new index. So, yeah, I think,
Zsolt Felföldi:at least the way I hope, there is going to be some kind of log re-indexing anyway, so I think it's still very useful.
Ansgar Dietrichs:Right, so… Yeah, so there seems to be some remaining considerations around 7708.
Ansgar Dietrichs:Do we make a decision today? On it, or… Do people want to… Look into those.
Ansgar Dietrichs:And keep in mind, I think usually saying keep… look into those. In two weeks, we probably will not have more information than we have today.
draganrakita:From Redside Sims, we… I think we support it and want to include it.
draganrakita:It makes sense to have logs for the transfers.
draganrakita:At least it is in the right direction.
Ansgar Dietrichs:Right. And given, like, every… every client had it in S or A tier?
Ansgar Dietrichs:So that's why I put it as TFI Canada.
Ansgar Dietrichs:In the, interest of…
Ansgar Dietrichs:making decisions, given that, overall, I would propose that we do CFI it, just given that there's overall, like, I see several messages in chat arguing for CFI status.
Ansgar Dietrichs:Does anyone object to certifying it?
Łukasz Rozmej:Well, the only downside is we are making EDA transfers, more pricey.
Łukasz Rozmej:Because we write more to history.
Zsolt Felföldi:Well, we do want this information, I mean, like…
Zsolt Felföldi:this is a work we should do, actually, so yeah, I think…
draganrakita:There's a HEP in the core group that reduces entrusty gas for transaction.
draganrakita:So those two should be, like, considered one another.
Ansgar Dietrichs:Yeah, so, as, as was already… as was said, yes, if we make an inclusion decision, then that means that any other EIP that touches the pricing of transfers will take this into account, and will basically, like, be marginally.
Ansgar Dietrichs:more increased, Lukash, then my question is, would you be okay with CFI-ing it now? And then if, during the process, basically, like, we see that the numbers seem…
Ansgar Dietrichs:More punishing than, than, than thought, that we, that we just.
Łukasz Rozmej:Yes, yes.
Ansgar Dietrichs:Not concluding it.
Łukasz Rozmej:Please see if I…
Ansgar Dietrichs:Okay, so then, CFI decision on this one.
Ansgar Dietrichs:Then we can move to the next section, the, opcodes.
Ansgar Dietrichs:So, first, a DFI candidate, 7791.
Ansgar Dietrichs:gas to ETH, there was some…
Ansgar Dietrichs:concerns around implications, that overall implications are just not… not well enough understood. It's…
Ansgar Dietrichs:pretty big paradigm change to the EVM was proposed relatively late, so for that reason, it seemed…
Ansgar Dietrichs:likely to DFI? Is anyone… does anyone want to argue against DFI?
Ansgar Dietrichs:And I would say B, deify it.
Ansgar Dietrichs:The next one, 7819, set delegate, the reason that's…
Ansgar Dietrichs:on the DFI candidate list, we did not… it did not come up on the last call, but all clients that have expressed an opinion on it have put it into C or D tier.
Ansgar Dietrichs:That just seems to indicate it doesn't really have a chance for that, folks, so… unless anyone objects, again, DFI decision.
Ansgar Dietrichs:Okay.
Ansgar Dietrichs:DFI. And then we have one, I mentioned briefly earlier, 7843 slot num op code.
Ansgar Dietrichs:steamed… For a potential candidate, it only is a question mark, because,
Ansgar Dietrichs:some clients will only put it into B tier. Geth was arguing for it on the last call. Yeah, I just want to check.
Ansgar Dietrichs:whether there's interest in CFI-ing it now, or whether this is more a filler EIP to decide at a later point.
Łukasz Rozmej:I think if we are… want to decrease, potentially, slot times in the near future,
Łukasz Rozmej:Pushing this in earlier would help to potentially develop some kind of,
Łukasz Rozmej:Ways of dealing with that later.
Łukasz Rozmej:on the EVM side.
Ansgar Dietrichs:Sounds good. Okay, then I would say we see a fire, is there any objection?
Ansgar Dietrichs:Okay, then… CFI decision on this one.
Ansgar Dietrichs:And next one, EIP7979.
Ansgar Dietrichs:call and return opcodes for the EVM.
Ansgar Dietrichs:That one… Seemed to…
Ansgar Dietrichs:overall have no client support. Aragon was speaking out against it, but Nethermine specifically had expressed
Ansgar Dietrichs:interest in it, so I just wanted to double-check with, Netherland, yeah.
Łukasz Rozmej:Just one argument for it, because there are,
Łukasz Rozmej:talks about potentially changing EVM to RISC-V, for example.
Łukasz Rozmej:Which… I'm totally not convinced. I think EVM has a benefit of being more domain-specific, and I think
Łukasz Rozmej:going to RISC-V might not be that good.
Łukasz Rozmej:But if we moved the EVM bytecode to this kind of call return opcodes.
Łukasz Rozmej:We could relatively easy transpile, compile, whatever we want to call it, JIT, whatever we want to call it, EVM bytecode to basically any other form. We could go to RISC-V, we could go to native x86, we could go to ARM,
Łukasz Rozmej:This unlocks potential optimizations of the… Of doing that.
Łukasz Rozmej:While keeping the whole, base language under our control, so… That's a big, big upside,
Łukasz Rozmej:I think it's also…
Łukasz Rozmej:I have to agree that it's probably mostly… could be ported from EOF, so it's not… that much work.
Łukasz Rozmej:On the… probably, maybe even on the testing side, I'm not sure about tests.
Łukasz Rozmej:So those are, like, the four… four things. I'm not sure if it should go to Glamsterdam, but in general… so, sorry, to Glamsterdam. To… yeah, Glamsterdam, Glamsterdam. Okay, I'm confusing the forks now, too many forks. But,
Łukasz Rozmej:Yeah, but I generally see this as an alternative path to different ESA, like Riskli.
Ansgar Dietrichs:Right, and given that,
Ansgar Dietrichs:all clients, except for NetherMind, had expressed skepticism on this one. Do you… would NetherMind be okay with us just deciding now to wait at least until H-star with this?
Łukasz Rozmej:Yes, yes, like I said, it's… we don't consider this as a super urgent, I just see a value of this path compared to the other one, and, it needs probably…
Łukasz Rozmej:deeper discussions.
Ansgar Dietrichs:Sounds good. So then I would just… Proposed to DFI it?
Ansgar Dietrichs:12% was another.
Greg Colvin:I had something to say about that.
Greg Colvin:Put it on the agenda 3 weeks ago.
Ansgar Dietrichs:Yes, if you want to.
Ansgar Dietrichs:Talk about that comment.
Greg Colvin:What would you… what was just said pretty much covers the technical reasons to put it in. The reasons… I would prefer to see if I, to some extent, are personal.
Greg Colvin:I'm 71 years old. Every time we delay this, I'm getting older, and the evidence is, that, it will get delayed.
Greg Colvin:And…
Greg Colvin:At this point, at least 3 times, we have gotten, proposals to fix this problem, as close to
Greg Colvin:In the code, and going into the upgrade, and then removed. So, I would much prefer to start to get this in sooner, so I can get to work. I want to
Greg Colvin:what I want to do, and so the community trying to do static analysis can do what they need to do.
Greg Colvin:Because they… they will not even start to look at this until it's actually on the main chain.
Greg Colvin:And,
Greg Colvin:So, I'd like to at least consider it, just even to consider it now, and get that conversation going.
Greg Colvin:Rather than… than kick it down the line, because I can't… I cannot predict that even 6 months from now, I'll be in a position to champion this.
Greg Colvin:I don't know that there's any champions left.
Greg Colvin:For this work, and it is such a small change, and that it is such an industry standard,
Greg Colvin:such an industry standard operation, there's just no reason it should not be an EVM.
Greg Colvin:That's it, that's all.
Ansgar Dietrichs:Right.
Ansgar Dietrichs:Thank you, Greg. And just, yeah, as a personal note, I do… I do agree that there has been… I've been some of these
Ansgar Dietrichs:And just that they've been so… have been very close to inclusion, at the edge of inclusion for a long time, that is personal… from a personal side, of course, for champions, very frustrating. So, I definitely understand that, Lukash?
Łukasz Rozmej:If I can say one more thing, because there's a question of the legacy bytecode. So, we tried to create ILEVM, which would do exactly that, transpire the legacy bytecode to native x86. It is possible, but due to…
Łukasz Rozmej:the size of the bytecode, that is basically one big method, right? One big function. No… no compiler later was put
Łukasz Rozmej:even try to optimize it. So, basically,
Łukasz Rozmej:That's the problem, so we can still support the old bytecode with the translation, but for example, we can price it out that it won't be practical for much use in the future.
Łukasz Rozmej:So, we do have kind of a backward-compatible way of going through things, but we would have to
Łukasz Rozmej:Support some kind of transition of most things to the new format.
Greg Colvin:The EIP discusses that some, and these are the kinds of things to discuss as we consider the EIP. I'm really almost begging
Greg Colvin:Let's consider it now. Let's not say maybe we will consider it much later.
Ansgar Dietrichs:So…
Ansgar Dietrichs:just in terms of process, given that we did otherwise have clients indicating that they would want to at least not include it into Amsterdam, I would, at this point, then ask
Ansgar Dietrichs:Did any client… would any client want to revise their opinion on this now? Otherwise, I would feel obliged to still go with the client decisions. But of course, if the client listening to this
Ansgar Dietrichs:Would want to revise their…
Ansgar Dietrichs:stance on the CIP, I'd be more than happy to hold off from the DFI decision.
Ansgar Dietrichs:then I… I do think that…
Ansgar Dietrichs:I mean, just process-wise, it seems like it's pretty anonymous text by clients to not have this in Glamstadam. I do think…
Ansgar Dietrichs:It might be a good idea to try to see if we can have a way to… Pass this…
Ansgar Dietrichs:ongoing conversation about the CIP with clients before we get to the next…
Ansgar Dietrichs:PFI phase for… for HSA, which indeed would only be 6 months down the road. So, if there's… I think it might be worth looking into a potential breakout process for this, to… to keep going.
Greg Colvin:Anything we can do to keep this rolling.
Greg Colvin:Because otherwise, you know, pretty much…
Greg Colvin:9 years into trying to get this work done for Ethereum, I will… Have to say… Goodbye.
Greg Colvin:It's not what I want to do.
Ansgar Dietrichs:Yeah.
Ansgar Dietrichs:bam… I think that is a strong case to try to keep the process rolling.
Ansgar Dietrichs:I would say, in terms of process, then I'll follow
Ansgar Dietrichs:go and say we will re-DFI it for Glamstadam itself, and just make a note that we try to
Ansgar Dietrichs:Keep this going, and not just revisit this in 6 months.
Greg Colvin:Yeah, I mean…
Greg Colvin:Excuse me. Yeah, I'm sorry. So that means we get a breakout room going, or we,
Greg Colvin:resolved to… to really get a discussion going on the magicians, but not just, you know, leave this sit for 6 months, or to have
Greg Colvin:Some sort of consensus that, yes, 6 months down the road, we will have reviewed this and be ready to make… be ready to make a decision after all this time.
Ansgar Dietrichs:Yeah, I don't think we can make a formal commitment process-wise, but I do think that it would be quite helpful if people can go find the ETH Magician's post, so we make progress on this. And, Nick's on chat is saying.
Ansgar Dietrichs:Okay. Protocol support can help facilitate this, to make sure that there's actual follow-up, not just empty words.
Greg Colvin:And then a breakout room is the process at this point, too.
Greg Colvin:to get a core devs discussion going on this.
Greg Colvin:Am I right?
Ansgar Dietrichs:I would leave that call up to protocol support, but Nick, so if you… do you have a…
Ansgar Dietrichs:It does seem like there's interest in a breakout, indeed, in chat.
nixo:Yeah, I think that's the right way to keep this conversation going.
Ansgar Dietrichs:Sounds good. So then we will have a breakout, and then, for us to be able to move forward now, I would just leave it at this. Greg, do you have anything more, or is that… does that satisfy?
Ansgar Dietrichs:The situation for the moment.
Greg Colvin:Well, thank you, yes.
Ansgar Dietrichs:Okay.
Greg Colvin:then…
Ansgar Dietrichs:We have another ERP right under this one, ERP 8013.
Ansgar Dietrichs:static relative jumps and calls for the EVM, also listed as a potential DFI candidate potential, just because, all clients had
Ansgar Dietrichs:B, C, or D, votes, but there was no conversation about it last call, so I wanted to check back whether anyone has changed their mind on this one either.
Ansgar Dietrichs:Otherwise, I would just DFI 8013 now.
Ansgar Dietrichs:Okay, that's DFI.
Ansgar Dietrichs:And then one last one in the section, EIP8024. That one was, I think, maybe together with the refund mechanism, the one that had the strongest support last call, that's the backwards compatible swap and dupe and exchange.
Ansgar Dietrichs:op codes, we have 3 clients that put it into S tier.
Ansgar Dietrichs:And…
Ansgar Dietrichs:and overall had strong support on Last Call Voice, and testing also saying that it would be a small change. I would propose we see if I had anything come up over the last two weeks, four weeks that would make that a bad decision.
Ansgar Dietrichs:Casper, you're unmuted? No. Okay.
Ansgar Dietrichs:Then, yeah, the decision CFI.
Ansgar Dietrichs:That one will then be in the glamstam scope. Okay, can we scroll down to the next sections?
Ansgar Dietrichs:So, on cryptography there, I think some of the early comments from Nico was related to cryptography, but my understanding is that that was regarding the… with regards to the post-quantum precompiles. Is that right, Nico? Can you… can you clarify that? So, given that those are not currently in the
Ansgar Dietrichs:DFI candidate list? We could skip this for now? Or was… were your comments also regarding the two that are marked as DFI candidates?
Nicolas Consigny:Yeah, so actually the two that are here are in the list. There is another one that is not in the list.
Nicolas Consigny:Which is AT52, like…
Nicolas Consigny:we wrote this one, and I realized, two days after the deadline that there was a deadline, so hence my comment on the needs to, reference these deadlines within EIP1.
Nicolas Consigny:But the two that are, I think, yeah, both of them are, in the list,
Nicolas Consigny:So we can definitely discuss them.
Nicolas Consigny:And, yeah, I can go, maybe Dano has a…
Nicolas Consigny:a point, too, to make, I assume.
Ansgar Dietrichs:Wait, but can you clarify? You're talking about 67… 7619 and 8051, is this the tool that you're talking about?
Nicolas Consigny:Yes, I think both of them, if I'm not mistaken, are… In the list.
Ansgar Dietrichs:Yes, but they're not CFI or DFI candidates for now, so we would… we can revisit this towards the end of the call if we have time. I assume we won't have time today, but…
Nicolas Consigny:Oh, okay. Okay, I see. Yeah, okay.
Ansgar Dietrichs:Okay.
Danno Ferrin (Tectonic):Should we just go ahead and DFI Falcon? There's good reasons to DFI it, but keep MLDSA open as a question.
Nicolas Consigny:I would agree with that statement, yep.
Ansgar Dietrichs:Okay, I mean, sure, I'm always happy to take unexpected DFI decisions, given that the people involved in this process are recommending this.
Danno Ferrin (Tectonic):Keep my notes in the comments, there's very good reason to wait on it.
Ansgar Dietrichs:Okay, so anyone who, for some reason, really wants to… is opposing DFI-ing a Falcon?
Ansgar Dietrichs:Okay, then we DFI DIP7619 Falcon for Glamstadon.
Ansgar Dietrichs:And we will discuss the other one in that section,
Ansgar Dietrichs:later, but for now, we move on to the DFI candidates that we have marked, which is these other two, secondary signature algorithms and the P256 transaction support. Overall, on last call, there was a lot of skepticism around these two with regard also to the
Ansgar Dietrichs:And…
Ansgar Dietrichs:kind of future account obstruction strategy, things like that. The P256 transaction support had pretty, pretty universal, projection. The, 7932 did have.
Ansgar Dietrichs:It was, was ranked quite high by, by,
Ansgar Dietrichs:by Bisu, if I'm not mistaken, so I did want to maybe double-check on this one. But otherwise, basically, both of those would be DFI candidates. So do we have anyone that specifically would not want to DFI?
Ansgar Dietrichs:either of those two, and in particular, maybe for 7932, whether Beso Has it?
Ansgar Dietrichs:Tesla opinion on this.
Justin Florentine (Besu):Yeah, our opinion on 7932 is really more of a PQ, preparation.
Justin Florentine (Besu):step.
Justin Florentine (Besu):So we see this as sooner rather than later. I don't know that we feel strongly enough that we'll fight hard against DFI, but we see this more as a CFI question mark.
Ansgar Dietrichs:Right, that's why I was bringing it up, because I think that that's exactly how I perceived the basic position. All the other clients seem to…
Ansgar Dietrichs:think that Lamsdam would be premature, at least, on this point.
Ansgar Dietrichs:So then I would… yeah, I would… Justin… yeah, would you… do you think, from the base side, it would be okay if we just push this one hot fog and we revisit this… this question for… for Ichtar?
Justin Florentine (Besu):Yes.
Ansgar Dietrichs:Awesome. Then I think we can…
Ansgar Dietrichs:go ahead with the PlumsetMDFI decision on both of these.
Ansgar Dietrichs:And…
Ansgar Dietrichs:Yeah, and then there's one last section here, that's the other section with some miscellaneous EAPs. The first tier is,
Ansgar Dietrichs:period, or the kind of periods related to proposals.
Ansgar Dietrichs:64… 04 and 6466. We talked about it, last call.
Ansgar Dietrichs:And…
Ansgar Dietrichs:overall, it seemed like clients did not feel like it was a priority for Glamstadam. I said, if, you know, if people change their minds, that that would have to happen until this call, so the question is, have people changed their minds here, or can we
Ansgar Dietrichs:Do we want to go ahead and DFI these?
Barnabas:Just one quick question. Is 7932 and 8030 handled together as…
Barnabas:one decision, because as far as I know, we just made a decision for $79.32, but not for 8030.
Ansgar Dietrichs:Okay, sure, fair point. We can revert back, just to double check. 80-30, yes, I was intending to have it be a shared decision, but, that's obviously… there's no reason to do that.
Ansgar Dietrichs:The main reason with 8030 was just that every single client that expressed an opinion, so everyone except for Rats, put it into D tier, which to me, implied, that it would not really have a chance in this artwork, but, yeah, is there anyone that would want to speak up in favor of 8030?
Ansgar Dietrichs:Barnabas to use?
Ansgar Dietrichs:I mean, do you have anything in favor of the AP that you'd want to bring up?
Barnabas:Yeah, so the only reason I brought this up, because we just included the SAC256R precompiled in Fusaka, and it's just interesting to me that we do not want this P256, because it would be, like, the…
Barnabas:completion of, finishing what we started in Fusaka, I think.
Barnabas:Maybe I misunderstood the IP?
Ansgar Dietrichs:My understanding is that it's not just a precompile, but an actual new transaction type.
Carl Beekhuizen:Yeah, we… so we already… I think the reason not to do this is partly because we just shipped this in Fusaka. We already get most of the benefits from…
Carl Beekhuizen:like, of having R1…
Carl Beekhuizen:On-chain by what we did in Fusaka. This is just whether we want to support it more natively.
Carl Beekhuizen:So, to me, that means, like, it's only if we want to see, like, even more adoption of this, and don't like that you don't have a native R01 transaction type.
Carl Beekhuizen:Secondly, I do want to raise that 8030 does require 7932.
Carl Beekhuizen:So we do, if we're including 8030, we do need to include 7932 as well.
Ansgar Dietrichs:Anya and Nico?
Nicolas Consigny:Yeah, I… I agree with Carl. I think we have most of the benefits, thanks to the precompile, and…
Nicolas Consigny:Adding this is, first, like, not very aligned with the PQ strategy, because basically we would make a lot of e-forths to include a new transaction type.
Nicolas Consigny:To find a way to deactivate it.
Nicolas Consigny:Maybe in one fork, because we were talking about the PQ precompile and PQ emergency plan at the same time. So to me, it really doesn't make sense.
Nicolas Consigny:Both from a strategy and technical point of view.
Nicolas Consigny:we… we have a cheap R1 precompiled. Also, like, the R1 curve is,
Nicolas Consigny:Is, yeah, doesn't have, nothing under its sleeve, proofs, so, like, we can't really know, all the details of the parameters, so, like, activating it as a native, curve adds more risk.
Nicolas Consigny:So yeah, to me, I would say no to both, I guess.
Ansgar Dietrichs:Yep, then, I do think we are probably still in the same position to make a DFI decision, or did anyone…
Ansgar Dietrichs:Want to change the mind here?
Ansgar Dietrichs:then we go ahead with DFI. So then that gets us back to the two pure, EIPs. Did we have anyone that would want to speak up in favor of those?
Ansgar Dietrichs:Then, otherwise, I'll, DFI… I'll propose we deify both of those.
Ansgar Dietrichs:Okay.
Ansgar Dietrichs:Okay, so then those of those elements are deified.
Ansgar Dietrichs:And then one last, one that was a candidate here.
Ansgar Dietrichs:is the sparse blot pool. Now, I wasn't sure, from glancing at the AP, whether this has any in-protocol changes, or whether this is a pure, kind of, out-of-protocol.
Ansgar Dietrichs:questions, so I'm not sure, also.
Ansgar Dietrichs:how much people have already looked into this. Overall, it seemed like there was…
Ansgar Dietrichs:Relatively strong support for this.
Ansgar Dietrichs:Does it make sense to… Cfi this today.
Ansgar Dietrichs:And Marius, maybe, if you can give some context?
Marius van der Wijden:Yeah, it's… it's out of protocol, but, I think it is very important.
Marius van der Wijden:And it is not super easy, so, client teams
Marius van der Wijden:Need to set aside some engineering time for it.
Marius van der Wijden:I guess that is why it was… proposed to ACD, so that It can, like…
Marius van der Wijden:It can be, bank teams.
Marius van der Wijden:If we included client teams concept, set aside the engineer time.
Marius van der Wijden:When thinking about the scope of the… of the fork.
Marius van der Wijden:I think it is very important.
Marius van der Wijden:For increasing the block… Coned.
Marius van der Wijden:We will probably not be able to go to…
Marius van der Wijden:the massive blob counts that we envisioned without this, so… Yeah.
Ansgar Dietrichs:And for all?
Raúl Kripalani:Yeah, so just to add to that, yeah, double-click on that, and specifically with, on the consensus layer, we're already…
Raúl Kripalani:working on testing and interoping on the partial messages, side of things on Gossip Sub, and that basically is the whole idea of cell-level messaging. So with that, we will be removing peer-to-peer, like, all…
Raúl Kripalani:network inefficiencies from the CL, where we're right now.
Raúl Kripalani:Transporting data that, you know, the node already has, and…
Raúl Kripalani:that will basically unleash the CL, but then the EL will become the bottleneck, because it is still fully replicating blobs in the mempool. So that will be… we predict that around 72 blob down, that will start becoming the choke point for the system.
Raúl Kripalani:And that's why we submitted the CIP. It is, right now, I would say, like, 90% confident that this can be rolled out progressively, and, like, it can be an opt-in, and over time, in… within the, like, even before Glamsterdam.
Raúl Kripalani:some nodes can already start supporting it. We still have to conduct some assessment there to analyze any risk for, like, network partitioning and so on, or block pool partitioning, if… so this is not entirely clear yet. So, the rationale for submitting this is to have a clear checkpoint that the network
Raúl Kripalani:should support this feature entirely as a whole by Glamstadam, but also to carve out some space in case we do actually, like, there is some…
Raúl Kripalani:Some possibility that we do need, a fully coordinated rollout, just to… in case we detect some risks of partitioning.
Ansgar Dietrichs:Right, and that was the general question, on the last call, how we would handle, proposed ERPs that do not have
Ansgar Dietrichs:protocol changes, that I put the other three that were in that category in the process box down there. None of them were, for now, like, the CFI candidates, because we wanted to first make that decision. I mean, Raul, as you're saying, this one here specifically at least has the potential to want to specifically be at the hardware boundary.
Ansgar Dietrichs:M…
Ansgar Dietrichs:I personally do think having non-protocol change EIPs in a hard fork to just signal prioritization can make sense.
Ansgar Dietrichs:Yeah, process-wise, is this… does this include any changes on the CL side directly? So is this something that… is this a CFI decision that we would have to make together with the ACDC side, or is this an EL side only?
Raúl Kripalani:There are some engine API changes, specifically for the CL to communicate to the EL any custody set changes, and that is pretty much it. As well, to receive cells only.
Raúl Kripalani:from the CL, but that's… from the EL, but that's actually coming sooner with V3. So it's really just the custody signaling side of things. So the change on the CL is very, very lightweight. I don't expect it to be… to be a blocker, and definitely not something that is consensus-breaking.
Ansgar Dietrichs:Sounds good. So then in terms of process, I think at least what we can consider here is CFI-ing it with the understanding that that's conditional on double-checking on the ACDC side, but because we have so much of this ping-pong, like, here, the decision would be on our side, and it's just a double-checking. Is there any unexpected concerns regarding that, engine API? So that would basically be, like, a one-week stay of.
Raúl Kripalani:Yes.
Ansgar Dietrichs:of a poll decision, but the question is, do we in general already have, even on the EL side, do we have enough support here? Do we have enough consensus that this is important, that we would want to make the CFI call today?
Ansgar Dietrichs:We had, client-wise, we had, 1S and two A's for this, so that did seem to signal pretty strong, overall support.
Ansgar Dietrichs:Maurice just spoke up in favor of it.
Ansgar Dietrichs:M.
Ansgar Dietrichs:I can, to step out of the coordinator role briefly, I can personally also express support, but…
Ansgar Dietrichs:Is there anyone that would basically specifically prefer to not have CFI today?
Ansgar Dietrichs:Okay, and I do think we make the decision today that,
Ansgar Dietrichs:we basically mark it as CFI, conditional on double-checking on the CL site, in a week.
Ansgar Dietrichs:Okay, so then we, add through the list. Now…
Ansgar Dietrichs:Good news is we made quite a few individual decisions, so this will cut down the list quite a bit. Thank you for sticking with me, this was a bit tedious, I understand that. Bad news is that we also now have, 4 minutes left.
Ansgar Dietrichs:And we specifically did not talk about any of the sections that require continued discussions, that were not just decision-ready. I think in… because of… in the interest of time, what I will do is I'll just briefly walk through that list that I put up on the agenda that's also just
Ansgar Dietrichs:my take on where there are open questions, so this is not at all necessarily, like, fully accurate or conclusive, but I do think the goal would be that in two weeks, we specifically focus on these open questions, no general purpose CFI, DFI discussions, unless maybe on the side if they come up, but really the focus on next ACDC… ACD will be to work through all of these individual questions.
Ansgar Dietrichs:I'll briefly go through them. So, the questions that we have is.
Ansgar Dietrichs:On the repricing side, in terms of the core gas, repricing, so that is not the state growth question specifically, but everything else, in the core, in this proposed core bundle, there was pretty strong interest,
Ansgar Dietrichs:Last call to consider unbundling this, and then in response, the champions, and that includes me, are working on a proposal to just basically regroup this in a more palatable
Ansgar Dietrichs:Form, so by 2 weeks from now, we would have to have a basis for
Ansgar Dietrichs:Of, of that work to, to discuss.
Ansgar Dietrichs:repricings, on the state growth side, that was one… that's just the one EIP that we have proposed right now, 8037, but there were questions of, is this quite the right approach? And there were two alternative proposals. We have, a write-up by Anders. I will…
Ansgar Dietrichs:Post that in the chat.
Ansgar Dietrichs:For people to look at, to compare these, the different ones. Also, by the way, Raul, your hand is still up, just, just to mention. So, so we have this right up by, by Andes on this point. Then we have the, topic of contract size increase. There's
Ansgar Dietrichs:none of those had… it basically has two set… two alternative approaches. Neither of them had clear support, and it seemed like…
Ansgar Dietrichs:we had, on the one hand, we had Geth and Guillaume that preferred the chunk-based mobilization, and then we had
Ansgar Dietrichs:other clients preferring the existing approach that we had already considered for Fusaka. So that one, I think we just need to resolve. Do we want to do one of the two, or do we want to do nothing?
Ansgar Dietrichs:hopefully a decision in two weeks. And then on the…
Ansgar Dietrichs:In the utility transaction block features block, we had, some…
Ansgar Dietrichs:updates by Zolt on 7745. I will note that Geth and Zolt were quite interested in this EIP, but most other clients
Ansgar Dietrichs:had concerns, so I'll post the update in… in chat, just to flag that we will make a decision there in two weeks as well. And then cryptography, post-quantum precompiles.
Ansgar Dietrichs:This is also what Nico came here to talk about. I think, Nico, I see your hand is up. I will say that we don't really have the time to go into this for now. The question there basically is.
Ansgar Dietrichs:for these is… well, we made one decision today. We made one DFI decision on Parkins, so the question on the other one is, is Glamstadlam the right time or not?
Ansgar Dietrichs:I do have… yeah, okay, then I appreciate that you took on the hand, because I think it's better to call… talk about it on next call. And then the last block of decisions we have to make is…
Ansgar Dietrichs:for these three, non-protocol changing EIPs beyond the SPASM block pool, yeah, how do we handle those? So, all of these questions are listed on the agenda for today, so maybe people can have a look at that, and, I'll also
Ansgar Dietrichs:Try to coordinate with people a little bit more, so in two weeks, we do have
Ansgar Dietrichs:A good basis for decisions on this one.
Ansgar Dietrichs:Mmm… Tony, do you… you have a comment?
Toni Wahrstätter:Yeah, do we… I mean, now it's almost too late, but do we also want to talk about the data repricing APs? If I remember correctly, like, 4 out of 5 clients?
Toni Wahrstätter:had the call data pricing at the S tier, so it might make sense to CFI. We have CFI DFPs that had way less support today.
Ansgar Dietrichs:Yeah, the problem is just that there were questions about the specific approach to these repricing APs, so whether we want to select them one by one, or consider them more as a grouping. I would, for that reason, hold off for now, although, yes, I think it seemed pretty clear that we will have
Ansgar Dietrichs:a repricing in the fork that will touch data. So, I think that's clear, but, like, just in terms of process, because otherwise, if we open that box now… I mean, now we can't open it anyway anymore, but that's why we didn't bring it up on this call yet.
Toni Wahrstätter:Okay, no, that's fine. It's fine, we don't need to discuss that. Okay.
Ansgar Dietrichs:Okay, and then I just mentioned the housekeeping we didn't get to, H-star name, we need to make a name decision, there's a link,
Ansgar Dietrichs:In… in the agenda, go and…
Ansgar Dietrichs:figure that out, everyone. And then there are…
Ansgar Dietrichs:comments that we should, clarify, kind of minimum hard fork testnet and maintenance rollout timelines on a future call. So all of that, hopefully, we get to in two weeks, but for today, that's all. Thank you, everyone, for your time.
Ansgar Dietrichs:I hope it was worth all of these micro-decisions, and talk to you all in two weeks.
Toni Wahrstätter:Thanks, everyone, bye-bye.
lightclient:Yep.
Chat Logs
00:04:29
Zsolt Felföldi:Replying to "Barnabas has sent yo..."
Do we have a star name starting with "gy"?
00:04:41
nixo:https://github.com/ethereum/pm/issues/1808
00:05:03
terence:happy to speak on the prysm issue
00:05:15
Barnabas:Think it was mostly prysm related bug.
00:05:22
nixo:https://notes.ethereum.org/Qcl9AZy6SiWAoTCSwDUTJg
00:07:20
Nicolas Consigny:Just for planning purpose : I Would like to make a quick point about the EIP process (discussion and deadline dates) before talking about crypto agility and PQ precompiles @Ansgar Dietrichs
00:07:44
Barnabas:Wouldn’t it be generally better to have a hotfix release out asap, with the flag enabled by default, then work on a proper fix and make a minor release?
For most operators its a lot easier to push a new version, vs adding a custom flag.
00:08:39
Toni Wahrstätter:Replying to "Just for planning pu..."
Is it on the agenda?
00:08:51
Nicolas Consigny:Replying to "Just for planning pu..."
yes
00:08:58
Potuz:GM crap I missed Terence's update
00:09:05
Nicolas Consigny:Replying to "Just for planning pu..."
not the meta point but the precompiles yes
00:09:11
Nicolas Consigny:Replying to "Just for planning pu..."
but because both are linked
00:09:18
Nicolas Consigny:Replying to "Just for planning pu..."
would like to make the point
00:09:39
Potuz:Not really, it was the same bug as in Capella
00:09:41
Potuz:resurfaced
00:10:07
Barnabas:I have delegated my vocal box to Stefan 😄
00:10:15
terence:participation back up to ~98%
00:10:59
stokes:bpo1 coming up
00:12:26
nixo:also ADCE on Jan 1?
00:12:48
Barnabas:whoever shows up to acde on jan 1 should be penalized 😂
00:13:08
Justin Traglia:Also cancel
00:13:10
nixo:cancel
00:13:39
Renaud-ZKNOX:A réagi à "cancel" avec ➕
00:13:45
Nicolas Consigny:One thing on fusaka is the safe RPC issues solved on OP chains ? (I heard unichain had issues yesterday ?)
00:14:15
Raúl Kripalani:Jan 1st => no sound decisions 😅
00:15:19
Justin Florentine (Besu):Besu wants FOCIL in G*, definitely for H* too.
00:15:30
Marc:Nethermind team supports SFI’ing FOCIL
00:15:46
nixo:if we go with a headliner proposal process, i have a proposed timeline: https://hackmd.io/@nixorokish/heka-timeline
00:16:07
lightclient:we should do the headliner proccess
00:16:10
stokes:just this one
00:16:27
Matthew Keil:we support SFI per h*
00:16:34
Trent:Feels most consistent to follow the regular headliner process
00:16:55
Toni Wahrstätter:It was to big to be put on top of ePBS and should now just follow the process as every other EIP.
Having many core devs committing to it is enough committment already, no SFI needed.
00:17:03
Lean F | Ethrex:Replying to "Besu wants FOCIL in ..."
Ethrex team agrees on this
00:17:54
Dustin:Nimbus still fine with either CFI or SFI for Heka
00:18:06
Barnabas:Lets aim to have Heka headliners set by end of Jan?
00:19:10
Trent:It’s clear we are still figuring out the headliner process. And there will be missteps and uncertainty, eg. the last 3 calls and various temp checks. I do not envy being in the position of call coordinator
But we should try to be consistent
00:19:26
Enrico Del Fante (tbenr):In teku we ending with a rough consensus with following the standard process. Even if we wanted to push FOCIL
00:20:21
Justin Florentine (Besu):is pectraA/B a helpful precedent?
00:20:45
Barnabas:Time to ship fusakA and fusakB
00:20:48
nixo:Replying to "is pectraA/B a helpf..."
i don’t think we want to enshrine that mess as process
00:21:36
Justin Florentine (Besu):Replying to "is pectraA/B a helpf..."
idk, i think the runner up for a headliner should be worth something, and not get forgotten for 6 months.
00:21:48
Justin Florentine (Besu):Replying to "is pectraA/B a helpf..."
it is nice to have something to do with the overflow
00:21:49
Pooja Ranjan:+1 to Nico
00:22:16
Toni Wahrstätter:Tim had a very clear process doc on ethmag. Not hard to find it.
00:22:31
Justin Florentine (Besu):Replying to "is pectraA/B a helpf..."
(I also didn't enjoy Pectra A/B) but we never really sorted the root cause
00:22:33
Ansgar Dietrichs:Regarding FOCIL, I personally agree we should not make process decisions now that would preempt the H-Star headliner process.
So e.g. FOCIL SFI is reasonable to me only if that doesn’t make selecting other headliner(s) outright impossible through the later normal headliner process
00:23:14
Barnabas:Could we please timebox FOCIL ? I feel like we been talking about FOCIL back and forth total 1.5h in the past 3 weeks
00:23:16
nixo:happy to draft sth but we should at least do it twice before it’s the “rule”
00:23:38
Nicolas Consigny:An to my question
00:23:42
soispoke:Replying to "Could we please time..."
Yeah stopping there sorry
00:23:58
Nicolas Consigny:Is it ok for someone to claim "champion" on an EIP that he didn't write and push it to ACD ?
00:24:08
Barnabas:Replying to "Is it ok for someone..."
sure
00:24:09
nixo:Replying to "Is it ok for someone..."
yes
00:24:10
Potuz:Alex and Ansgar on where the decision will be made
00:24:10
Potuz:Giphy [ID:v1dTuaCHDuEA8]
[Full message cannot be displayed on this version]
00:24:26
Nicolas Consigny:Replying to "Is it ok for someone..."
So authors have to be aware of this imo
00:24:26
Marc:Replying to "Regarding FOCIL, I p…"
other headliners could be in the same position as FOCIL in this fork - either we can ship it if possible or it could be pushed into next fork
00:24:27
Danno Ferrin (Tectonic):To address the PQ precompiles, I was in communication wth the authors and they were aware and supportive of me pushing them for Glamsterdam. I did this instead of writing my own EIPs for the PQ precompiles, which I nearly did.
00:24:29
lightclient:Idk, I think we should just stop discussing this and do the regular headlining process. Saying there was a chance we would “SFI” it was a mistake and violated the process
00:24:53
Carl Beekhuizen:Replying to "Idk, I think we shou..."
Strong agree.
00:25:59
Nicolas Consigny:Replying to "To address the PQ pr..."
Yeah I know but wasn't clear about the impact on the process. THanks for the support BTW much appreciated. I am sure they love to have you has a champion it's just a question of timing
00:26:00
Toni Wahrstätter:SFI'ing FOCIL also impacts work that would happen for 6-seconds slots, which is also a community favourite. Having FOCIL skip the headliner process would be unfair towards other headliners
00:26:12
Ansgar Dietrichs:https://notes.ethereum.org/@ansgar/glamsterdam-el-pfi-eips
00:26:35
Nicolas Consigny:Replying to "To address the PQ pr..."
E.g does it make sense to propose PQ precompiles while we don't have ways to deactivate EOAs private keys ?
00:26:50
draganrakita:Replying to "https://notes.ethere..."
Very nice list!
00:28:16
Ameziane Hamlat:Yes, besu in favour of it
00:28:22
Łukasz Rozmej:in favor
00:28:41
draganrakita:EIP-7768 makes sense
00:29:19
Nicolas Consigny:Replying to "Tim had a very clear..."
Still not even close in terms of traffic compared to https://eips.ethereum.org/ or EIP-1
00:29:45
frangio:what EIP ?
00:29:56
Renaud-ZKNOX:A réagi à "To address the PQ ..." avec ❤️
00:30:03
Nicolas Consigny:Replying to "Tim had a very clear..."
And if the process enforces deadlines for ACD discussion it should definitely be referenced in EIP-1
00:30:03
Justin Florentine (Besu):how many eips are we planning to CFI?
00:30:04
Barnabas:can we maybe highlight on the screen what we are talking about ?
00:30:15
Trent:https://eips.ethereum.org/EIPS/eip-7971
00:30:49
Renaud-ZKNOX:Répondre à "To address the PQ ..."
It does with 4337, but we need 7851 to enable PQ 7702
00:30:49
Danno Ferrin (Tectonic):Replying to "To address the PQ pr..."
Yes, a full EOA solution is not needed to provide value. a PQ precompile can still be used for smart wallets (safe, 4337) as well as sigining messages.
00:31:15
Renaud-ZKNOX:A réagi à "Yes, a full EOA so..." avec 👍
00:31:34
Barnabas:I don’t think we should limit the number of CFI-ed EIPs now
00:31:41
draganrakita:Replying to "https://eips.ethereu..."
Imo if this is done for tload/tstore, and it should be done for sload/sstore warm access. Would need to re consider the eip.
00:31:48
Barnabas:Replying to "I don’t think we sho..."
we can circle back to DFI-ing them later
00:31:49
Nicolas Consigny:Replying to "To address the PQ pr..."
Yep true but then from an ACD POV is "safe + 4337" enough to move the needle or should we bundle it with the a full solution ?
00:31:59
Barnabas:Replying to "I don’t think we sho..."
if they are tend to be too complex/useless
00:32:13
Renaud-ZKNOX:Répondre à "To address the PQ ..."
yeah, co-author of 8051 here, we are gratefull to Danno cause we would have missed this spot. Unfortunately too late to push 7851 as well.
00:32:14
Danno Ferrin (Tectonic):Replying to "To address the PQ pr..."
We have zero solutions if CRPQs arrive early in the window.
00:32:26
Mario Vega:Replying to "I don’t think we sho..."
This is good idea, some of these CFI candidates have no testing assessment yet, if we find that they are too complex we can circle back
00:32:33
Nicolas Consigny:Replying to "To address the PQ pr..."
We hit the solidity verifiers (available today)
00:32:54
Danno Ferrin (Tectonic):Replying to "To address the PQ pr..."
Adding one PQ precompile allows software wallets to at least lock value behind a PQ signature, efficiently.
00:32:58
Nicolas Consigny:Replying to "To address the PQ pr..."
1.9M gas for FALCON I would pay that any minute to save my net worth
00:33:23
Danno Ferrin (Tectonic):Replying to "To address the PQ pr..."
But eveveryone at onece? We need something on the order of thousands, not millions, to verify a sig.
00:33:25
Renaud-ZKNOX:A réagi à "Adding one PQ prec..." avec 👍
00:33:40
Anders Elowsson:Regarding EIP-8011, the issue with DFI is EIP-8037. We should ideally remain open to a metering approach similar or identical to EIP-8011 that only is focused on separating state creation, as well as an approach similar or identical to EIP-8075 for this purpose. It would be appropriate to wait with taking a decision on how to process state creation until we know how strong price increases that are necessary.
I have prepared a document outlining the three different paradigms for how the protocol can process state creation operations: https://notes.ethereum.org/@anderselowsson/3-paradigms-for-state-creation-repricing
00:34:27
Toni Wahrstätter:Did we now skip all repricing EIPs or will they still be discussed?
00:34:42
Anders Elowsson:We can take a decision on full 8011 but not restricted 8011 only for state if that makes sense.
00:35:10
Anders Elowsson:Also Maria is not here today. She is the champions for 8011 so might wanna give her a chance to chime in. Dunno
00:36:00
Nicolas Consigny:I get your point and we both want PQ resilience ASAP. Still I would rather have a combination of solutions rather than isolated PQ precompiles which could lead ACD to think that "problem is solved". In an emergency scenario not everyone will act fast so EOAs are rekt
00:37:15
Luis Pinto | Besu:Can’t the private key actually override the smart EOA signing? So the precompiles actually do not protect against PQ today. Now, there was an EIP to disable private keys floating around
00:37:53
Barnabas:I think all EIPs that are questionable now, should be just DFIed now.
00:38:24
Nicolas Consigny:Replying to "To address the PQ pr..."
No in safe and 4337 no EOA key
00:38:44
Justin Florentine (Besu):i think we should just CFI all teams S tiers, and then argue that out, and see what remains
00:39:02
Renaud-ZKNOX:Répondre à "To address the PQ ..."
We need some red button in case of quantum apocalypse. In this case it would imply a freeze. Users would be able to provide a ZK proof of knowledge of a seed from which to derive the PQ keys.
00:39:38
Renaud-ZKNOX:Répondre à "To address the PQ ..."
You just need a BIP44 in circuit
00:39:40
Nicolas Consigny:Replying to "To address the PQ pr..."
> to provide a ZK proof of knowledge of a seed from which to derive the PQ keys.
Yes that should be the case
00:39:41
Nicolas Consigny:Replying to "To address the PQ pr..."
yes
00:39:50
Nicolas Consigny:Replying to "To address the PQ pr..."
like in BIP 44
00:40:14
Luis Pinto | Besu:Replying to "To address the PQ pr..."
Really hope we don’t get to that
00:40:36
Łukasz Rozmej:DFI, this is micro-optimizations where bigger things are to be done first
00:41:08
Luis Pinto | Besu:Replying to "DFI, this is micro-o..."
BALs at least
00:41:29
Łukasz Rozmej:Kill that with fire before it lays eggs!
00:42:13
Renaud-ZKNOX:Répondre à "To address the PQ ..."
it is like the parachute under your seat in a flight. You don't want to use it. But would refuse the seat that doesn't come with it
00:42:15
Nicolas Consigny:Replying to "To address the PQ pr..."
We can have a smooth transition in H*. That's why I am advocating for ACD to consider a "full" solution ASAP. As I am afraid one isolated PQ precompile could be seen as "good enough for now" until we actually hit the wall
00:42:51
Danno Ferrin (Tectonic):Replying to "To address the PQ pr..."
Someone should procude a working “emergency zk proof from seed” circuit instead of talking about it. Until it’s been demonstrated it is execisable and as long as we have zero post-quantum DSAs we have zero backup we can activate on short notice.
00:42:55
Nicolas Consigny:Replying to "To address the PQ pr..."
So TLDR PQ precompiles gud. We need them ASAP. But we need ACD to understand that just this doesn't bring PQ resilience nor a good PQ emergency plan
00:43:09
Danno Ferrin (Tectonic):Replying to "To address the PQ pr..."
My point being a solution could be made but a solution doesn’t exist.
00:43:41
lightclient:I feel like we should go through the things we really want in the fork before going through the less desired ones?
00:43:48
Toni Wahrstätter:why are we discussing cfi for eg. 7971, which was more contentious, but not for 7976 which was S-tiered for 4/5 clients
00:43:52
Greg K | Lido:Isn't 7903 contradicting with 7907?
00:43:53
Renaud-ZKNOX:Répondre à "To address the PQ ..."
this zk proof is actually easy to implement. There is just no business model behind it.
00:43:55
Nicolas Consigny:Replying to "To address the PQ pr..."
I think Bitcoin people did it already ? OP_STARK_VERIFY does it no ?
00:44:58
Justin Florentine (Besu):Replying to "I feel like we shoul..."
we spent a lot of work doing the tiering, should be using that.
00:45:10
Danno Ferrin (Tectonic):Replying to "To address the PQ pr..."
We don’t have an equivelant OP_STARK_VERIFY protoype for ethereum. It falls into the joke about a mathamatician not putting out a fire because a “solution exists”
00:45:15
Łukasz Rozmej:I think we can increase contract size without chunking, just wouldn't go to 256kb
00:45:15
Renaud-ZKNOX:Répondre à "To address the PQ ..."
Any zk dev can ship this. Only thing missing is the incentive maybe. There is no UX problem with this proof being long to compute (and verification will be fast).
00:45:52
Nicolas Consigny:Replying to "To address the PQ pr..."
Ok let's discuss business model shouldn't be a problem here
00:45:56
Renaud-ZKNOX:Répondre à "To address the PQ ..."
It just takes some time, one must implement HMAC512 in circuit
00:45:57
draganrakita:Replying to "I think we can incre..."
48kb would be great, even 32kb would be good, it is definetly needed.
00:45:58
Luis Pinto | Besu:Replying to "I think we can incre..."
Not sure about that. CODECOPY already has pricing broken without code chunking
00:46:02
lightclient:Wait you can’t have them together?
00:46:16
Łukasz Rozmej:Replying to "I think we can incre..."
I'm fine with everything up to ~64kb
00:46:24
nixo:we got outreach from an indexer on 7708, they feel very strongly on its inclusion: https://ethereum-magicians.org/t/community-feedback-on-non-headlining-features-in-glamsterdam/26410/6?u=nixo
he couldn’t come today, but added it to the agenda this morning
00:46:30
frangio:Replying to "To address the PQ ..."
the implementation is not the difficult part but the analysis of how viable it is as a solution. keys are not all derived from seed phrases. see MPC, also keys from KMS
00:47:17
Renaud-ZKNOX:Répondre à "To address the PQ ..."
let's hope those power users will have a higher migration rate
00:47:20
Danno Ferrin (Tectonic):Replying to "To address the PQ pr..."
To be a real emergency solution I would want to see somehting that is in a state it could be live on chain within 30 days of notice.
00:47:45
draganrakita:Would say kill it, but it is low priority
00:47:49
Nicolas Consigny:Replying to "To address the PQ pr..."
That was a response to your previous point " Until it’s been demonstrated it is execisable" well if it has been implemented elsewhere we could consider it has been demonstrated. But ofc agree with you on the need to do it asap on ethereum
00:47:53
Łukasz Rozmej:this is cleanup, low effort but low value TBH
00:48:16
Justin Florentine (Besu):but also low risk?
00:48:21
Trent:Replying to "I think we can incre..."
Should something related to contract size be CFId then?
00:48:25
Barnabas:if we keep postponing decisions, we gonna have the same call again in 2 weeks
00:48:44
Trent:Replying to "I think we can incre..."
It doesn’t appear to marked that way, and I know the dev ecosystem is interested
00:48:46
lightclient:CFI it
00:48:52
Carl Beekhuizen:Replying to "if we keep postponin..."
not trying to postpone, just think we need to consider it at the end
00:49:18
Greg K | Lido:Replying to "Wait you can’t ha..."
7903 removes the initcode cap, 7907 keeps the cap but increases the value.
7907 also increases the max contract code size.
00:49:35
Danno Ferrin (Tectonic):Replying to "To address the PQ pr..."
exercisable would be nice, but go live with 30 dyas of notice is what I would want to see to call it a viable emergency solution. That doesn’t require an execrised solution, but I would expect it to be a bit furhter along than “bitcoin can do it”
00:49:36
Greg K | Lido:Replying to "Wait you can’t ha..."
I think 7907 is the most appropriate choice here
00:49:43
Justin Florentine (Besu):it'd be an ERC-20 log i'd imagine
00:49:44
Nicolas Consigny:Replying to "To address the PQ pr..."
To be a real emergency solution I would want to see somehting that is in a state it could be live on chain within 30 days of notice.
I agree very much. We have the same goals here. My fear was just that we will burry our heads in the sand if we have one PQ precompile
00:50:00
Danno Ferrin (Tectonic):Replying to "To address the PQ pr..."
I’m not stopping at one PQ precompile, trust me.
00:50:07
Nicolas Consigny:Replying to "To address the PQ pr..."
Ok good
00:50:37
Renaud-ZKNOX:A réagi à "I’m not stopping ..." avec 👍
00:50:42
Dustin:Nimbus position: https://pureth.guide/glamsterdam/#future (i.e. 7708 doesn't suffice on its own)
00:51:33
draganrakita:Replying to "Nimbus position: htt..."
What is missing?
00:51:37
Tamaghna Choudhuri:Shipping 7708 + 7745 together makes a lot of sense
00:52:26
Dustin:Replying to "Nimbus position: h..."
"Ensuring that the ETH balance is exactly the difference of all inputs minus all outputs is essential for reliable accounting, and removes the requirement for external indexers for basic wallet and dApp usecases. This should cover all initiated transactions, all inner non-zero value transfers, all fee payments (base + priority have different recipients!), beacon chain operations, as well as original genesis balances. How exactly this is done needs more discussion. Only doing EIP-7708 is insufficient to remove external indexers as certain ETH balance changes are still not covered."
00:52:28
Łukasz Rozmej:7745 is headliner size
00:52:54
Dustin:Replying to "Nimbus position: h..."
it enumerates other omitted cases
00:53:07
Mario Vega:Replying to "7745 is headliner si..."
Due to ssz formatting right? or something else?
00:53:23
Marc:was A tier for us so I guess CFI
00:53:36
Łukasz Rozmej:Replying to "7745 is headliner si..."
just sheer complexity, ssz adds even more
00:54:08
Nicolas Consigny:Replying to "To address the PQ pr..."
> Someone should procude a working “emergency zk proof from seed” circuit
let's create a group for this @Renaud-ZKNOX @Danno Ferrin (Tectonic) will reach out on signal
00:54:33
Dustin:Replying to "7745 is headliner ..."
SSZ formatting per se is only part of it
00:54:40
Tamaghna Choudhuri:Replying to "7745 is headliner si..."
@Mario Vega for 7745 the proof format is still a wip other than that the complexity of the filtermap impl is itself also is quite complex
00:57:36
Barnabas:cfi it
00:57:39
Justin Florentine (Besu):cfi it
00:58:35
Zsolt Felföldi:Replying to "7745 is headliner si..."
Python EELS is not terribly complex but I agree it's not trivial. I hope I can finish the missing spec parts like proof format and wire protocol ext in december.
00:58:49
SanLeo:Replying to "To address the PQ ..."
I'm potentially interested in helping on this, could I be added to the group?
@sanleo on discord, or @sanleo461 on tg
00:59:04
Ansgar Dietrichs:sorry that this is so tedious, but if we come out of this call with 10-15 clear individual EIP decisions, that really makes our job much easier on the rest
00:59:25
Luis Pinto | Besu:Cfi it
01:00:00
Luis Pinto | Besu:Replying to "Cfi it"
There are EOF tests as well, it had plenty coverage
01:00:03
Zsolt Felföldi:Replying to "7745 is headliner si..."
I also think I can have a devnet geth implementation by first half of jan, then we'll see.
01:00:28
lightclient:But we still have the legacy without the call and returns? So we can’t transpile it
01:00:37
Dustin:Replying to "7745 is headliner ..."
These still point to major missing elements, nonreadiness and inability to sufficiently assess its overall complexity
01:00:52
Luis Pinto | Besu:New contracts will have guarantees from what I read from the EIP
01:01:01
Dustin:Replying to "7745 is headliner ..."
proof format and wire protocol are not small side points
01:01:04
lightclient:Replying to "But we still have th..."
Sure, but there are a lot not new contracts
01:01:34
Zsolt Felföldi:Replying to "7745 is headliner si..."
I don't see these as major missing elements but still, I'll finish my proposed specs so we can discuss it further.
01:01:39
lightclient:Replying to "But we still have th..."
Also it would require solidity to integrate it too, not like we get benefits of it for free
01:01:44
Greg K | Lido:Replying to "sorry that this is..."
A small issue in the process is that there is no prioritization taken into account.
So if we CFI 10 EIPs with lower priority and keep it open about some others "a bit more important" due to technical questions being open, then the volume of CFIed EIPs might lead to DFI-ing the remaining ones (even more important)
01:01:59
Barnabas:How complex is it to implement 7979?
01:02:09
lightclient:Replying to "How complex is it to..."
Not too bad
01:02:16
Alexey:Replying to "But we still have th..."
disallow calls to old ones?
01:02:27
Marc:Replying to "How complex is it to…"
as lukasz mentioned may be already implemented for EOF
01:02:38
Luis Pinto | Besu:Replying to "But we still have th..."
They were eager to have EOF even
01:02:44
Tamaghna Choudhuri:Replying to "7745 is headliner si..."
We will have a nimbus el impl in jan to do a devnet too but both me and etan are of the opinion its better to get 7745 for h star
01:02:56
Carl Beekhuizen:Replying to "sorry that this is s..."
yeah, it’s hard to make decisions in a vacuum
01:03:05
lightclient:Replying to "But we still have th..."
We can’t disallow calls to old contracts 🤣
01:03:15
draganrakita:Replying to "How complex is it to..."
Two opcodes, that push, pop PC to local Interpreter stack.
01:03:38
Alexey:Replying to "But we still have th..."
from new ones man
01:03:42
Dustin:Replying to "7745 is headliner ..."
Lukasz wrong thread?
01:04:00
Justin Florentine (Besu):Replying to "But we still have th..."
0xEF has entered the chat
01:04:15
lightclient:Replying to "But we still have th..."
We’re not going to fragment contract calling the EVM
01:04:37
Łukasz Rozmej:Replying to "7745 is headliner si..."
sorry
01:05:05
Łukasz Rozmej:Replying to "But we still have th..."
But we still have the legacy without the call and returns? So we can’t transpile it
just price it out with time
you can transpile that too, we did that, the result is just quite messy and unoptimised
01:05:31
Marc:why are people against this EIP?
01:05:33
Łukasz Rozmej:no compiler wants to optimise several tens of thousands instruction function
01:05:38
Luis Pinto | Besu:Replying to "But we still have th..."
It’s additive and doesn’t break any deployed contracts. What other solution do you want?
01:05:56
frangio:Replying to "why are people aga..."
because it's a rehash of EOF
01:06:08
Marius van der Wijden:Replying to "why are people again..."
Complexity and prioritization
01:06:13
Łukasz Rozmej:I am fine with CFIng it for Glamsterdam :)
01:06:16
Marc:Replying to "why are people again…"
way smaller though right
01:06:57
Luis Pinto | Besu:>no compiler wants to optimise several tens of thousands instruction function
Not every compiler do exclusive full method body optimizations. Look into OSR
01:07:09
Dustin:Replying to "7745 is headliner ..."
@Tamaghna Choudhuri this also is a data point regarding complexity modulo SSZ, because that aspect is significantly reduced due to Nimbus having an SSZ stack
01:07:59
nixo:@Greg Colvin we (my team, protocol support) will reach out to you about setting up a breakout call
01:08:13
Dustin:Replying to "why are people aga..."
I assume there are arguments for, beyond "industry standard"?
01:08:28
Łukasz Rozmej:I'm for breakout room!
01:08:56
frangio:what is the point about optimizations? why does the transpiled code need to be optimized? we don't optimize EVM code once deployed
01:09:00
Mario Vega:Replying to "why are people again..."
This section looks tricky to get correctly tested: https://eips.ethereum.org/EIPS/eip-7979#constraints-on-valid-code
01:09:05
Łukasz Rozmej:Replying to "why are people again..."
because it's a rehash of EOF
EOF the most important parts
01:09:32
Daniel Lehrner (Besu):Replying to "why are people again..."
It would be helpful if Solidity or Vyper would share their opinion on it. I am also missing who wants to include it
01:10:52
Danno Ferrin (Tectonic):DFI EIP-7619 - The NIST handlers in the las few weeks have made it clear Falcon / FN-DSA-206 will be undergoing a lot of changes in the next year. We don’t want Keccak/SHA3 again.
01:11:29
draganrakita:About EIP-8024 it would be simpler and maybe better to use SWAPN PUSH x00 format. CFI for sure
01:11:56
Marc:Replying to "DFI EIP-7619 - The N…"
you think we should go with ML-DSA instead then?
01:12:01
jimjim:Sorry just joined. No FOCIL? 🥺
01:12:12
Barnabas:whats wrong with 8030?
01:12:15
Nicolas Consigny:8052
01:12:23
Renaud-ZKNOX:Dilithium Pros:
Web2 adoption (chromium, tls, probable future of passkeys)
FIPS204 stabilized
MPC/ZK more friendly (less hashing)
HW vendors + first HW implementation
Dilithium Cons:
slower than falcon, higher bandwidth and key sizes
hashing not separable from core operations like in 8052 FALCON (7619 is monolithic)
01:12:23
Marius van der Wijden:I think its to early to pick a pq sig winner at this moment. I think its important to continue the expkoratory work though
01:12:27
Greg Colvin:8013 depends on 7979, and I proposed it on the chance that the objections to 7979 are that it is too simple. So DFI is appropriate.
01:12:29
Dustin:Replying to "Sorry just joined...."
You missed FOCIL
01:12:49
Justin Florentine (Besu):CFI? 8051
01:14:11
Nicolas Consigny:CFI 8052 I'm in favor too
01:14:12
Danno Ferrin (Tectonic):We will want both ML-DSA and FN-DSA, the issue is FN-DSA is getting some non-trivial revisions in data formats in the next year
01:15:37
Barnabas:we just included the secp256r opcode in fusaka, why not have the matching 8030 ?
01:15:44
Luis Pinto | Besu:Are clients fully against EIP-7932 or just for Glamsterdam?
01:15:48
Nicolas Consigny:Replying to "DFI EIP-7619 - The N..."
Agreed with Danno we want ML-DSA as it is today. FN-DSA I'm following very closely the process and I think they'll not do the revisions but it's indeed a bet
01:15:53
draganrakita:P256 tx is interesting, should definitelly be considered for later hardforks
01:16:10
frangio:Replying to "P256 tx is interes..."
isn't it superceded by native AA?
01:16:23
Danno Ferrin (Tectonic):Replying to "Are clients fully ag..."
Two unrelated issues: SSZ transacitions and alternat sig algos. It’s packing two unrelated issues into one EIP
01:16:24
Nicolas Consigny:P 256 tx I strongly oppose the curve isn't "nothing under the sleeve" also not PQ aligned
01:16:30
draganrakita:Replying to "P256 tx is interesti..."
What is EIP for native AA?
01:16:38
Mario Vega:8030 requires 7932 no?
01:16:53
frangio:Replying to "P256 tx is interes..."
7701
01:16:56
Renaud-ZKNOX:Répondre à "P256 tx is interes..."
7701
01:17:03
Barnabas:Replying to "8030 requires 7932 n..."
thought it would only require the 256r precompile.
01:17:42
Mario Vega:Replying to "8030 requires 7932 n..."
EIP states it in the “Requires” section
01:19:09
Renaud-ZKNOX:A réagi à "P 256 tx I strongl..." avec ➕
01:19:32
Barnabas:thanks for circling back guys. Feel free to DFI both.
01:19:39
frangio:my assumption is there should be a new PQ tx type in the future, all other kinds of signatures should go through AA. is there no consensus about this?
01:19:57
Tamaghna Choudhuri:Replying to "7745 is headliner si..."
😆
Yeah nimbus does already have good starting point for ssz parts hence its in a really good position to gauge the difficulty of just the filtermap logic + proof format + wire protocol has from the devnet in jan .
That will put more light on a clearer point on the non-SSZ side for others
01:20:15
Marius van der Wijden:Dfi ssz for now pls
01:20:45
Danno Ferrin (Tectonic):It should be a cryptographically agile TX type, one that can accept multiple algorithms and evolve over time. The real PQ theme is Crypto Agile implementations.
01:20:53
Marius van der Wijden:Purely out of protocol
01:21:05
Dustin:Replying to "Dfi ssz for now pls"
"for now", the perpetual SSZ library issue
01:22:39
Danno Ferrin (Tectonic):Replying to "Dfi ssz for now pls"
Ok, let’s formalize in the EL never doing SSZ when RLP can work. no need to keep this going.
01:22:48
Nicolas Consigny:Replying to "my assumption is the..."
Crypto agility yes please. The PQ era will be a land of new primitives we don't want Ethereum to be stuck. We shouldn't go all in on one scheme
01:23:46
Marius van der Wijden:Replying to "Dfi ssz for now pls"
Not really just the library issue imo, just general prioritization. Other features are just more important in my opinion
01:24:06
Justin Florentine (Besu):Replying to "my assumption is the..."
i don't think tx signatures should be left up to only the application layer. a signature type byte goes a long way to future proofing ethereum.
01:24:21
Marius van der Wijden:Oh we also need a fully coordinated rollout for eth/70
01:24:32
Marius van der Wijden:We could bundle it with a bpo
01:24:53
Barnabas:Yeah I think non protocol coordinated things should be targetting BPOs
01:25:10
Danno Ferrin (Tectonic):Replying to "Dfi ssz for now pls"
‘Not Now’ is indistinguishable with ‘never’ when there is no threshold to cross. What is that threshold? Needing other issues to clear out will never change because new issues will always be considered more important.
01:25:43
Danno Ferrin (Tectonic):Replying to "Dfi ssz for now pls"
A flat “no” will make planning easier.
01:26:29
draganrakita:Replying to "Dfi ssz for now pls"
Imo, I could live with not doing ssz at all. It will always be a low priority imo.
01:26:32
Raúl Kripalani:Yeah the center of gravity for this is the EL
01:26:46
Dustin:Replying to "Dfi ssz for now pls"
On very few topics, though, is there a commitment to "never" in a positive sense
01:26:51
Luis Pinto | Besu:Replying to "Dfi ssz for now pls"
Put Claude working on it
01:26:59
Dustin:Replying to "Dfi ssz for now pls"
It would be strange to do that specifically for SSZ
01:27:07
Raúl Kripalani:SG, thanks!
01:27:07
Danno Ferrin (Tectonic):Replying to "my assumption is the..."
Also L2s can experiment with non L1 signaures with a type byte, for example. If they don’t have issues with P256 they can support P256 without requiring L1 ot adopt.
01:27:16
Josh Davis:CFI
7778
7708
7843
8024
8070*
DFI
8011
8053
8059
8057
7791
7819
7979
8013
7619
7932
8030
6404
6466
Delay
7971
8032
7903
7668
01:27:57
Toni Wahrstätter:Can we talk about some of the repricing EIPs such as the calldata one, which had big support by clients?
01:28:00
Nicolas Consigny:8052 CFI ?
01:28:03
Dustin:Replying to "Dfi ssz for now pls"
@Luis Pinto | Besu there are already a half-dozen Go SSZ libraries. They're all lacking in some way, apparently
01:28:15
Nicolas Consigny:Replying to "CFI
7778
7708
7843
8..."
8052 CFI I think
01:28:22
Nicolas Consigny:Replying to "CFI
7778
7708
7843
8..."
the other was DFIed
01:28:28
Josh Davis:Replying to "CFI
7778
7708
7843
8..."
That decision was not made
01:28:41
Danno Ferrin (Tectonic):Replying to "8052 CFI ?"
8052 DFI, it’s another falcon EIP.
01:28:57
Nicolas Consigny:Replying to "8052 CFI ?"
Sorry sorry
01:29:00
Ansgar Dietrichs:https://notes.ethereum.org/@anderselowsson/3-paradigms-for-state-creation-repricing
01:29:02
Nicolas Consigny:Replying to "8052 CFI ?"
8051 I meant
01:29:14
Danno Ferrin (Tectonic):Replying to "8052 CFI ?"
crosses fingers for FN-DSA ready for H-star*
01:29:21
Nicolas Consigny:Replying to "CFI
7778
7708
7843
8..."
I think we said DFI for falcon CFI for ML DSA
01:29:46
Danno Ferrin (Tectonic):Replying to "CFI
7778
7708
7843
8..."
ML-DSA was in the more discussion list
01:29:50
Nicolas Consigny:Replying to "8052 CFI ?"
yep yep but 8051 for glamsterdam right ?
01:29:55
draganrakita:EIP-7907: Meter Contract Code Size And Increase Limit sounds good for Glamsterdam
01:29:58
Carl Beekhuizen:Replying to "CFI
7778
7708
7843
8..."
We didn’t make a decision on 8051(ML-DSA)
01:30:05
Danno Ferrin (Tectonic):Replying to "8052 CFI ?"
More discussion list, neithr C nor D FI
01:30:10
Ansgar Dietrichs:https://gist.github.com/zsfelfoldi/3f0f44c4ac0fb940907f9fa714d2334c
01:30:20
Nicolas Consigny:Replying to "CFI
7778
7708
7843
8..."
Ah ok
01:30:37
Nicolas Consigny:Replying to "8052 CFI ?"
Ok ok
01:30:57
Nicolas Consigny:Replying to "8052 CFI ?"
My bad next call
01:31:17
Marius van der Wijden:Dfi max blob flag, shouldn't be an eip
01:31:34
Luis Pinto | Besu:Replying to "EIP-7907: Meter Cont..."
I don’t get, why fixing things with a patch while we could fix it in the design? how can you remove contract size limits without something like code chunking?
01:31:34
Marius van der Wijden:Replying to "Dfi max blob flag, s..."
Clients should just implement it
01:32:05
Barnabas:Do we plan to make a decision on every single EIP next acde? So we can go to the end of the year break with knowing which EIPs are DFI/CFI-ed?
01:32:17
Barnabas:Replying to "Dfi max blob flag, s..."
just do it then 😄
01:32:18
draganrakita:One by one please, most (maybe all) should be CFI-ed
01:32:28
Marius van der Wijden:Replying to "Dfi max blob flag, s..."
I have a pr
01:32:32
Josh Davis:HEKOTA
01:32:37
Barnabas:Replying to "Dfi max blob flag, s..."
lets go
01:32:44
Nicolas Consigny:Replying to "CFI
7778
7708
7843
8..."
I was confused it was nowhere in the list
01:32:47
Danno Ferrin (Tectonic):But what’s the mascot animal, we can’t end yet!
01:32:54
Marius van der Wijden:Replying to "Dfi max blob flag, s..."
I think it was already merged even
Summary
15 highlights
· 8 decisions · 4 action itemsExperimental
Summary
15 highlights · 8 decisions · 4 action itemsExperimentalfork status and schedule
glamsterdam cfi
- EIP-7778 (block gas accounting without refunds) - CFI, universal support00:27:56
- EIP-7708 (ETH transfer logs) - CFI despite pricing concerns00:54:07
- EIP-7843 (slot number opcode) - CFI for future slot time changes00:56:35
- EIP-8024 (SWAP/DUP/EXCHANGE opcodes) - CFI with strong client support01:10:04
- EIP-8070 (sparse blob pool) - CFI conditional on CL confirmation01:26:49
glamsterdam dfi
- EIP-8011 (multidimensional gas) - DFI as overly complex00:35:00
- EIP-8053, 8059, 8057 (gas precision/locality) - DFI00:40:57
- EIP-7791, 7819, 7979, 8013 (various opcodes) - DFI00:55:52
- EIP-7619 (Falcon PQ) - DFI; NIST format changes pending01:12:53
- EIP-7932, 8030, 6404, 6466 (signatures/SSZ) - DFI01:15:09
Decisions
- Cancel ACDC Dec 25 and ACDE Jan 1; explore replacement00:13:13
- EIP-7778 moved to CFI00:27:56
- EIP-7708 moved to CFI00:27:56
- EIP-7843 moved to CFI00:27:56
- EIP-8024 moved to CFI00:27:56
- EIP-8070 moved to CFI; conditional on CL confirmation00:27:56
- EIP-8011, EIP-8053, EIP-8059, EIP-8057, EIP-7791, EIP-7819, EIP-7979, EIP-8013, EIP-7619, EIP-7932, EIP-8030, EIP-6404, EIP-6466 moved to DFI00:35:00
- Postponed: 7971, 8032, 7903, 7668 pending further review00:29:20