All Core Devs - Execution #239

Transcript

Nixo: Good morning, good morning. We'll wait till the, 2 or 3 minute mark to get going.

Okay, I think we can go ahead and get started. Welcome to All Core Devs… er, sorry, David, are we… are we ready to go?

David (dionysuz): Yes, we are.

Nixo: Okay, great. Welcome to All Core Devs, execution number 239. Today's June 18th. We've got a pretty light agenda today. Let's start out with Glamsterdam. We'll do some DevNet updates. Barnabas, are you… can you give an update on DevNet?

Barnabas Busa: Sure, so we have Glamsterdam on DevNet 5 currently happening. And we have a few clients that are struggling to keep up. especially Prysm, previously had some issues. They have been looking into those and ironing it out. We currently are at 95% participation. And, we have some Nimbus and Prism nodes still offline. I think most of the client teams now are already looking at devnet-6 specs. Which will be the upcoming DevNet, hopefully sometime next week. We are targeting, launching it in the middle of next week. currently are targeting Alpha 11 specs, which should be coming out, hopefully, by end of Monday, and we're gonna have the EL test also out by Monday, ideally.

Nixo: Great. Can you remind me, does devnet-6 have all… all Glamsterdam's EIPs in it?

Barnabas Busa: It has, most of it. So on the ER side, we will have all of them. And on the CL side, we're still missing the stable container, the SSZ, VIP.

Nixo: Okay. Great. Thank you very much. So just a, I guess, just an FYI from, ACDE, Acdt this week discussed adding, 82… EIP8282, to ACDE, or to Glamsterdam. Does anybody want to talk about that? As far as I understand, there's pretty unanimous consent on adding it, as CFI. It… Resolves a case of validators and builders, entering the same queue and, potentially Being able to, DDoS that queue, is that correct? Does anybody have any updates or want to say anything about it?

Barnabas Busa: Yeah, I think that's, that's the bulk of it, and We are, we're looking at having two implementations of this already on the CL side, and we currently are waiting for a single EL to have an implementation for it. as I said, the tests are coming a bit later, tests are a bit slower this time around, but But yeah, we should be able to start testing as soon as we have an EL ready as well.

Nixo: Great, great. Assuming that there is no pushback on this call from… for adding that, I will get that merged into 8081 after this call. And while we're on the Barnabas train, Barnabas, do you want to talk about 8189?

Barnabas Busa: Sorry, which one was that?

Nixo: The network, the one that you were talking about adding to.

Barnabas Busa: Oh, the Snap 2. Yeah, yeah. So that is an optional, networking EIP, that would be good if we could mention it in the Glamsterdam and Matai EIP. This is, mainly for EL devs, this is SNAP2. Which enables, bulbous, state healing. And if there's any opposition, to merging the thing, I think, None of the clients have implemented it yet, but, work should be in progress.

Nixo: Okay, great. Does… do any, client teams have… Keth has it? Do any of the client teams have any opposition to adding Snap2 to, the networking section? E3X has it, great. Oh, that's 8282. Okay, Let's move on to, tony's, agenda item, EIP7928, the State Accessing, State Access Restructuring. Tony.

Toni Wahrstätter: Yeah, just one small comment regarding Snap 2. I think we should put it into one of the, hard fork Meta EIPs, it doesn't matter if it's Glamsterdam or Hegota. But we should put it somewhere, because it's not necessarily to ship it with a fork, but we should probably include it in one of the Meta EIPs, so either Glamsterdam or Hegota. I think GEF is quite far with Snap2, same for Besu. If Rex said they're quite far, I have to double-check with Nethermind, but I know that They are also on it, Yeah, so I… I would say we would… just added to the Meta EIP, but no strong opinion on that. So, yeah. Right. Regarding the point I put on the agenda.

