All Core Devs - Execution #221

Transcript

Justin Florentine: Good morning, all core devs!

Tim Beiko: Mori, Justin. Okay, we'll get started in just a minute.

Okay, we can move over to the livestream.

Josh Davis: You're alive.

Tim Beiko: Thanks, Josh. So welcome, everyone, to ACDE number 221. I have a fairly light agenda today, but we'll talk about a lot of important things, so, Fusaka, obviously, and, the path towards the testnets. Then, if there's any, updates on Glamsterdam, we can cover those, and a couple minor process things. But to start on Fusaka, we've had the Bug Bounty competition, live. I don't know if Frederick is on the call to give a… High-level overview of how that's been going.

Fredrik Svantes: Yeah, I'm here. Yeah, we have, had a few interesting reports. We've had a lot of… Issues that are not actually issues as well, but, Yeah, things are, definitely progressing, and What's… like, if we look at the previous, competitions, we've seen more and more valid reports as the competition nears its end, because it's quite complex to… To wrap your head around these, these upgrades, so, Yeah, quite excited to see what's gonna come out of the competition.

Tim Beiko: Thanks. And yeah, I know, there's been, like, already some bugs reported in some clients, some clients seem to be working on them, But yes, at least so far, nothing catastrophic, seems to have, come up.

Fredrik Svantes: Nothing, nothing that should affect the timeline has come up on the main upgrade or anything should, has come up yet.

Tim Beiko: Nice. I'm… Yeah, so I guess this… Yeah, this kind of ties into the second point, so the testnet schedule. We discussed this last week, and had, like, a full update for the rollouts for Fusaka, including the BPOs on testnets. So the plan was to, for Koleshky, on October 1st, so basically a week from now, and then, two weeks after that for Sepolia, two weeks after that for Kudi, have the BPOs, on each of these networks, activate one week after their, Fusaka activation. So, yes, there's this… still makes sense to people. I know some clients have put out some releases, so the plan is we'll, announce this formally with a blog post tomorrow, once we have a couple more releases. I think there might be one or two clients, who would have a release more by Monday than by tomorrow.

But yeah, just wanted to give people a chance to chime in on the schedule, and… Raise any concerns before we… move ahead. Okay, Lighthouse release will be ready Monday, and… Okay, we're… and then, yeah, Barnabas saying we're… we still don't have a release from Geth, Lighthouse, Nimbus, Prism. I guess, is there anyone from Geth, Nimbus, or Prism that wants to give a… Bit of context. Or EPA for their releases.

Dustin Brody: Sure. So… the release, per se, for Nimbus is… ready? We're having process issues on the… on the… Build side for… still… unclear reasons. In any case, that's where we are. Where we are, sorry.

Tim Beiko: Got it. And I guess… Should we expect something in the next day or so, or… I…

Dustin Brody: That… that's the goal, yeah.

Tim Beiko: Good luck, yeah. Sounds good.

Dustin Brody: In any case, we're not debugging Ethereum issues at this point. We're looking at others.

Tim Beiko: Yeah, debugging CI pipeline issues. Yeah, yeah. Yeah, that's a good sign. Anyone from Prism or guests wanna… Give some coffects? Okay, if not, then, oh, yeah, Prism is working on it, also hoping for a release in the next day or so. Awesome. And then, yeah, Geth, if you want to help Geth also, working on it already, he's trying to get it out today. So yeah, so, some clients already have the releases out. If you're using those other clients, you can already go to their GitHub pages and download the latest release. for everyone else, expect something either tomorrow or Monday. We'll have the announcement go live tomorrow, and then obviously update it on Monday if more releases come in, from other clients.

