What is an Ethereum Improvements Proposals (EIP)?

The EIP or Ethereum Improvements Proposals, is a documentary structure that allows to standardize the development of improvements within Ethereum, allowing anyone to present their proposals and thus improve the development of this blockchain.

Unot of the most important processes within the development of Ethereum (ETH), takes place in the acquaintances EIP or Ethereum Improvements Proposals. These are technical documents in which the Ethereum development community makes its improvement proposals for this project. This is an idea that was adopted from the experience of Bitcoin (BTC), where there are Bitcoin Improvement Proposals (BIPs), which have the same purpose and which we have already talked about in Bit2Me Academy.

The reason for adopting this organizational model is due to the requirement of a high level of organization in decentralized development communities to manage and decide on the next improvements that will be integrated into the project. In this way, any developer can present an improvement proposal that will be discussed in the community, and depending on its impact, it may or may not be included within the Ethereum protocol.

For this, the developer of the idea must explain in detail his proposal, argue why its implementation in the project is positive, and clearly demonstrate its viability and impact. Hence, the creation of these documents is explicit and has a very clear and defined objective: to propose to the community the future of the project and give everyone the opportunity to discuss it.

Start of Ethereum Improvements Proposals or EIP

As we mentioned, the idea behind the creation of the Ethereum Improvements Proposals or EIP, comes from the experiences applied in Bitcoin. Let us remember that, in Bitcoin, the BIPs are intended to allow the community to show the rest of the members improvements that they want to include in the Bitcoin protocol. The idea of the BIPs was initially proposed by Amir Taaki, who designed the initial protocol to present them, creating the Bitcoin BIP-001.

Then the developer Luke dashjr, improved this idea thanks to his experience of development in free communities (especially, his experience in Gentoo GNU / Linux), creating the BIP-002. From that point to the present, BIPs have been the vehicle that has been used to include new enhancements within Bitcoin.

The idea was so successful that it was replicated in other cryptocurrencies, and Ethereum did not escape it. This is how on October 27, 2015, the EIP-001, created by Martin Becze and Hudson Jameson, two major Ethereum developers. In said EIP, the following title can be read:

EIP Purpose and Guidelines

That is, this first EIP established the general lines and the purpose of what the EIPs would be within Ethereum. In fact, his introduction could not be clearer in this regard:

EIP stands for Ethereum Improvement Proposal. An EIP is a design document that provides information to the Ethereum community, or that describes a new feature for Ethereum or its processes or environment. The EIP must provide a concise technical specification of the feature and a justification for it. The author of the EIP is responsible for building consensus within the community and documenting dissenting opinions.

EIP classification

As with Bitcoin's BIPs, Ethereum's EIPs respect a series of classifications that specify where the improvements they present are headed. In that case, the Ethereum EIP classification is divided into three classes that are:

EIP Standard

These EIPs are used to describe changes that affect most or all Ethereum implementations. Let's remember that Ethereum is a protocol, and its official implementation is given in the software Geth. But like this software there are other implementations like the one we can see in Hyperledger Besu. o Parity.

The improvements described in a Standard type EIP generally include changes in the network protocol or a change in the block or transaction validation rules. It also applies to proposed application standards changes or any changes or additions that affect application interoperability. Thus, EIPs of the Standard type are the ones with the greatest scope in the development of Ethereum.

Additionally, EIPs of the Standard type are divided into the following subcategories:

Basic- In this sub-category are EIPs seeking improvements that require a consensus change within Ethereum. A good example of these EIPs are EIP-005 and EIP-0101). However, those enhancements where the changes are not necessarily critical to the consensus protocol are also included. An example of the latter can be seen in EIP-086 and EIP-090.
Social: this subcategory includes improvements around devp2p (EIP-8) and the network protocol, this includes those improvements proposed to the specifications of the gossip protocol and Ethereum swarm.
Interface: This subcategory includes those improvements in the specifications and standards of API / RPC of the Ethereum client. In addition, the changes at the ABI and API level of the same are also included. A good example of these EIPs can be seen in EIP-006.
ERC- Application level standards and conventions, including contract standards such as; token standards (ERC-20, ERC-721 y ERC-1155), name registries (ERC-26, ERC-137), URI schemes (ERC-67), library / packet formats (EIP-82), and wallet formats (EIP-75, EIP-85).