So this was a point raised by, originally by Ignacio and then by Dragon, and the point was about, moving… End up putting an address into the PAL that is eventually not really accessed. This is not really PAL-specific, but we can Change it with bars, because we touch all of that code anyway. And based on what Dragon was saying in the Discord, this would, potentially allow clients to do additional optimizations. We already discussed that a few weeks ago, and by the time we said. If we don't find consensus on it, we would just keep it as is, which means we don't change anything, and specs and ERP stay as they are. And yeah, I hope we can take a decision on that.

Dragan Rakita: Yeah, that part was changed a few times. I think current spec is not reflecting what the clients have. In general, the… my proposal is basically most optimal here. In general, it does… when you do call, first do check for the call stack limit and the caller… if the caller has enough balance to transfer. And then do loading of the target. In that sense, the… All the loading is delayed, and potentially not get included in the bolt that basically we want. So yeah, I think that's, like, a good proposal, so… That, that's comment.

Nixo: Great. Tony, what are the next steps for this?

Toni Wahrstätter: So I'm curious what other clients think about this, because we cannot… If clients are not looking into it, so we would have to take a decision, I guess, to delay that further.

Nixo: Can you repeat that one more time? You were breaking up pretty bad during that.

Toni Wahrstätter: Yeah, sorry. I think we should take a decision on that today. I don't, sorry, let me try something.

Barnabas Busa: That's very bad.

Nixo: Yeah, it's pretty… it's pretty bad.

Dragan Rakita: Yeah, from a few seconds, we can hear you clearly, then it's like, it cut off. What I understood, what you wanted to say, is we should make a decision today, and it's more like what other clients think about this.

Toni Wahrstätter: Exactly, I hope it's better now. So then…

Trent Van Epps: It's not better, Tony.

Nixo: Tony, it's pretty busy.

Toni Wahrstätter: What's it?

Nixo: Pretty bad on this one.

Toni Wahrstätter: Over the…

Nixo: Yeah.

Dragan Rakita: Maybe, maybe we can jump and just ask all the clients what they think about this. This should be, like, smaller change, and… yeah.

Nixo: Have the other clients had a chance to look at this? We'll start with… is anybody from Geth here?

Felix Lange: Oh, yeah.

Jared Wasinger: Yeah, I have not… I have not personally looked into this edge case, but I can. I guess I'll just say I'm in favor of whatever reduces the, Added protocol complexity, but, yeah, I don't have an opinion on this right now.

Dragan Rakita: Generally, it should be small change, but yeah, it depends on implementation.

Nixo: Besu, Erigon? Or another mind?

Karim Taam: On Besu, we tried, for me, it was not a small modification in Besu, it's adding, Some duplication, or more complexity, but, Yeah, it's, it's only my opinion, so… I don't have a strong opinion against it. If all of the clients want to have it, why not? But for Bezo, yeah, it will not be a small modification.

Ben Adams: It's in a fairly niche failure… failure path, so… I mean, what optimizations Do you gain in the common case? From the point of view, we have… we have, like, working code, and it's… Possible, that's… Is it… is it worth changing at this stage?

Dragan Rakita: Yeah, basically, Current test doesn't reflect what's current in the spec. So we should change something. But my proposal is, like, the third thing. Where I moved the checks even, like, earlier. It helps to not load one account when that kind of checks basically fail. So… Yeah. to be honest, I would prefer the currently what's Implemented clients, or my proposal. This what's currently spec'd in the… what's currently in the spec'd is basically… It's… it, breaks the bond between warming of the account and what account are inside the… Inside the ball, so I would like to skip that, to be honest. So yeah, it's small optimization in the end, but it's still there, so yeah.

Nixo: Or anybody from Erigon?

Andrew Ashikhmin: I didn't have a chance to look into it, sorry.

Nixo: Okay. It doesn't sound like we are quite ready to, Commit to it, just because it doesn't sound like, there's… enough familiarity? Is it possible to… to… for all the clients to look at it and, come back to ACDE, possibly? Yeah, decide on ACDE, the latest.

Ben Adams: Yeah, I'd like to see a Dragon's version.

Dragan Rakita: I can write it after this call, but in the end, I think we should make a decision after this call, probably today, if we can ask doing async.