And then, Barnabas said that PandaOps is gonna run, Shadow Fork of Holeshky tomorrow with, I guess, the releases that are out, and then potentially some of the branches, for the, targeted releases for other clients. But yeah, congrats, everyone. It's been a… long, long sprint, to get the Fusaka releases, so excited to see this, Yeah, finally about to ship on testnets, yeah, Trudy, great work, everyone. And yeah, for anyone who wants the full schedule ahead of the, announcement tomorrow, the Meta EIP, EIP7607 has been updated, so there's, both the fork activations there, as well as all the BPO listed for all of the testnets, and then once we've seen Houdi finally activate successfully, assuming there's no issues through this rollout, obviously, then we talk about, the specific timeline for mainnet.

I'm… And then one last exciting thing, I guess, to, at least call out on this call is that as part of this release, we've, discussed on Monday raising the default gas limit on mainnet to 60 million, so we had an informational EIP for this, and I believe, the EL clients and CL clients that are, that are being released will have a default value for $60 million as part of their mainnet Fusaka releases. So the testnet's already running at $60 million, but then Once we have these mainnet releases out, the plan is to have a 60 million default gas limit so that, yeah, the network can kind of, increase towards this by default. Once we… once we start, preparing for… for, Fusaka's activation on Mainnet, and if things go smoothly, this means that before Fusaka goes live, Mainnet would already be running at 60 million gas.

Pop. Yeah, any comments? Thoughts on this? Okay, that's the last minor thing, so, for everyone who's just an EIP author for Dysphoric. When we move to testnets is the time to move the EIPs to last call, so I… I opened a bunch of PRs right before this call. to move every single Fusaka EIP to last call, so if you're an author, you can just go and review the PR and ideally approve it or make any final changes in your EIP, and then, once mainnet is, is, once Fusaka's gone live on Mainnet, we'll move all these to 5 off. But yeah, anything else on Fusaka? We are in the finishing stages.

Okay, off. Nice. Yeah, again, congrats, this is huge to finally see this start to ship. Moving on, then? Glamsterdam, I know there were some breakouts on EPVS and block access lists. Did people want to give updates on those, or have points from them they wanted to discuss on the call?

Toni Wahrstätter: I can give a quick update on block access lists. We had the breakout on Wednesday, we discussed, several points, yeah, please have a look at the agenda. Basically there's no change to the block level access list ERP. We went a little deeper on self-destructs and how we want to handle precompiles in the block level access list and clarified Yeah, how clients should, should handle them. So, not that many news, I think. We are still, on the timeline to, having the first FNET by October.

Tim Beiko: I'll sub… Any other thoughts or updates on BALs? And, yeah, I… Taryn said in the chat there's an EPBS breakout, tomorrow. Taryn said, do you think people should Read up on, or try to look into before that?

Terence Tsao: We had a SPAC release, thanks to Justin, yesterday for, I believe this is Beta 0, so I think, like, EI37732 with this release, at least the container type and the stage transition function are at a pretty good stage, such that we can implement and ready for definite zero. Hopefully, early November and end of October. we should… we, like, want to claim will have a definite zero by then, but the latest spec is good for that. It also contains spec tests for the basic things, so we can do that as well. And yeah. And, if there's questions, feedback, yeah, this Friday's breakout is a good forum for that.

Tim Beiko: Nice. Barnabas asking if there's any EL implementation progression.

Terence Tsao: For, for EPBS, EIP7732, there's no EL, changes at all, yeah.

Barnabas Busa: My question was for Atlanta.

Tim Beiko: Both. Okay, got it. Yeah. Yeah, do any of the ELs have started to work on the ELs?

Andrew Ashikhmin: Yeah, so in Aragon, we've started working on it, but it's still early days.

Tim Beiko: Okay, and Justin's saying Basu has, and I believe Geth has as well, so… at least a couple of the… ELs are, working on it, another one too, so… Nice. And then, back to EPBS, Barnabas is asking whether we should use, the latest CLPAC as the basis, I guess, for both EPBS and block accesses, should we use, yeah, beta 0 from V1.6 to base these definites on? I assume we should have to make sure that they're based on Fusaka, but does anyone… Disagree with that? Okay, maybe you can discuss this, I think, but yeah, I think to the extent we can build both the BAL and the PBS definites on top of Fusaka, that will save us some pain in the future, trying to rebase on the… from an old version of the spec.

