EIP-7723: Network Upgrade Inclusion Stages

Transcript

we just waste like tons and tons of cycle without actually knowing like okay of these like 25 proposals which one do we actually want to spend a bunch of time reviewing which one do we want to implement and prototype and then which ones do we want to ship on mainet we would try to do all of that at the same time and it was very hard to coordinate this is the right process in a way because when we deploy an EIP on mainet we can't ever take it out right like the the blockchain has to keep it forever so we have to be extremely extremely sure about it. It's not trivial to remove EIPs from hard forks and it's also prone to bugs. We've had bugs on the Ethereum mainet because we've done a poor job of removing EIPs in the past.

[Music] Hello and welcome back to Penney where we dive into Ethereum improvement proposals and protocol development. This is episode 149 brought to you by ECH Institute. I'm your host Puja Randan and today we are going to discuss one-of-a-kind proposal EIP723 network upgrade inclusion stages.

EIP723 was documented in June 2024. This is a meta that is currently in last call status and the proposal has been partially tested with Pectra upgrade. It's close to being made as a standard since this is a new way of doing things. Some of the community members may still have some questions about how it works, what it means for Ethereum upgrade process. To help explain it clearly, we are joined by Tim Beo who helps Ethereum's all core dev calls and he's also the author of EIP723. Tim, welcome again to PE. Thanks for having me. We are super excited to have you here and so thankful for your

time. I understand you have been coming on penip time to time to talk about different proposals and share the latest upgrades. So I understand there are lot of activities ongoing over past few months. We have seen a lot of effort going into improving Ethereum's governance and lot of development of processes around that. EIP7723 is one example and there have also been some discussion happening on fellowship of Ethereum magician around the all core of process improvements. So in today's conversation we would love to better understand the network upgrade inclusion stages and if time permits we'll also explore few of other ongoing process improvement efforts such as ACD

process. So for all who are new here Tim if you could uh kindly share a little bit about yourself how you got involved with Ethereum your journey so far and what is that you are most excited about for 2025 and 2026 yeah well first of all thanks for having me again big question to start with so what I do today is I run the alcore devs calls for Ethereum um I also work at the Ethereum foundation and help with a lot of things around client development grants events and different programs to support core devs whether this is like the protocol fellowship or organizing interop events. So I do a lot of just core dev related work. I got into Ethereum actually working on one of the

core clients. So I used to be a product manager working in tech and I loved Ethereum but I didn't want to work on any of the specific applications at the time. This was in 2016 2017. I felt like they were all quite speculative and a bit too risky for me to join. So I wanted to work on improving the protocol but there was no kind of product manager of the protocol. That role didn't exist. So I spent probably like a year or so just you know trying to think of different roles and learning solidity and applying to a bunch of places and getting rejected. And eventually I got lucky that consensus put together a new client team which is now the basu team and they kind of structured it like a

normal tech startup with product managers and engineers. So I I got a full-time job there working as the product manager on the Basu client on the mainet implementation. When I joined the Basu team, they had just finished implementing the kind of first version of the client. So it worked as an archive node, but it was extremely slow. It was not performant. Um so even though it passed all the tests and it it conformed to the spec, it wasn't something that you could actually use, you know, in production quite well. And so I spent two three years there effectively working on a bunch of performance features and at the same time as that continuing to support the different hard forks and EIPs. So through that I got quite involved with the alcore devs process. At the time

there weren't many people attending a core devs call that weren't just core dev engineers. So I was one of the few kind of product managers or or more like process-minded people there. I spent a lot of time just helping Hudson who was running these calls since uh pretty much Ethereum's launch around a bunch of Ethereum project management stuff and then in 2020 Hudson decided to step away. So he'd been running the calls for over five years and I decided to take over from him and focus on that. So that's what I do now.

You had been modest enough to not mention that you are actually kind of running the entire ecosystem right now because everybody who is trying to follow Ethereum protocol must be following all core dev calls and hurting core developers is challenging. Thank you for battling that very well for us. Well, I understand for today's proposal you have been trying to document the process here. the process that you think could be useful for managing network upgrades which is one of the core activities around process management for Ethereum. So I'll be curious to hear your thoughts. What motivated you to formalize this as an EIP the network process into a proposal? Yeah. So

there's always been this weird tension between EIPs and hard forks where EIPs are meant to be these standalone documents that can be used in any context but at the end of the day they are very coupled to like the core Ethereum network right so even though other blockchains might use EIPs and obviously there's test nets and those change you know most people when they think of the EIP process what they care about is like this EIP is going on Ethereum mainet and so you know how should this be like included or proposed or whatnot? And historically we only had like a very like casual way to signal to signal that. So we have kind of these formal stages to the EIPs themselves,

you know, like a draft review, last call, whatever. And these correspond to the level of finalization of the spec. So is this proposal actually final or or not? But it's kind of independent from whether it's adopted on the Ethereum mainet. you can have a proposal that's, you know, final that never gets adopted and it just means you have a spec that's complete. And similarly, a lot of the most uh important changes we've made to Ethereum and including the ones we're doing now, like take Purdue as an example, there's still a lot of heavy iteration on the actual spec and EIPs as we work on this even though we agree that this is a thing we want to put in the next hard fork. And so historically what we would do when like I started