Nixo: Spencer?

Spencer Taylor-Brown: Yeah, kind of forward what Dragan said, if we can get a decision on it today, it means we can either add it to Glamsterdam DevNet 6 or not. Because I feel like if we wait until Monday. We potentially end up pushing the DevNet forward by a couple days. Maybe that's okay as well, but just wanted to relay Dragan's point.

Nixo: Gotcha. What is the, what's the timing on deadline to get it into devnet-6? Is that by, like, end of day today, or by tomorrow?

Spencer Taylor-Brown: So we want to have, our tests out by next Monday. And then, I guess, as soon as clients are passing the tests. M… Next week.

Nixo: Okay, then in the interest of moving this forward, can we have the, clients who are not familiar enough with it, take a look at it async, today and tomorrow, and we can soft commit to it now, unless there is opposition from those clients, after having looked through it. Does that sound like a good compromise? Okay. Looking for opposition, going once. Going twice. Okay, so we're gonna, soft commit to that. Dragon, if you can, still put out a write-up of your alternative, and then Erigon, and… I think it was Nethermind, look into it.

Dragan Rakita: I'll write a summary of all three of those, so yeah, you can… Yeah, summary is better, I think.

Nixo: Okay, great. And then, that can go in the… DevNet 6 specs. Okay, do we want to move on to the repricings update from Maria? Maria, are you here? Yeah.

Maria Silva: Hello, hello. Can you… can you hear me alright?

Nixo: Yep, very great.

Maria Silva: Yeah? Okay, so two main updates. So the first one is on, 7904, so the compute repricing. This was already announced in ACDE, on Monday, but it was within the breakout session, context, so to make sure that this is clear for everyone, we already transformed that EIP into an informational EIP, because at the moment, all clients are performing above The 100 million gas per second anchor, so that means that we don't need to do any compute repricings on Glamsterdam. So, at the… at this moment, that EIP is still in Glamsterdam at the EIP, but it's an information EIP, so it just documents the process, what we were trying to do, and then the key conclusion that we don't need to do any repricings.

So I think just, to say that, yeah, we won't need to… included in any DevNet or anything like that. I think process-wise, it still makes sense to have it as part of the Meta EIP, just for documentation reasons, but yeah, there's no action on our side. The second update is… so on ACDE, we were discussing some additional, changes to AD37, so the state growth EIP, they… there were two, open questions that, I opened a couple of, threads on Discord, so that we could discuss them. So the idea was. I shared the design or a PR with the changes to the EIP for those two changes, and I asked people to raise any concerns. There were a few small comments, but all in all, I don't think any concern was raised. So here on this call, I just wanted to

let everyone know that we'll go with those two changes. So the first one is, The first one is around the… where the, state gas, refunds or refills go to. So before, they were always going to the reservoir, and now they are going to the place where they were taken off, so it means that, we first, give back to gas left, if there was any spill to gas left, and then, we give back to the reservoir, when there's no more, spill, to… to account for. So that, is change number one. The change number two is a clarification on when. the state gas charging is done for create, and essentially now we are just charging it unconditionally, and then at the end of the execution for Create, if the account was already there.

We just, refill, the state gas. So those are the two changes. The EIP, so there's a PR to the EIP with the changes. Spencer also shared the changes to the specs. So here is, like, the only, thing is, like, doesn't seem to be any issue raised so far. I'll open the floor for… someone to complain, and if not, we'll just merge it, today, and that will be the specs for, DevNet 6. So yeah, do we have any last-minute concerns or issues? Okay, perfect. Then in that case, we'll do that, so we will merge… I'll merge today the updates to the EIP. Then we also have two more updates for the missing, or the last two.