Anything else on that? either EPVS or block access lists people wanted to bring up. Okay, if not, then, the other thing I wanted to flag for, Amsterdam is, obviously, we've started to work on these two EIPs that are SFI'd, want to make some progress on them before accepting anything else, but, in terms of proposals for at Amsterdam generally. We said the deadline should be when we put out the mainnet releases for Fusaka. Which we don't have a date for yet, but I expect would happen in the next month or so. And so, if anyone on this call or listening has some EIPs they want to propose for Fusaka, or sorry, for Glamsterdam, please do so in the next few weeks. To do this, you just open a PR against the Meta EIP for Glamsterdam, and,

yeah, propose your EIP. Justin?

Justin Florentine: Hi, Tim, long-time listener, first-time caller. Quick question. How do you imagine, when we have EIPs that are, like, really early for CFI, getting them from CFI to SFI while still juggling all of the smaller PFI issues. I know I'm using a lot of acronyms here, but I'm thinking about things like, FOSSIL, Right? Where we're kind of like, we really want to do this, but it's also kind of a lot of work, and I'm just curious as to, like, how we imagine this fitting into this early process where we're trying to get everything in order and promote them through the different stages. So, thanks for your time, I'll take my answer off the air.

Tim Beiko: Thanks. I guess my view there is… Yeah, look, we have to gate when the new proposals come in, so it limits what we have to review. So first step is actually looking at everything that's come in. And then, yes, I would… Advocate fairly strongly that we don't move anything from CFI to SFI until we're very far along with the implementations for the SFI EIPs, in this case, BALs and EPVS. And I think, you know, for fossil specifically, the question will be. do we think we understand it well enough? Do we think it adds, you know, like, a reasonable amount of complexity relative to the value we get of having it in this fork? And… you know, do we think it'll be easier to do, say, Fossil, or potentially, like, 3 small EIPs that are, like, you know, very well understood?

So, yeah, I don't think there's a silver bullet here, beyond just making sure that we Keep the focus on the things we've already committed to before committed. Committing to even more, and… So… Yeah, I… so I guess I would put a pin in moving things from CFI to SFI until EQBS and block access lists are, like. you know, at the very least, running on a multi-client DevNet that's, you know, showing us what's the… what are, like, the open issues. And then I think the move from PFI to CFI, like, yeah, we should have the teams review all the different EIPs, kind of like we did in the last work, and, you know, make a list of

what are the EIPs everyone feels strongly about, prioritize those, and when we have some breathing room in terms of implementation, we make a call of what from the CFI bucket we want to actually move up to SFI.

Justin Florentine: That's clear. Thanks, bud.

Tim Beiko: Yep, of course. I'm… Any other questions about this? Okay, related to this, Mark had a proposal, to somewhat more formally define what an EIP champion is and should do. He had a PR for this, but, yeah, Mark, do you want to give some context on this, and… Yeah, what you hope to get out of it?

Marc Garreau: Yeah, sure. Mostly what I'm doing is posing the question, like, would it be more helpful to clearly spell out the point of contact for each proposed EIP in a given fork? So… Within… The link you shared there is a minimal suggestion that we define the role as the primary point of contact. Within a given network upgrade, and then we state that an EIP should specify a champion in the PR to propose it for inclusion. So the… the motivation there is… is obviously the ship has sort of sailed on Fusaka, but there are… Looks like 23 proposed. For Glabsterdam now? And that represents a lot of communication channels when you consider all the parties involved, between authors, call facilitators, client teams, panda ops, testing teams, so on.

Not to mention, any other external parties, like L2s or app teams that might want to share some insights. So, yeah, open question there. If we require a, or a soft require, a champion be named for each of these given proposed EIPs, will that meaningfully reduce friction? By establishing those clear communication channels out of the gate. So there's some small logistics questions baked within, but I don't think any of them are… Much more than trivial. So I suppose the call to action is if you'd like to weigh in on that, to jump into the… The poll request there, and leave a comment.