participating awkward devs is we would have like this one stage like included. So we would look at all the possible EIPs that we could include and then we would decide which ones to include and that would be it and we would implement them. And the problem with this is we would just spend so much time kind of debating and deciding and and trying to get to the final step that we just waste like tons and tons of cycle without actually knowing like okay of these like 25 proposals which one do we actually want to spend a bunch of time reviewing which one do we want to implement and prototype and then which ones do we want to ship on mainet we would try to do all of that at the same time and it was very hard to coordinate and one reason why this is hard to coordinate is there's

many different client teams, right? So, if you did all of this with one team, it would already be hard. You know, imagine there's 30 proposals. You need to figure out the 10 you want to spend time on and the five that you actually want to ship. If one client team is doing this, it's already quite hard. But if you have 10 different client teams doing it at the same time, that it means that when you go from 30 to 10 in that first like triage stage, maybe not everybody agrees and people are like reviewing different things. And then when you're asking about EIPA, not everybody's reviewed it because some people were looking at EIP B. And then similarly when you get to implementing and you want to test these features in the clients, then you know maybe client one has implemented EIPs A and B and client two has B and C and

client three has C and D. And so it's really hard to get everyone moving together in the same direction. And the last part of context here is nothing is ever final or like fully included on Ethereum until it ships on mainet. Like we have many cases in Ethereum's history of just finding an issue with a feature and removing it you know right before shipping it on mainet and this is the right process in a way because when we deploy an EIP on mainet we can't ever take it out right like the the blockchain has to keep it forever so we have to be extremely extremely sure about it but before the only stage we had was called included and so that kind of implied like oh we this thing is going to go to mainet even though in

practice a lot of didn't we also didn't have a good way before to say no to EIPs and this has been a problem in the past on awkward devs where if you know the person who's pushing the EIP has a lot of incentives to be very vocal and and you know very like pushy for it every time and the core devs they kind of just want to say no once and not think about it or even if we know that something is a priority even just reviewing something can be hard and you know then people have like this expectation that cordv should review every single EIP. But if we just do this blindly, then it means a way you can stop the entire process is just submit a bunch of EIPs for quarters to review and and kind of argue with

them. So to kind of address with all of this, the idea with 7723 is that we should have some stages that just correspond to what part of the hard fork planning schedule an EIP is in. And this is independent from the status of the EIP like whether it's a draft or in review but it's more about how close is it to be on maintenance. So happy to go into the details of the different status but I can stop there if there's any questions or clarifications before. Well the why part has been very well explained. We will get into status versus stages and would like to explore more about how it happens. So if you can maybe uh walk us through different EIP stages and maybe provide an overview and if there is any specific minimum

criteria to be considered into that particular stages right yeah okay so I'll start with the stages at a high level and then we can go into more depth but so the idea of these hard fork stages is that we want to again map this process between someone has an idea for an EIP on Ethereum to something has been shipped on mainet. So the first stage of the process is called propose for inclusion. And this is also something that we we used to do very poorly. Before we didn't have a formal way to track which EIP which EIPs are actually proposed by the community. It's been done in kind of ad hoc ways where you know people would post it on the awkwards agenda.

Sometimes we would use E magicians. Sometimes it was like a GitHub issue. So, so the first step was saying like if you want to propose an EIP for a hard fork, there should be a clear place and this is the proposed for inclusion status. So, every hard fork today has a meta EIP associated with it that tracks all the EIPs. And for the proposed for inclusion status, anyone can go open a poll request and just say here's my EIP. I would like to propose it for this hard fork. And one thing to note about all of these statuses is they're all only applied to the a specific fork, right?

Like so right now we just shipped the Petra hard fork. We're working on Fusaka. We're going to start planning Glamsterdam soon. So people can go and propose something for Glamsterdam. But it doesn't mean that it's proposed forever. It's really within the context of that work. And so for the propose for inclusion status, basically the only thing that you need is an EIP that's been merged and that has a number. So there's very low bar there. And obviously we want to keep this open and we want to allow the community to participate there. Then when we have this entire list of proposed EIPs for inclusion, we want to get a sort of short list for core devs, which is what are the EIPs we think might go into this fork. And the way that we've developed these forks historically is with what we

call these dev nets. So devets are effectively just a private Ethereum network that's run to test some new EIPs and we just spin it up and then shut it down when we find bugs over and over. And so every fork we usually run through like about you know 10 of these devets. And so we we have this next step in the process which is called considered for inclusion. And this is the list of EIPs we think could go onto Ethereum and that will probably be implemented in DevNet. And so when we get to that stage core should generally like the overall concept and idea of the EIP but there might still be some design or implementation issues to figure out. And this is where we expect there to be more

testing support provided and you know we start actually looking into like what's the testing coverage we need what kind of implementations we need and whatnot and then after that sequentially the other status in the IP can go is scheduled for inclusion and the scheduled for inclusion status means we want to implement this in the very next devet for this hard forge and back to my earlier point about having all these different teams working different EIPs. One thing that's really important is that we sequence the work so that teams know like there's 10 EIPs we might want to do in this hard fork. Here are the next two that we're doing in the next two weeks because this way we can test