repricing EIPs, which is the State Access EIP, 8038, and ETH Transfers EIP 2780, so there. I also did updates to the EIPs and shared on Discord, asked for reviews, there's been some comments, and but they have mostly been addressed so far. The Steel team is also already working on the implementations on specs and tests for those two new versions, so I guess, also, if there are no more issues, we'll just merge these changes, and then that will be also the spec for Glamsterdam DevNet 6. So, are there any concerns on those two? new, on those two EIPs, or is it okay to merge them? Okay. So, no concerns, we can just merge them. And yeah, so I guess, like, is there anything else on repricings that anyone wants to raise, or can we move to the next point?

Okay, Nick, so I don't think there's any more concerns there, so yeah, thank you.

Nixo: Thank you, Maria. That's all we have on the agenda for Glamsterdam. Does anybody have any other Glamsterdam items?

Barnabas Busa: Yeah, I would like to highlight, that we… We have a temporary, PR, well, we just merged it in with the two new system contracts for 8282. And, if you're an ELDev, please use these, For now. programs for STEM diagnostics testing. I put, the PR in the comment section.

Nixo: Great. Anything else on Glamst Jam? Cool. Then we will move on to Hegota. We have two… Eips being proposed for inclusion. We'll start off with, Schultz 8304 Trustless Login Transaction Index.

Zsolt Felföldi: Okay, yo, let me… Share my screen. Right, no? Okay, so, So this EIP is, let's just say the spiritual successor… successor of a 7745, but it's, different designs. So, 7745 was proposed for Glamsterdam, and, it was concluded that, yeah, so it was, it was, it was very complex, and also… like… Hard to implement, and… and… and, And so, overall, I realized that I need a different approach, but this is the same part of the same Trustless Log Index project, and now this current EIP, it's… It's a much simpler design, and it can even achieve better performance, faster proof generation, smaller proofs, but very quickly, so about the purpose of this whole thing is, yeah, as the name suggests, it indexes log events.

here in the EIP motivation, I… brought quite a few points on why I really want this, so one of them is the obvious, to finally be able to provide a trustless API to users. That's also an ongoing effort. mainly from the GATT team at the moment, and, and, Being able to prove the results of log queries, and also a few other queries, so this index also indexes transaction hashes and log hashes, so… so it can also give an inclusion or exclusion proof for a transaction index, for example, which is also impossible right now. I mean, in a trustless way. And, yeah, so, so one of the reasons is to be able to do a better API. Also, it could be a…

Big step forward for, cross-chain communication, because… If it's cheaply provable on-chain, what happened in another chain in the recent block since the last update, that's… That's, I believe, really useful, and, well, the rest is a bit of speculative right now, but, I believe over time, as we start using recursive ZK proofs for, for, for, like, post-quantum signatures and, and all this. So, so, it looks, like, looks to me at least, like, the… In the future, we are going to have more and bigger, proof and witness data, in the transactions, and, and the way… way forward for scaling… one way forward for scaling is to, separate out the pre-check parts of transactions, which the frame transactions, the IP also supports now, so… so, in this,

In this, future scenario, these, these, proofs generated by this, log index, can also be much cheaper, and then logs can find even more uses for, for, for, like, making off-chain computations cheaper for, like. making things more parallelizable. So this… this… so log is basic. Logs can also be… in general, another form of storage, contract storage, that's much easier to expire. So, yeah, I don't want to spend too much time on this, so let me just quickly show what this EIP does, and why I believe it's it's the right way to go, so… So, the way it works is that, it generates, index tables. The index tables are really simple data structures, so the index tables contain

all the searchable entries in a block, which include the block hash, all the transaction hashes, and the log addresses and topics, and deposition information. And what happens with these is… so in an index table, these are sorted. So here, let me just show an example. So here, in this table, this is a chronological order of events. And, and, in the next table, this is, this is, this is the, the, content-based sorting of events, so… so, they are sorted by, by, entry type and content first, and then by position. So, actually, actually, they have a binary encoding, all these index entries have a binary encoding that, so that, these entries are basically ordered lexicographically based on the binary encoding, which is also used for hashing, so this is a convenient thing.

