From Draft to Inclusion: A proposal’s Journey

Transcript

[music] Hello, my name is Chihun. I'm a research engineer at the Ethereum Foundation. My role is bringing forefront research ideas into production serving as a liaison between researchers and developers and [music] I'm also recently became a big country inspect maintainer. So this talk is about what it t what it takes to ship an EIP. I'm going to walk through the process from the practitioners perspective. Um, some EIPs go smoothly, some EIP is contentious, but I do hope this talk could give you some the sense of what what's it like to proposing a changes uh to Ethereum.

So, let's take a look into how it makes changes to Ethereum. Ethereum protocol is evolving. It has a governance process that decides what goes into the protocol. Governance can be either onchain or off-chain. Onchain governance is when protocol changes are decided by onchain voting typically by uh governance token holders. Whereas in offchain governance, a process of social social discussion makes decisions and the decisions are imple implemented in code later.

Ethereum has adopted offchain governance. Roughly speaking, when you have an idea of proposing some change, you want to write it as a proposal. You want to discuss with as many people as you can to flesh out your idea. Uh you're going to use writeups, Ether Discord, ETH research, Ethereum magicians or Twitter signal or whatever to share and discuss your idea. And then you're going to write an EIP. How to write an EIP is a different topic, but there will be a talk regarding that. So, please check it out later.

Now, let's say that you want to advocate for your EIP. Um, we call those people EIP champions. As an EIP champion, you want to demonstrate that the proposal is valuable for Ethereum, technically sound and reasonable, and has higher priority than others. uh we decide which proposal to implement in all core devs call it held every Monday and Thursday at 14 UTC is open for everyone so you can present your proposal there uh you should be able to find a GitHub issue under the Ethereum PM repo you can leave a comment there about what you want to discuss during the call and if the moderator finds it relevant to the call then you will have

a chance to discuss So if everything goes well and people approve your proposal, it will be included in an upgrade. Of course, there are many back and forth and iterations, but we will jump into it later. So that's the overview. Now let's say that you have your EIP prepared. Uh you've done lots of research. Uh you went through the EIP review process. You got your EIP number. You shielded on your Twitter. You got many likes. Great. Now you are in the beginning of your journey. Writing an EIP is a definitely good milestone, but it's like you are at

5% there. So idea doesn't talk itself. You want to have people learn about your EIP and then convince them to include it in a fork. uh if your change is small or not contentious then it could go smoothly but it might not always be the case. People are not always agree with you. Uh people might be too busy to take a look into your proposal. Uh people might just misunderstand your proposal. So you probably want to share some writeups or Twitter threads that capture the gist of your proposal. You could also do podcast. uh you can answer answer many

questions in the discord. You probably going to find yourself repeating the same things over and over again. So you better be prepared. And sometimes people come to you and say, "Ah, I broke your design." But actually when you look into that, that's actually on top of your FAQ. Sometimes people give you like great feedback but sometimes people just don't like your proposal but they cannot come up with why they don't like it. So there are many cases but in any cases uh you should be able to convince yourself to in order to convin uh convince other people.

So you will have to communicate with people a lot. You want to reach out to different uh stakeholders such as researchers, client developers, application developers, staking communities, L2s builders, you name it. You basically want to have them on your side to back your proposal. Then you need to listen to them and if if they're not uh pro for your proposal, then you need to figure out why and solve it. Uh so basically you should be able to answer the question of why do we need it? Is it is it valuable? Uh does it have to happen now? Is it forward compatible?

Getting various feedback and having more eyes on your EIP will make it more robust. You might find some bug. You might learn something you haven't really thought about. Uh for example, I've been working on fossil and we didn't know about we could use fossil as a a force inclusion mechanism for L2s. That's what we learned down the road. Um it might sound intimidating if you have to reach out to all of them but as you talk with them they will connect you with other people and sometimes people just come to you um so you know every journey begins with a single step.

The last point that I want to talk is although it's not strictly necessary uh there are many EIPs that are included without it but having specifications and client implementation could go a long way. It is probably the best way to demonstrate the technical readiness of your proposal and all core devs is um as the name suggests is for core devs and sometimes developers uh find it easier to read code rather than reading a um conceptual paper and especially if you are proposing um closer to the deadline and people want to see if your proposal is mature enough. Uh so in that case providing a spec implementation could be