you know those two EIPs, have everybody working on them and you know test all the crossclient interoperability and things like that. And generally this allows us to prioritize a a bit better where we can say, hey, of these 10 IPs, these are the two that should really make it in. So we're going to schedule those for inclusion first and we're not going to schedule anything else until we've implemented these two and we're confident that like they broadly work. And so at the scheduled for inclusion stage, this is where we want to have test coverage for these EIPs. We want to have full implementations and and again this is like the set that we're comfortable pulling either in the current or the next devet. So scheduled for inclusion means we want to implement this in the next devnet or the current hard fork and this implies that not

everything that's in the considered for inclusion list will actually make it into the fork. Generally the way we schedule these forks is there's a core feature we want to ship you know say for Fusaka it's pureas. So when pure is ready you know we'll move from devets to actually deploying it on test nets and whatnot. And so it means we're not going to be adding more new eips into the spec. And so the scheduled for inclusion status again like represents those dev nets and and one nuance that's worth noting there too is we explicitly named it scheduled for inclusion and not included to reflect the fact that even late in the process you know it is possible that an EIP gets removed from a hard fork for a whole host of reasons.

Obviously, the more you kind of go through this funnel, the less likely it is. But this is something that is really important to convey that nothing is final until it's actually deployed on the Ethereum mainet. And so, the last stage in our process is just called included. And this only happens when the fork has been activated on mainet. It's kind of a retroactive looking stylus saying these EIPs were actually deployed on mainet in this fork. So, that's the entire kind of flow. There's one status that I missed there which is decline for inclusion. And the idea of decline for inclusion I kind of touched on earlier is a way for core devs to say no to an EIP for a specific hard fork. So you know when we have this list of proposed EIPs at some point we have a deadline to

like make choices of which EIPs we want to CFI and SFI. And so anything that's been proposed but that wasn't CFID effectively gets declined for inclusion. And this again only applies to the current hard fork. So an EIP being declined for this fork just means it was not the priority now. It doesn't necessarily imply that it's a bad EIP. There's a technical problem. And also it shouldn't imply that core devs reviewed it or had like a a strong opinion. Like it's possible that for a fork we say that you know these three IPs are so important we don't want to do anything else. We can decline everything else.

And it's important that we don't have a pressure that like core devs need a really good reason for it because then you can again you can just spam the core devs effectively and require like a really good reason for decline for inclusion whereas the thing you actually want to do is to work on the the most important EIPs. So that's kind of why we have the status there is like a way to say for the purposes of this fork we're not doing this. It doesn't mean people have to stop working on these EIPs. doesn't mean we're not going to do it in the next fork, but it just means that for his current fork, we're not considering it anymore. Well, that's thoroughly explained. I believe some people may had questions earlier like, you know, why so many stages? Why not just have simple consider for inclusion in or out, but

you have explained each of these stages PFI, CFIs and SFI and variable. So, I'm sure that there is an answer that people may have received by now. I'm curious a little bit uh more about two stages here because you mentioned that these two include devets. I'm talking about consider for inclusion and scheduled for inclusion. What would you say is the key difference between these two stages? Considered means we want to do this if we have the time and bandwidth scheduled should mean we are implementing this in the next and it's by default going to go to mainet. So you can think of it as just like a pipeline, right? Like where anyone can propose things and then

there's a subset that we consider more seriously. Of that subset, there's a smaller subset that we decide to implement and test thoroughly and schedule. And then ideally 100% of those make it in, but that's not always the case. So when the fork actually activates, we go back and we say these ones included or deployed on mainet. Um, so it's really just like a a refinement at each stage with kind of a higher bar and and more constraints. It definitely looks like uh DevNets factors a lot into these inclusion stages. I'm curious what happens when an EIP that is added as scheduled for inclusion fails during uh one of the DevNet testing. Yeah, it

always depends on the specifics in the EIP, but we should be open to removing it. And the way I think about this is there's almost like two types of EIPs. I use the word headliners because like if you imagine a music festival and you have like a headliner that's announced at the music festival. If the headliner has to cancel, you probably reschedule the music festival, right? But if you have a bunch of other support acts and they cancel, you still have the festival. There's just less people playing. And I kind of think of EIPs in the same way where which each fork we typically have a headliner you know say for Fusaka it's pureas you know forcun it was 4844 and whatnot and then when that headliner is delayed we should probably just fix the

bug and continue working on it because we've agreed it's the most important thing to deliver but for all the other EIPs if there are issues we should be very willing to just remove it and and kind of reconsider having this EIP in the form And that's kind of the the subtlety there where like we're not committing 100% to include it. And it's possible as well like if we find something that's bad enough with a headliner, maybe we should also remove it and ship something else. But in in general, we would bias towards making sure the headliner actually gets shipped. Obviously trying our best to get the small EIP shipped, but if the small EIPs become so complex and so burdensome that they delay the main thing, we should consider removing them

quite actively. I think Ethereum devs have been creative enough to think of ways of removing proposals if that is not working as expected. We have actually seen a an upgrade in which when a proposal was actually taken out. We have St. Petersburg upgrade. So that was kind of removal of a proposal and we have also seen examples of proposals just coming out of the upgrade list right before the mainet. Yeah. And this is actually a really good point uh that might not be obvious to most listeners is it's not trivial to remove EIPs from hard forks and it's also prone to bugs.