And and the way it becomes a table is basically, it's an… all the hashes of these entries all go into an SSD list, and the root hash of the SSD list is the index table root, and I have a nice little… Drawing, which I made for Denver to… Yeah, but now I'm going to reuse it. So this is, so this is how… an index table, looks. This is… this is a tree hash. There's… there's the index table root, and, the next… here, here, here's an example of how this can be used. So, for example, This is… this is how an exclusion proof works. If we are looking for a transaction hash that doesn't exist, then we look up the two entries between which it would be placed, if it would exist, and we…

do a Merkle proof of these two entries, and this will prove that the search entry doesn't exist. And for more complex cases, like when we do a lock pattern search, yeah, I don't want to go into all the details, but now, yeah, this… this… this looks for a USDT transfer from… from an address called Bob, and yeah, this… these last four red entries here in this list. These are the red and the proven entries, so the two entries of Bob as topic one, and the two adjacent entries that prove that there are no more, and a few more entries proving Yeah, the other, providing an exclusion proof for the non-valid results. So yeah, this is… this is basically how,

How… how these tables can be used, and Okay, so, so what the protocol, needs to do about this is, So, in this, in this EIP, I'm proposing a kind of a hybrid solution. So the problem with generating these big indexes, and that was also a problem of 7745, that I tried to do all the… the big indexing, like, generating the final index in the protocol, and this EIP doesn't do that, so… so the way the tables are generated is, they're… they are generated for every single block, and, actually. they are stored in a system contract, so this AIP doesn't even touch the block header, it just stores all these table roots in a system contract.

And it generates a table for every block, and since these are… these lists… these tables are just sorted lists of items, they can be merged together, so, So it, it, it, generates, also generates, let me just… yeah, where are the constants here? So there's this, this, this table sizes, list. So generates tables of single blocks, 4 blocks, then for every 16 block, every 64 block, and then every 256 blocks. These numbers are just proposed values, but This is more or less what I think is realistic. And And this is how much the protocol processes, and bigger tables can and should be generated, of course, to make this, This index efficient, because the lookup cost is logarithmic with the size of the table, and yeah, so it's better to have a few big tables than a lot of small ones.

But, this is something that can be left to the infrastructure, and my… Plan is to, To have the protocol generate tables up to 256 blocks, and then, then, let the infrastructure providers generate zero-knowledge proofs of bigger merge tables and put them in, well, basically another contract, which has a similar interface to the system contract of the protocol-generated tables. But, yeah, so the rea… and actually, I strongly believe that this hybrid solution is the best of both worlds solution, because while processing the entire index in protocol is… both too much of a burden to, the protocol participant, and also, requires, non-future proof, assumptions. But, also, it's not a really good way to just.

process everything with zero-knowledge proofs, because then there's always a delay, and the last few blocks will never be indexed, and actually, the most valuable things when we are looking up for events, then the latest ones are Like, always interesting, and a lot of applications, like cross-chain communication, would be absolutely unfeasible. if we didn't always have the latest blocks indexed, and even for the API use case, just proving a few last blocks would require just downloading all the blocks and receipts of those blocks, and that's quite heavy, so… So yeah, that's why I'm proposing this EIP to, put the first… first stages of table generation in the protocol. And, well, that's pretty much, what the AIP does, and just to finish quickly, I have this,

some numbers for performance, because I already have a work in progress, but a more or less efficient implementation of this whole thing. So, yeah, I have got get branch where all the tables are generated, both these protocol-level tables and also bigger tables, up to tables of 4 million blocks, so that's why I can do efficient lookups now, and Well, the typical… so the… so typically, searches are, including proof generation, so, like, doing a full history search of 25 million blocks and generate a proof of the query results, that typically takes less than a second, so we have this, workload test during GATT, Where, which, does, queries that yield results with diffic… different densities, and, Here, like, like, like, these, these, on average, 18 million block-long queries.

