How Change is Managed with Ethereum

There is no central authority that controls Ethereum. Its very nature is decentralisation which is also one of its core values. No single company controls Ethereum. So when changes are required to evolve the product, there is no chief executive officer or benevolent dictator to facilitate such change.

Ethereum has instead adopted an open source type approach for managing change. Anyone can propose a change, whether it is a technical standard or a change to a core function. These changes are proposed through “Ethereum Improvement Proposals” (“EIP”).

The acceptance and adoption of an EIP depends upon community consensus where the community consists of developers, client teams, validators, applications, infrastructure providers, and end users. The process can take months or years depending on what sort of change is proposed.

An EIP is a formal technical proposal with a lifecycle. EIP1 is the first EIP to have been proposed and it includes a description of the specification document to be submitted as an EIP. It can be used to add new transaction formats, define token standards, modify gas behaviour, improve wallet compatibility, add cryptographic capabilities, as well as introduce account abstraction mechanisms.

Some well known examples include ERC20, the fungible token standard, EIP1559, when the fee mechanism was changed, and ERC4337, the mechanism used to introduce account abstraction to Ethereum without a fork.

EIPs are sorted into three main categories: Standards tracks, Meta, and Informational. Standards tracks is then further broken down into the following subcategories: Core, Networking, Interface, and “ERC” (“Ethereum Request for Comments”).

The Core category includes changes to Ethereum protocol rules. This can include consensus, gas rules, transaction processing, opcodes, and precompiles (which are discrete pieces of logic used to reduce gas costs). These are the hardest to implement because the teams building the Ethereum clients must agree to them.

Networking includes changes to the peer-to-peer network or node communication. These can also be hard to implement since they would need to be adopted by clients or validators depending on the nature of the change. These are changes to the layer of communication that is internal to Ethereum.

Interface changes are those that affect how a user connects to Ethereum through the “RPC” (“Remote Procedure Call”) or “API” (“Application Programming Interface”). These are changes to the layer of communication between external users and Ethereum.

ERCs are the best known of the Standards track and are easily identified by their use of the ERC- prefix instead of the EIP- prefix. These define patterns that standardise how information is presented or used in Ethereum. The most well known example is ERC20 which is the fungible token standard; ERC20 defines basic attributes and methods for tokens to ensure all tokens had the same behaviour such as the name, symbol and ability to transfer them to another wallet.

Some other examples of ERCs include ERC721, the non-fungible token, ERC1155, the token collection, and ERC4337, account abstraction. Standards contribute towards composability where smart contracts can be written to interact with other contracts, such as tokens, knowing that these basic features are always available.

The Meta track includes proposals to change the governance process, procedures, or workflows. These do not change Ethereum directly but instead change or describe a process surrounding Ethereum. EIP1 would be an example of a Meta EIP since it is a process for implementing change to the Ethereum ecosystem but does not directly affect the code base.

Finally, there are the Informational EIPs. These can describe a design issue, or provide general guidelines to the community; they do not propose any new features. Since they are informational, users and implementers are free to either ignore them or follow the advice.

Anyone can initiate an EIP, you do not need to be technical to do so (although some of the steps in the process rely on using technology like GitHub).

The first step, as with change in any system, is to identify a problem and a possible solution. These need to be discussed in an open forum so the community has a chance to provide opinions and feedback. The most common place to open a discussion thread is the Ethereum Magicians forum, EIP1 specifically recommends this website for starting the process. This is also a good place to look for any related changes to ensure you are not duplicating existing work (although you may have a better solution to the same presented problem).

Initial discussions can also happen in GitHub, research forums, or possibly social media but Ethereum Magicians is by far the most popular approach.

Once the idea has been vetted by the community, it can then be presented formally as an idea to reviewers. The EIP itself has been standardised and includes the following sections:

• abstract
• motivation
• specification
• backwards compatibility
• security considerations

The EIP is then submitted to an editor for review where the editor will check that it has been written in an acceptable format as well as review the discussion threads to gauge interest, before assigning a number and moving the status from idea to draft.

Draft status is the first tracked stage of the EIP. It can be subject to discussion and review but that is more likely to come from contributors rather than the general community. Once an author (or authors since there can be more than one) is satisfied that the change has been discussed thoroughly and ready to be discussed, the status can be updated to review. The review status marks the EIP as ready for and requesting peer review.

Once an EIP is in review status, then considerable review and discussion can occur. It may be challenged about concerns on security, complexity, decentralisation impact, user experience implications, or economic incentives.

The champion of the EIP, who is the lead author, has to ensure that raised concerns are either addressed or sufficiently mitigated. The presented solution could change considerably based on the feedback. Some feedback may even lead to the EIP being withdrawn if a weakness is detected or an alternative EIP is presented with a stronger model.

So the EIP can change considerably between its initial proposal and when it is finalised. It is quite normal in software development for requirements to change during the lifecycle of a project since not all impacts and effects may be evident in the early days of discussing change.

Some EIPs can be debated for years, many never progress.

If the authors/champions are confident in their EIP document and have addressed any concerns, they can then request an editor to update the status to last call. This is the penultimate status before finalising the EIP. It also sets a deadline for further reviews.

During last call, the champion may be required to join an Ethereum core developers call to defend the request. If any further changes to the EIP are requested, the status will revert to review. If, however, there are no more changes required and the specification is accepted, then the status can then be updated to final by an editor.

EIPs in a final status can only be updated to correct errata (spelling mistakes, incorrect references) or to add any clarifications. It is important to note that even if an EIP is in final status, it is still subject to a social consensus as to whether or not it is used.

Governance is by no means an easy task in centralised organisations let alone a decentralised model like Ethereum. Ethereum does not have a formal voting system, users essentially vote with their wallets; positive changes should result in better user experiences which ideally expands the community.

There is certainly influence in the governance of Ethereum. When well known figures like Vitalik Buterin submit an EIP, people will pay more attention but no one in Ethereum has absolute authority.

Coordination can be difficult and larger changes can takes years to implement. This is why planning post-quantum Ethereum has begun now with a 2029 deadline; the risk may not be there presently and it may not even be there in 2029, but it will take that long to adopt the necessary changes.

Managing change in a system that is not led by any one entity or individual but instead a community is always going to be slow and difficult. This is by design. Consensus is much more than just agreeing which transactions are accepted into a block.

How Change is Managed with Ethereum was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.