We've had bugs on the Ethereum mainet because we've done a poor job of removing EIPs in the past and so when we get the scheduled for inclusion like we should consider removing things if they're problematic but it's not something that we can just like flip a switch and do it because all the code is in the client. oftent times these EIPs relate to each other. So and then all the test is kind of built with all these EIPs working together. So when we remove things we need to make sure that the removal is also bug free and that's not a a trivial exercise. So that's kind of why we want to get to the scheduled for inclusion stage and have very high confidence that these EIPs are good that they're already well tested and and that

we know what we're going with. Ideally, you know, it's it's only in like fairly exceptional scenarios that we have to to remove something from that. That's true. Yeah, it is exceptional. And the best part here is people are open to ideas and open to do whatever is needed and required at the time. So that makes us feel way safer here. Very well. Switching gears to the editorial review of it. Um we understand that anyone can make a pull request to update the meta e like any author of proposal can make appeal. If it is other than the author of that meta EIP or the ECD coordinator, how can an EIP editor verify that a decision has been made by client teams before merging the PR into the upgrade

meta e? I guess they have to watch a call but yes in practice it's usually me helping these PRs or people you know who follow the calls very closely right maybe we can try to add an additional mandatory clause there that if you are proposing this as a result of some decision that happened in all core dev meeting please site a reference of that we know and that's usually what I do when I propose them I'm not super precise about it but I'll say in you know all core devs number 209 we agreed to add EIPs A, B, and C to consider and I'll at least link the call agenda and then people can review that. I'll also usually try to get a couple thumbs up on

the PR from core devs before it gets merged so that it's not just me going and silently making all these changes to the fork. Well, this question was more for when it is not you. We were just trying. Yeah, I I think I would use the same process, right? like I tried to reference when a decision was made and then try to get some confirmation from other people than the PR author about the specific decision and yeah then the editors obviously have to exercise their judgment. Absolutely. So under this new network upgrade inclusion process how do you see meta EIP getting evolved like will they become more of a road map or do you think it is more as a checklist for an

upgrade? I actually think we should do a much better job of meta EIPs and more than partially this is in large part on me. Historically, we've treated them more as checklists and I'm the main author. I think I've had like a good sense for every fork of what is the thing we're trying to prioritize and we discussed this in awkwards but it the meta EIP doesn't quite reflect that. So one direction I would like us to go towards is to have the meta EIP be a much more well-reasoned and well articulated document explaining why are we doing this in this fork like why is pure das the priority in Fusaka why was you know for4 the priority in this other fork and and yeah I think that would be good for the community so that they can come and see like okay this is the the

fork where we're trying to do you know we're trying to scale the amount of of blob space or we're trying to like improve performance to scale the gas limit on the execution layer and I think like yeah having the metaip a bit more verbose and that would be good and then even better I think part of the process improvements that I' that I proposed is it would be nice for us to first have a highle conversation about what the goal of the upgrade is independent of specific EIP before kind of getting into the weeds right now the way it works is more like there's an entire list of proposed EIPs and oftentimes as part of that there's like the most important one and a bunch of small ones and we kind of do it all at the same time. So I think it would be a bit cleaner if we could

say what's the most important thing we want to do in this fork. Why is this important? You know why does this matter to users? What what is like the impact both positive and negative and say okay so if we want to do this then this is the best EIP for it that's like our headliner for this fork. this is why we picked it and then once we have that decision and everyone's on the same page about it we can figure out like okay what are the small features we want to add alongside it that's something I'd like to see evolve in the process I'm sure with your initiatives around process improvement we are going to see it is going to be way more structured in future but I have a follow up on meta eS you know that after activation both core and non-core EIP evenformational ones

are listed as included. Given that EIP1 definesformational EIPs as optional, doesn't including them in meta contradict their purpose? I'm wondering if you would be open to excludeformational EIP to be added as an required section of the proposals. Yeah, I see why that's kind of technically correct. I do feel like it's valuable to present to the community what is the highlevel contents of the forks and why and we shouldn't expect them to have super deep context around like the minutiae of the EIP process. You know, in this specific case, I think we should probably be more willing to revisit our

definitions of categories and different types of EIPs to like suit the process than to try and have this nonobvious meta EIP that's really hard to understand just because it fits with all of our constraints. This is something I haven't had the time for it, but I do think we should try to rethink a bit more like the EIP process and the different categories of EIPs and how they actually fit with what we ship on mainet because like you said like you know metaipformational EIPs are kind of being used in a bunch of weird and different ways and maybe we just need different types of categories to think about this stuff better where like we should have you know consensus critical changes, we should have non consensus critical changes or you optional versus

not optional and maybe like EIPs that are more descriptive like these hard fork metas and EIPs that are more like about the specific issue. So I lean towards like rethinking the EIP categorization to match the process. And the reason for this is I think the process generally works in that Ethereum ships these upgrades. The software is generally safe and it works. So I feel like we should make the EIP process work for like the actual hard forks are trying to routed in the other way around. Yeah, I'm in favor of having the mention of information EIP on the meta e suggesting that it is there. But I was just uh curious about keeping it in the required section because