Tim Beiko: Thanks. Yeah, I… I personally think this is good. I… yeah, like, I think it's true that we sometimes get people who are championing EIP who aren't necessarily the author, or, you know, EIPs have, like, 7 authors, and it's not clear who to ping. And some EIPs also get proposed, like, you know, multiple forks, over and over, like, 2537 is probably the best example we've had of this. so my, minor proposal would be that whoever opens the PFI PR should be… You know, considered the champion. And maybe if that changes, it's, like, on them to change it throughout the process, but that's also kind of an easy… like, think to hook on, and just say, like, okay, if you're… if you're proposing the CIP for the fork, you're also signing up to be, like, the main point of contact and whatnot, and…

And honestly, if no one is willing to do that for an EIP, then it's unlikely that the EIP will… will make it through the entire process anyway, so we're probably just wasting people's time, of having them review, so I kind of like the idea of, like, yeah, gaining the proposal on whoever proposes it, being willing to step up and be the champion for EIP. And… Yeah, and I know the PR was just open yesterday, there's a couple comments on it already. So, like. maybe we can leave it open for a few more days, and at the lay lists get it merged by next Awkward Evs. If… Yeah, maybe there's some outstanding questions, but… And… if we do move forward with something like this, then we can maybe say, kind of by default, everyone who's already proposed an EIP for Fusakai is a champion, and if people want to opt out, or, you know, they're unresponsive, we can deal with that, but…

Given we're, like. partially through the process already. Whatever we decide, we could kind of just retrofit to Fusaka, and then have it start cleanly for Amsterdam. Sorry, retrofit the Glamsterdam, and then have it start Q&B for H-star.

Marc Garreau: Yeah, I will volunteer. If this is, an attractive solution, then I'll volunteer the protocol support team to go and source the champion name for all of the existing PFI EIPs.

Tim Beiko: Amazing. Yeah, I guess anyone have concerns or objections that they want to raise? Otherwise, like, we can discuss the specifics of it in detail, but… Is the role of the chip?

Pooja Ranjan: I just have a point to make. I mean, like, I'm just trying to understand here, like, do we really need to mention the name of the champion? Because anytime we make any changes to an EIP, all the authors and champions are by default co-authors of the project. So, if we find, like, too much value in adding this piece of information in Meta EP, then only we should consider this, because I feel like MetaEP is very, very important, and we should not go too much granular there. That's my personal thought on that, but yeah, I'm more open if people think it, otherwise, and we should add the name of the champion in the proposal of MetaEP itself as well.

Tim Beiko: I… I don't have a sh… I guess, like, once the fork is final. I don't think we should have it in the Meta EIP. Because it's kind of weird, like, once the forecast ships, we care more about, like, the authors, in a way. But, I don't have a strong opinion. Like, I would actually just start by having it on, like, forecast or something before we put it in the meta-EIP, see if that's, See if that's, like, sufficient. We can also add it to the MetaE IP as, like, yeah, just, like, a semi-ephemeral bit.

Pooja Ranjan: Yeah, right. Yeah, that's my point as well, like, you know, this is, like, too granular information, and I don't see it's too much valuable in MetaHeep. Although the proposal, which are already included, we have the link, and that proposal includes the list of authors, so we are anyway going to get it there.

Tim Beiko: Yeah, I do think one notable thing is the champions aren't necessarily the authors, like, this was true, say, of, like, the BLS precompile, and I don't know, the last EIP I championed was 1559, and I wasn't an author either, and yeah, like, Mixo has another example in the chat, so, like, I think there is value in setting up, like, okay, who is, like. the champion for this EIP for this fork, and they don't necessarily have to be an author, and then similarly, the most, the most, like, I don't know, like, contributing author might not be the person you ping, And yeah, I guess to Daniel's comment, like, by semi-ephemeral, what I would say is, like, for the development cycle of a fork. So, like.

