| S No | Agenda | Summary |
|---|---|---|
| 189.1 | Pectra Scope : | Finalized the Pectra scope ! EOF and EIP-7702 are both included. |
| 189.2 | Discussed deactivating EIP-158 | As it would cause issues similar to SELFDESTRUCT in a post-Verkle world and EIP-7702 as currently specified could create accounts with 0 nonce/balance/codehash but storage. |
| @gballet will draft a proposal to formally consider the change. If 7702 is tweaked in a way that does not cause this issue, we’d consider it for the Verkle fork. | ||
| 189.3 | EIP-4444 & Portal | @pipermerriam came on to get a status update on EIP-4444 & portal support by client teams. A few client teams have begun working on this, but flagged that they currently have many competing priorities. The Portal team will keep monitoring history-expiry to offer help to any client team needing it! |
| 189.4 | ACD, Network Upgrades & EthMag Improvements | agreed to try the “EIP Review Request” proposal. There weren’t any objections to PFI/CFI/SFI, but given the scope I’ll open a PR for us to discuss before agreeing to the change. |
| 189.4 | Testing/Devops comms channels | Testing teams proposed a new channel layout for discord |
| 189.5 | PeerDAS Breakout Room #1 #1059 | PeerDAS (June 11) breakouts |
| 189.6 | ePBS breakout room #2 #1060 | Falgged the upcoming EPBS (tomorrow) |
Tim Beiko 3:00: Good morning everyone. We are live for All Core devs number 189. Main thing on the agenda today or at least most important thing is finalizing the Petra scope. The biggest question there seems to be around what to do with EOF and then potentially how we'd approach a blob count increase. Thank you to all the teams who've likely out their positions and views before the call. I had some time to read through all of them. They're all on the agenda then Mikhail had a lot of spec issues around the picture that he wanted us to look into. So go through those. We also had another breakout room on 7702 and yeah spent most of it discussing some concerns around viability. So it's worth getting this group's opinion on those. Then a last pectra thing there's a proposal by Guillaume about deactivating EIP 158. As it has some implications with Verkle. After that is Portal. After that I had some potential improvements for All Core Devs how we run network upgrades and how eth magicians plays into that and then testing teams has some comments stuff they want to talk about. And lastly sh out to the first peerDAS Breakout out next week. Hopefully we get through all this. And so first on the list. So the Petra scope discussion. So on the agenda as I said we have an updated views from Besu ethereum JS nethermind Reth had shared their views before. And then the EOF devops team had shared their view of all the potential Forks we could do and what it would mean from a testing perspective. So I think the only two teams we didn't hear from in writing were Geth and Aragon but we have heard a bit from them on the last call. Reading through all of them this morning it seems like pretty much like everyone across Besu Ethere JS nethermind and Reth would like to ship EOF relatively soon. So before the Verkle fork and then the question is whether or not we want to combine it with Pectra. Some teams raised concern around the scope of that other teams would rather have everything together in one fork. And there seems to be also a pretty common or like broadly shared view that if we split the forks out like if EOF is a separate Fork. We should keep this minimal like people don't want to do a fork with many other features in addition to EOF before Verkle. So I guess I'll pause here anyone from any of the client teams wants to add more color or new ones. I thought I just said and if anyone from Geth or Aragon specifically want to share their perspective. Yeah that'd be great. Yeah Lukasz?
Lukasz 6:29: So from my perspective I personally would like to ship Fork that is more or less implemented at the moment with some minor changes might still go in but without any major changes. I would consider EOF actually implemented so it more depends if testing and would delay the fork but I would like it to ship in 2024. And then I'm open if anything else important comes up that is more urgent than Verkle trees and for that for example peerDAS might be or something Else. That will be ready later, maybe EPBS for example with inclusion list if that's have a different iteration. Then I'm fine if we decide this if it's more urgent than verkle for example and will be ready earlier than Verkle to be shipped to ship it earlier. So I'm kind of or this because my reasoning is also because prague is already quite big. I wouldn't call it small, making it even larger would increase the risks of shipping it in time whatever the time frame is as well as bugs and just increase the complexity. And I think we should ship in small Forks probably you know are a lie in my opinion but we shouldn't also aim for extremely big Forks because they increase complexity of testing and and shipping gas etc. And they cause delays. So that's my stance.
Tim Beiko 8:10: Thank you. Guillaume.
Guillaume 8:13: Yeah so you were asking for perspective. I've got some perspective some New Perspective I have tried to run a transition on the more recent database which I hadn't done in a few years. And with 10K which was the upper bound sorry 10,000 leaves being translated per block. We already are over the two week two weeks limit. Which means the state has grown way faster than the 2022 estimates. That was on the database that is about a year old. The state is growing now the question comes about the usability, sorry the feature like shipping features just because we can ship them now including EOF but not only I don't think this is what we should be doing we should be figuring out. What we really need to do right now and my understanding or at least my fear is that the more we wait the bigger the Verkle translation will take the longer the Verkle translation will take. Is EOF really that urgent. I don't think. So I've read several Arguments for shipping it in Prague the more I read those arguments the more I realize no they actually like there's no nothing that really justifies EOF to begin with. Like dragon has published something I read it with interest. I asked a couple questions. My understanding is that everything can be done without EOF. I think EOF still doesn't have a very strong case and we are delaying verkle just because it's been coded doesn't mean it's been tested. Yeah I heard about the two test but for when I have understand understood as Pari and other people it has not run on a testnet. So you are not ready like EOF is not ready. We don't know. So that's one thing. As when it comes to shipping EOF and other features in yet another fork in between Pectra and verkle well once again the state is growing time to wake up time to start taking the problem seriously.
Tim Beiko 10:29: Thanks. Andrew?
Andrew 10:34: Yeah from my point of view if we can if we agree that both Verkle and EOF are good things and we should deliver them both. Then my thinking is that if we input the EOF into pectra and then deliver vle that will be the fastest way to deliver both. That's my intuition. so that would be my preference EOF and Pectra. And then verkle if we are not happy with that then I am fine if EOF is excluded from pectra and then we deliver Verkle in the next fork. I Osaka my least preferable option is to have a fork between pectra and verkle to ship EOF because here I agree with Guillaume. The state is growing and I think Verkle is more important than EOF. So I yeah that would be I think to my mind that's the worst outcome.
Tim Beiko 11:40: Thanks. Dragon?
Dragonrakita 11:46: Just to address the statement of growing urgency for the verkle. We are talking about 10 - 20% of the longer transition time. EOF is not going to increase the state and three additional months that we will need to ship additional Fork are not going to delay verkle for a lot. if you're talking about 10-20 percentages not even that it's not like 2x. So framing that inclusion of the EOF is going to damage the ethereum is really bad to be honest. That's it for me.
Tim Beiko 12:31: Thank you Matt?
Guillaume 12:35: Sorry can I just respond to this?
Tim Beiko 12:37: Sure and then Matt’s after.
Guillaume 12:40: Yeah I'm not saying EOF per se is going to like the the size of EOF contract I'm aware very are smaller. Well at least that's the claim and the Hope but I'm talking about the time it takes to deliver yes the state is growing Maybe by 20% per year. But my data is from last year. So it's already grown much more since then. So and then once again the claim that it can be implemented in three months doesn't mean it's going to be delivered in three months. just a yeah just some Precision but I'm not blaming EOF for everything. It's EOF and other features that do not that as a whole delay Verkle.
Tim Beiko 13:32: Got it. Matt?
Matt 13:35: Yeah no I mean I agree with Andrew here that this is essentially an opportunity cost and that if we kind of delay EOF beyond the vertical transition that it might be hard to deliver at any reasonable timeline and the two Fork approach also seems dubious from a scope perspective. And you know there's also the during our testing are more efficient than what we have right now and I know there's a few ideas kicking around on how we can improve the performance of the transition. So I I kind of echo the point of reth and other folks that the transition time might not be the end of the world here especially considering the L2's position of posting stayed involves in these other kind of reductions that we're taking. But yeah I mostly see this as an opportunity cost from our perspective of if we don't ship EOF prior to Verkle it's going to be a long time before we see anything meaning full in the EVM like that.
Tim Beiko 14:33: Thanks. Gajinder.
Gajinder 14:53: So as you know what as you know from our blog post what the perspective of ethereum JS team is and we see that EOF if it has to make the window it has to make the window by Q1 for that you know the devnet for EOF needs to start as soon as pectra is shipped out. And maybe if we can ship it out by October and so that that is our team perspective but in terms of in my opinion refactoring verkle on top of EOF will delay verkle at least by 3 months to 6 months with in. so I think we can we we can try to do it in a quarter. so it will delay at least by a quarter and that that is something that should be take taken care of that you know it might ship verkle onto 2026 rather than 2025.
Tim Beiko 15:56: Thanks let's do Lukasz again and then Dragon .
Lukasz 16:02: So from my understanding so while understand it can be very frustrating especially for the people working on it. But even if we go from two week transition to 4-week transition those additional two weeks are so small in grant scheme of things to everything else that I just I don't know why we are over stressing on it right. In my opinion is okay it takes two weeks more that's not the big deal.
Guillaume 16:32:Thanks well what I'm telling you is that it's not two weeks. it's already two weeks a year ago. so that means it's about well okay if we ship next year which we want because of all the extra two forks apparently or at least if that realizes. We're already at three weeks, potentially four. Is it going to stay linear probably not because my estimates were linear and clearly just from data a year ago the growth is not linear at all. It depends on what events happen on the Chain there's no guarantee it's going to be one month if we Ship by 2026.
Tim Beiko 17:15: Thanks. Dragon?
Dragonrakita 17:18:I want to say that the EOF is one man job. Basically it's localized to evm and it requires one or maybe two people to implement additionally there's a big group effort on the testing that's already started. So we are not just starting EOF now. The implementation spec and everything around that all the in finalized basically State.
Tim Beiko 17:45: Thanks. Kamil?
Kamil Sliwak 17:50: I just wanted to quickly update the perspective in from the slate compiler. I mean like for us like like I know like it's like on the client side it's a different matter but like for the compiler EOF is like a huge Improvement in terms of like implementation time for future program to deliver for example will be we already have like a lot of workaround we have like for things we didn't like we had to do before we had like feature of the EOF but we'll probably rewriting those parts of the compilers. So in terms of that, like having to write it once, EOF would be feasible to us. and also some of the EIPs that are included like access to the bigger area of Stack would help like also in the terms of movements like those stack to that are plugging users. So overall we're very strongly in favor of having this in Prague as soon as possible.
Tim Beiko 18:51: Thank you. So I guess from all this discussion what the caveat that I think Geth like obviously on the Verkle side is kind of against included yet. And it seems light client is at least more in favor of keeping the Petra scope as is. Like it seems like pretty much everyone else thinks that we should do EOF before Verkle. And then the question is how this relates to like the current scope with some people saying it's better to breaking out in two forks and others saying it's better to have it all in one fork. One thing I guess one of the risks I see of having everything together in like a single Fork now is that it lowers the speed at which we can test stuff across all the client teams. Because you know nethermind is working on some EIP and then Reth is working on another and Besu is working like on a third and it's really hard to get like you know like a new Devnet up where like we're testing all three against each other because they don't have the same subset of EIPs ready. I guess my suggestion based on this discussion would be to include EOF in like the same Fork scope as pectra to signal that you know we don't want to open up a whole other Fork which would have a bunch of different things in. But then to use kind of Devnets as a way to sequence like okay when should teams have stuff ready implemented. And this kind of allows us to you know like make sure that we're testing cross client stuff kind of in a gradual way. And that we don't end up in a spot where like yeah we're waiting three months for everyone to have implemented everything and there's like not any cross try testing going on. And this would probably look like you know Devnet 1 is all the stuff we had in Devnet 0 with like the spec fixes. I'm not sure what a definite 2 would look like if there's like some first set of EOF EIPs that make sense to bring in and test. And I feel like if we go with it that way we can also potentially make the decision to break EOF into a separate activation. Yeah break break EOF into like a second activation like they've you know decided to to potentially do on the EL side with peerDAS. But we sort of don't have to make this decision now right like we can keep moving on the Devnets. And try to like coordinate cross client testing that way and then if we see that you know everything else is literally ready to ship and then EOF still needs a couple months of testings maybe we decide to yeah maybe we decide to like separate them at that point and like yeah there's two comments in the chat right now that like multi Forks have more risk. And have you know more overhead. So I agree with that and this is also why I wouldn't want to make that commitment today but rather say that it's all part of the same Fork by default. Use Devnets a way to sequence what we prioritize in terms of testing on the multi client front. And then if we see that you know for some reason EOF is going to delay stuff like for a very long time we can then make the call to split it out. I don't know yeah what do people think about something like that. I know there's a couple hands up that they were up before so.
Greg Colvin 22:42: I'm sorry because the conversation weird while my hand was up and in the chat I still see discussion of whether we should do this at all. And so I'd like to say just a little. We've been trying to get in what amounts to EOF functions for about 7 years now. I showed up seven years now and said Gee I can pick up my research and within a year or so we could actually have a compiler from EVM bytecode to machine code and that should help with everyone complaining that the EVM is too slow. I kept hearing that when I got here it was known EVM is broken and for 7 years we've been trying to do what we needed to do. To be able to compile EVM code to machine code in linear time. So that we could do it on the blockchain with it not being a denial of service, attack service and that has been impossible for seven years now attempt after attempt to get it in every single time people come, people go. We explain again why it's necessary. We're told again it's less important than anything else and it just keeps rolling and I had wanted to write this thing like before I retired. And at this point I just turned 70 I'd really like to write that compiler before I die. Okay.
Gakonst 24:26: This is Georgio from Reth. For what worth we have written a jit compiler for EVM without having EOF. So it's not necessary per se to use the EOF for that. We do know that it makes the code produced more efficient. And two we do know that EOF removes the need for live jump dust analysis which is a very expensive operation which is part of the reason why jit could not be safe to do near the tip. Would like to Echo some of the earlier points that the ethereum platform also serves its users which are smart contract developers. The reth team also maintains the Foundry project and we have very good understanding of what do smart contract developers want and need. And I think somebody wrote in the chat Ben Adams that yes large contract sizes and no out of Stack errors are actually indeed one of the most common solid the errors. And we really strongly believe that these should be fixed ASAP. Yes there might be other ways for fixing them for example there was a swap and an opcode proposal a while ago that didn't come with EOF. Sure yes you could do it maybe other ways given there's a set of features you can get do it at once. I personally think that's it's a huge benefit and also dragon from our team who spoke earlier he shared the whole document with like 10 bullet points for application developers benefitting. So I guess I'm kind of confused at this point around why we're discussing this. I think most teams have said they like it solidity has said they liked it. Viper has said there is some also some extra small things that they need to do they prefer to do some of the reentry things but also supportive. Let's just do it. Why are we? It is a bit confusing where we are where the conversation is at right now because the chat has been saying we don't mind extending the verkle transition by couple days. The data says State growth is going down. So that is a confusing argument in the first place and you have a bunch of application devs telling you this is a good feature. So yeah it's just confusing why we're considering not doing it given that most people have voiced support. And yeah I think the question is around the Petra scoping and not around on the you know what to do about Verkle. It's literally do we do pectra now 1fork 2 Forks 2024, 2025. So should we scope the conversation to that. Tim?
Tim Beiko 27:14: Okay. Yeah I guess that's kind of what I was proposing and I think the I think it's really hard to predict like you know how much work EOF is going to be how much it will delay things and all of that. So I think you know what we what seems like everyone wants is to not extend the pectra scope significantly Beyond potentially adding EOF. So like opening up another Fork would do that kind of by default. So you know putting everything in one fork but then again like using Devnets as a way to coordinate on. Like what we prioritize in terms of implementation work what are we doing cross cine testing on and then you know if we find out later in the development process that for some reason EOF is you know like a few months delay that we'd rather not have. And we'd rather ship the rest of Pectra we can make that decision to split it at that point. I think the the biggest risk. I see of like increasing the fork is just like yeah again one client team is working on like a subset of EOF EIPs while the other one is working on like Petra core. And then we lliterally cannot ship anything before everyone has done everything and we can't even test everything before everyone has done Everything. And that slows us down. So I think if we have like relatively like strong prioritization across what we test on devnets that would be like a way to manage this.
Gakonst 28:43: Is there a world where we do devnet one start with EIP 7702 and all of the stuff that we agreed on the last time and and you know maybe we do devnet 2 , 3 the same way. And then around devnet 4 say around whenever it is we also add EOF on it.
Tim Beiko 29:09: That would be my proposal, like I would do Devnet One for sure.
Gakonst 29:12: Almost like a stretch go.
Tim Beiko 29:15: Yeah but I think people should start working on it and we'll keep adding some static tests for EOF in the meantime but yes I would not add. I think for devnet 1. We have a bunch of stuff that came out of interop that we need to test in a multi client setting. I would isolate those changes you know get them tested on devnet 1 ship that have it be you know stable then you know layer more stuff on top.
Gakonst 29:47: Yeah so it seems like CFI in terms of people working on it doesn't mean anything right now.
Tim Beiko 29:53: Yes so I would we did this so I would propose like we basically include the whole Suite of EOF EIPs if this is and then you know if in the future we did we decide that like we need to split it out let's do that but I think by default we'll assume it's all shipping together. And yeah again just think we need to be mindful of how we approach Devnets but the Devnetspecs are kind of independent from the fork spec. So we already have a way to manage this separately.
Gakonst 30:28: We' be supportive of that.
Tim Beiko 30:30: Yeah okay and I guess yeah from the other client teams basically including including it in the fork and then adding it into the devnets once we've tested everything else. Okay Besu support Oh sorry yeah Maurius.
Maurius 30:54: Yeah as I kind of wrote in the chat I don't think that's a good argument. That no one would start working on it because people have already started working on it even and everyone has started working on it. Everyone who needs to work on it has started working on it sure but I think I don't really but I don't think it's a great argument to say people will only start working on it once it's included because the people that need to work on it already working on it.
Tim Beiko 31:23: That's fair but I do think like it's like stronger people are saying like we want want to ship this you know around Prague. And I think that's what it like meant to highlight like changing the stuff like whereas there's other stuff you know like in the CFI that we probably won't do do or even try to do in prague. So I think moving yet makes it a bit clearer if not for us like at least for I think the rest of the community yeah.
Marius 31:54: So just to make sure I understand don't most client teams have EOF implemented and at the risk of being too provocative are we not discussing whether Geth should allocate more resources to do It.
Guillaume 32:12: I thought it was all you needed was one person to spend two months on it that's the claim your team is making right so we have one person working on it for over a month now that should be enough right.
Gakonst 32:22: Okay great great yeah sure that's okay with us. I also think that's not the productive way to approach the conversation you young with all due respect and so I guess I wonder what we're discussing because they that implementation Matrix that showed which teams have implemented it.
Tim Beiko 32:40: I think you know testing and devops also like making it like a focus on their end like so yeah I think you know clearly.
Gakonst 32:49: Yeah exactly exactly exactly.
Tim Beiko 32:50: Okay yeah but like yes I think on every client team there's someone who's been working on it. And like I don't suspect this would change you know if we include it like but like yeah it makes it clear like what's the full scope. Okay so to summarize yeah what I propose is we include all the EOF EIPs in pectra. Basically the whole list you know I'll post the link but there's like 12 of them. And then we do Devnet one like we don't include them in Devnet one. We do devnet one which is just like an iteration on what we had in devnet 0 with like the 7702 which we probably need to discuss after. Because it's not you know formally included but assuming 7702 is included. We do that. We do like the changes that we made to 2935. Basically all the fixes coming out of interop. We use that for Devnet 1. I think when we're ready to do Devnet 2 we decide you know what else we want to include but I think having teams all coordinate on having teams all coordinate on like okay this is the next Devnet. That we're targeting and this is where you know we should make sure that things are production ready is probably the most like productive way to move forward rather than having these like yeah 20 EIPs that people are are sort of working on in different capacities. Does that make sense Pari? And then yeah Marius has a comment saying like want to make it clear that we can still remove EOF even if it's included and yeah I think that's always sort of been true. But so far it seems like people want to actually do it and try it and then and then yeah once we know how well is going. We can decide if we want to split it or yeah postpone it or something like that but yeah having that be the default path that it would ship all together in Pectra and it would be minimal delay.
Gakonst 35:03: Oh to confirm them that this mean that A teams are expected to implement and test the EOF, B the EOF testing team will be expected to start shipping or allocating actively resources on the EOF testing and we should be able to start pinging them and maybe even help them ship this more because we've been doing that already and I wonder like if now that's considered priority and we should go ham on it.
Tim Beiko 35:31: Yes and then the one caveat is like yeah for cross client testing stuff. We probably don't want to do for cross client testing stuff. We probably don't want to prioritize EOF right now until we have like just implementations that are further along for both EOF and single clients and then the rest of pectra in the multi client context.
Guillaume 35:58: Just running on this isn't that what the the testing team is doing right now working on the EOF. That was my understanding.
Gakonst 36:05: Yeah I'm just confirming the case for everybody's context.
Tim Beiko 36:16: And I guess yeah Mario from testing you want to give yeah you're thoughts.
Mario 36:23: Yeah so yeah we've been working on including EOF tests into the execution spec test for the past month and in the last couple of weeks we have really good progress. I think if we keep up this way I think we should be able to fully cover. And I wouldn't say in less than a month I but I would say maybe in two months we will have full and confident coverage in execution spec tests. The great thing about how we have been working now is that we have this isolation between EOF. And the rest of the prague EIPs. But it is really easy to just join EOF into the full PR test set when the time comes. So now we have like this releasing pre-release schedule. We have not done pre a pre-release for EOF now but we will do in the maybe this week or early next week we'll have the first EOF only pre-release and it's really easy for us to do. So we have been working really hard on the framework to make these things easier to have features and in this case EOF feature release only for a test. So that we will try to make these announcements a little bit more clear in the future and we will have the test sets ready for you guys to consume.
Tim Beiko 37:53: Okay. Potus
Potuz 37:59: Yeah. I don't have any take on EOF at all but I just wanted to mention that I haven't seen any studies like when people propose to include this or include that in a fork I haven't seen any report on how how are these features testable in an independent fashion from the other ones that are already being tested and already being considered for inclusion the issue being that adding a feature even if it's been already worked out the testing is not linear with the number of features is quadratic every feature that you add if it cannot be tested independently it needs to be tested against every of the other features in an independent faction from the remaining ones. And I think this has to be taken into account . It doesn't seem to me that people are considering the amount of testing and the complexity of testing and how it increases with any feature that is added to a fork not against. I'm just asking whether or not this has been worked out, if there's a report of this can be tested independent of that and so forth.
Tim Beiko 39:08: Yeah I guess do any of the EOF or testing people have a yeah perspective on that.
Paritosh 39:17: Yeah that's also been the point that I brought up in the ethpandaops document as one of our concerns. Even just looking at all the CL EIPs there a lot of them that have interactions between EIPs that we don't even know what parts to exactly test. And yeah I think adding more and more is just going to make it even more complicated but yeah I do agree that at least the benefit of EOF is that you can test it quite a lot in isolation while that won't be true for most of the CL EIPs.
Tim Beiko 39:52: Thanks and Charles your hand has been up for quite a while.
Charles C 39:58: Yeah just wanted to reiterate Viper's position which is that I don't think that EOF is that urgent. I mean like the see it in obviously I've been contributing but EIPs for preventing re-entrancy are more important for users. I think from a prioritization perspective because users are trained sorry smart contract developers are trained not to have non re-entrancy protection because of the gas cost. And if it's cheaper then people will use it more whereas EOF you know has some performance improvements and quality of life improvements.
Marius 40:48: It would be great to so as far as I've seen from solidity they like EOF but they also not been very pushy about it. So I don't know if compiler teams are not really pushing for it because they need it and they need it done yesterday then I don't really see the urgency to it.
Charles C 41:18: For compiler teams EOF has a lot of quality of life features. I don't think you need EOF to prevent stock to deep Viper doesn't have stock to Deep like I said it does have quality of life improvements. It improves performance but from my perspective preventing re-entrancy is like a huge massive security hole or whatever you want to call it foot gun for users .And EIP 7609 is small you know and it would let us prevent it at the application a lot more cheaply and easily.
Tim Beiko 41:59: I guess yeah from my perspective just it seems like on the client side like everyone or there's like pretty broad consensus around EOF. And yeah it's not clear to me how much support there would be for something like that. And I think what's also pretty clear is if we do move forward with EOF there's very little bandwidth to do anything else. It would already be the largest Fork by far. Yeah I don't know Lukasz, Dragon is this what you want to.
Lukasz 42:33:Yeah so this is about the EIP 7609 a bit. So we would be also for this EIP though I think it needs a bit more analyes from EL developer perspective. We want to run some benchmarks on it. Basically we also provided some feedback about decreasing the cost a bit less. So increasing the cost that was initially offered and we also think potentially warm S loads could also be decreased in price. But yeah I think it needs a bit more analyses and like a benchmarks being run actual numbers before we can fully commit to it. But it is a very small because this is gas repricing basically. So could also be I don't think it's exclusive to EOF. We can also think about including it either in pectra or the next Fork after pectra. Yeah that's basically my comment on this EIP.
Charles C 43:45: Yeah I'm happy to like incorporate feedback like fiddle with the pricing schedule a little bit. There's some more benchmarks that I want to run unfortunately I've been very busy with other things and any help with benchmarks is actually really appreciated. But yeah I mean I'm happy to fiddle with it more. But I think the thing I want to see is whether it gets in the large you know and can talk about the details later.
Tim Beiko 44:14: Thanks Dragon?
Dragonrakita 44:18: Yeah I would like to say that I think this meeting is really good example why us in communication is very important because when I joined this meeting I was assuming that we are talking about if we're going to have one fork or two forks to be honest. And now the this basically from few few people from the call they'll Shipped in discussion if the suite doesn't want it or not if the EOF needs to come before verkle.
Tim Beiko 44:46: We've kind of Healing diminishing returns with this conversation. And there's a bunch of other stuff on the agenda we're probably going to have to kick out. So yeah unless there's any like strong objection now I would move forward with including EOF in Pectra. Again this is the entire list of EIPs they're all relisted in 7692. And then scoping devnet 1 which we can do we can like finalize async to not include EOF to include kind of the other pectra EIPs to make sure we get cross client testing on that. I think this will help you know everyone sort of prioritize multi client testing for everything non EOF keep working on static testings for EOF and then we can see what the best scope for future devnets after devnet 1 is. So yeah I guess this make sense okay.
Tim Beiko 45:53: Then next up I think the probably second most important Petra decision to make on this call is 7702. So we talked about replacing 3074 with that EIP. It seems like there's broad support to do that and then there's still some spec issues around 7702. So we discussed them on a breakout call yesterday. But didn't quite get to like a final conclusion on them but in short there's some concerns around just how we handle revocability. I know Andrew you posted about them on the agenda for today. Do you want to take a minute to just walk through this? Hopefully Andrew's here? Otherwise I think Sudeep from Erigon you were on the call Yesterday?
Sudeep 46:54: Yeah so I think it's about we feel strongly that we should have in protocol revocation. And that it should not be optional which is what is there in the current version of 7702. It should be a a mandatory feature and we are sort of exploring ways to have that revocability mentally revocability while also providing the wallet providers of enough breathing room to maybe innovate and not it's not being too constraining. So I think maybe yeah this week and over the next week we'll be coming up with solutions to that. We also decided that if there are no good solutions that we can agree on. Then we sort of move ahead with the version of 7702 which is pointed out in light client's PR.
Tim Beiko 47:55: Thank you. Light client?
Lightclient 48:21: Yeah I was just curious to but if you had a perspective on what the difference with the 7702 proposal on revocability is versus what is spec for 3074 and was accepted in Pectra right now.
Sudeep (Erigon) 48:45: 3074 I think it had the same problems I don't think the problem of the revocability was Solved there.
Lightclient 48:55: Right but we accepted 3074 into pectra with this property and Andrew even came out. And said that he was very supportive of 3074. Now that we have a way of having in protocol revocation even if it was sort of optional depending on what nonce you chose. So it just doesn't I don't really quite see what is different about the 7702 proposal versus what we seem to agree on with 3074. Like this is kind of why these this was put into 7702 because we were under the impression that this already addressed the concerns from client teams.
Sudeep (Erigon) 49:32: Right I think I think the scenario is about changing the changing the smart wallet and like their existing previous authorizations which can still be used I think that's the major scenario that I'm concerned about. And so yeah I think we should have a way to for the user to kind of revoke that which is baked in protocol and does not rely on Trust on wallet providers.
Lightclient 50:09: Is that not what is in 7702 right now? Like we have an in protocol revocation mechanism in 7702 for this exact purpose.
Sudeep 50:19: But it is optional the nonce byte is optional.
Lightclient 50:28: And it was also optional in 3074 and we have to rely on wallets to use some of these optional things. Like we rely on them to use the optional chain ID that exists in transaction types to avoid cross-chain viability.
Sudeep 50:46: Yeah but yeah that's the scenario that I'm concerned about. And you know if that gets answered sufficiently if we trust like there's a good mechanism to do that in the proxy contract like I think there was a gist by you. So I think yeah I'm willing to change my mind on that. So yeah maybe I do need a few days in that.
Ansgar 51:22: You mentioned proxy contract but like Lightclient said the revocation is in protocol if the nonce is specified. So like why in the proxy contract do we need to look into it it's like in protocol like how you were asking?
Sudeep 51:48: I think lightclients just had a way to kind of revoke things in in the proxy contract level. So that's what I'm referring to.
Ansgar 52:06: But no like that that was how it was in 3074 but how it is in 7702 is that it's in protocol level not even on proxy level so even better.
Sudeep 52:25: Yeah that's what like I'm willing to kind of change my mind like I was coming from a position where you know it should be mandatory and it should be at a protocol level. And maybe I was not okay with having it in kind of trust the smart wallet providers for that. But I think yeah like I said I'm open to kind of the change in perspective especially after like leading Lightclients. Just so yeah I think I need a bit more time on that. Ansgar?
Ansgar 53:02: Yeah I just wanted to say that kind of the 7702 authors have also kind of brainstormed a little bit on potential kind of solutions for this. And it does seem in general that indeed I mean many people have been unhappy with this general property of 7702 that you kind of have these sign that are floating around. And can be used in unexpected moments at any time basically. And well I think the Erigon team right now is the only team that actually basically would have this be a blocker for them. I think a lot of people share that General uneasiness and so in principle it would be preferable to find a mechanism where you basically have a more permanent way to store the currently active delegation Target for an account on chain. And then have specific operations that ideally also signed over the account nonce that bump that delegation Target to a different delegation Target. There are actually several ideas how to do this. So for example you could basically either do it. I think the most elegant way at least in my opinion would be to just basically use some sort of special EOF version just temporarily until we get to verkle with then we could have it more natively stored in the as an extra account field or something. And basically slightly change the way 7702 interest work. So that basically you have two different versions one of them changes the delegation Target and they signed over specific nonce. And then you just have a flag of like hey this account is supposed to have delegation active for this during this transaction would not have to come with the signature at all. So the only problem here is that in terms of prague we are already relatively late in the fork in the process. Of course this will take a little bit more time to figure out. And so yeah I already said that earlier in chat like if we end up kind of having having some sort of smaller scope of pectra that is ready to ship early. And we're thinking about what to split out to me basically it would be worth taking like two extra months two three extra months making sure we have the best possible version here of 7702 because it does seem like we there's a scope here that would basically make everyone happy.
Tim Beiko 55:05: So I guess given that and I think yeah people generally want 7702 and you know we had included 3074 in the past. I'd kind of do something similar to what we did with EOF. So I would include it in the fork and maybe not have it part of like Devnet 1 or even Devnet 2. That to if we're not quite happy with where the spec is and then spend the next month or two like two months feels like it's probably a bit too long but say like the next month actually ironing out the spec. So that we have a revocation mechanism that's potentially better than what's proposed now. It doesn't seem like a huge EIP to add a bit later in the process like you know on say Devnet 3 or whatever even if we change nothing but then this saves client having to like Implement different versions of it if we we feel there's like a high likelihood it's going to change so that makes sense people like yeah Gorgeous?
Gakonst 56:09: A quick question so if Devnet 0 spec was what we did in Kenya and if we don't do 7702 then devnet 1 spec diff from devnet 0 would be just the EIP 2935 changes?
Tim Beiko 56:29:Yeah removing 3074, 2935 changes? I feel like there was something else and I know Mikhaill has a bunch of small changes he wanted to cover as well. So maybe some of those.
Gakonst 56:40: Ah right.
Tim Beiko 56:42: But yeah so like high level yeah high level we would remove 3074 from the devnet and potentially not have 7702. And then basically spec changes on like every everything that's already there. Yeah so does this make sense to people including 3074?
Gakonst 57:07: And sorry Tim. Like Richard asks a good question was it already formally decided to replace I'm of yes based on what you just said maybe worth so.
Tim Beiko 57:17: Like last call we basically removed 3074 because we knew we would not do that given that 7702 was still being like was like a better alternative. So I think there was broad consensus that like we we'd rather do 7702 than 3074. The reason we didn't include it on the last call was because we saw there were still some spec issues. I think you know there still are today but like if we are kind of trying to finalize the scope in terms of what EIPs will be worked and iterated on. I think it makes sense to include it but then yeah not have it as part of the Devnet in the same way we're holding off on EOF. So that we don't get clients like reimplementing different versions of EIP if we can avoid it. I think this does mean though like I guess this does mean that the 7702 people and like account abstraction people like need to make this a priority in the next month or so to. Yeah and I guess yeah look like client said you know we can consider putting it in the next the next devnet 2 like if we feel we learn more by implementing it as is. Then we do by like then like the time we save by not implementing it like I don't have a strong opinion there but we should just be mindful that we're likely going to put something in and and tweak it. So I guess to start like anyone against having it in the fork regardless of which devnet it lands in. If not, yeah anyone against having it in the Devnet 1 spec even though it'll likely change based on iterations. Okay and then Ansgar said that's like you know any final version would probably share most of the logic. So probably minimal changes. So okay let's move forward with 7702 in the fork add it to the Devnet 1 scope. So Devnet 1 would basically be everything that was already included plus 7702 minus 3074 which were already removed. And then EOF is not included in Devnet 1. And then yeah I think probably the next most important thing is to go over these spec issues that Mikhail brought up unless there's anything else left on 7702. People wanted to discuss? Okay in that case yeah, Mikhail. Hopefully you're still on I guess in the order that you've put them. I'll but the first one was the execution API PR .
Mikhail 1:00:12: Yeah thanks team I'll just briefly go through all of them if anyone has any comment raise your hand or just interrupt me So the first one was the EL trigger it request as a sidecar. So during the last week we've been exploring the idea of processing the EL triggered requests like withdrawals deposits and consolidations potentially as a sidecar to the execution payload. So basically it means that they're not a part of the execution payload but the execution layer returns them in the get payload method call. So CL can take them and incorporate them into the beacon block body and keep them in the beacon block body and then can send them to EL via a new payload method to validate them. This idea is appealing because the main consumer of those requests is CL. So let's just keep this data in the on the CL side and EL will not have to do this all this work related to storing them in the block and yeah and some validation can be admitted. So it's a kind of like alternative to 7685 EIP which is general purpose EL request EIP. And yeah after a few iteration on that we conclude that the original design kind of breaking the optimistic Sync and one of the edge cases and to avoid breaking the optimistic sync we would have to keep at least requests route in the execution payload. Header in the execution block header. So the commitment to those requests needs to be kept on the EL side and it creates a cross- layer complexity where you have data on one on on CL side you have the commitment on the EL side. And you have to verify that the data actually matches the commitments. And yeah there is a discussion threat in this PR. So the conclusion the final conclusion is that with after iterating on this. It seems to be really a quite marginal benefit that this proposal brings and the engineer complexity kind of in my opinion personal opinion outweighs the benefits. So I tend to personally I tend to leave everything as is with 7685. And forward just wanted to bring this up because we brought this up during the previous call and yeah this kind of an update on this stuff. Next is EL consolidation spec.
Potuz 1:03:19: So can I can can I quickly comment Mikhail on that. In particular it's not that it's a killer but I would be against and strongly against any commitment for get payload to return something that needs to be included in the becon block. Because I would want to have I mean I'm it's public that I'm strongly advocating for epbs. And I want to have that separation of concern of concerns being kept. So that the beacon block should not be contingent to the payload already being present anything. So withdrawals deposits whatever it is I do not want to have the beacon block depending on something that the payload needs to have. Because this breaks the flow of epbs.
Mikhail 1:04:14: Right and it does not breaks with the blobs and the KCZ commitments as of today.
Potuz 1:04:25: Well it is more or less the same situation it requires that then the builder needs to send the blob KCZ commitments in the bid. So that's why it's not a killer but whatever whenever you break this separation of concerns that the payload needs to include something so that the beacon blobe includes it. Then that thing will have to go on the bid. And it makes the Bidding process more complicated.
Mikhail 1:04:52: Got it. Yeah thanks for sharing this yeah okay well.
Tim Beiko 1:04:59: Okay so closing this PR. Next one is like the EL consolidation.
MIkhail 1:05:07: Yeah EL consolidation spec we had been working on the EL trigger smart contract, the system smart contract. During the interop we have it's this smart contract finished need to write some tests as a followup to the smart contract. There is a PR to the EIP 7251 which is the max effective balance increase which introduces the EL Trigger consolidations. And it has the spec now it has the smart contract code there is the transaction to deploy the smart contract. So and also there is the corresponding change to the engine API which introduces consolidations. It would be great to get some early feedback on on these two PRs before basically we merge them. Yeah also ideally we have this in devnet 1 but it would be great if someone can check that this transaction actually deploys the code. And yeah I'm kind of, I did not do this check and yeah I need some help here. Many thanks to Lightclient who has worked on this on the similar stuff for 7002. And yeah the spec and the smart contract. Basically leverages on his work pretty much.
MIkhail 1:06:43: Okay so the next one is the align Withdrawal Request V1 with the EIP and consensus Spec. This PR is about renaming. It renames the validator Public Key to The validator POP key as it is. This changed to the engine API. So the engine API uses this long validator public key name while the EIP and consensus spec uses validator oop key. And I think that this as far as I can see in the comment Besu has implemented it as well there POP key and the engine API. So I think that this discrepancy will fight us here in there and it is better to do the renaming and align the names everywhere in all the spec documents. The problem is that basically the EL and CL has to do adjustment on their sides. So yeah it would be great to have this PR merge soon. So please take a look rise your concern but I think we just merge it and have it devnet 1 probably. Also it needs to be taken to account for hive tests that needs to incorporate these changes.
Extend V1 vs introduce V2 for engine_getPayloadBodies* requests [ engine: Extend payload bodies with deposit and withdrawal requests execution-apis#545]comment
MIkhail 1:08:11: Well okay and the last thing is the slide discussion around engine getPayload bodies requests we we are extending payload bodies by deposits withdrawals and consolidations now. And the question is actually we already have these methods version two of this of the payload bodies method in the in the engine API spec. And Sean actually came with an idea that we we could extend the V1 data structure and extend actually V1 methods and in this particular case it can work because it's backwards and forwards compatible. But I don't know if want to do this from my perspective from the spec perspective and probably from testing perspective. It is cleaner to introduce V2 but from the execution layer client perspective it's probably easier to keep V1 and just extend it instead of introducing couple of new methods and do some pumping. So it would be just great to have more to see more comments in this in this PR that introduces V2. And yeah so we can make the right decision and ideally also if we want to change if we want to switch back to V1 and just extend them. So ideally we can do it before Devnet 1. Yeah that's pretty much all. I had for today. Thank you.
Tim Beiko 1:09:50: Thank you I guess my proposal for all of these. So like the first PR the one that had issues with epbs we closed that one but then for the three other one of them. I guess is already merged. So by default I guess we would include it. But then the EL consolidation one I would lean towards we include it in Devnet one tentatively and like over the next week or so people can review and then ideally we merge it before ACDC next week. So that it's clear by then that like you know this merged PR is included. Does this make sense for everyone? Okay no objections oh Stokes is a message?
Stokes 1:10:41: I was just saying we didn't really test consolidations in Denet 0. So be prepared for this to bring up some more bugs. But generally yeah I think this is the plan to move to EL consolidations. So I think what you said makes sense.
Tim Beiko 1:10:55: So okay. Last agenda item around potentially pectra but potentially another Fork. So Guillaume you had posted around deactivating EIP 158 because of some potential interactions with Verkle. Yeah you want to give some context on that.
Guillaume 1:11:20: Yeah I mean the the general idea is that from what I gather EIP158 was a temporary measure that was meant to avoid some some use case that has to do with the Shanghai attack. Today this turn of event cannot really happen. And now with 7702 we have the problem that you can again find some contracts that would be with an empty nonce with an empty code hash sorry not contracts precisely EOA you would find EOA that have an empty nonce that have zero balance that would have an empty code hash and they would therefore have to be deleted with EIP 158. The problem is that these EOAs because of 7702 would have state would have storage and that storage would have to be deleted except with Verkle you can't . This is one of the reasons why we disable self-destruct. And I would argue we should treat EIP 158 exactly like we treat self-destruct namely that if you start creating an account and immediately delete it or gets that that then gets deleted by EIP 158 in the same transaction then it should be removed or not make it to the state. but once it's made it to the state it should remain there. Yeah otherwise we will find ourselves with dangling well potentially dangling Storage storage slots in the tree which might have some negative impact at a later stage which is I'm trying to remember there was an EIP Push by Gary that it was about deleting these this storage sorry it was not about deleting the storage but we resolved it by saying during the verkle conversion. We will delete those storage slots, yes 7610. Thank you and yeah we would find a new with 7702 we open up a new way to produce to produce this kind of this kind of Situation. So if we disable if we disable store in 7702. We could somehow avoid this problem but I still think from a purely correctness point of view EIP 158 should have the exact same behavior as self-destruct. And yeah that's the gist of the argument. I'm just wondering if there are counters to that.
Tim Beiko 1:14:22: I guess one question or like the comment back Ansgar is you know depending on how we change 7702 this like these accounts might not have a nonce of zero. Would that be like assuming that 7702 incremented the nonce would this make this change obsolete or would we still need it for some other reason?
Guillaume 1:14:46: I would argue we still need it but at least form coherence between the behavior of SELF DESTRUCT and one well the current 158. But yes we discussed that was actually the first idea to increase the nonce. We had the conversation with several people in the guest team and it appeared that was going to be fairly tricky to do. When there's no reason to keep 158 around so that was the argument it might it's the simpler approach. But yes we could potentially if we manage to increase the nonce exactly when we need it that would be a possible way to to circumvent this problem as well.
Tim Beiko 1:15:28: Got it. I guess so yeah there's a comment on Dragon saying like it would be nice to have this discussion async. So we can understand the issue better. So I guess my proposal would be yeah if we can have an EIP or Proto EIP for this yeah that's probably like a better way to Anchor the discussion.
Guillaume 1:15:51: Yeah I mean that would be the point but I'm also trying to get some early feedback before I spend time writing the the EIP. I saw a comment like yeah I'm on mobile so I don't really have all the comments but I saw a quick comment by Lukasz. No we cannot be activated at the same time as Verkle. It has to be activated at the same time as EIP 7702 otherwise we would have well or we decide to delete all the storage slots during the conversion as well but the problem is that more accounts more empty accounts will find themselves with storage and that's the risk actually wait no because then you would be able to delete them. Okay yeah I guess it can be delete them and activated at the same time.
Tim Beiko 1:16:42: But yeah so I guess it seems like there's like you know no objection or like no like it generally seems like a good idea to spec out. Yeah, any other comments or thoughts? Okay. Thanks Guillaume. Next up I believe we had Piper to talk about 4444s and portal. Are you still on Piper?
Piper Merriam 1:17:13: I am. Hello everybody! All right so we had our summit. We've discussed kind of like what EL client integration looks like looked at our last client to join the network. I'm curious if we to hear from EL teams possibly individually on kind of like what EL’s stances on 4444s on this. We our last client that entered the network took six months to implement our spec. They did that without really asking us for any support. They read our implementations, they read our specs, they implemented our cross client tests and it took them about six months to implement history Network. I think that timeline can be sped up especially with support and help and guidance. So we think that if this is a priority for EL teams that if EL teams are able to get started on 4444s integration. In the next roughly two months that it is very reasonable to have some of those teams be done by Devcon and those that aren't done to have really significant meaningful progress done and delivery ideally probably by the end of the year. This is an effort that like our that the portal teams are absolutely here to support. And if EL teams are interested in running with this we're here for it. So I'd be curious to hear from any teams that have opinions on this whether this is something that you'd like to do. Yeah that's the gist of it.
Tim Beiko [1:18:58(https://www.youtube.com/watch?v=A5EaPLLRsoQ&t=4738s): Thank you. There's a question by Pari. Yeah if the security has had time to look at portal is the implementation audited or reviewed or just like yeah what's the General Security status.
Piper Merriam 1:19:18: To the best of my knowledge. No I'm not aware of any security teams that have looked at or audited portal.
Tim Beiko 1:19:33: And then yeah. Comment by Ansgar around the seems like every client team can decide whether they want to bundle it with their main client.
*Piper Merriam 1:19:42: Yes the I think that the recommendation would be that clients Implement their own client to the network but bundling an existing one is absolutely an option. And I don't know this is a conversation I'd be happy to have with any client team who's trying to decide which path they want to take. I don't think it's a decision that we can you know . It's not a decision that I can make for them or anything like that.
Tim Beiko 1:20:12: Any other questions comments and I guess is the history expiry channel on the R&D Discord still the best place to chat about this stuff.
Piper Merriam 1:20:26: Yes the history- expiry Channel we're monitoring it actively if people have questions we will be there for it I think the timeline for delivering this year runs out in about a month and a half to two months that's about the timeline where if we were going to ship this by the end of the year. It would be good for client teams to get started in that timeline and similarly we'll all be together in person for Devcon later this year. And if client teams get started and get working on this that sets us up to have a very impactful and kind of like meaningful in-person event around portal at Devcon within that timeline.
Tim Beiko 1:21:13: So sweet anything else on the portal.
Piper Merriam 1:21:20: Can EL teams report on where they're at with this I gotten a lot of silence in these questions. And I'm curious to hear back from EL teams whether this is a priority for them because if it's not I can anyways. I'm curious to hear the answer to that question.
Lukasz 1:21:44: So overall it is a priority we had I meeting yesterday with portal team. The problem is that there are so many priorities. It's sometimes hard to juggle everything correctly. So it's the less urgent priority compared to for example the hard Fork right. But yeah we never mind we'll be working on it. And we will prioritise it.
Matt Nelson 1:22:09: It's a similar answer from the besu team.
Guillaume 1:22:19: With Geth I don't think we discussed it yet. So currently it's not a priority if if it makes sense we're happy to revise that but yeah we haven't really looked into this yet.
Piper Merriam 1:22:36: Cool Any teams who are interested in scheduling a meeting or talking about this more asking questions? We're here for that thanks guys.
Tim Beiko 1:22:48: Thank you Okay wow! I think we made it through all the technical stuff on the agenda. So I had a doc that I shared on the agenda as well. So we had some conversations at interop. And I've been having these similar conversations with many of you for much longer time around ways. We can like tweak the Core devs EIP process and use ethereum magicians better to yeah surely make things more efficient. I think yeah there was a bunch of proposals in there but like I think maybe the two that are most important or like that like yeah would be good to have live feedback on are one this idea of having EIP review requests. So I think it's come up a lot that when people present the EIPs on All core Devs most folks don't have like context on them and then it can be kind of a like yeah low value discussion because people have not gotten up to speed. So one tweak that came up was the idea that when people put EIPs on the agenda for the first time instead of having like a Long Live conversation about them. We just you know like bring up the concept like does anyone want to review these async before the next call. So people basically get two weeks to look into it and then you know we sort of default only discussing something live on the call if there's been a review request made before. And yeah so I guess I'll pause here like does anyone have an objection to that. Okay if there are no objections to this. I think we can give it a try and see how it goes. It's a pretty easy thing to switch back the second one's probably the most impactful and you might not make a decision on this today. So people when I ask people like whether they thought this CFIs status was useful people said generally yes but it's kind of hard to figure out what it means and it's hard to see like what's all the EIPs that are proposed what are like the CFI ones and then which ones are like actually confirmed for the fork and as we were discussing just you know earlier around EOF even when we like quote unquote include something in the fork there's always a chance that we take it out. So one proposal I had to make this all kind of more legible is adding a stylist before CFI that's proposed for inclusion and this would be like the canonical way someone could propose an EIP for a hard fork. And what they do is just open a PR against a meta EIP and add their EIP in the list under like a PFI section right now. It's kind of weird where like on eth magicians people sort of propose them they propose them on the Alll Core Dev's agendas. And there's like the eth magician thread and some GitHub issue in the CL spec repo that like tracks the proposed the EIPs. And it's just kind of a weird you know hard to find resource that like is effectively like yeah like not like lives kind of separately from all of the other information around the for. So yeah this would just add a section to the hard Fork if you want to propose EIP for the next hard Fork you open a PR this gets merged in. CFI basically remains as it is today. If we want to formalize it some more like there were some ideas around you know as soon as a single client team you know would like this to maybe be in the fork we CFI it or as soon as two client teams bring it up we CFI it. So and and to Ansgar's comment like you know CFI earlier in the process to like give the signal to people like okay this is the subset we're actually considering. And then what I would also suggest is we rename included to scheduled for inclusion which kind of conveys a bit more that you know the default path is we're going to ship this. But as always if we find some security issues or some you know Blocker we you know we reserve the right to take it out. And then once the EL once the hard Fork ships and we move the EIP to final we currently clear all the CFI stuff from the meta EIP. So what we would do is clear the proposed clear the CFI and maybe rename scheduled for inclusion the included which kind of denotes that it's actually live and on the network. So now we only have three minutes. I'll pause here any thoughts comments? And I guess yeah one last thing I would not do this for pectra like I think it's pretty far in the process to change things so like this would be for like the next fork and onwards. Okay if there's no objections on the call then what I'll do I'll open a PR to formalize all of this and get some feedback on that. And we can discuss it later. It's not a super time critical thing and yes I guess yeah before we wrap up there is a breakout on peerDAS and a breakout on EPBS next week or sorry the EPBS one is tomorrow and the PeerDAS one is next week. I'll post both issues in the chat and then lastly with like two minutes. There was something by the testing team around Comms Channels with client teams. I don't know if someone from the yeah.
Mario Vega 1:29:04: So yeah basically the proposal is to we have as as it is right now the R&D Discord server it has like testing channels all over the place. There are several places where one has to go to obtain different information for testing. So we are proposing now that we create a new subgroup channel. Just the way that we have like pectra sharding cross layer and so on we will have a new subgroup call testing which should be the new way that one gets their testing release information and all the testing related discussion happens. So this will be like the one stop for the client apps to go and to check testing information. We have a link in the agenda that you can go into and take a look. If you have concerns about this change please just raise your voice and we will try to make it better but yeah if no one opposes. I think we could go live with this one but yeah. Thanks.
Tim Beiko 1:30:14: Okay I know we're at time. Any quick comments otherwise let's yeah. Mario do you want to maybe post this link in the All Core Devs chat. So people can comment on there but if there's no objection and some support then we can make this change in the next week or so.
Mario Vega 1:30:38: Yeah absolutely I will send the link right now.
Tim Beiko 1:30:41: Awesome. Thank you. Anything else before we wrap up. Okay well yeah thanks everyone. I can't believe we got through the entire agenda. Yeah see you all tomorrow on the EPBS breakout and please check the PM repo for all the other breakouts of the next week or so and yeah talk to you all soon.
- Tim Beiko
- Potuz
- Kasey
- Kamil Sliwak
- Pooja Ranjan
- Siladu
- Mikhail Kalinin
- Danno Ferrin
- Justin Florentine
- Mrabino1
- Piper Merriam
- Andrew Ashikhmin
- Justin Traglia
- Ben Edgington
- Kolby Moroz Liebl
- Paritosh
- Lightclient
- Toni Wahrstaetter
- Dragonrakita
- Ansgar Dietrichs
- Terence
- Marek
- Carl Beekhuizen
- Vid Kersic
- Peter
- Saulius Grigaitis
- Karim T.
- Lukasz Rozmez
- Guillaume
- Matthew Smith
- Marcin Sobczak
- Mehdi Aouadi
- Daniel Lehmer
- James He
- Sudeep Erigon
- Anders Kristiansen
- Enrico Del Fante
- Pk910
- Francesco
- Pawan Dhananjay
- Hasiao - Wei Wang
- Spencer -TB
- Trent
- Nflaig
- Nicolas Consigny
- Charles C.
- RIchard Meissner
- Greg Colvin
- Matt Nelson