againformational EIPs cannot be required only core can be required because without that the proposal won't work. So that's general thought process there. I have one more question on the stages here. So all these stages can we consider these as unidirectional and if so what happens when something is declined? Uh decline should definitely be final except in like maybe some small like exceptions like the whole point is we want to stop talking about it for this fork and so maybe it could come back but generally we should expect it to be final. For the other stages, I would kind of see it as a pipeline where you get, you know, from proposed to considered to scheduled to included and

then if you never if you don't make it to the next stage, you just go to declined every time. So that would be my rough model like it's just a pipeline like you have to go from proposed to considered to schedule to included and then yeah, anything that gets trimmed every time goes to declined. Decline is pretty final for this fork and maybe in some exceptional circumstances you bring something back. Yeah. Right. So more or less these are unidirectional and if it is declined it is declined at least for this upgrade it is and same yes and same also for like CFI and SFI like we shouldn't be bringing stuff back and forth like we should decide okay are we going to consider this for the fork yes is it going into the next devet yes or no but then if it's gone in the next

devet it's like sfied maybe in some exceptional cases we could realize like it wasn't quite the right pick and like put it back in CFI or something but generally if it makes it to sfi I either it's going to be included or it's going to be declined. It shouldn't like go back one stage. I don't think that specific case has ever happened but maybe it it could right there was this discussion of like uh on decline like when we are saying that when an EIP can be declined for one upgrade but it may be again proposed for the future upgrade. We have seen it with the EUF with um Pas and proposals like that. So there was this proposal of changing the

name to deferred for inclusion. I'd be curious to hear your thoughts why or why not you think deferred for inclusion could have been a better term instead. I don't think deferred is a good term because it implies it will eventually ship and I think that's not the default case for most EIPs. Most EIPs just are not going to be added on the Ethereum mainet. If you look at just the raw numbers, I don't know how many EIPs there are, but there's high hundreds of EIPs that have been written and there's low dozens at most that have been shipped to mainet. So most EIPs will be declined and that's okay from Ethereum's perspective. We shouldn't try to fit

every feature forever. And I think it's also good to be clear with the authors and the champions and those VIPs about it. The other thing as well is I don't think awkward devs can actually give good commitments or good like directions past one or two hard forks. So even you could imagine the opposite where it's like should decline have be be valid forever, right? Like once we decline it once, why would we want to consider it again? and and and I think there it's like things change a lot and and the ecosystems evolves and it's possible that we do bring stuff in that we previously thought was not a priority and and actually in this current fork pectra if you look at the EIP that's in PCRA there's like two or three EIPs that are quite old there most notably I think

the BLS pre-ompile EIP 2537 this one must have been declined from like three or four hard forks already and it was never because people thought BLS was a bad idea but it was more because they thought it wasn't technically ready there. There were just other priorities and stuff like that. So, I think, you know, it's a good example of saying we had the CIP many times. It was not a fit in those forks and it would have been totally fair for people to stop working on it if they're like, you know, people are not going to do this. But every fork we did open the door for it again and we test the situation and the progress made since the last fork and whatnot. And this fork, we we ended up shipping it.

Of course, I agree. there are multiple criterias to be considered while we are selecting proposals for an upgrade. So that may not be the best timing for it. There are higher priorities as you mentioned. Uh we should not give up on good proposal. I always recommend it to all authors that you need to stick around. If the timing is right, the proposal is good. It will be included sooner or later. Very well. I'm just trying to take a step back here and understand about the overall process. In your mind, what metrics do you think should we use to measure the success of this process? How do we say that this has actually improved our network upgrade selection criteria or the process? That's a good question. I think one thing that's hard with metrics here

is the thing that matters a lot is the quality of the decision rather than the quantity. Like it's possible that for some hard fork, you know, doing one EIP is the right decision and for the other one doing 10 EIPs is a decision. So I couldn't tell you like the number of SFI EIPs is the right metric. Maybe like off the top of my head, something I would look at is for every fork, what does the funnel look like? You know, like how many get proposed versus how many get CFI versus scheduled versus included. And it would be healthy if proposed is much bigger than CFI. CFI is bigger than SFI and SFI is pretty close to included and I don't have like a a rough like percentage or something like that but if

if it didn't look like a pipeline like that it would tell you something is wrong. I think the other thing that I would look at is just like the delay to come to these decisions. So the other part where the process is helpful is instead of arguing over an EIP for six months can we just DFI it and say we'll discuss it in the next fork. So the the kind of deadline between the first call for proposals for a hard fork and you know the final set of EIPs should hopefully get shorter and that would be a sign that at least the process is working. The thing that would be hard with that though is it's so little data points right every fork can be kind of unique but in like a year or two once we have more runs at this you would hope

that this kind of shrinks. Yeah, to me those would be the two, but I think they're kind of less important than whether we actually make the right decision for what goes in and that's a harder metric to measure. Yeah. Right. And I believe when we are considering this metrics with respect to network upgrade, it will anyway give us a longer duration because we can see the frequency of an upgrade between 6 to 8 months or 9 months. So we will get to know and realize if the process is effective and maybe next two to three years with whatever data point we can collect and try to analyze the situation. Yeah. All right. Uh I think that uh concluded my list of questions with respect to proposal 7723 in specific. Uh people on the call if you