if you're the champion for, I don't know, EIPX during the Glamsterdam fork, it's expected that you're, like, listed as that, and you're the main point of contact at EIP until we ship the fork, but then once the fork is shipped. We don't necessarily record like, who was the champion beyond just the authors on the EIP.

Pooja Ranjan: I would rather advocate to add champions as co-authors, and in any way, EIP1 provides us that provision to be added, because champion would be the one who would be most active, and we need that most active person in order to merge any small changes that is recommended to that proposal. And if we don't have Champion added as an EIP author, like co-author. Then the proposal will be sitting on the repository for a very long time.

Tim Beiko: Okay, so we can… I'm not against adding the champion by default as an author, but I think it's also worth explicitly flagging the champion, because they, because an EIP can have, like, many authors, so it should be clear that there's an EIP with, like, 6 authors. Who's the person I paid to get, yeah, a test case added, or something like that. Yeah, so I, yeah, no issues with adding them as an author by default, but I think it's worth… making it explicit, like, who is the champion and how, and I think proposing the EIP for the fork is kind of the… The most formal hook we have into the process, in a way, where someone says.

I will push for this to happen in this fort.

Pooja Ranjan: Just to be clear that we are planning to keep it on forecast, or on an FMRL basis on Meta ETH.

Tim Beiko: I don't have a strong opinion. I'm fine. Either way, I don't know if anyone… Feel strongly.

Marc Garreau: It's an open question. Yeah, forecast is an easy way to socially enforce this, if we don't… in a minimally invasive way to the rest of what goes on in the protocol, so… maybe that's our starting point, and if we want to add… if it's useful to champion… to add champion names to the meta EIP, To anyone specifically, I would suggest that they Leave those comments in the poll request?

Tim Beiko: Yeah. I kind of like trying it on Forecast 2, just for Glamsterdam, seeing if we like it, or if there's changes to be made, and then, you know, based on how it goes, we can… quote, like, enshrine it in either, like, the meta-EIPs or the individual EIPs themselves, but I think, like, yeah, forecast is a nice way to… to test it, to iterate quickly, without having to mess with the EIP process as a whole, and then, yeah, in Glamsterdam, we can figure out the right you know, set of expectations, the right way to set this up, and then for H-star, we can potentially formalize it in either the meta-EIP or, Or, like, yeah, the EIP header field or something.

Okay. Anything else on this? Yeah, thanks, Mark, for pushing this proposal. I think this is going to be really helpful in coordinating, the different, yeah, different EIPs for the fork. That was the last thing, yeah. we had for Glamsterdam, and generally on the agenda? Anything else people want to chat about? And no one, yeah, no one asked to present any… PFI the IPs, but if people have some that they'd like to present, that they've already proposed, that we can definitely do that. And if… Yeah, if folks want to hop off and, you know, watch their presentations later, that's fine, but if we,

if we are doing these presentations, I just make it clear we're not going to make any decision about Clam Sudan or the scope today, and it's more about, yeah, sharing information and answering questions, but… Yeah, happy to… to do that. If there's nothing else, I'd wrap it up. Yeah, Adrian?

Hadrien Croubois: Yes, thank you. So, since we have time, I don't want to keep everybody… anybody here, but I'd like to present my Missouri IP I've proposed for inclusion in Amsterdam very quickly. It's something that I've proposed in Fusaka, but at a very late stage, and it could not make it for inclusion. For obvious reasons. This is EIP 7819, which is, which proposed to introduce a new set delegate insertion, or op code. The idea of this EIP is to propose a mechanism so that smart account factories are able to instantiate objects that are equivalent to what we have today in terms of proxies or clones. So those are currently designed around ERC 1167 or ERC 1967. and replace those objects with something that is more native to the protocol, which are the EIP7702 delegation. The 7702 delegation are something we are used to have now placed at the location of EOA, or of private keys, addresses.