They take, on average, 17 milliseconds, so it's really quick, and as the number of results grow, obviously the search time also grows, but it's really quick, and also the proofs are really, cheap, so, if the proof is an exclusion proof, like, there's no results, then proof is typically around 70 kilobytes, which is, like, really good for API usage, and for on-chain usage, it's even cheaper, because then we don't have to prove the index table roots from the state, then it's 25 to 30 kilobytes, which is… For some use cases, still feasible for on-chain usage. And I also did some measurements of how much burden it places on the block processing, and the nice thing in this design is that only the single block stables are generated during block processing, because they are hashed into

The current, block state, but that takes just, less than 2% of of the block processing time, and this is a single thread CPU cost, and it is absolutely parallelizable. It's even… it can even be parallelized with the block processing, and also parallelized with itself, so… It can be reduced to totally acceptable numbers, and the bigger tables can be generated asynchronously, because they are referenced in the state with a delay, and Yeah, so, I believe… I believe, this is a valuable, effort, and that's why I spent so much time on it, obviously, and I think I have the right solution, and… Yeah, so… so this is the PRM proposing. That's it.

Nixo: Thanks, Schult. Any, feedback, comments, questions? Okay. If not, we'll move on to the next PFIs. This is PFI2488, deprecate the call code, opcode, and… EIP7645, alias, origin to sender, proposed by ABC123. I am not familiar with this person. Are you here?

Cyrus: the, guy asked me in the… Ethereum Magicians chat to talk about 7645, if you want me to. This is Cyrus.

Nixo: Yep, that would be great.

Cyrus: I don't know what the other one is. So 7645 is just a proposal to to alias Origin, to sender, to, you know, once and for all, sort of get rid of the origin tech debt. Before… Before account abstraction, the account paying the gas and doing the thing were synonymous. And in any true AA solution, these roles get separated, meaning origin will be broken. And I guess 702 already broke it to some degree. So… The proposal is to just get rid of that tech debt. In general, however, my inclination on this topic is that the champions of AA in general, are better suited to advocate for all AA solutions, whatever they may be, 7645 included or not.

I'm just an app dev, and I can't really hang in these low-level protocol discussions for very long. Secondly, I think the client teams are gonna do what they're gonna do, and if the political will is there or not there, it's not likely that anything I'm gonna say is gonna have much effect on that. Which is why I haven't championed it since originally proposing it. That said, I can confirm that origin use is being exploited in the wild right now, if anybody's curious to hear that. It's written in the Future AA channel of the Discord. But I can try to explain it here if people want to. That's all I have to talk about. I don't know who the… who the person is, ABC123, I don't know who that is.

Nixo: Okay, thanks, Cyrus. We will get the 7645 merged into CFI to, Hegota. I will ping ABC123, to… maybe he can get someone to come talk about 2488 at the next call. That is all we have for Hegota. Does anybody have any comments on, Cyrus's… the 7645 alias origin descender? Okay. And anything else on Hegota? Cool. Then this looks like it's gonna be a pretty short call. We have, two more items, just miscellaneous items. The, coalition that is trying to encrypt the mempool is looking for feedback on both EIP18105,

which is Universal Enshrined Encrypted Mempools, and 8184, which is Lucid Encrypted Mempools. There is a comment that he left, Here, put it in the chat, looking for, Feedback, and there is a bounty out for that feedback. The other item, is that a mascot is needed, for Glamsterdam. and A.B. Coathup, put… up a post on Ethereum Petitions, there is a vote, so go add your vote for… whatever mascot is up there. Right now, the Flamingo looks like it's winning, with Polar Bear second. So… Go add your vote, if you… Want to see a specific mascot for Glamsterdam.

Yeah, Barnabas, we have lots of call left. I think that that would be… A good use of this time. So Barnabas asked in the chat if we could use the rest of the call to discuss any potential open PRs for devnet-6 scope, and I think that would be great. Felix, do you have something?

Felix Lange: I have a process question.

Nixo: Okay.

Felix Lange: Why is the mascot not decided by the client teams?

Nixo: I mean, because the community put a post up, first, and the client teams didn't have any, have any proposal before that, I think that that's open for discussion, but A move needs to be made, either way.