have any question on this particular proposal please feel free to drop it in the chat and we will invite you to take the question. But Tim since I have you here today if it's all right maybe let's touch on another big topic that you have recently proposed the proposal to restructure the all core dev process into ACDE DC and DT so what do you say is the specific pain point you are hoping to solve with this restructuring there are a lot of pain points I'm hoping to solve but I think if I had to distill it it's just better clarity of the different stages kind of like what we've been discussing. And the reason why this is important is just because there's a lot of different peoples

participating in this and you kind of want to give them clear guidelines of where and how to interact. And so at at the high level, the first part of the process is saying we should separate planning the fork from implementing the fork. And we've already kind of done this. So we had these testing calls that have gone on for years now where you know we get very much into the weeds of like which PR is going into which EIP and what's the status of the death nets and whatnot and we discussed this a bit on awkwards too but we do a lot of it on these these testing calls and so the idea is to elevate these testing calls a bit more and say like this is the main place where we discuss the current hard fork you know once we have a scope once

we have a set of EIPs and we've agreed on like what we want to do this is where we discuss like the implementation of And then this means all core devs, the ACDE and AC/DC calls that currently exist should be more focused on scoping the next hard fork. And then back to what we we discussed a bit earlier around the meta EIPs. The idea is that if we create more space in a core devs for this, we can actually have like a higher level conversation around what is the purpose of this fork, why do we want to do it, what's the most important thing, align on that and then get that sorted in advance while we're implementing the next fork. And another part of this that's quite important is that I think historically we've done too little to bring the broader Ethereum

community into a core devs. Obviously, like some people contribute. We've had different teams from the community like push EIPs through, but it's always felt like very much them coming in and fighting this uphill battle to get their thing in. I would much rather move all devs to a model where we kind of actively solicit their input and we try to figure out like what is the most important thing for the Ethereum community as a whole right now, not just what the core devs think, you know, they want to work on for the next six months. And again by having like more space effectively in awkward devs I think we'll we'll be able to do that a bit better. So the high level process separation would be ACDE and AC/DC are used to debate like what is the high

level goal and and kind of scope for the next hard fork and then ACDT this testing call is used to discuss the current implementation details and and spec changes for the current fork. Well from where I see I find it like very structured approach. I remember the era of 2019 when the focus was on decoupling the EIP process with the network upgrade process. Now we have a structured network upgrade process and plan and we are going forward with this planning and implementation decoupling of of a particular upgrade. So kind of uh proceeding forward with right approach here and I believe we can get into the granular description of all these stages with the individual team. So sounds

generally good to me. I'll be curious to hear your thoughts on the role of communication within this complex ecosystem because I feel like you know when people are not informed there are a lot of confusion and that could be one of the reasons for the delay in decision making that we do here. Yeah, I agree. We need to do way more in communications. I used to do more of this and just got busy with other stuff and I think we need more people. Also, Nixo recently joined our team at the EF and has been great with this, but I think we need to do far more. I think we also just need to do a better job of describing how the process works. We've started adding some stuff in the PM repo around this, but again, we're quite far from complete there. My hope is like

over the next year, we're able to not only align on the process, but describe it in a way that's like broadly understood by the community. Yeah. Maybe along the line if I can pick your brain around the ideas or initiatives such as Penney playing a role in the ecosystem. I think people deep is actually very good to like provide deeper dives in a more accessible way to the ecosystem. But I think the thing that we should not delegate like to people is just basic documentation and like you know articulation of the process. I feel like for those things we want to have like a canonical place whether it's EIP1

whether it's the PM repo or whatnot that just lists out how things work and then pipe is great conversations like these where we can go deep into the nuance and and subtlety of it but the average person shouldn't have to watch pean to understand how awkward work but ideally the people who are like really into this and want to contribute or stuff like that you know they have more resources like this one that are available for them and that kind of help them on So yeah, I really see PDF as just like an extension of something, but I don't want to use it as like a crutch and just say, "Oh, because I went and sat down with PA to talk about this for an hour, now we don't need to explain how any of this works anywhere else." Very well said. So we'll keep that in mind. I

understand uh BEN is kind of educational resources as you mentioned to get deep dive into it and there are other stuff in place which we can make use of. I see a question here in the chat. by Justin Florine. Justin, if you would like to read the question. Sure. Uh, it's just a curiosity actually. Tim, you made a point earlier talking about we have ACDE, AC/DC, and ACDT. How much longer do you think the ACDE versus ACDC distinction remains useful? Yeah, that's a good question. I think it's actually slightly more useful in a world where we have ACDT handling the current fork. I do think we need a call every week at

least where everyone's expected to show up from every client team and we can't like block because we're missing some consensus team or some execution layer team and I think ACDT should be that call where we expect every team to be there to show up and to be able to like address issues that come up. I think if we have a longer term view for ACDE and AC/DC, it's actually kind of helpful to have like domain separation where if we want to talk about, you know, reducing slot times as being a core feature of the next hard fork or delayed execution on the execution layer, then you don't necessarily need every consensus layer dev there to debate the specifics of, you know, different ways to do delayed execution, nor do you need EL devs to