EIP goal

The other classification of EIPs is known as Meta EIPs. These EIPs describe a process surrounding Ethereum or propose a change to it. These EIPs generally propose changes to an implementation, but not to the Ethereum code base. These often require community consensus, unlike informational EIPs, users are not free to ignore them.

A good example of this type of EIP can be seen in the changes of procedures and guidelines in the decision-making process and changes in the tools or the environment used in the development of Ethereum. Any Goal EIP is also considered a process EIP.

Newsletters

An informational EIP describes an Ethereum design issue, or provides general guidance or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or recommendation, so users and implementers are free to ignore informational EIPs or follow their advice.

How Ethereum Improvements Proposals or EIP works

The operation of the EIPs is clearly defined in EIP-001. This process begins with the process of generating the idea or proposal by the author of the EIP. At this point, the responsibility of development begins on the author, and it will be he who must present the necessary arguments to demonstrate the need for his proposal, as well as defend it. Because of this, the author of the EIP must create a clearly explained idea and present it in the body of the EIP, along with a justification and elements that support its presentation.

Thus, at this point we have the following stages:

How Ethereum Improvements Proposals or EIP works

Thus, at this point we have the following stages:

First stage: Presentation of the idea

It is the most basic and unpolished stage of an EIP. It is basically presenting the upgrade as a suggestion on the Ethereum forums. The objective of this is to obtain feedback from the community, to continue or not with the development of the proposal in a more elaborate way.

Second stage: Creation of the draft

At this point the idea is already embodied and executed following the organizational parameters expected from an EIP. It's an active, work-in-progress where you can submit follow-up requests with further changes to your draft to the point where you think the EIP is mature and ready to move to the next state.

Third stage: Last call

At this point the corrected draft becomes featured on the EIPS Ethereum website. The idea of this stage is to present the EIP to the greatest number of people within the community, complete corrections, and create a fully functional and revised implementation of the EIP.

Fourth stage: Acceptance

This status indicates that material changes are unlikely and Ethereum client developers should consider this EIP for inclusion. Your process for deciding whether to modify it on your clients as part of a hard fork it is not part of the EIP process. This status is only applicable to EIPs for core blockchain processes.

Fifth stage: Final presentation

This point represents a state where the EIP should only be updated to correct misprints. Additionally, other states can be marked such as:

Assets: In some informational and process EIPs they may also have a status of "Active" if they are never to be completed.
Cancelled: The original authors no longer seek to implement this EIP or it may no longer be a (technically) preferred option.
Rejected: An EIP that is fundamentally broken or a Core EIP that was rejected by Core Devs and will not be implemented.
Replaced: An EIP that was previously Final but is no longer considered cutting edge. Another EIP will be in the Final state and will refer to the Superseded EIP.

Format of an Ethereum Improvements Proposals or EIP

Of course the Ethereum Improvements Proposals or EIP, being technical documents, have a standard presentation format that clearly indicates all the information necessary to understand the improvement proposed by it. Thus we have that the EIP format contains the following lines:

