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,
Transcript
Tim Beiko: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.
Tim Beiko: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…
Tim Beiko:High-level overview of how that's been going.
Fredrik:Yeah, I'm here.
Fredrik:Yeah, we have, had a few interesting reports. We've had a lot of…
Fredrik:Issues that are not actually issues as well, but,
Fredrik:Yeah, things are, definitely progressing, and
Fredrik: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…
Fredrik:To wrap your head around these, these upgrades, so,
Fredrik:Yeah, quite excited to see what's gonna come out of the competition.
Tim Beiko:Thanks.
Tim Beiko:And yeah, I know, there's been, like, already some bugs reported in some clients, some clients seem to be working on them,
Tim Beiko:But yes, at least so far, nothing catastrophic, seems to have, come up.
Fredrik:Nothing, nothing that should affect the timeline has come up on the main upgrade or anything should, has come up yet.
Tim Beiko:Nice.
Tim Beiko:I'm… Yeah, so I guess this…
Tim Beiko: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.
Tim Beiko: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,
Tim Beiko:activate one week after their, Fusaka activation.
Tim Beiko:So, yes, there's this…
Tim Beiko: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.
Tim Beiko:But yeah, just wanted to give people a chance to chime in on the schedule, and…
Tim Beiko:Raise any concerns before we… move ahead.
Tim Beiko:Okay, Lighthouse release will be ready Monday, and…
Tim Beiko: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…
Tim Beiko:Bit of context.
Tim Beiko:Or EPA for their releases.
Dustin:Sure. So… the release, per se, for Nimbus is…
Dustin:ready? We're having process issues on the… on the… Build side for… still… unclear reasons.
Dustin: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:That… that's the goal, yeah.
Tim Beiko:Good luck, yeah. Sounds good.
Dustin: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.
Tim Beiko:Yeah, that's a good sign.
Tim Beiko:Anyone from Prism or guests wanna… Give some coffects?
Tim Beiko:Okay, if not, then, oh, yeah, Prism is working on it, also hoping for a release in the next day or so.
Tim Beiko:Awesome.
Tim Beiko:And then, yeah, Geth, if you want to help Geth also, working on it already, he's trying to get it out today.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:But yeah, congrats, everyone. It's been a…
Tim Beiko:long, long sprint, to get the Fusaka releases, so excited to see this,
Tim Beiko:Yeah, finally about to ship on testnets, yeah, Trudy, great work, everyone.
Tim Beiko: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.
Tim Beiko:I'm…
Tim Beiko: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
Tim Beiko:raising the default gas limit on mainnet to 60 million, so we had an informational EIP for this, and I believe,
Tim Beiko:the EL clients and CL clients that are, that are being released will have a default
Tim Beiko:value for $60 million as part of their mainnet Fusaka releases. So the testnet's already running at $60 million, but then
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:Pop.
Tim Beiko:Yeah, any comments?
Tim Beiko:Thoughts on this?
Tim Beiko:Okay, that's the last minor thing, so, for everyone who's just an EIP author for Dysphoric.
Tim Beiko: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.
Tim Beiko: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,
Tim Beiko:once mainnet is, is, once Fusaka's gone live on Mainnet, we'll move all these to 5 off.
Tim Beiko:But yeah, anything else on Fusaka? We are in the finishing stages.
Tim Beiko:Okay, off.
Tim Beiko:Nice. Yeah, again, congrats, this is huge to finally see this start to ship.
Tim Beiko:Moving on, then?
Tim Beiko: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.
Toni Wahrstätter: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
Toni Wahrstätter:Yeah, how clients should, should handle them.
Toni Wahrstätter:So, not that many news, I think. We are still, on the timeline to,
Toni Wahrstätter:having the first FNET by October.
Tim Beiko:I'll sub…
Tim Beiko:Any other thoughts or updates on BALs?
Tim Beiko:And, yeah, I… Taryn said in the chat there's an EPBS breakout, tomorrow. Taryn said, do you think people should
Tim Beiko:Read up on, or try to look into before that?
terence:We had a SPAC release, thanks to Justin, yesterday for, I believe this is Beta 0, so I think, like, EI37732 with this release,
terence: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.
terence: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.
terence: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:For, for EPBS, EIP7732, there's no EL, changes at all, yeah.
Barnabas:My question was for Atlanta.
Tim Beiko:Both.
Tim Beiko:Okay, got it. Yeah.
Tim Beiko: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…
Tim Beiko:ELs are, working on it, another one too, so… Nice.
Tim Beiko:And then, back to EPBS,
Tim Beiko: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?
Tim Beiko:I assume we should have to make sure that they're based on Fusaka, but does anyone… Disagree with that?
Tim Beiko: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.
Tim Beiko:Anything else on that?
Tim Beiko:either EPVS or block access lists people wanted to bring up.
Tim Beiko: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
Tim Beiko:at Amsterdam generally. We said the deadline should be when we put out the mainnet releases for Fusaka.
Tim Beiko:Which we don't have a date for yet, but I expect would happen in the next month or so.
Tim Beiko: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,
Tim Beiko:yeah, propose your EIP. Justin?
Justin Florentine (Besu):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,
Justin Florentine (Besu):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,
Justin Florentine (Besu):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.
Justin Florentine (Besu):So, thanks for your time, I'll take my answer off the air.
Tim Beiko:Thanks. I guess my view there is…
Tim Beiko:Yeah, look, we have to gate when the new proposals come in, so it limits
Tim Beiko:what we have to review. So first step is actually looking at everything that's come in.
Tim Beiko:And then, yes, I would… Advocate fairly strongly that we don't
Tim Beiko: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.
Tim Beiko:And I think, you know, for fossil specifically, the question will be.
Tim Beiko: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…
Tim Beiko: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?
Tim Beiko:So, yeah, I don't think there's a silver bullet here, beyond just making sure that we
Tim Beiko:Keep the focus on the things we've already committed to before committed.
Tim Beiko:Committing to even more, and…
Tim Beiko:So…
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko: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 (Besu):That's clear. Thanks, bud.
Tim Beiko:Yep, of course.
Tim Beiko:I'm… Any other questions about this?
Tim Beiko:Okay, related to this, Mark had a proposal, to somewhat more formally define
Tim Beiko: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…
Tim Beiko:Yeah, what you hope to get out of it?
wolovim: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…
wolovim:Within…
wolovim:The link you shared there is a minimal suggestion that we define the role as the primary point of contact.
wolovim: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…
wolovim:Looks like 23 proposed.
wolovim:For Glabsterdam now?
wolovim: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.
wolovim:Not to mention, any other external parties, like L2s or app teams that might want to share some insights.
wolovim:So, yeah, open question there.
wolovim:If we require a, or a soft require, a champion be named for each of these given proposed EIPs, will that meaningfully reduce friction?
wolovim:By establishing those clear communication channels out of the gate.
wolovim:So there's some small logistics questions baked within, but I don't think any of them are…
wolovim:Much more than trivial.
wolovim:So I suppose the call to action is if you'd like to weigh in on that, to jump into the…
wolovim:The poll request there, and leave a comment.
Tim Beiko:Thanks. Yeah, I… I personally think this is good. I…
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:so my, minor proposal would be that whoever opens the PFI PR should be…
Tim Beiko:You know, considered the champion.
Tim Beiko:And maybe if that changes, it's, like, on them to change it throughout the process, but that's also kind of an easy…
Tim Beiko: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…
Tim Beiko: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,
Tim Beiko: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.
Tim Beiko:And… Yeah, and I know the PR was just open yesterday, there's a couple comments on it already.
Tim Beiko:So, like.
Tim Beiko:maybe we can leave it open for a few more days, and at the lay lists get it merged by next Awkward Evs. If…
Tim Beiko:Yeah, maybe there's some outstanding questions, but… And…
Tim Beiko: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…
Tim Beiko:Given we're, like.
Tim Beiko:partially through the process already. Whatever we decide, we could kind of just retrofit to Fusaka, and then have it start cleanly for Amsterdam.
Tim Beiko:Sorry, retrofit the Glamsterdam, and then have it start Q&B for H-star.
wolovim:Yeah, I will volunteer. If this is, an attractive
wolovim: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.
Tim Beiko: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…
Tim Beiko: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
Pooja Ranjan: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.
Pooja Ranjan:That's my personal thought on that, but yeah,
Pooja Ranjan: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.
Tim Beiko:I don't think we should have it in the Meta EIP.
Tim Beiko:Because it's kind of weird, like, once the forecast ships, we care more about, like, the authors, in a way. But,
Tim Beiko: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,
Tim Beiko:See if that's, like, sufficient.
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:the champion for this EIP for this fork, and they don't necessarily have to be an author, and then similarly, the most,
Tim Beiko:the most, like, I don't know, like, contributing author might not be the person you ping,
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko: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.
Pooja Ranjan:And if we don't have Champion added as an EIP author, like co-author.
Pooja Ranjan: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
Tim Beiko: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.
Tim Beiko:Yeah, so I, yeah, no issues with adding them as an author by default, but I think it's worth…
Tim Beiko:making it explicit, like, who is the champion and how, and I think proposing the EIP for the fork is kind of the…
Tim Beiko:The most formal hook we have into the process, in a way, where someone says.
Tim Beiko: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.
Tim Beiko:Either way, I don't know if anyone… Feel strongly.
wolovim:It's an open question.
wolovim: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…
wolovim: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,
wolovim:To anyone specifically, I would suggest that they
wolovim: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…
Tim Beiko: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
Tim Beiko: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,
Tim Beiko:Or, like, yeah, the EIP header field or something.
Tim Beiko:Okay.
Tim Beiko:Anything else on this?
Tim Beiko: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.
Tim Beiko:That was the last thing, yeah.
Tim Beiko:we had for Glamsterdam, and generally on the agenda? Anything else people want to chat about?
Tim Beiko:And no one, yeah, no one asked to present any…
Tim Beiko: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…
Tim Beiko:Yeah, if folks want to hop off and, you know, watch their presentations later, that's fine, but if we,
Tim Beiko: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…
Tim Beiko:Yeah, happy to… to do that. If there's nothing else, I'd wrap it up.
Tim Beiko:Yeah, Adrian?
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):For obvious reasons. This is EIP 7819, which is, which proposed to introduce a new set delegate insertion, or op code.
Hadrien Croubois (OpenZeppelin):The idea of this EIP is to propose a mechanism so that smart account factories are able
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):The idea is to have the ability for factories to deploy these objects.
Hadrien Croubois (OpenZeppelin):The rationale for proposing that, there are a few.
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):would be way smaller. A 7702 delegation is just 23 bytes, when, like.
Hadrien Croubois (OpenZeppelin):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
Hadrien Croubois (OpenZeppelin):Use less states on-chain for… for storing things.
Hadrien Croubois (OpenZeppelin):So…
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):From clones and proxies that were using unconventional storage slots, which explorers were not able to observe and document for the users.
Hadrien Croubois (OpenZeppelin):So… so those are… are the main idea. Everything should be documented on the… on the, on the EIP document.
Hadrien Croubois (OpenZeppelin):I'm really looking for feedback and curious on what the community feel about this proposal.
Tim Beiko:Thanks, Felix and Guillaume after.
Felix (Geth):Yeah, sorry, I hope you can hear me alright.
Felix (Geth):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 (OpenZeppelin):Yes, create and also update existing delegations.
Felix (Geth):Okay, so, but then in that case, also, there has to be some kind of…
Felix (Geth):authorization method built in. I'm sorry, I mean, I have skimmed the eep, this is just, like.
Felix (Geth):I was just curious.
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):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
Hadrien Croubois (OpenZeppelin):Re-delegating, changing the address of the target of the delegation, so access control would have to be implemented in the factory contract.
Felix (Geth):Alright, thank you very much.
Tim Beiko:Justin?
Justin Florentine (Besu):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.
Justin Florentine (Besu):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?
Justin Florentine (Besu):You know, without having to speculate on adoption. I know that's impossible.
Justin Florentine (Besu):Thanks.
Hadrien Croubois (OpenZeppelin):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
Hadrien Croubois (OpenZeppelin):the estimates were, like, about, I think, 80% of contracts on-chain are likely to be clones or proxies, or a similar objects.
Hadrien Croubois (OpenZeppelin):So, even if there is little adoption by factories, even if, like.
Hadrien Croubois (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):And we would be saving Multiple bytes, sometimes hundreds of bytes per object.
Justin Florentine (Besu):Thanks, Logan.
lightclient:There is a trade-off here?
lightclient:And that's
lightclient: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 (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):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:Right. Are you also proposing of an ability of changing the delegation?
lightclient:There's, like, a creative… okay, I see, I see.
lightclient: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.
lightclient:But… obviously, 7702 does it by address, so… I think that's the most straightforward answer.
Hadrien Croubois (OpenZeppelin):And I don't have a strong opinion either way. The idea to reuse 7702 is also to
Hadrien Croubois (OpenZeppelin):Use objects and workflows that are already present in the execution code, so that it's easier to implement?
Hadrien Croubois (OpenZeppelin):But if core devs want to do it a better way, that is more work for them, that's fine by me.
Felix (Geth):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?
Danno Ferrin:And one would be for a smart, a smart wallet contract.
Danno Ferrin: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.
Danno Ferrin: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.
Danno Ferrin: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 (OpenZeppelin):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.
Hadrien Croubois (OpenZeppelin):It would be up to the factory to decide how they want to implement that.
Tim Beiko:Thanks, Guillaume.
Guillaume: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.
Guillaume: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.
Guillaume: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:Yes, absolutely.
Tim Beiko:Sweet. Anything else on the CIP?
Tim Beiko:Okay, any other PFI DIP people wanted to discuss?
Tim Beiko:Yeah, fragile.
frangio:Yeah, sorry, this is not about PFI, EIP, but more like a temperature check.
frangio:I've been looking into, Swap N and DupeN.
frangio:which are EAP663.
frangio:Originally, and the possibility of doing that… that EIP is built on EOF, so it's obviously not, viable.
frangio:But I've been looking into the possibility of doing that without EOF, there's… Actually, quite a few…
frangio:Alternatives and ways… to do it,
frangio:I just wanted to see if anyone has any opinions about Trying to get those in.
frangio:And these are the extended stack operations which go beyond
frangio:Depth 16, and, you know, they would be useful to very easily solve the Solidity stack too deep error.
frangio:You know, there are alternative fixes for that error, but it is…
frangio:True that, you know, having these opcodes would make things…
frangio:a compiler so much easier.
frangio: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.
frangio: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.
frangio:We… you know, there's a discussion to be had about how to do the immediate.
frangio:But it's… it's not an issue.
frangio:There are quite a few ways to do them without breaking change.
Tim Beiko:Thanks. Does anyone have opinions on this?
Tim Beiko:Okay, if not, maybe we can discuss on the Discord in the EDM channel or something?
Tim Beiko:Anything else people wanted to bring up today?
Tim Beiko: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.
Tim Beiko:And yeah, looking forward to seeing Fusaka go live.
Tim Beiko:Thanks, Oliver.
Justin Florentine (Besu):Tim, we'll miss you, Tim!
Tim Beiko:Thanks.
Tim Beiko:Yes.
Pooja Ranjan:Thank you, Tim.
Marius van der Wijden:Hey, guys.
Pooja Ranjan:Thanks, everyone.
Chat Logs
00:05:22
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7607
00:06:26
kingy_sigp:Lighthouse release will be ready Monday
00:06:33
Barnabas:we are still waiting on releases from:
geth
lighthouse
nimbus
prysm
00:07:24
Barnabas:we are targeting holesky sf tomorrow.
00:08:00
James He:We’re working on it. Hoping next day or so.
00:08:12
Marius van der Wijden:Also working on a release
00:08:13
lightclient:we were waiting for confirmation today
00:08:15
kingy_sigp:Replying to "we are targeting hol..."
we'll have a branch merged down for you tomorrow, just release process to do on Monday
00:08:25
Łukasz Rozmej:Nethermind released today
00:11:06
Tim Beiko:https://github.com/ethereum/EIPs/pull/10423
00:12:17
terence:there's an eip7732 breakout on friday
00:13:25
Barnabas:Any EL impl progression?
00:13:47
Justin Traglia:https://github.com/ethereum/consensus-specs/releases/tag/v1.6.0-beta.0
00:14:47
Barnabas:Replying to "https://github.com/e..."
do we target this for bal-devnet-0 and epbs-devnet-0?
00:14:48
Justin Florentine (Besu):Besu has
00:15:03
Marc:yep Nethermind have started
00:15:10
Barnabas:Please use bal-devnet-0 branches once you got something.
00:15:43
Justin Traglia:Replying to "https://github.com/e..."
Not sure 🤷
00:17:02
Justin Traglia:Here's the agenda for this week’s epbs breakout call. Please comment if there’s anything you’d like to bring up.
https://github.com/ethereum/pm/issues/1735
00:19:21
Justin Florentine (Besu):so put a pin in CFIs till we know how many PFIs are gonna get promoted
00:20:46
Tim Beiko:https://github.com/ethereum/EIPs/pull/10391
00:25:25
Hadrien Croubois (OpenZeppelin):Is the role of a champion described anywhere. In addition to being available, is there anything they must proactively do ?
00:25:58
Mario Havel:Replying to "Is the role of a c..."
It's better defined in the PR adding the requirement https://github.com/ethereum/EIPs/pull/10391/files
00:26:23
Justin Florentine (Besu):maybe EF can setup an email anonymizer for anons?
00:26:45
nixo:agree that “champion” should be semi-ephemeral
00:27:27
nixo:e.g. 7691 was championed by Francis Li
00:27:29
Luis Pinto | Besu:Replying to "maybe EF can setup a..."
Authors are already listed anyway. Usually champ is one of them
00:27:44
Danno Ferrin:When it’s semi-ephemeral it becomes difficult to figure out who to poke to get things moving, like BLS when we need new test cases
00:28:43
Danno Ferrin:+1, herding the cats is as important as writing the spec
00:30:07
nixo:my vote is just forkcast for now
00:30:14
Luis Pinto | Besu:Why not having a field in the EIP itself?
00:30:27
Tim Beiko:Replying to "Why not having a fie..."
Much harder change :-D
00:31:59
Justin Florentine (Besu):PFI presos?
00:33:18
Pooja Ranjan:Replying to "Is the role of a cha..."
From EIP-1
“In short, your role as the champion is to write the EIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea.”
00:34:08
frangio:Hadrien's EIP: https://eips.ethereum.org/EIPS/eip-7819
00:38:41
Guillaume:https://ethereum-magicians.org/t/not-all-state-is-equal/25508 what Hadrien is referring to
00:39:09
frangio:'clone' is a misnomer
00:39:44
Wei Han Ng:Replying to "https://ethereum-mag..."
based on our analysis 89.1% of the contracts are deployed from factories
00:40:37
Justin Florentine (Besu):does everyone index by codehash?
00:43:25
Justin Florentine (Besu):seems appropriately scoped as a "ride along" eip?
00:46:25
Phil Ngo:Thanks Tim! Enjoy your time off!
00:46:26
Toni Wahrstätter:Thanks tim! 🫶
00:46:31
Barnabas:Good luck tim
00:46:31
Manu:Thanks Tim!
00:46:33
Christine Kim:thank you tim!
00:46:35
Louis:Thanks Tim!
00:46:40
panaw:Thanks Tim
Summary
14 highlights
· 2 decisions · 3 action itemsExperimental
Summary
14 highlights · 2 decisions · 3 action itemsExperimentalfork status and schedule
client updates
testing progress
organizational
- All Fusaka EIPs moving to last call as testnets activate00:11:06
- Glamsterdam PFI deadline: when mainnet Fusaka releases ship (~1 month)00:17:02
- No CFI→SFI promotions until BAL/EPBS running on multi-client devnet00:20:46
- EIP champion role proposal: primary contact per fork, tested on forkcast00:22:41
- Tim OOO rest of year; Ansgar hosting next ACDE00:45:57