debate the specifics of of the slot time. I do think you need like some overlap as we're kind of specking out the high level goals for the fork. But maybe a way to think about this is you kind of need n participants from all the client teams on acdt or like a smaller number of participants from all of the client teams on their layer of the call and maybe like a subset of each layer on the other calls. Like it's always helpful to have EL devs on ACDC and CL devs on ACDE because some stuff does does kind of go across these boundaries but but we shouldn't expect like most of the those teams to attend like the call that's not for their layer whereas we should kind of nudge as many people as

possible to be or like teams to have everyone with the required context at like ACDT. I'll also say just having two people even if we split ACDE and ACDC Yeah. and we we merged them and they were the same. I do not want to run the call every week. I think having two people and we have Mario and Perry for ACDT as well. Like that feels super valuable just from like one a sanity perspective but two also like a risk mitigation perspective and a bunch of other reasons. So I yeah maybe like the distinction over time should blur. I think in the short term it's still useful but I don't think we want like a single person who runs like the entire series of calls. Thanks Tim. I expected

some nuance in that answer and you delivered. Appreciate it. I have my last question before we jump into the rapid fire round. Tim, you have been part of Ethereum ecosystem for very long time and we really value your suggestions. So looking ahead and thinking about Ethereum's road map, do you have any advice for nontechnical contributors or for us at Ethereum cat herders on how we can better help the Ethereum ecosystem grow? Maybe like my first level advice would be like the non-technical binary is probably wrong.

I mean look to take you as an example Puja you have all these interviews with literally every EIP author including Vitalik multiple times. I also joke like you might be one of the person who's interviewed Vitalik like the most because he writes so many EIPs. So I think like maybe my number one like meta advice would be like to not think of yourself as non-technical or that being like a major blocker. Like there's always different degrees of technical. Like I have like a computer science degree. I'm not a professional engineer. Like I don't write code for a living. I could not write code in any of the clients. And you would not want like a smart contract that's secured by me. But I'm still able to like reason about the technical implications of some features.

And in part, this is just because I'm like interested in them and I spend time trying to understand it. And you know, the more time you spend, the more you're able to understand different parts of the stack. I I think that would be maybe my advice is like you have to find some part of the protocol or the community or whatever that you're interested in and then try to understand as much of that as possible and explaining it to other people is a great way to understand it. So to the extent that like cat herders leans into that, yeah, it is an extremely valuable resource like to both the people producing it because it helps them understand what these things actually do and why they're important, but also to new people coming into the community where you know for a lot of people it's easier to listen to someone

talk for an hour on a podcast than to go and open the Python spec. But I don't think you should be like afraid to go and open the Python spec. I'd also say that like the recent like progress in LLM has been wild for this just like I've done this a ton like I work mostly on the execution layer you know I follow the consensus error stuff but I don't review every PR to the specs and then just being able to copy paste you know a file from the spec and GPD and be like what does this thing do or is this thing possible like you know with the spectra hard forks I had a bunch of weird questions about like some consolidation scenarios and like is this possible is that possible And being able to have like the LLM explain to me like yes, this is possible

because of this line in the spec or no, this is not possible because of this check has been really helpful. So yeah, my overall suggestion would be just like find the thing you're interested in, dig deep into that and don't try to like box yourself as non-technical versus technical. Yeah, that's a very good piece of advice here, Tim. Thank you so much and thank you for all the kind words. It's really valuable coming it up from you that the content that we are creating here makes a lot of sense for people. Yeah, I can relate like I have a technical background in a sense like I did my technical courses but not active coding. So it makes sense over there.

And I would also like to share this piece of information which was shared by a load start. He was originally not from the technical background meaning he did not do his undergrads in computer science. he was from a different domain but he is still contributing to Ethereum. He's a part of it. So if it interests you, there is never too late to join the ecosystem. Yeah. And one good piece of advice I've heard kind of related from this is when you're new to Ethereum or even to a part of Ethereum, right? Like you're trying to learn something new, there's always going to be some sort of resource you wish would have existed and and didn't. So that's a good way to find like if you're looking to make a non-technical or like more educational contribution, think of it as

what is the thing you would have wished to have to learn when you tried to learn this thing and and and because you're probably not the only person with this question and and there's probably a lot of people who are not learning this thing just because this resource doesn't exist. So like writing the kind of explainer that you wish you would have had is a good way to get started. Yeah, that's a very good way to put it in. Well, that kind of conclude most of the question answered. Tim, we have one more round for you which is called as rapid fire [Music] round where we try to collect your response in one word or one sentences.

We'll try to get it done in a minute but uh if it is longer that should not be a problem. Just try to answer what comes to your mind. Okay. Your favorite Ethereum upgrade so far. Kaga. The next big thing in Ethereum, I was gonna say Fusaka again. Yeah, I'll say Ethereum scaling. Most underrated EIP as per you. I'm blanking on the number, but Justin, you might actually know this one. I think is it 2124? The handshake for the peering on the execution layer. It's very neat.

