This does not represent a Standard Operating Procedure (SoP) for Ethereum upgrades. This is a personal account of how the Ethereum upgrade process works

If you’re on the app layer, totally separated from Ethereum core development, and have fundamental frustrations with the L1 protocol, this post is for you.

Once the Pectra network upgrade goes live, attention is going to be turned to Fusaka (the next network upgrade) and you might think: how would I get a proposal into a network upgrade? How would I write it? How do I begin to even think about addressing an L1 problem as an app developer?

There’s some criticism in the Ethereum community that core developers are too separated from the app layer and there’s validity to that claim. As many programmers tend to, core developers can get hyper-focused on their niche, especially knowing that so much value depends on their finding and addressing bugs before release. But they often don’t even know how each others’ clients work. And because the core development process is, first and foremost, making sure these client software can talk to each other with whatever features are going into the next network upgrade, their voices tend to naturally dominate the All Core Dev (ACD) conversation and make it somewhat intimidating to see where you can fit in.

The good news is that the Ethereum community has communicated this shortcoming - core devs & researchers are listening and facilitating solutions that address the situation. One such frustration is L2 interop(erability) - standards, liquidity, and UX across L2s needs to get better now. To that end, a group of L1 researchers & core devs and L2 researchers & core devs have directed their attention to L2 interop and IRL events to bring together L1 and L2 developers to hash out solutions.

But back to the point - how do you get this attention on the problems that you as an app developer experience? Here’s how I see the process - and this isn’t an official process™️ - it’s just how I’ve seen it work in this governance model we call rough consensus.

• Find others who are similarly affected by the issue that you experience. If you’re an L2 app developer, even better if they’re across different L2s. Write up explainers about it. Gather feedback from those who are affected. If it’s a widespread frustration, it might be a good candidate for a proposal

• You’ll need to brainstorm a fix, but you don’t have to do it alone - you can start off by looking at EIP-1, which describes how the EIP (Ethereum Improvement Proposal) process works. Knowing the process can help you approach the problem with a framework for a solution

• Does it need to be an EIP? It should only be an EIP if it absolutely must be a protocol-level change. Maybe what you need can be handled at the application layer with an Ethereum Request for Comment (ERC) or Rollup Improvement Proposal (RIP) - these will be faster processes as you don’t need to wait to be included in a network upgrade

• Bring that conversation to the appropriate category on Ethereum Magicians. If you don’t know exactly what the fix for the problem is, this is the place to flesh it out! This is also where you can gather feedback to ensure it truly is necessary at the protocol layer

• When you have a draft for your EIP* (using the template), you can submit it to the EIP Github repo as a pull request. You can check out old examples of newly proposed EIPs here. You will also need to create a discussion topic in Eth Magicians and an EIP editor / associate will assign your EIP the next sequential number

  *scroll down to “writing an EIP is daunting” for tips on getting an EIP written

• This is where it’s important not to let momentum drop off - you need to educate the appropriate people about your EIP. If there’s strong support behind it, it’ll be easier to get included into the process! The people who need it should be willing to publicly put their support behind it. Write posts explaining the benefit and costs of the EIP and share them and your Ethereum Magicians discussion widely!

• If you’re technical (or know someone capable), you can implement a proof-of-concept on at least one client or client pair. u/sm3gh34d points out that EIP-1153 languished until it had PRs to clients

• Once you have general consensus from the community that:

• Propose it for a specific network upgrade by opening a pull request to add it to the Proposed for Inclusion section of the Upgrade Meta EIP (which is the EIP that lists all the EIPs going into the upgrade)

• Prepare a short (~5 min) presentation with slides to explain to client teams why it’s important to implement, what it does, who it affects, and what kind of due diligence has been done to make sure it doesn’t break things

• Then ask to add the EIP to for the agenda of the next appropriate ACD call (depending if it impacts execution or consensus layer).  This can be done in the open issue for the meeting & make sure to include your slides.  Client developers may choose to wait so they can review all of the Proposed for Inclusion EIPs for a network upgrade in one go

• Attend calls relevant to this! There are all kinds of breakouts on different topics both within the pm repo and outside of it (e.g. L2 Interop, RollCall, CAKE) and the best way to make sure your EIP doesn’t fall off the radar is to go to the relevant calls

• Keep up the momentum! Educate the community about it and keep the public updated on the EIP’s progress

I know what you’re thinking at this point:

If you lack the funding to dedicate time to this process, there are a ton of public goods funding initiatives that will fund exactly these sorts of things. If your proposal benefits L2s, check out Optimism, Arbitrum, Polygon or Base for grants. If it benefits a wide variety of app developers, check out Gitcoin, Octant or the EF’s Ecosystem Support Program (EF-ESP).

If you don’t feel like you’re the right person to brainstorm a fix, that’s okay! You can stop at the first step. Gather feedback, write up explainers, talk to people who might be able to bridge the gap of knowledge in order to come up with a solution. Sometimes the right people to figure out the solution to something is a different group than the ones who experience the problem.

Jason Chaskin at the Ethereum Foundation just started a series where you can get your experiences in front of some core devs, researchers, and those in the EF in a private call. It was kicked off with Patricio Worthalter at POAP, who spoke of his issues with the L1 and roadblocks he’s encountered while building on Ethereum and it was very illuminating for those who attended.

To help you draft an EIP or if you have questions about the process, there’s a regular EIP editing office hour hosted by the Ethereum Cat Herders (ECH). And if this is your first EIP, I suggest reaching out to someone who’s written one before for some advice or mentorship!

Ethereum is a new type of technology and the cadence and norms for these upgrades have just recently been established and rapidly evolved along the way.

Coordinating the upgrades around decentralized software that has millions of participants, tens of thousands of developers, and hundred of core protocol developers is a new situation to navigate. With an enormous amount of increased interest in getting features into the network upgrades in the past few forks, it has become clear that the current process has its strengths and weaknesses in choosing which features get prioritized and which do not.

As the ACD calls have gotten relatively quiet while the final Pectra feature set is implemented, tested, retested and tested again, core developers and protocol supporters are now taking the time to talk about what can be done better in the process. If you want to follow along or contribute to the conversation, check out Tim Beiko’s thread on Ethereum Magicians.

I know this can be a frustratingly long process. As Ethereum’s value, relevance, and number of involved parties increases, the more difficult it becomes to get consensus across the majority. Whether or not this is on our way to protocol ossification and subtraction of human intervention is a matter of discussion. This is the nature of decentralized governance & “rough consensus” and the tradeoff we make to get a credibly neutral platform on which to launch our apps.

Thank you to Phil, Andrew, & Paul for feedback 🤗