Ethereum, an open-source project, offers the possibility to propose, discuss, and track new ideas for systems operating on the Ethereum EVM via Ethereum Improvement Proposals, abbreviated as EIPs.

What is an EIP?

EIP stands for Ethereum Improvement Proposal. It is a design document used by those who want to add new features to Ethereum or processes that will take place on Ethereum to explain their purposes and provide information to the community. A brief technical specification of the proposed feature and its rationale should be addressed explicitly. The person/s or company/community preparing the document is primarily responsible for creating a consensus within the community and documenting the defense of their proposed ideas against the demands of opposing views.

Rationale for EIP

EIPs are intended to serve as the primary mechanism for proposing new features, gathering community technical input on a topic, and documenting design decisions that enter Ethereum. Since EIPs are maintained as text files in a versioned repository, they are historical records of the idea and evolution of the feature proposal they contain.

For those in the Ethereum ecosystem who implement these standards, EIPs allow for structured tracking of application progress. Ideally, each implementation lists the EIPs they implement, allowing end-users to more easily track the current state of the application.

EIP Types

1. Standards Track: This type defines any changes affecting most or all Ethereum implementations. Examples of such definitions are:

• A change in the network protocol
• A change in the block or transaction validity rules
• Proposed application standards/conventions or any change or addition that affects the interoperability of applications using Ethereum

Standards Track EIPs are divided into 3 and these are as follows:

• Design Document
• Implementation
• An update to the formal specification (if necessary)

In addition, Standards Track EIPs are divided into the following sub-categories:

• Core: A sub-category used for fundamental development or for operations related to consensus. An example of this can be given as EIP-225.
• Networking: A sub-category where the network protocol specifications of Light Ethereum Subprotocol, swarm, and whisper are included. An example of this can be given as EIP-8.
• Interface: A sub-category that includes proposals regarding API/RPC usage, contract ABI definitions, method naming, or interface usage. An example of this can be given as EIP-6.
• ERC: A sub-category where application-level standards are defined. An example of this can be given as EIP-20.

2. Meta: This is a group where EIP proposals classifying the definition of a process surrounding Ethereum or a change in a process (or in an event) are categorized. Meta EIPs are like Standards Track EIPs but apply to areas outside the Ethereum protocol itself. It is a proposal that does not process in Ethereum's codebase but generally requires community consensus. Unlike Informational EIPs, these are not proposed as recommendations, and users are expected to take them into account. The items subject to this proposal are as follows:

• Procedures
• Guidelines
• Changes in the decision-making process
• Changes made to the tools or environment used in Ethereum development

3. Informational: A classification that generalizes proposals that do not contain a new feature addition but provide a design problem, general guidelines, or information to the community. Since Informational EIPs do not represent the community's consensus or a recommendation, users and implementers are free to ignore or follow their advice.

It is strongly recommended that a single EIP contain a single key proposal or a new idea. The more focused an EIP is, the more successful it will be. A change in a client does not require an EIP; they are defined when there is a need to define a standard for multiple clients or for multiple applications to use.

An EIP must meet certain minimum criteria. It should have a clear and complete explanation of the proposed improvement. The proposal should represent a clear improvement. The feasibility of the proposal should be solid if it is to be implemented, and it should not complicate the protocol unnecessarily.

EIP Processes

The standardization processes for EIPs are as follows:

• Idea: As the name suggests, it is a pre-prepared idea. This idea is not tracked within the EIP Repository.
• Draft: This is the first stage of a developing EIP that is officially trackable. When an EIP is properly formatted, an EIP Editor merges it into the EIP repository.
• Review: When an EIP Author matures their proposal, they mark the EIP as ready and request a review.
• Last Call: This is the stage where there is a final review for the proposal before it moves to the Final stage. An EIP Editor will assign status change for Last Call status and set a review end date (last call-deadline). A 14-day period is usually chosen for this stage.
• Final: Represents the final state where the proposal will be standardized. An EIP that has reached its final state is in a state of finality and should only be updated to correct errors or to add non-normative clarifications.
• Stagnant: Any EIP in Draft Review or Last Call states is moved to Stagnant status if they have not been active for 6 months or more. An EIP can be moved out of Stagnant status by its Author(s) or Editor(s) by moving it back to Draft or a previous state. If this is not done, a proposal can remain in Stagnant status indefinitely.
• Withdrawn: The EIP Author(s) has withdrawn the proposed EIP. In this case, this EIP number can no longer be revived. The idea presented as a proposal can be presented again as a proposal with a different number at a later date.
• Living: This is a special case for EIPs that are designed to be continually updated and do not reach a state of finality.

NOTE: You can access the EIP-1 source, which explains the purpose and usage of the EIP structure by Ethereum, from here.

SOURCE:

1. Ethereum Improvement Proposals(EIPs)