Yeah. So, I I think it's 2124, but anyways, there's an there's an EID, a fork ID. It's 2124. Yeah. So, it's nice because one, it's useful. Two, it's conceptually simple, but then three, the implementation is slightly more complex than you would think from a first glance, but extremely well like detailed and explained. So, I think if you actually wanted like if I was sending someone like their first EIP to understand like how EIPs work, it's it's like a great one because it works really well at different levels of depth. And I've never implemented it. So maybe when you implement it, there's like some neat things there too. But I like like why the feature exists and then that it's actually has a bit of quirks in it, but

that it's so well explained in the EIP that it yeah, you feel like you learn a lot. And the good news for people who may not have known about this proposal, we already have recorded an episode to explain this proposal. The episode number is 30. So please go and check it out. We'll try to add the link here in description. The next one here is hardest allcore dev call you have hosted. I don't know about the hardest like there's been a lot of hard ones. One that I do remember one of the first I've hosted was the call where we agreed what we would do with Praguepow and kind of the path forward there. And I remember it was during ETCC and that was still on like Fridays. So it was like Friday night in France for me. So I remember

that one being particularly hard but also kind of nice because we did come to a resolution and then wrapping up my week in Paris after HCC. So it's kind of a a nice contrast of like relatively hard call but then we got to a conclusion and it was the weekend in Paris. Propa was altogether a different subject. Yeah. Very well. My next question is your favorite word as on date. It could be a feature, it could be an upgrade or anything related to maybe crypto Twitter. I feel like the thing I use the most frequently is the smiling and swelling emoji. So that would be it.

Right. Yes. What is the biggest governance pain point? I think fundamentally it's like an unsolvable problem and so you kind of have there's no clean solution so you kind of have to just muddle around. There's a good book about this. I think it's called like slouching towards utopia. And the idea is there's a lot of people they come up with these very like top- down fancy governments frameworks. And this is for the real world. It's not for crypto. And and they often result in just like tyrannies because like the real world is much more messy. And a lot of the like better outcomes we see in the world are just this like very iterative like complex like a bit unsatisfying process.

but it just at each step kind of tries to do a bit better. So that's like I think the fundamental problem. It's like you you have to like slouch towards utopia, but it's harder and less motivating and intellectually satisfying than it would be to just design the perfect governance system. What's more fun facilitating all core dev call or documenting a proposal? Oh, running the calls. Like I really love running the calls. Yeah, like I I get really excited from it when like they go well. It's like one of the best feelings. I think it's extremely stimulating. So yeah, running the calls over pretty much anything in my schedule is the most fun thing by If it has to be a word, what would that word be that you

wish more people use in these Ethereum meetings? I think the word no. I think I understand why people don't do it as much, but it's very there's like an asymmetry a lot in all core devs where if you want to push for some things, you're very incentivized to say like yes, yes, yes, and let's do this. And then if you say no, you're kind of the bad person. And and it's oftent times like when somebody voices an objection, my intuition is like many many more people feel that same thing. And so having more people willing to like shoulder that burden would be good. It would also make it less demanding on like the the people who currently do.

It's a very hard thing to do and I don't know that you can like actually train people to do it or get them to do it. Like sometimes I joke about this with people. It's like can you tell people to care more? Like you can you can tell them the words, right? Like you could say care more but it you can't quite like get them to care more, right? there's like a sense of just either people tend to have this or or not. So I that would be it. It's like if people are more willing to step up and say like actually we think this is bad for these reasons and not to derail the entire process but to make sure that we don't succumb to just people aggressively pushing stuff because it's in their interest to do so and then nobody wanting to like argue with them and the

outcome is that we we do the thing that everyone silently think was thinks was a bad idea. My first instinct was that your answer would be yes, but you very well explained no and why no. No. Well, my last question for you here today is Ethereum in 2030 what it would be like. Very hard to predict. I think I was actually re reflecting on this early this year. Ethereum in 2020 was like at this really interesting spot where me was starting to be a thing. L2s was starting to be a thing. we started to have a vision for like how the merge would go and whatnot and but none of this was quite sort of set in stone but we I think in 2020 we kind of knew what

all the big important things would be maybe we didn't realize how important they would be but they were kind of starting to show and then that ended up being what we we worked on for the past five years I feel like we're in a similar spot today like we have a sense around like global adoption we have a sense around what uh cryptography is going to be possible we have a sense around like these kind of endgames in terms of me, in terms of staking economics, we don't quite have like a fully fleshed out vision yet. And so my sense is all of these kind of complicated rapidly moving topics that we that are not the main thing we discussed today, but kind of in the background of all of the conversations will be the things that like we end up

studying the next five years on. Very well done, Tim. uh you answered all the question and you really spoke your mind. So thank you so much for answering all these questions. Of course, this is great. Very good questions. Tim, thank you so much for joining us and helping clarify the network upgrade inclusion stages through EIP723 as well as sharing insights on the all core dev process. These conversations are so important as Ethereum keeps growing and changing and we hope this helps the community stay informed, get involved and contribute to better decision making. Appreciate your time. Thank you so much for having me.

Dear listeners, if you enjoyed this episode, don't forget to subscribe and share. You can find the EIP and discussion thread in the links show note below. Until next time, keep building, keep reviewing, and keep perfecting the Ethereum ecosystem. Cheers.