Preamble. This is the introduction to the EIP. They are formatted following the style guide established by the standard RFC 822. This preamble includes all the basic data of the EIP, such as its number, its author, the name and a brief description.
Summary. At this point we will find a brief description (no more than 200 words) of the technical problem that is being addressed in the EIP.
Motivation. This point is optional and should only be mandatory in case you want to alter the Ethereum protocol. At this point, the author of the EIP must clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without convincing motivation at this point may be rejected entirely.
Specification. At this point the author of the EIP must create and explain the syntax and the improvement he is proposing. It must be clear and concise, demonstrable and reproducible. If the specification does not respect these principles it will simply be rejected.
Justification. The justification develops the specification by describing what motivated the design and why particular design decisions were made. It should describe alternative designs that were considered and related work. Justification can also provide evidence of consensus within the community, and should address important objections or concerns raised during the discussion.
Backward compatibility. All EIPs that introduce backward incompatibilities must include a section that describes these incompatibilities and their severity. The EIP should explain how the author proposes to address these inconsistencies. EIP submissions without a sufficient backward compatibility treaty may be rejected entirely.
Test cases. Test cases for an implementation are required for EIPs that affect consensus changes. Other EIPs may choose to include links to test cases, if applicable.
Implementations. Deployments must be completed before any EIP receives the "Final" status, but need not be completed before the EIP is merged as a draft. While the approach of reaching consensus on the specification and rationale before writing the code has merit, the “general consensus and code running” principle is still useful when it comes to resolving many arguments over API details.
Security Considerations. all EIPs must contain a section discussing the security implications/considerations relevant to the proposed change. Include information that may be relevant to security discussions, surface risks, and that can be used throughout the proposal lifecycle. E.g. They include security-relevant design decisions, concerns, important discussions, specific implementation guidance and pitfalls, a summary of threats and risks, and how they are being addressed. EIP submissions missing in the "Security Considerations" section will be rejected. An EIP cannot move to the "Final" state without a discussion of Security Considerations that reviewers deem sufficient.
Copyright exemption. All EIPs must be in the public domain.

Some Important Ethereum Improvements Proposals or EIPs

Although you can see all the EIPs hereHere we explain some of the most important EIPs.

EIP-606: Hard Fork Goal: Homestead

El EIP-606 it is an EIP of the Meta type. This describes all the necessary points to carry out the Homestead update on Ethereum. As it is an EIP of the Meta type, it refers to other EIPs that explain all the changes that will be made. In this case, the EIP-606 invokes the following EIPs:

EIP-2: Homestead Hard-fork Changes
EIP-7: DELEGATE CALL
EIP-8: devp2p Forward Compatibility Requirements for Homestead

Each of these EIPs individually explains the changes that will be made and together, they lead to the Homestead update.

EIP-20: ERC-20 Token Standard

El EIP-20 is perhaps one of the best known EIPs in the world of Ethereum since it was created to implement the well-known ERC-20 standard token. This development marked the beginning for Ethereum to create a standard tool to deploy tokens on its blockchain. As a result, Ethereum has become the blockchain with the most tokens that exists today.

EIP-137: Ethereum Domain Name Service - Specification

El EIP-137 gave birth to the specification of the Ethereum Domain Name system. From here, all the necessary infrastructure would be created so that Ethereum can become a gigantic domain name service (DNS) completely decentralized and focused on privacy. But not only that, it would also allow associating a readable address with a cryptographic address to receive and send cryptocurrencies with it. This work resulted in the ENS.

EIP-721: ERC-721 Non-Fungible Token Standard

El EIP-721 is another widely known EIP because he created the Ethereum non-fungible token standard, the ERC-721. From this token, projects such as CryptoKitties were born.

EIP-779: Hard Fork Target: DAO Fork

This is perhaps Ethereum's most controversial EIP. The EIP-779 He was responsible for "fixing" the problem of The DAO's multi-million dollar hack. To do this, EIP carried out a rewrite of the entire history of the Ethereum blockchain from moments before The DAO was hacked.
This with the aim of returning the stolen funds to their owners. As a result of the application of this hard fork, Ethereum was divided into two communities each with its own blockchain. The one that applied the patch (Ethereum) and the one that did not apply it (Ethereum Classic).

EIP-1155: Multi token standard

El EIP-1155 Also known as ERC-1155 token, it is an EIP of the standard type that seeks to design a new type of token, which brings together the capabilities of the ERC-20 and ERC-721 tokens in the same standard. In this way, ERC-1155 tokens have fungible and non-fungible properties.

EIP-1559: ETH 1.0 Fee Market Change

This EIP seeks to change the way commissions are handled within the network. For this, the EIP-1559 creates a commission burning mechanism that prevents Ethereum from having higher inflation, and at the same time, expands or contracts the ability of Ethereum blocks to include more transactions to decrease network congestion.