Felix Lange: It's just, it is my understanding that in this call, the client teams, decide.

Nixo: If you want to put up that proposal, that the client team should decide, I think that that… Could be fine. Okay. Either way, it's gonna be fine for, disco ball. Yeah, I think the disco ball was the original… was the original one. I think that that would be something that we could discuss async, in the R&D Discord. I… I think it would be fine either way if the community decides. Or if, the core devs decide. There was an EIP put forward for, like, choosing the mascot, I can't remember what the EIP was. I think it's kind of nice to have the community involved in, choosing the… the…

Mascot, since it's such a low… technical barrier, and it's something the community can be involved in. I don't know. I think this is probably better for the… for an async chat in the R&D Discord somewhere, maybe in, like, the uncategorized channel. But yeah, let's move on to devnet-6 scope. Barnabas, do you wanna, okay, Felix! Phoenix was joking, okay. Barnabas, take it away with devnet-6, open questions. Everybody's done… Felix is done trolling me.

Barnabas Busa: Yeah, so we have the, And then 6 spec sheet right here. So, on the CS side, I basically just listed all the, open PRs that we… Potentially want to merge in for… 146? Feel free to ignore that, because this is an ER call, so for the ERL side, I think, the most… The biggest question is 8282. And what are… this EIP should be, Basically, good to go in, or do we require additional reviews, or do we require additional changes? Would anyone have any takes on this?

Marius van der Wijden: Yeah, for us, it's, good to go. Mod you know that we might… Would like to change the contract? But we have the 8282 implemented, and, yeah, we can just merge with our dummy contracts.

Barnabas Busa: Yeah, so as I mentioned, we have a potential placeholder contract for now, with the latest commit. changing the dequeuing to 64 and 256, deposits.

Justin Traglia: I want to quickly mention that I have a follow-up PR after 8282. To set the, When onboarding builders at the force, instead of using 0x03, we'll use 0 for the builder, for example. It's a very small change.

Barnabas Busa: Does that, yeah, so that will be also on the side, right?

Justin Traglia: I'm sorry, that'll be on the CL side.

Barnabas Busa: CSI donor?

Justin Traglia: Yep.

Barnabas Busa: Huh.

Marius van der Wijden: Is it? I thought we… I thought it would change the contract, right?

Justin Traglia: No, I mean, this will just… Hard code builders at the fork to use version 0, regardless of the withdrawal credential.

Marius van der Wijden: Okay. Oh, sorry, yeah.

Justin Traglia: It just doesn't make sense to use version 3 for builders within your deposit contract. I'll make a PR after 8282 is merged.

Barnabas Busa: Right, and then the other one was, 11807, but I think we… We decided to merge this one in after the call, right?

Justin Traglia: Maria's not on the call, but if that was her EIP, I believe it was yes, right?

Marius van der Wijden: But there's one more change that we want to make, right? The thing that we talked about at the beginning of the call.

Barnabas Busa: Is Maria gonna make that change, or is someone else volunteering for this?

Marius van der Wijden: Well, we have two… two different proposals, right? With the 20 proposal empties. Dragon proposal, I think? We have to decide?

Barnabas Busa: Could we… Not decided now?

Marius van der Wijden: I think so?

Nixo: Is there any opposition to it?

Marius van der Wijden: To what? The proposal from Tony, or the proposal from Dragon?

Nixo: So I think the decision that we had made is that the default that we're gonna do is Tony's proposal. Dragon's gonna put, dragon already put an overview of those three, options in the ACD channel, and the teams that have not looked at either Tony's proposal or Dragon's Alternatives are going to look at it by by, either end of day tomorrow, or end of day today, or, by tomorrow, and then Tony's gonna follow up with them. And so, the soft commitment is we go with Tony's proposal, unless there's opposition, we can go with Dragon's proposal, if there's more support for that, either way, a decision is going to be made async by the end of this week. I just would like,