The idea is to have the ability for factories to deploy these objects. The rationale for proposing that, there are a few. one of the first ones is to… to reduce the cost of using these kind of proxies. Grantedly, this kind of proxies rely on having code on-chain and storage for the gradability part. And even when they are not upgradable, you still have to copy a lot of things from call data to memory, and then perform a subsequent delegate call. This would avoid all of that complexity by moving it to the protocol using a primitive that already exists, and that's already implemented in execution clients. One of the benefits would also be that the object that we would create, that this factory would create.

would be way smaller. A 7702 delegation is just 23 bytes, when, like. Clones are close to 70, and proxies are in the multiple of hundreds. And those make up for a very large fraction of the contracts that are deployed in chain, so one of the benefits would be that those factories would deploy smaller objects, and that would Use less states on-chain for… for storing things. So… So that's one of the rationales. Another rationale is to have clearer upgradeability patterns and the ability to do things in a more, like, native way, using the delegation, instead of relying on storage. We've seen bugs in the past, or attacks. From clones and proxies that were using unconventional storage slots, which explorers were not able to observe and document for the users.

So… so those are… are the main idea. Everything should be documented on the… on the, on the EIP document. I'm really looking for feedback and curious on what the community feel about this proposal.

Tim Beiko: Thanks, Felix and Guillaume after.

Felix Lange: Yeah, sorry, I hope you can hear me alright. I just quickly want to ask, just to clarify, so this proposal is for adding a create-like mechanism that will create a delegation, right?

Hadrien Croubois: Yes, create and also update existing delegations.

Felix Lange: Okay, so, but then in that case, also, there has to be some kind of… authorization method built in. I'm sorry, I mean, I have skimmed the eep, this is just, like. I was just curious.

Hadrien Croubois: No problem. Yeah, so it's similar to Create2 in the sense that the address that is used for the new object is deterministic based on the address of the factory and assault. So, basically, the factory that… the contract that uses this OP code can create a delegation, and if they reuse the same salt, they could be… could replace it, which is the equivalent of an EOA Re-delegating, changing the address of the target of the delegation, so access control would have to be implemented in the factory contract.

Felix Lange: Alright, thank you very much.

Tim Beiko: Justin?

Justin Florentine: I just wanted to… I think I'm pretty clear on the design and, you know, what it's going to do. Could you elaborate maybe a little bit on the impact? I'm looking through the motivation section of the EIP. I understand what it's going to do. I'm unclear as to, like, how much of our population we expect would actually benefit from this, and, you know, how much… how much code reuse do we think we're going to yield? You know, without having to speculate on adoption. I know that's impossible. Thanks.

Hadrien Croubois: Yeah, so all I can say is that I think it's the guest team that came up with this number for contract usage. I think the… I would have to get the right number. I'm sure someone from the guest team can find them, or it's posted somewhere on my Twitter page, but the estimates were, like, about, I think, 80% of contracts on-chain are likely to be clones or proxies, or a similar objects. So, even if there is little adoption by factories, even if, like. 50% of the future factories adopt that, and then they have an incentive to adopt that because it makes it cheaper for them to both deploy these objects, and then use… for users to use them. Then we are looking at something that could be in, like, it could be a quarter of all future contract deployment on-chain that would be these objects.

And we would be saving Multiple bytes, sometimes hundreds of bytes per object.

Justin Florentine: Thanks, Logan.

Lightclient (Matt Garnett): There is a trade-off here? And that's It's going to be more expensive to interact with these contracts now, that you have to warm both the contract with delegate lives and the contract which is the target of the delegates.

Hadrien Croubois: That's already the case for all clones and proxies. You already have to warm up the clone and then warm up the implementation, and when the clones are upgradable, or when the proxies are upgradable, you also have to warm up a storage slot. That is the address of the implementation. So actually, it should be cheaper now. And I'm not even considering the cost that doing that in user space have of copying call data to memory, and then doing an additional call with that. And on the way back, getting return data, and copying that to memory, and then forwarding that again.

Lightclient (Matt Garnett): Right. Are you also proposing of an ability of changing the delegation? There's, like, a creative… okay, I see, I see. Yeah, I mean, I think it makes sense. The only comment I have is we should look into if it makes sense to do this with code hash instead of address. But… obviously, 7702 does it by address, so… I think that's the most straightforward answer.