a good answer but in reality it doesn't always work out. So people might find other EIP more important and more urgent than yours. Uh yours might turn out to be just nice to have. For example, uh some some people might support your EIP because uh it would pave the way for their favorite EIPs and something they want to achieve. But somehow things get changed, a new idea came up and they don't want your AIP EIP anymore. Things happen um and sometimes um proposals get gets killed in a later stage. Uh it could be because

some edge case is found that could invalidate the whole design. Um for example EIP7547 is a formal version of enclosure list to fossil. Uh it was killed because there was a case that it could hold um when there is some interaction with account abstraction transaction or some previously unknown issue cames up and it um delays the fork more than enough and that could be escalated to a deal breaker unfortunately.

So be aware that even if it's scheduled for a fork, it is not the end until it's end. So that was pretty much what I prepared for today. Formulating your idea into EIP uh building the cons community consensus and if it's scheduled for an upgrade uh you still want to keep your eyes on it. Some unknown issue might um might appear and people will come to you to ask for something because you are the one who knows all the history.

Um so it might take it might look like a lot to take in but all cordfall is open for everyone and if your idea is a good idea people will recognize it and there are people including myself who are working on Ethereum for full-time and you can always collaborate with them. Uh so Ethereum is an open source open source and I would encourage you to uh contribute to Ethereum and thank you for your listening.

[applause] So we have got another four minutes. If there are any question if not then I would hope that you guys should consider taking a look at fellowship not fellowship of ethereum magician but also the research eth research forum and consider being an author and helping us out. All right we are around and we we are I guess 3 4 minutes ahead of time. So if there are any question or anything that you would like to know about the

process, please raise your hand. Hello. I've been out of the process for quite a while, but the numbers start creeping high and we're in the 7,000s. There was a long time ago discussion of once we get past 10,000, do we do like 11 xxx is going to be for a particular sort of change and 12xx will be another and we'll divide up that way. Uh what's the development been? Is this just like we're going to soon get EIP 13,055 and it's just going to be the same as like 14,55 and it will just be chronological. um the GitHub repo situation like what's the uh movement there

>> from like the past five years or the evolution of this if that's fine. >> All right, I think I can perhaps take this one. So earlier so earlier the way we used to allocate EIP number was based on the pull request and that's how we reached to the number that we do not have those number of EIPs as we have number of uh P um number of PRs that's right yeah so we have stopped it actually we are now going sequentially so you would not be able to get a special number just by making your entry in the pullup GitHub pull request as like very special number. No, that's

not how it works anymore. So the way it works right now on today's date is like you have to make a pull request. We have a team of course editors allocate uh the PR numbers but we do have people who are helping out. They are called associate editors. They will take a look. We are trying to get it done in next 24 hours after your PR is there and that's how you are getting the number. We are in process of making this process automated. So we don't need intervention of auditor or the associate auditors. But while we reach there this is the present process and yes we are not going to get a huge number for EIPs very soon.

Thank you and any more question we have two more minutes. I can perhaps take one more. Hey June, um, what would you say has been the most troublesome part of your entire journey to pushing Fossil and how would you go about recommending to fix that?

>> All right, Phil, it's a good question. Um, just give me a moment. There are a lot >> the the best one. >> The best one. Um I would say uh the moment we SFI sorry CFI fossil I mean the moment before we did it uh like in the Berlin interrop uh when we we as in like people who've been working on fossil asked people around like what do you think about fossil do you do you want to ship it and then the response was like nearly I would say like 98ish people

were like great we want fossil we want censorship resistance it's important but it turns out that it may not be true like because of priority for cadence complexity um I get that because like you know things always changing and people always change your their opinion because they learn something new every day uh there was kind of a little bit of a surprising news for me because I thought that uh there will be no huddle for fossil to get in still is struggling and we don't know how it how it's going to be like after like two weeks for example and your last question would be how can we um how would I recommend to um amend

it um honestly I don't have a good answer to that question um if you want to try to tackle it then we need to define like what the problem is like do we agree that that's a problem? Um yeah, I think many many things boils down to um coordination across different stakeholders who measure things in uh uh in different values and I'm not sure to be honest >> maybe if that is of uh any comfort. I have seen proposals getting out of upgrades list just a day before the

upgrade goes live. So this is not the end of the journey of an proposal. We could see more proposals getting in and there are possibilities. Sometimes we give a break to a proposal assuming that either the proposal is not fully ready or the team is not fully ready to implement that proposal alongside of many other proposals which are getting in. So I would like to wish you all the best. We would love for you all the work that you have done here and we hope that we could see it in the next upgrade. Thank you Jihan. >> Thank you Puja.