Client teams to actually take a look at it, rather than just blindly, blindly agree to it now, so the soft commitment is Tony's proposal right now. And then that way, it does get into DevNet 6. And if Dragon wants to, Ping the teams to support his… alternative, I think, Tony, is, is, not in opposition to, Dragon's alternative. Is that… is that… An acceptable timeline, both Barnabas and Marius.

Barnabas Busa: Yeah, so my timeline would be that we have all the tests ready by Monday, which would basically require us to make a decision on this, Probably by end of the week, or end of the working week, so, like, maybe by tomorrow night.

Nixo: Okay, perfect. So, if you're, like, in, European time zone, please make a decision by tomorrow. If you're in, the West Coast, or in the U.S. time zone, please make a decision by the end of today, so that, they can figure out whether they're going with Tony's or Dragon's. If they don't hear from client teams, we'll just assume that we're going with Tony's. No, Saturday is not a workday. Which is why European, time zones should make a, A decision by tomorrow morning. Are we settled on that?

Barnabas Busa: There's… I know that there's a few more CL, questions. Maybe Justin, could take over. I'm not sure if… Do you have any more pending EL questions?

Justin Traglia: She's currently on my phone. I can talk about it.

Barnabas Busa: Well, I think the most recent one is, the… this one.

Justin Traglia: The 1x4.

Barnabas Busa: Yeah, Divine Library.

Justin Traglia: Yeah, that's a bug fix, sort of, so we intend to merge that for this upcoming release. Please take some time to review it, find those. Thanks for… Do you want me to give a brief overview of it, or… Thank you for running.

Barnabas Busa: Yeah, I can give a quick overview. So the bug was basically, That exited, builders could still be topped up basically immediately, and then they could potentially, take up some space in the… Validator withdrawal queue. Basically tossing the whole… queue for, for answer letters.

Justin Traglia: I won't be gone.

Barnabas Busa: So, the way to fix this was basically, as soon as you make a new top-up deposit into an exited validator, then the withdrawability delay will be reset to 36 days, the 8,192 epochs.

Justin Traglia: A clarification for exited builders, not exited copies.

Barnabas Busa: Yes, this is for existing builders, correct. Yeah, I don't know if there's any other open CL… questions. I know that there's still quite some, open PRs. I'm just curious what's the holdup on merging those in.

Justin Traglia: I mean, from my side, my schedule's fine. Kind of busy this week. Okay, I would.

Nixo: Justin, we can't hear you very well.

Justin Traglia: What? Oh, I'm sorry. We do intend to launch those before the end of the week, and make a release. Oh my god. I'm sorry, can you hear me?

Nixo: Your… I think your background noise is.

Justin Traglia: Meaning for your voice. I'll go there. Okay, that would be on the side. We will merge those PRs.

Nixo: Great. Barnabas, do you have any other open questions you want to get to?

Barnabas Busa: No, so, like, again, assuming that we can merge in all the APRs by Friday, and then we can have the CL release Alpha 11 by Monday, then I think we should be all set for… Then that launch on Wednesday. If you can target that, that would be very nice, and yeah, if you have a… client branch ready to go, please let me know, and then we can start testing already. Ahead of the test… ahead of the test, and expect us to come out.

Nixo: Okay, great. Barnabas, will you send me the… all the open… any of the open PRs that you haven't that… don't have consensus, and we can follow up async and make sure that, all of these are… have enough consensus by ACDE.

Barnabas Busa: Yeah, sure.

Nixo: Okay, great. Anything, any other… Glamsterdam stuff. Abc123 is here, and did not get a chance to talk about, 2488, ABC123, do you want to say anything about deprecate the call, call code, opcode? VIP. Cyrus spoke on behalf of 7645. Okay, if not, then we have no more agenda items for today.

Anybody else have anything else? Okay, then we will close up early. Thank you guys for coming.

Potuz: Goodbye, thank you.

Justin Traglia: Hi, everyone.

Marius van der Wijden: Goodbye.

Zsolt Felföldi: When I see you.

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