Hadrien Croubois: And I don't have a strong opinion either way. The idea to reuse 7702 is also to Use objects and workflows that are already present in the execution code, so that it's easier to implement? But if core devs want to do it a better way, that is more work for them, that's fine by me.

Felix Lange: Yeah, it is kind of funny, because this is sort of, like, coming at 7702 from the other direction. So it's like, you know, with 7702, you can turn an EOA into a contract, and with this, you can turn a contract into a kind of EOA. Like, it's…

Danno Ferrin: So this was, gonna be the basis of my comment to talk to Justin. What are the use cases for this? And one would be for a smart, a smart wallet contract. And there's some that just, when they look at the delegate process, they say, I don't want to use it, because there's a chance this EOA key could override it. But if it's coming from the contract, and the contract controls, and they know how it's going to be changed, then there's a whole category of smart wallets that can be created that don't, that are never, impacted by any CDSA EOA account. Because, yeah, I've read lots of places where people say, I'd love to use that, but I don't want to have the chance that someone's public key is going to change the delegation.

Hadrien Croubois: Yeah, so the factory is in charge of the upgrade, so all the re-delegation logic is visible and clearly on-chain. In the case of smart wallets, you could imagine that the smart wallet could update itself, and the factory would recognize that only the smart wallet has the ability to self-upgrade. It would be up to the factory to decide how they want to implement that.

Tim Beiko: Thanks, Guillaume.

Guillaume Ballet: Yeah, I just wanted to add, so, it's not the guest team who has done this research, it's take less consensus, namely it's Wei Han, who's in that chat. So if you have more questions about the reason why, we think it's a good idea. you should talk to him, but to give you the TLDR, we have seen that, indeed, a lot of contracts are… that are deployed, like, a huge portion of them are just the same contract over and over again. We don't know exactly how many of those are proxies. So we're going to look into this, but, yeah, just, in the world of support for the CIP, it seems that it could, if our research confirms it, it looks like it could have a lot of impact on state growth.

Danno Ferrin: Beneficial impact?

Guillaume Ballet: Yes, absolutely.

Tim Beiko: Sweet. Anything else on the CIP? Okay, any other PFI DIP people wanted to discuss? Yeah, fragile.

Francisco Giordano: Yeah, sorry, this is not about PFI, EIP, but more like a temperature check. I've been looking into, Swap N and DupeN. which are EAP663. Originally, and the possibility of doing that… that EIP is built on EOF, so it's obviously not, viable. But I've been looking into the possibility of doing that without EOF, there's… Actually, quite a few… Alternatives and ways… to do it, I just wanted to see if anyone has any opinions about Trying to get those in. And these are the extended stack operations which go beyond Depth 16, and, you know, they would be useful to very easily solve the Solidity stack too deep error.

You know, there are alternative fixes for that error, but it is… True that, you know, having these opcodes would make things… a compiler so much easier. And the stack too deep is just… it's an extremely pervasive problem in the ecosystem. Smart contract developers, you know, deal with that all the time. And so, yeah, I just wanted to check on, like, does anyone have an opinion? Should I try to pursue this? And then, you know. We… you know, there's a discussion to be had about how to do the immediate. But it's… it's not an issue. There are quite a few ways to do them without breaking change.

Tim Beiko: Thanks. Does anyone have opinions on this? Okay, if not, maybe we can discuss on the Discord in the EDM channel or something? Anything else people wanted to bring up today? Okay, then we can wrap up early. Also, as a reminder, Ansgar will be taking over, for the rest of the year, starting for the next ACDE, so, I will see you all in the new year. And yeah, looking forward to seeing Fusaka go live. Thanks, Oliver.

Justin Florentine: Tim, we'll miss you, Tim!

Tim Beiko: Thanks. Yes.

Pooja Ranjan: Thank you, Tim.

Marius van der Wijden: Hey, guys.

Pooja Ranjan: Thanks, everyone.

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